TCP代理下Nginx异常诊断需聚焦四层行为，优先分析error_log中errno错误码（如111、110、113、104、99），结合本机telnet/nc测试、ss监听检查、DNS解析验证及云环境安全组等综合排查。
在 TCP 代理（stream 模块）环境下，Nginx 本身不解析应用层协议，异常连接往往表现为“连不上”或“连得上但业务卡住”，诊断需聚焦四层行为、系统状态与日志线索，而非 HTTP 层逻辑。
抓取并解读 error_log 中的 errno 关键码
错误日志是第一手证据，重点筛查以下系统级错误描述：
-
Connection refused (111)：上游服务未监听端口，或被 iptables/nftables OUTPUT 链拦截；立即用
nc -zv IP 端口验证 -
Connection timed out (110)：SYN 发出后无 ACK 返回，可能是网络丢包、防火墙静默丢弃、或后端内核
net.ipv4.tcp_syncookies=1触发限速 - No route to host (113)：常见于容器网络异常（如 CNI 插件故障）、VPC 路由缺失，或目标 IP 根本不可达
- Connection reset by peer (104)：后端主动 RST，可能因进程崩溃、SSL 握手失败（如 TLS 版本不匹配）、或 Redis/MQ 在连接建立后立即关闭空闲连接
-
Cannot assign requested address (99)：本地 ephemeral port 耗尽，检查
net.ipv4.ip_local_port_range和net.ipv4.tcp_tw_reuse是否生效
验证 TCP 连通性与监听状态
不能仅依赖 Nginx 日志判断，必须在 Nginx 服务器本机实测：
- 用
telnet 后端IP 端口或timeout 5 nc -zv 后端IP 端口测试建连耗时；超时即说明链路中断 - 执行
ss -tlnp | grep :端口确认后端是否真正在监听，注意 bind 地址（0.0.0.0vs127.0.0.1） - 若 upstream 使用域名，运行
nslookup 域名和dig +short 域名，确认 DNS 解析稳定且返回预期 IP - 云环境额外检查：安全组出方向规则、目标组健康状态（AWS ALB/ELB）、服务发现注册状态（Consul/Eureka）
分析连接分布与长连接行为
TCP 代理下长连接易掩盖负载不均或节点卡死问题：
- 启用 stream 日志，添加
log_format stream_log '$remote_addr:$remote_port -> $upstream_addr [$time_local]';，观察请求是否集中落在某节点 - 在各后端执行
ss -tn state established | grep :端口 | wc -l，对比 ESTABLISHED 连接数；若某节点远高于其他，检查其应用线程阻塞或连接池满 - 关注
$connection_requests（需自定义 log_format），若持续增长（如从 1 到 200+），说明连接未被重分配，可能因后端未正确发送 FIN 或 keepalive 超时未触发断连 - 检查 Nginx error_log 中是否高频出现
upstream connection is busy—— 表明 proxy_pass 的 keepalive 连接池已空，被迫新建连接，导致 least_conn 失效
联动内核与连接队列状态
高并发下很多“超时”本质是内核资源瓶颈：
- 检查半连接队列：
netstat -s | grep -i "listen overflows"，若数值增长，说明net.ipv4.tcp_max_syn_backlog不足 - 检查全连接队列溢出：
ss -lnt | grep -E "(Recv-Q|Send-Q)"，若 Recv-Q 长期非零，需调大net.core.somaxconn并在 listen 指令中加backlog=65535 - 确认 TIME_WAIT 端口复用是否生效：
cat /proc/sys/net/ipv4/tcp_tw_reuse应为 1，且客户端开启 timestamp（现代 Linux 默认开启） - 查看本地端口使用情况：
ss -ant | awk '{++S[$1]} END {for(a in S) print a, S[a]}' | sort -k2 -nr | head -5，判断是否接近ip_local_port_range上限
