防火墙拦截导致Connection reset需通过日志特征、时间规律和网络验证交叉判断：集中爆发的recv() failed(104)、多IP多URL指向同一后端、后端无异常、upstream_response_time为“–”、系统/防火墙日志含DROP记录、tcpdump捕获非后端IP发出的RST包、nc/curl连通性失败等综合确认。
防火墙拦截导致的 Connection reset 并不直接写“防火墙”三个字，而是通过日志特征、时间规律和网络验证交叉判断。关键在于区分：是真实连接被中间设备 RST，还是后端或客户端主动断开。
看日志里有没有“集中爆发+无后端异常”的迹象
如果错误日志中出现大量 recv() failed (104: Connection reset by peer)，且满足以下条件，要高度怀疑防火墙或中间设备干预：
- 错误集中在同一分钟内批量出现，不是零散发生
- 涉及多个不同客户端 IP 和不同 URL，但都指向同一个 upstream
- 后端服务自身日志（如 Tomcat、Node.js）没有对应崩溃、超时或关闭记录
- Nginx 的 $upstream_response_time 字段为 “–” 或极小（说明请求根本没发到后端）
查系统和防火墙日志找 DROP 记录
Linux 系统上，防火墙拦截常会留下痕迹：
- 运行 journalctl -k | grep -i "drop\|reject"，看内核是否记录了丢包
- 检查 iptables/nftables 输出链：iptables -L OUTPUT -n -v 或 nft list chain inet filter output，确认是否有针对目标 upstream IP+端口的 DROP 规则
- 云环境重点查安全组/ACL 出方向规则——ECS、K8s Node 或 SLB 后端节点是否限制了 Nginx 到后端的出向流量
- 某些 WAF 或云防火墙会在 syslog 中写入拦截日志，路径可能是 /var/log/messages 或 /var/log/audit/audit.log
用 tcpdump 抓包确认 RST 来源 IP
这是最硬的证据。在 Nginx 机器上执行：
- tcpdump -i any 'tcp[tcpflags] & (tcp-rst) != 0 and dst port 8080' -nn -w rst_from_firewall.pcap（把 8080 换成你的 upstream 端口）
- 复现问题后打开 pcap 文件，过滤出报错请求对应的 TCP 流
- 若 RST 包的 源 IP 是非后端地址（比如是网关、SLB VIP、或一个陌生内网 IP），基本可锁定是中间网络设备所为
绕过防火墙做最小化连通性验证
排除配置干扰，直击网络层：
- 在 Nginx 所在机器上运行：nc -zv 后端IP 后端端口，看是否能建立 TCP 连接
- 如果 nc 失败，但你知道后端确实在运行，大概率是防火墙拦了 outbound
- 换用 curl 测试 HTTP 层：curl -v http://后端IP:端口/health，观察是否卡在 CONNECT 阶段或直接报 Failed to connect
- 临时停用本地防火墙测试：systemctl stop firewalld 或 ufw disable（仅限排查，勿长期关闭）
