分析 Nginx 错误日志以排查连接被拒绝问题
学习如何从 Nginx 日志中追踪连接被拒绝错误，定位到确切的上游服务、端口、套接字或网络问题。
分析 Nginx 错误日志以排查连接被拒绝问题
分析 Nginx 错误日志以排查连接被拒绝问题，可以帮助您从泛泛的 502 页面定位到具体的后端故障。“连接被拒绝”通常意味着 Nginx 尝试连接上游地址，但没有进程接受该连接。
这与超时、DNS 故障或错误响应不同。一旦识别出日志模式，您就能快速缩小修复范围。
“连接被拒绝”的含义
在 Nginx 日志中，常见的消息如下：
connect() failed (111: Connection refused) while connecting to upstream
这意味着操作系统拒绝了连接尝试。Nginx 已到达目标主机，但目标端口上没有进程在监听，或者连接被主动拒绝。
当 Nginx 代理到以下配置时，您可能会看到此错误：
proxy_pass http://127.0.0.1:3000;
但应用程序已停止或在不同的端口上监听。
此错误在部署后很常见。进程管理器可能未能重启应用，容器可能崩溃，或者新配置可能更改了应用端口而未更新 Nginx。
不要将每个 502 错误都视为连接被拒绝。超时消息指向不同的方向。权限被拒绝消息通常指向套接字或安全策略。确切的日志文本很重要。
找到正确的 Nginx 错误日志
默认的错误日志路径通常是：
/var/log/nginx/error.log
但服务器块可以定义自定义日志：
error_log /var/log/nginx/app-error.log warn;
如果默认日志没有显示最近的条目，请检查相关的 Nginx 配置。在某些系统上，服务级别的消息也会出现在系统日志中。
有用的命令包括：
tail -n 100 /var/log/nginx/error.log
以及：
journalctl -u nginx -n 100
测试时，在浏览器或使用 curl 触发一个请求，然后立即检查最新的日志行。这样可以更容易地将用户看到的错误与后端故障关联起来。
良好的日志审查应捕获四条信息：
- 失败请求的时间戳。
- 上游地址和端口。
- 请求路径。
- 确切的系统错误，例如
111: Connection refused。
有关更广泛的 Nginx 故障排除，请参阅修复 Nginx 502 Bad Gateway 错误。
将日志条目映射到上游
典型的日志行可能包含类似以下的上游值：
upstream: "http://127.0.0.1:3000/api/status"
这告诉您 Nginx 尝试将请求发送到何处。现在验证是否有进程在那里监听：
ss -ltnp
查找 127.0.0.1:3000、0.0.0.0:3000 或预期的地址。如果端口缺失，则应用未在 Nginx 期望的位置监听。
直接测试上游：
curl -i http://127.0.0.1:3000/api/status
如果此操作失败并显示连接被拒绝，则您已确认问题，无需 Nginx 介入。
如果应用在 Docker 中运行，请小心处理 127.0.0.1。从主机来看，它指的是主机。从 Nginx 容器内部来看，它指的是 Nginx 容器本身。在 Compose 设置中，Nginx 通常需要代理到服务名称，例如：
proxy_pass http://app:3000;
前提是两个容器共享同一个 Docker 网络。
对于 Unix 套接字，日志可能指向路径而不是端口：
upstream: "http://unix:/run/app/app.sock:/"
在这种情况下，检查套接字是否存在以及 Nginx 工作进程用户是否可以访问它。
常见原因和修复方法
最常见的原因是后端服务已停止。使用以下命令检查：
systemctl status your-app
如果失败，在重启前阅读应用日志。重启可能使网站恢复，但日志解释了失败的原因。
另一个常见原因是端口不匹配。例如，应用从端口 3000 更改为 8080，但 Nginx 仍然代理到 3000。修复 Nginx 上游目标或恢复应用的预期端口。
第三个原因是绑定到错误的接口。仅在 127.0.0.1 上监听的应用只能从同一主机上的本地 Nginx 访问。但如果 Nginx 在另一个容器或另一台服务器中运行，则无法通过该回环地址访问。在这些设置中，应用可能需要绑定到私有网络内的 0.0.0.0。
防火墙规则也可能拒绝或阻止连接，尤其是在跨服务器的情况下。如果 Nginx 代理到另一台主机，请确认上游端口在 Nginx 机器上已开放，而不仅仅是在您的笔记本电脑上。
最后，部署时机可能导致短暂的连接被拒绝错误。如果 Nginx 在新应用进程准备就绪之前发送流量，用户可能会看到间歇性的 502 错误。健康检查、就绪探针或优雅重启策略可以防止这种情况。
实用的故障排除流程
当日志显示连接被拒绝时，请按以下顺序操作：
- 从 Nginx 错误日志中复制上游主机和端口。
- 在 Nginx 服务器上使用
curl直接访问该确切上游。 - 运行
ss -ltnp确认有进程在监听。 - 检查后端服务状态和应用日志。
- 比较 Nginx 的
proxy_pass值与应用的实际绑定地址。 - 仅在配置正确且
nginx -t通过后重新加载 Nginx。
此流程可防止一个常见错误：在应用只是宕机时编辑 Nginx。它还可以防止相反的错误：在 Nginx 指向错误位置时反复重启应用。
有关命令基础，请参阅Nginx 日志监控命令。
何时寻求专业帮助
当连接被拒绝错误仅在负载下、跨多个上游或滚动部署期间发生时，请寻求帮助。这些情况可能涉及进程监督、容器网络、负载均衡器健康检查或容量限制。
如果上游是生产支付、身份验证或面向客户的 API 服务，您也应该升级问题。快速恢复很重要，但保留日志并理解故障同样重要。
一旦仔细阅读，连接被拒绝是 Nginx 中较清晰的错误之一。在日志中找到上游，直接测试该目标，并修复阻止 Nginx 连接的服务、端口、接口或网络路径。日志已经为您提供了起点。