Nginx Worker 进程不主动处理转发失败，而是被动响应 upstream 错误并按配置返回状态码（如502/504），具体行为由 proxy_next_upstream、超时指令、error_page 等协同控制，日志需结合 access_log 与 error_log 定位。

Nginx 的 Worker Process 本身不主动“处理”转发失败，它只是执行配置指令、发起代理请求、等待响应并返回结果。所谓“转发失败”，其实是 proxy_pass 发起的上游请求出错后，Worker 进程按既定规则做出响应——这个过程是被动响应而非主动干预。

真正决定如何应对失败的，是配置中的一系列配套指令和错误处理机制。下面从实际运作角度讲清楚关键点：

Worker 进程遇到 upstream 失败时的默认行为

当 proxy_pass 转发请求给后端（如 https://www.php.cn/link/674da981bae2fc6b8cfc30c852bf4a14 进程会根据以下情况返回不同状态码：

• 后端完全不可达（连接拒绝/超时）→ 返回 502 Bad Gateway
• 后端返回了非成功状态码（如 404、500）且未配置 error_page → 直接透传该状态码给客户端
• 后端响应为空或协议异常 → 返回 502 或 504 Gateway Timeout

这背后没有“重试逻辑”或“兜底逻辑”，纯靠配置驱动。

Nginx Config Linter

对 Nginx 配置文件进行语法检查、验证和安全、性能审计。

下载

关键配置决定失败时的表现

Worker 进程的行为由这些指令协同控制：

• proxy_next_upstream：指定哪些错误触发重试（如 error timeout http_500 http_502），配合 upstream 块使用才生效
• proxy_read_timeout / proxy_connect_timeout / proxy_send_timeout：超时设置直接影响是否判定为“失败”
• error_page：可捕获 502/504 等错误，转到自定义页面或内部 location，例如：

  error_page 502 504 /50x.html;
  location = /50x.html {
      root /usr/share/nginx/html;
  }

• proxy_intercept_errors on;：启用后，才能让 error_page 拦截上游返回的 4xx/5xx（否则直接透传）

转发失败日志定位靠 Worker 记录

每个 Worker 在 access_log 和 error_log 中都会留下线索：

• access_log 里能看到状态码（如 502）、响应时间（- 或极小值）、上游地址
• error_log 里会有更明确提示，比如：
  upstream timed out (110: Connection timed out) while connecting to upstream
no live upstreams while connecting to upstream

这类日志必须结合 worker_processes 和 error_log level（建议设为 warn 或 error）才能捕获全貌。

不复杂但容易忽略