端口通只说明一件事：TCP 连接能建立。至于连上之后能不能拿到正确的页面，是另一层的事。

这就好比电话能打通，但对面没人说话。线路没问题，问题在人。

先看返回什么

用网站测速或者 curl 请求一下，看 HTTP 状态码：

  • 502 / 504：反向代理连不上后端，后端服务挂了或者超时
  • 503：服务在，但不可用，常见于过载或维护
  • 404：服务正常，路由或文件不对
  • 301 / 302 循环：重定向配置出错
  • 连接被重置：中间设备或 WAF 干预

状态码基本能把范围缩小一半。

反向代理配置

Nginx 监听 443 成功，不代表它能正确转发给后端。

常见问题：proxy_pass 指向的地址或端口错了、upstream 里的后端已经下线、Host 头没传对导致后端虚拟主机匹配失败、WebSocket 没配 Upgrade 头。

看 Nginx 的 error_log，通常第一行就写着原因。

域名解析

端口是通的，但你连的可能是错的机器。

域名解析到旧 IP、解析到 CDN 但 CDN 回源配置错了、本地 DNS 缓存没刷新，都会出现「能连上但内容是错的或打不开」。

用 dig 对比一下各地解析结果，或者直接拿 IP 访问试试。

证书问题

HTTPS 站点尤其常见。证书过期、证书链不完整、域名不匹配，浏览器会直接拦截，用户看到的是安全警告而不是页面。

端口层完全感知不到这些，因为 TLS 握手是在 TCP 连接建立之后才发生的。

应用本身

最后才轮到代码。数据库连不上、依赖服务超时、配置项缺失、磁盘写满，都会让应用返回 500。

这时候看应用日志比看网络指标有用得多。

排查顺序

先看状态码，再看反代日志，再查解析，再验证书，最后进应用。

从外往里一层层剥，比一上来就重启服务靠谱。