网络排错应先验证基础连通性：先 ping 域名和 IP，再查 DNS、路由、防火墙；区分 Connection refused、timeout、no route to host 的根因；必要时抓包并确认命名空间与资源限制。
确认目标地址是否可达
连接失败的第一反应不应该是查服务端，而是验证基础网络连通性。很多问题其实卡在 DNS 解析或路由层面。
- 用
ping -c 4 example.com看是否能解析并通 ICMP —— 如果失败，先跑nslookup example.com或dig example.com检查 DNS；如果解析成功但 ping 不通，说明可能禁 ICMP 或中间路由有问题 - 别只信域名，立刻试 IP：
ping -c 4 192.0.2.1。若 IP 可通而域名不通，基本锁定 DNS 配置（/etc/resolv.conf）或本地 hosts 冲突 - 注意：某些云环境或容器网络中，
ping被策略屏蔽，此时改用curl -v telnet://192.0.2.1:22或nc -zv 192.0.2.1 22更可靠
检查本地 TCP 连接是否被阻断
即使路由和 DNS 都正常，connect() 仍可能返回 Connection refused、Timeout 或 No route to host —— 每种错误指向完全不同环节。
-
Connection refused：目标端口上没进程监听，或防火墙明确拒绝（如 iptables DROP 后会静默丢包，REJECT 才返回该错误）；用ss -tlnp | grep :80确认本机服务状态 -
Connection timed out：数据包发出去了但没回 SYN-ACK，常见于目标主机防火墙丢包、目的端口未开放、或中间设备（如安全组、NAT 网关）拦截 -
No route to host：本地路由表无匹配项，或 ARP 失败（局域网内）；运行ip route get 192.0.2.1和arp -n | grep 192.0.2.1快速定位
抓包确认数据包实际走向
当 ping、nc、curl 行为不一致时，必须看真实流量。不要猜，要抓包。
- 优先用
tcpdump -i any host 192.0.2.1 and port 443 -w debug.pcap，避免指定接口漏掉路由转发路径 - 关键观察点：是否有 SYN 发出？是否有 SYN-ACK 返回？是否有 RST 中断？没有 SYN → 本地被拦（如 iptables OUTPUT 链）；有 SYN 无响应 → 中间链路或远端问题
- 注意：容器或 network namespace 场景下，
tcpdump必须进对应 namespace 运行（nsenter -n -t $PID -- tcpdump ...），否则看不到内部流量
排查 socket 层资源与策略限制
看似网络问题，有时其实是内核参数或 cgroup 限制导致连接无声失败。
- 检查连接数上限：
cat /proc/sys/net/core/somaxconn（listen backlog）、cat /proc/sys/net/ipv4/ip_local_port_range（临时端口范围），短连接密集场景容易耗尽 - 确认是否触发 conntrack 满：
conntrack -S查entries是否接近max；满后新连接会被丢弃且不报错 - 容器或 systemd service 下注意 cgroup v2 的
net_prio或net_cls限制，以及systemctl show --property=IPAddressDeny类网络策略
实际排错时，最容易被跳过的环节是确认「发起连接的进程运行在哪一个网络命名空间里」——宿主机 curl 成功不代表容器内也能通，而 strace -e trace=connect curl ... 能直接看到系统调用级的错误码，比任何高层工具都准。
