关键在于确认连接是否被中间设备在空闲阶段主动切断：先通过日志区分是proxy_connect_timeout（握手失败）还是proxy_read_timeout（建立后超时），再用tcpdump抓包实测防火墙rst/fin时机，结合proxy_socket_keepalive与内核tcp_keepalive_time协同探测并规避静默断连。
排查网关防火墙策略导致的 Nginx 代理连接超时，关键在于确认连接是否被中间设备（如硬件防火墙、云安全组、WAF）在空闲阶段主动切断，而非后端响应慢或配置不合理。核心思路是：绕过 Nginx，复现并抓包验证真实断连时机。
确认超时是否发生在连接空闲期
先区分是“建立连接失败”还是“连接建立后无响应”：
- 若 proxy_connect_timeout 触发（日志含
connect() failed或Connection refused），问题在 TCP 握手阶段，与防火墙空闲超时无关，应查端口监听、路由、ACL放行 - 若 proxy_read_timeout 触发（日志含
upstream timed out while reading response），且请求已成功到达后端（可通过后端日志/直连验证），才需怀疑防火墙空闲切断 - 典型表现：同一连接首次请求正常，隔几十秒再发请求失败；或长轮询、大文件上传中途断开
实测防火墙实际 TCP 空闲超时值
不能依赖文档或经验，必须实测：
- 在 Nginx 与 upstream 之间无流量时，用 tcpdump 抓包：
tcpdump -i any host 10.0.1.100 and port 8080 -w firewall-test.pcap - 等待连接静默，观察多久后出现防火墙发出的 FIN 或 RST 包（非后端发的）
- 常见值为 30s、60s、120s；若抓不到明确 FIN/RST，可配合
ss -ti查看连接状态变化时间点 - 联系网络团队确认策略——有些防火墙对不同协议（HTTP/HTTPS/TCP）设置不同超时，需明确代理走的是哪条路径
检查 Nginx 是否主动探测连接有效性
仅调长 timeout 不能解决防火墙静默断连，必须让 Nginx 在断连前主动发现：
- 确保 upstream 块启用 proxy_socket_keepalive on Xs Ys Z（X 为空闲启动探测时间，建议设为实测值 −10s）
- 配套三要素缺一不可：
proxy_http_version 1.1、proxy_set_header Connection ''、upstream 内keepalive N - 验证是否生效：用
ss -ti查看活跃连接的keepalive字段是否显示计时器已启动 - 注意：该机制依赖内核
tcp_keepalive_time，若系统值远大于 Nginx 配置（如默认 7200s），需同步调小
隔离验证防火墙是否为唯一瓶颈
排除其他干扰因素：
- 临时关闭防火墙策略（测试环境）或添加精确放行规则（源 IP → 目标 IP:端口，协议 TCP，不限制 idle 超时）
- 将 Nginx 与 upstream 部署在同一局域网（甚至同一台机器），复现问题是否消失
- 用 telnet 或 nc 手动建连后保持空闲，观察是否同样被断——若会，则确认是网络层策略
- 检查是否有中间设备（如 SLB、API 网关）也设置了连接空闲超时，其值可能比防火墙更短
