netstat 和 ss 是排查 Nginx 故障的关键工具，可直接反映内核网络层真实状态：验证端口是否监听（如 ss -tuln | grep ':80'）、区分监听地址（127.0.0.1:80 不对外）、分析连接状态（ESTAB 正常、CLOSE-WAIT 危险、TIME-WAIT 指向短连问题）、定位异常 IP 及检查资源限制（文件描述符、ephemeral port、OOM、防火墙）。
排查 Nginx 故障时，netstat 和 ss 是直接观察内核网络层状态的关键工具——它们不依赖 Nginx 进程是否响应，能真实反映端口监听、连接建立、资源占用等底层情况。重点不是“有没有连上”，而是“连在哪一环断了”。
确认 Nginx 是否真正在监听端口
服务“启动成功”不等于“端口已监听”。常见问题包括绑定地址错误（如只监听 127.0.0.1）、端口被占、或 Docker 映射未生效。
- 查所有监听中的 TCP 端口：
sudo ss -tuln或sudo netstat -tuln - 精准过滤 Nginx 常用端口：
sudo ss -tuln | grep ':80\|:443' - 验证监听地址：若输出是
127.0.0.1:80，则外部无法访问；应为0.0.0.0:80或具体网卡 IP - Docker 场景下，还需运行
docker port <container>核对宿主机端口映射是否正确
统计并分析当前连接状态分布
不同 TCP 状态指向不同问题根源，仅看总数没意义，必须分类观察。
- ESTAB（已建立）：表示正常通信中。数量持续高位且响应变慢，说明后端处理延迟或 worker 处理能力不足
- CLOSE-WAIT：危险信号！Nginx 或上游服务未主动关闭 socket，会导致文件描述符快速耗尽
-
SYN-RECV：大量存在可能遭遇 SYN Flood 攻击，需检查防火墙或启用
tcp_syncookies - TIME-WAIT：短连接频繁关闭的自然现象，但若集中在某几个上游 IP，说明 Nginx 与后端未启用 keepalive
定位异常客户端或上游来源
快速识别流量特征，区分是业务高峰、爬虫还是攻击。
- 查看活跃连接的客户端 IP 分布：
sudo ss -tn state established '( dport = :80 or dport = :443 )' | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head -10 - 检查与 upstream 的连接状态：
sudo ss -tn state time-wait '( sport = :80 or sport = :443 )' | awk '{print $4}' | cut -d: -f1 | sort | uniq -c（注意是sport，即本地发起的连接） - 对比 stub_status：若
Active connections远小于ss -tn state established数量，说明请求堆积在读取阶段（如大 body 未收完、proxy_read_timeout 过短）
检查系统级资源限制是否触发静默拒绝
Connection refused 错误往往不是配置问题，而是内核因资源不足直接拒连。
- 查文件描述符上限：
cat /proc/$(pgrep nginx)/limits | grep "Max open files"，默认 1024 极易不够 - 看临时端口范围：
cat /proc/sys/net/ipv4/ip_local_port_range，若压测中耗尽，新连接会失败 - 确认是否 OOM 被杀：
dmesg -T | grep -i "killed process"，尤其关注后端应用进程 - 检查防火墙规则：
sudo iptables -L INPUT -n -v，确认目标端口是否放行；SELinux 若为 Enforcing 模式也可能拦截
