1. 从一条错误日志开始的故事
那天早上我像往常一样检查服务器日志,突然发现Nginx的error.log里出现了大量重复报错。最显眼的一条写着:"connect() failed (111: Connection refused) while connecting to upstream"。作为一个经历过多次线上故障的老运维,我立刻意识到这可不是普通的404错误,而是后端服务出现了严重问题。
这种错误通常发生在Nginx作为反向代理时,无法连接到配置的后端服务(upstream)。想象一下Nginx就像个尽职的前台接待,当它无法把客户请求转交给后台处理部门时,就会在日志里留下这样的"投诉记录"。具体到这条日志,我们可以看到几个关键信息:
- 客户端IP:172.12.23.44
- 服务端地址:212.65.12.29
- 请求的后端地址:127.0.0.1:8060
- 错误代码:111(对应Linux系统的ECONNREFUSED)
这个错误看似简单,但背后可能隐藏着至少五种不同的故障原因。就像医生看诊需要结合多种检查报告一样,我们排查这个问题也需要系统性的方法。下面我就带大家完整走一遍我的排查过程,这套方法适用于绝大多数Nginx连接后端服务失败的场景。
需要模型API调用? 免费领10W Token,多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 庖丁解牛:日志分析实战
2.1 解读日志关键字段
先让我们把这条日志拆解得更加细致:
bash复制[error] 2334#2334: *253268 connect() failed (111: Connection refused) while connecting to upstream,
client: 172.12.23.44,
server: 212.65.12.29,
request: "OPTIONS /yun//sys/menu/nav?t=1583288052697 HTTP/1.1",
upstream: "http://127.0.0.1:8060/yun/sys/menu/nav?t=1583288052697",
host: "212.65.12.29:8002",
referrer: "http://39.107.238.105/yun-web/"
每个字段都有其特殊含义:
- error:错误级别
- 2334#2334:Nginx工作进程ID
- *253268:本次请求的唯一标识
- client:直接客户端IP(可能是用户或上一级代理)
- server:Nginx监听的服务器地址
- upstream:Nginx尝试转发的后端地址
这里有个关键细节:upstream地址是127.0.0.1:8060,而server地址是212.65.12.29。这说明Nginx配置可能存在问题——当server是公网IP时,upstream通常不应该是本地回环地址。
2.2 构建排查决策树
面对这类问题,我通常会按照以下顺序排查:
-
网络连通性检查
- 测试从Nginx服务器到upstream的网络连通性
- 检查防火墙规则
- 验证端口监听状态
-
服务健康状态
- 后端服务是否正常运行
- 服
