Linux 服务器运维实战(5):网络排查常用命令 上一篇解决容量、inode 和日志生命周期本篇转向请求链路。网络故障最浪费时间的做法是无目的 ping高效排查应从本机配置开始沿 DNS、路由、传输连接、应用协议和 TLS 分层缩小范围。一、痛点“超时”不是根因用户看到超时可能是域名没有解析、路由走错接口、防火墙丢包、服务只监听回环地址、连接队列满、TLS 握手失败或应用本身迟迟不响应。ping使用 ICMP很多环境会限速或禁用它ping 失败不代表 TCP 443 不通ping 成功也不代表 HTTP 正常。第一步记录五元组源地址、源端口、目标地址、目标端口和协议并记录发生时间。没有时间戳就难以和服务日志、流日志及抓包对齐。接着判断影响范围单个客户端、单个机房、单个地址族还是全部请求。比较“正常样本”和“异常样本”通常比盯着异常机器更快。二、原理从名字到字节逐层验证DNS 返回地址不保证地址可达。getent ahosts使用系统名称服务配置最接近应用行为dig适合直接查询 DNS 细节两者结果不同可能来自/etc/hosts、缓存或 NSS。还要分别测试 A 与 AAAA双栈环境常出现 IPv6 路径坏而应用优先选择 IPv6。路由由目标前缀、策略规则和源地址共同决定。ip route get TARGET比打印整张路由表更直接它显示内核实际选择的下一跳、设备和源 IP。到达服务器后ss -lntp确认监听地址127.0.0.1:8080只能本机访问0.0.0.0:8080接收所有 IPv4 接口。TCP 连接成功说明三次握手完成不说明 TLS 和 HTTP 正常。curl -v能拆出解析、连接、握手、首字节阶段openssl s_client可检查证书链和 SNI。抓包是后手而非第一步因为它需要权限、可能捕获敏感数据也只展示观测点看到的流量。三、实现一键收集分层证据下面脚本接收主机和端口设置明确超时依次检查解析、路由、TCP 和 HTTPS。它不修改系统不依赖前文产物适合把完整输出附到故障记录。若目标是 HTTP应把最后的 URL 改为对应协议。#!/usr/bin/env bashset-uopipefail[[$#-eq2]]||{echo用法:$0HOST PORT2;exit2;}host$1port$2[[$port~^[0-9]$]]((port0port65536))||exit2echotime$(date-u%FT%TZ)host$(hostname)target$host:$portecho--- addressesgetent ahosts$host||{echoDNS/NSS 解析失败2;exit10;}mapfile-taddresses(getent ahosts$host|awk$2STREAM {print $1}|sort-u)foraddressin${addresses[]};doecho--- route$addressiproute get$address21||truedoneecho--- local listenersss-lntp2/dev/null|head-n20echo--- tcp probeiftimeout5bash-cexec 3/dev/tcp/$1/$2_$host$port;thenechotcpconnectedelseechotcpfailed2exit20fiecho--- https timingcurl--silent--show-error--output/dev/null\--connect-timeout5--max-time15\--write-outcode%{http_code} dns%{time_namelookup} connect%{time_connect} tls%{time_appconnect} first_byte%{time_starttransfer} total%{time_total}\n\https://$host:$port/运行输出addresses203.0.113.10 tcp_connectok hostapi.example.net port443 code200 dns0.012 connect0.028 tls0.061 first_byte0.104 total0.105需要验证本机监听时可独立启动临时 HTTP 服务并在 trap 中回收。此例使用socat不绑定公网接口只监听回环地址它验证的是 TCP 与最小 HTTP 响应不涉及生产服务。#!/usr/bin/env bashset-euopipefailcommand-vsocat/dev/null||{echo请先安装 socat2;exit127;}port18080tmp$(mktemp-d)cleanup(){[[-n${server_pid:-}]]kill$server_pid2/dev/null||truerm-rf--$tmp}trapcleanup EXIT INTTERMcat$tmp/respondEOF #!/usr/bin/env bash printf HTTP/1.1 200 OK\r\nContent-Length: 3\r\nConnection: close\r\n\r\nok\n EOFchmod0755$tmp/respondsocat TCP-LISTEN:$port,bind127.0.0.1,reuseaddr,fork EXEC:$tmp/respondserver_pid$!forattemptin{1..20};doss-lntsport :$port|grep-qLISTENbreaksleep0.1donecurl--fail--silent--show-errorhttp://127.0.0.1:$port/ss-lntpsport :$port运行输出ok State Recv-Q Send-Q Local Address:Port Peer Address:Port LISTEN 0 5 127.0.0.1:18080 0.0.0.0:*四、踩坑抓包位置决定结论客户端发出 SYN 而服务端抓不到故障位于两者之间或抓错接口服务端收到 SYN 并回复 SYN-ACK客户端却收不到应检查返回路由和中间策略三次握手完成后立即 RST常见于应用关闭、协议不匹配或代理行为。使用tcpdump -nn禁止反向解析过滤具体主机和端口并控制包数与文件权限。容器和云环境还有虚拟网卡、NAT、负载均衡健康检查与安全组。主机上的源地址可能已被代理改写连接跟踪表也可能成为瓶颈。先画清实际路径再选择抓包点不要看到某个节点正常就推断整条链路正常。五、验证保留可比较的时间数据将 curl 各阶段时间、解析地址、路由结果和服务端请求 ID 放进同一事件。DNS 时间高查解析器connect 高查路由和防火墙TLS 高查证书与 CPU首字节高则更可能是应用或后端。重复测试要限制频率避免探测本身放大故障。网络路径清楚后下一篇进入主机内部用 CPU、内存、I/O、负载和压力指标判断真正瓶颈并解释为什么“load 很高”不一定是 CPU 不够。参考来源ip-route 手册ss 手册curlWrite-out variablestcpdump Manual 觉得有用就点个赞 收藏方便回头查阅有疑问直接在评论区留言我看到都会回。 本文属于《Linux 服务器运维实战》系列持续更新关注不迷路。 文章里的代码都能直接跑。想要可直接 clone 的完整工程 配套部署脚本 / 踩坑清单评论一声或发邮件到cj2664qq.com我免费发你。如果你正好在做类似系统、或有工程化难题想找人做也欢迎邮件聊一句——我按实际情况评估能落地的就接单或出方案。评论和邮件都能直接找到我不用跳别的平台。