服务打不开时，先别重装：从客户端到应用层的排障路径

先记录现象

“打不开”不是可以直接排查的描述。先记录准确时间、访问地址、客户端网络、错误文字，以及最后一次正常状态。不同现象通常指向不同层：

• 一直超时：数据包可能没有到达目标，或返回路径失败；
• 连接被拒绝：目标地址可达，但对应端口没有服务监听或被主动拒绝；
• 证书错误：TCP 与 TLS 已经开始工作，问题更接近主机名、时间或证书链；
• 502 / 504：反向代理可达，但它与上游应用之间有问题；
• 404：服务已经返回响应，应继续检查虚拟主机、路由或文件路径。

不要一开始就重装系统或重写全部配置。这样会破坏线索，并增加新的变量。

建立两个交叉测试

先用另一台设备和另一条网络访问同一地址。如果只有一台客户端失败，优先检查该设备的 DNS、代理、VPN、时间和本地防火墙；如果所有客户端都失败，问题更可能在服务端或共同链路。

然后分开测试域名与地址：

dig A example.com +short
dig AAAA example.com +short
curl -4 -I https://example.com/
curl -6 -I https://example.com/

这一步可以迅速发现错误解析，或只有 IPv6 路径失败的情况。

从外到内检查

按固定顺序推进，每一步都保留结果：

1. 客户端能否解析到预期地址；
2. 地址是否有可用路由；
3. 目标 TCP 端口是否可达；
4. 服务器是否在正确地址和端口监听；
5. 主机防火墙与上游安全规则是否允许；
6. Nginx 是否命中预期虚拟主机；
7. 上游应用是否运行、是否能从 Nginx 所在主机访问；
8. 应用自身是否返回正确结果。

在服务器上查看监听状态：

ss -lntp
systemctl --no-pager --failed

127.0.0.1:8080 与 0.0.0.0:8080 不是同一件事。先确认服务应该被谁访问，再判断监听地址是否正确。

读取日志，而不是猜

同时观察反向代理与上游服务日志，并用一个新的请求留下明确时间点：

sudo tail -f /var/log/nginx/access.log /var/log/nginx/error.log

如果 access log 没有出现请求，断点还在 Nginx 之前；如果出现 502，再查看 error log 中记录的上游地址与错误类型。若 Nginx 日志正常而应用返回错误，就继续查看应用日志。

日志可能包含公网地址、令牌、Cookie 或内部路径。复制给他人之前先去除敏感信息。

一次只改变一个变量

找到可能原因后，先做最小修改。例如怀疑防火墙时，只添加精确端口规则；怀疑 Nginx 上游地址时，只调整对应位置。每次修改后重复同一组验证，避免“好像好了”却不知道原因。

如果修改会影响在线服务，先保存配置：

sudo nginx -t
sudo systemctl reload nginx

语法检查通过不代表业务一定正确，但它可以阻止明显错误进入运行配置。

完成与回滚

问题恢复后，再从原始客户端、外部网络、IPv4 与 IPv6 分别验证，并观察一段时间的错误日志。记录：实际断点、修改内容、验证命令和恢复旧配置的方法。

一条稳定的排障路径，比记住更多零散命令更重要。它让每次判断都缩小范围，而不是把系统变成新的未知状态。