排查nginx网络层异常需聚焦error.log中errno编码及关键词：111（connection refused）、110（timed out）、113（no route to host）、104（reset by peer）、99（cannot assign address）；结合telnet/nc、ss、nslookup实测连通性，并检查防火墙、dns、端口资源与路由。
排查 Nginx 错误日志中的网络层异常，核心是识别日志中与连接、路由、端口、防火墙、DNS 或传输失败直接相关的错误线索，并快速定位到链路中断点。这类问题通常不表现为配置语法错误或权限不足，而是“Nginx 能启动、能收请求，但连不上后端或客户端”，错误日志里会反复出现特定的系统级 errno 编码和描述。
重点识别 error.log 中的网络类错误关键词
打开 /var/log/nginx/error.log，用以下命令快速筛选典型网络异常：
-
连接拒绝：搜索
Connection refused（errno 111）——说明上游服务未监听目标端口，或被本地防火墙（如 iptables/nftables）拦截 -
连接超时：搜索
Connection timed out（errno 110）——可能是网络延迟高、中间设备丢包、后端响应极慢，或 TCP SYN 包未返回 ACK -
无路由/主机不可达：搜索
No route to host（errno 113）——常见于 Docker 容器跨网络通信失败、K8s Pod 网络插件异常、或宿主机路由表缺失 -
连接重置：搜索
Connection reset by peer（errno 104）——上游服务主动关闭连接，可能因进程崩溃、SSL 握手失败、或应用层协议不兼容（如 HTTP/2 降级异常） -
地址不可用：搜索
Cannot assign requested address（errno 99）——通常是 ephemeral port 耗尽（net.ipv4.ip_local_port_range设置过窄），或绑定的 upstream 地址不存在（如 DNS 解析失败后仍尝试连接）
验证上游服务可达性与监听状态
仅看日志不够，需立即在 Nginx 所在机器上做实测验证：
- 用
curl -v http://upstream_ip:port/health模拟 Nginx 的上游请求，观察是否返回响应或明确报错 - 用
telnet upstream_ip port或nc -zv upstream_ip port测试 TCP 连通性；不通则说明网络层或端口层已阻断 - 检查上游服务是否真正在监听：
ss -tlnp | grep :port（注意运行用户和 bind 地址，127.0.0.1和0.0.0.0效果不同） - 若 upstream 是域名，执行
nslookup domain和dig +short domain确认 DNS 解析正常，且返回的是预期 IP
排查中间网络策略与内核限制
即使上下游服务都正常，网络策略也可能静默拦截：
- 检查本机防火墙：
sudo iptables -L -n -v或sudo nft list ruleset，确认 OUTPUT 链未屏蔽 outbound 连接 - 检查云平台安全组/VPC 网络 ACL，确保出方向（egress）允许目标端口和协议
- 查看是否启用 SELinux：
getenforce，若为Enforcing，临时设为 permissive 测试：sudo setenforce 0 - 检查文件描述符和端口资源：
cat /proc/sys/net/ipv4/ip_local_port_range和ulimit -n，若大量Cannot assign requested address，说明临时端口枯竭
结合 access.log 交叉判断网络行为
错误日志告诉你“连不上”，访问日志可帮你确认“谁在连、连了多久、有没有收到响应”：
- 用
awk '$9 ~ /^50[24]$/ {print $4,$1,$9,$NF}' /var/log/nginx/access.log | head -20查看最近的 502/504 请求时间、IP、状态码和响应时间（$NF） - 若
$request_time接近proxy_connect_timeout值（如 60s），大概率是 connect 阶段卡住；若接近proxy_read_timeout，则是连接建立后读响应超时 - 对比同一时间段内正常请求（200）和异常请求（502）的
$remote_addr，确认是否特定客户端网络路径异常（如某 IDC 出口 NAT 失败）
