我一直觉得全栈工程师最值钱的技能不是会多少个框架而是遇到问题的时候能不能快速把范围缩小到某一个具体的层。尤其是网络问题它不会只属于运维写接口的人会遇到“前端说后端连不上”写前端的人会被问“为什么请求超时”做部署的人要解释“为什么容器起来了但访问不了”。网络排查命令手册这种东西看着像给网工准备的实际上是我们每天都在用的救命工具。今天我就把日常用得最多的排查命令和思路整理出来按“从下往上、从近到远”的顺序讲尽量说人话每一步都告诉你为什么要这么做以及踩过的坑在哪里。不管是刚转全栈的新手还是已经被线上问题折磨过几轮的老人这篇都值得收藏。1. 网络排查的整体思路与必备准备1.1 先分层再动手别急着敲命令很多人一遇到网络不通就直接拿起telnet冲上去结果端口通着业务还是报错人就懵了。我个人的习惯是先把问题放在一个分层模型里一般简单划分为四层网络接口层网卡通不通、网络层IP通不通、传输层端口通不通、应用层服务和协议正不正常。排查顺序不是固定的但绝大多数场景都可以按“从底层到高层”去做先把不用猜的确认掉再往上层查。举一个很常见的例子浏览器打开页面提示连接被重置。如果你先在应用层折腾比如重装Nginx、调后端超时时间大概率白费力气。正确的思路是先ping一下对端IP如果不通查网卡、路由和防火墙如果通再telnet对端80或443端口看传输层端口也通最后才会切到应用层看Nginx日志、后端日志和证书。每次先定位到某一层排查范围就会缩小很多而不是到处敲一通命令然后看谁顺眼就去查谁。我还会先把问题复现一遍记录下时间点、报错信息、涉及的服务和链路。很多排查做不好不是因为缺少命令而是因为没有把故障现场记录下来。后面你会发现在多个服务互相调用的时候精确到秒的时间戳就是破案的关键。1.2 本机状态检查从网卡到连接状态在开始远端排查之前先确认本机的基本状态。Linux下我喜欢用ip addr来看网卡IP和启没启动然后ip route查看默认路由Windows下对应的是ipconfig和route print。很多所谓“网络不通”其实是网卡被禁用、IP配置错误或者默认网关丢了。连接状态用ss或netstat我个人习惯用ss因为输出更快、更直观。ss -tnp可以列出所有TCP连接以及对应的进程ss -uanp看UDP。这里有个很实用的技巧当你说“连不上Redis”的时候先看本机是不是已经建立了到Redis端口的连接如果连TIME_WAIT和ESTABLISHED都没有那就不是应用层的问题而是更底层就被挡了。系统资源也要顺手看别忽略top命令它虽然不直接查网络但能帮你确认CPU和内存是否异常因为有些网络故障其实是资源耗尽导致的。比如句柄数满了、连接数满了表现跟网络不通很像但看top和ss -s就能发现端倪。1.3 排查工具的准备与选择排查工具不需要装太多但建议提前把常用的准备好避免故障时才发现没装。Linux一般自带ping、telnet很多发行版默认没有需要yum install telnet或apt install telnet、traceroute、dig、curl、tcpdump这些齐全了90%的排查都能完成。如果没有traceroute可以装mtr用起来更顺手。抓包工具用tcpdump加tshark或者本地用Wireshark可以快速分析包内容。容器场景下docker exec进容器后未必有网络排查工具这时候可以在宿主机上用nsenter进入容器的网络命名空间复用宿主机的工具非常方便。containerd环境也一样用ctr命令找到容器PID再nsenter -t pid -n进入网络命名空间。这个方法比在容器里装包要快得多而且是临时排查不会污染容器镜像。有一个容易忽略的点是命令要能追溯。每次排查完我会把用到的命令和关键输出放到一个本地文件里尤其是线上问题。以后遇到相似的故障直接搜索自己的排查记录比重新敲一遍命令、瞎猜半天要高效得多。2. 端口连通性排查从telnet到更可靠的替代2.1 telnet命令怎么用返回结果怎么看telnet应该是大家最早接触的端口排查命令最基础的用法就是telnet ip 端口。比如要确认某台机器能不能访问数据库的3306端口直接执行telnet 192.168.1.10 3306如果端口通屏幕会显示连接成功甚至进入一个空白的交互界面这时按Ctrl]再输入quit退出。如果不通通常有两种表现一直卡着直到超时或者直接提示Connection refused。前者的意思是包发出去了但没人回应大概率是防火墙丢弃、IP不可达或者路由问题后者说明目标主机收到了请求但目标端口没有服务在监听所以主动回了RST包。很多新手分不清这两种情况其实区别特别重要。超时属于“无声无息”的丢包拒连则说明“我能找到你但你的门没开”。顺着这个思路你能立刻判断下一步是查网络路径还是查服务状态。不过telnet有两个缺点一是很多环境默认没装二是它不适合自动化脚本因为要处理交互式终端。所以在写自动化检查脚本时我更推荐用下面几种方式。2.2 nc、curl与bash /dev/tcp更适合作脚本的替代方案ncnetcat是我最常用来替代telnet的工具一条命令就能完成TCP端口检测而且适合脚本nc -zv -w 3 192.168.1.10 3306-z表示只扫描不发送数据-v输出详细信息-w 3指定超时时间为3秒。端口通会输出类似Connected to 192.168.1.10的信息不通会返回非零退出码这样在shell脚本里就可以直接用$?判断结果。curl也能测端口尤其适合HTTP服务curl -v telnet://192.168.1.10:3306这个命令会建立TCP连接输出详细的握手过程哪怕不是HTTP服务也能看出连接能不能建立。如果你连nc都没有用bash自带的伪设备也可以timeout 3 bash -c echo /dev/tcp/192.168.1.10/3306 echo port open这个方法不依赖额外包很多精简版系统上很好用。不过它有个限制只能判断TCP端口开不开拿不到更复杂的响应内容所以适合快速确认。2.3 UDP端口排查的特殊性很多人会在UDP上栽跟头因为UDP没有三次握手端口通不通不能靠“建立连接”来判断。比如DNS用的53端口、NTP用的123端口用telnet去测根本没有意义。nc加-u参数可以发UDP包但结果不太直观nc -vzu 192.168.1.10 53有些时候只是显示“Connection succeeded”但实际对端并没有应答因为UDP的“通”只是代表本机能发包没收到ICMP端口不可达而已。所以排查UDP更靠谱的办法是抓包看有没有应答或者直接问业务方“你期望的协议交互是什么样的”。另外可以用ss -uanp查看本机UDP监听状态确认服务是不是真的在监听。比如NTP没同步先看UDP 123端口有没有监听再配合抓包看服务端有没有回应链路才清晰。2.4 端口排查的几个高频误区这些年我见过不少“telnet能通但业务不通”的怪事总结下来有几个高频误区。第一服务监听的地址是127.0.0.1而不是0.0.0.0。这种情况从外部telnet必然失败但在本机却能通。遇到“外网访问不了本机正常”第一反应就是看监听地址。用ss -lntp可以看到具体绑定的是哪个IP如果一个服务只监听127.0.0.1你又希望它能被远端访问就得改配置文件里的bind地址。第二云平台安全组和主机防火墙双重限制。你telnet不通可能是云平台的安全组没放行也可能是主机上iptables或者firewalld拦了。光查一层往往会漏。我习惯两边都看用iptables -L -n -v查看规则用systemctl status firewalld看防火墙状态再登录云控制台确认安全组顺序别乱。第三IPv6的问题。有时候你ping的是IPv4地址但DNS解析返回的是IPv6地址而链路上IPv6路由不通表现为“解析正常但连接超时”。解决思路是先用ping -4和ping -6分别测试再用curl -4或curl -6强制指定IP协议族确认是不是IPv6的锅。3. 数据链路与路由排查不只是ping通就完事3.1 ping的进阶用法延迟、丢包与MTUping可以说是网络排查的起点但它不只是“能通就行”。我一般会看三个指标丢包率、延迟和延迟波动。丢包率长期大于0就说明链路不稳定延迟突然升高有可能是带宽被打满或者路由绕路。连续ping几百个包再统计比ping三五个包就下结论靠谱得多。ping -c 100 -i 0.2 目标IP-c 100表示发送100个包-i 0.2表示每0.2秒发一个这样可以比较快地得到统计结果。Windows下对应的是ping -n 100。还有一个非常实用但容易被忽略的参数-M do用来测MTU最大传输单元ping -c 3 -M do -s 1472 目标IP这个命令会发送不允许分片、大小是1472字节的数据包。1472这个数字怎么来的以太网默认MTU是1500减去IP头20字节和ICMP头8字节剩下1472。如果通则说明MTU没问题如果不通或者提示需要分片说明链路上某个设备MTU小于1500可能出现“网页打不开但ping能通”的诡异现象。3.2 traceroute与mtr分段定位丢包点当ping发现丢包或高延迟时下一步就是确认丢包发生在哪一跳。traceroute的原理是发送TTL从1开始递增的包让每一跳的路由器都告诉你“我收到了但我不知道最终主机在哪”。输出结果会显示路径上的每一跳IP和响应时间。不过traceroute一次只发几个包抖动大的时候很难判断。我更推荐mtr它相当于traceroute和ping的结合体会持续探测每一跳并统计丢包率和延迟mtr -r -c 10 目标IP-r是report模式-c 10是探测10次结束后直接输出报告。看输出时有一个重要经验最后一跳之前的中间路由丢包往往不代表链路有问题因为很多路由器的ICMP响应是限速的丢包率高但最终目标不丢包就很正常。真正的判断标准是看最后一跳目标主机的丢包情况最终目标丢包才算链路有问题。还记得有一次线上调用变慢我ping外网IP延迟只有1ms但访问某个内部服务却要卡好几秒。用mtr一看发现流量绕到了另一个网段的网关估计是路由策略问题最后通过调整静态路由解决。没有mtr这个问题可能要排查半天。3.3 tcpdump抓包思路不靠猜看数据说话当排查到“端口通、服务通但业务就是不对”的时候就该上抓包了。tcpdump是Linux下最经典的抓包工具我常用的几个过滤写法是tcpdump -i eth0 host 192.168.1.10 and port 3306 -nn -w /tmp/mysql.cap-nn表示不解析域名和端口名-w指定保存文件。抓完把文件拖到本地用Wireshark打开或者直接在服务器上用tshark -r查看。如果是临时快速查看可以不加-w直接打印包内容tcpdump -i eth0 tcp port 80 -nn -c 10抓包的时候重点看TCP三次握手SYN、SYN-ACK、ACK是否完整有没有大量重传有没有RST包。我见过一种情况客户端与服务端三次握手成功但数据传输时客户端频繁重传最后连接被RST。这种问题靠telnet完全看不出来只能通过抓包看到“包已经发出去了但对端没有ACK”最终定位到是中间链路MTU问题。另外抓包时要注意网卡和网段本机有多块网卡的先确认流量走的是哪一块。使用ip route get 目标IP可以查看发往某个IP的流量会从哪个网卡出去避免抓错网卡导致什么都看不到。3.4 防火墙与iptables排查顺序防火墙导致的网络问题非常隐蔽因为很多服务看起来正常但请求就是进不来。遇到这种情况我习惯按这个顺序排查先确认服务监听地址ss -lntp再查宿主机防火墙iptables -L -n -v或firewall-cmd --list-all最后查云平台安全组。三层都放行才能通。iptables输出里我主要看INPUT链的Policy是ACCEPT还是DROP以及有没有匹配的规则。如果Policy是DROP且没有放行规则那端口不通毫无悬念。这里有个细节iptables -L默认不显示规则匹配次数加上-v才能看到每个规则被命中多少次能帮你判断到底是哪条规则在起作用。修改防火墙规则要特别谨慎线上的机器最好先备份原有规则并且不要一口气清空链。改之前用iptables-save /tmp/iptables.rules.$(date %F)备份改完单独验证验证完再固化。很多线上事故就是因为改防火墙时手滑把规则清空了导致服务瞬间全断。4. DNS与应用层排查域名解析的坑4.1 DNS解析第一步dig与nslookup域名解析是应用层最容易出问题又最容易被忽略的环节。我的习惯是先确认“域名到底解析到了哪个IP”再用这个IP去做连通性测试。dig是Linux下最顺手的工具dig short example.com这会返回A记录IPv4或者AAAA记录IPv6。想看更完整的信息可以去掉short能看到查询的DNS服务器、TTL、返回结果等。用dig 8.8.8.8 example.com可以指定某个DNS服务器比如你想确认是不是本地DNS缓存的问题就用公共DNS直接把解析结果拉出来对比。Windows环境下没有dig一般用nslookupnslookup example.comnslookup也会显示当前使用的DNS服务器和解析结果适合快速排查。但输出格式不如dig易读所以我的建议是如果有条件装一个digWindows也可以装或者用在线DNS查询工具辅助。4.2 本地域名配置与缓存/etc/hosts和resolv.conf解析不对不一定是DNS服务器的问题也有可能是本机配置被改过。Linux下/etc/resolv.conf定义的是DNS服务器顺序/etc/hosts则可以直接指定域名到IP的映射。有时候开发环境会往hosts里加一条测试映射忘了删上线后就会“域名解析到内网IP”或者“解析到旧IP”表现就是服务访问异常但别的地方都正常。DNS缓存也是个经典坑。systemd-resolved、nscd、dnsmasq都有自己的缓存改完DNS记录后线上总是有一批机器还在用旧IP。排查时可以手动清一下缓存systemd-resolve --flush-caches或者nscd -i hosts在CDN场景下这个现象尤其常见。你改了一条DNS记录刷新后自己电脑上解析正常但服务器上还是旧IP大概率就是服务器上有DNS缓存。所以遇到“为什么我本地能通服务器不能通”的奇怪问题顺手查一下服务器DNS解析结果和缓存能省很多时间。4.3 应用层请求排查curl、openssl、redis-cli应用层的问题工具要跟着协议走。HTTP服务用curl最多尤其要会用-v和-w。curl -v https://example.com/api/health-v会显示TLS握手过程、请求头、响应头能很直观地看到连接建立在哪一步出现问题。如果只想看耗时用-w输出时间明细curl -o /dev/null -s -w DNS解析:%{time_namelookup}s 连接:%{time_connect}s TLS握手:%{time_appconnect}s 总耗时:%{time_total}s\n https://example.com这一条命令把网络耗时拆开了是排查“接口响应慢”的利器。如果DNS解析耗时很高就查DNS如果连接耗时长就查端口和防火墙如果TLS握手慢就要看证书链和双方密码套件协商了。数据库和其他中间件也有自己的命令比如Redis用redis-cli ping如果返回PONG说明端口和服务都正常如果超时或者DENIED再根据报错查网络或者ACL。Kafka有kafka-broker-api-versions之类的工具可以检测Broker连通性。总之不要停留在“端口能通就行”的层面要试着用对应的客户端工具确认协议层面也正常。HTTPS证书问题用openssl来排查openssl s_client -connect example.com:443 -servername example.com这条命令会输出证书链、有效期和握手结果如果证书不匹配或过期这里会报错。很多“App无法访问”的诡异问题最后查出来就是证书链少发了一张中间证书。4.4 从日志反推网络问题当应用层命令也看不出问题的时候日志就是最后的突破口。我一般会把时间点作为联合主键拿客户端报错的时间去查负载均衡的访问日志再查应用的access log最后查中间件日志和系统日志。每一步都对不上就继续往下挖如果某一层日志有异常网络排查就变成日志排查了。Linux系统日志一般看journalctl -u 服务名nginx看/var/log/nginx/access.log和error.logTomcat看catalina.out。有一个技巧是先grep出错误前后各几秒的日志而不是只看那一条错误。很多网络故障是连锁反应错误前后的日志能帮你理清因果链。5. 高频故障场景实战把命令串起来用5.1 远程数据库不通或者很慢以MySQL为例假设应用报错“无法连接数据库”我会这样串命令排查。第一步在本机确认MySQL端口telnet 192.168.1.20 3306如果不通再去数据库服务器上看监听地址和防火墙ss -lntp | grep 3306 iptables -L -n -v | grep 3306如果通但连接慢多半是DNS反查或者连接数满了。MySQL默认会做反向解析DNS有问题的时候连接就会卡。解决办法是在配置里加skip-name-resolve。如果连接直接被拒绝且应用账号没问题就要查max_connections是不是满了用mysqladmin -u root -p status看Threads和Connections。记住端口通只是第一关连接数、权限、ACL都可能成为下一道坎。5.2 容器环境里的网络排查容器环境比传统虚拟机多了一层网络排查思路略有不同。首先要分清问题发生在容器内、宿主机还是跨主机。在宿主机上用docker ps和docker inspect 容器名看端口映射和网络模式。进入容器内的方式我用得比docker exec多的是nsenterPID$(docker inspect -f {{.State.Pid}} 容器名) nsenter -t $PID -n ip addr nsenter -t $PID -n ss -lntp这样能直接在宿主机的命名空间里看到容器内部的IP和端口省去在容器里装工具的麻烦。containerd环境下先ctr c list拿到容器ID再用ctr c info拿到PID同样用nsenter进入网络命名空间。跨主机容器通信的问题往往要看CNI插件配置和宿主机路由。比如weave、flannel这些网络插件都有对应的命令像weave status可以看连接状态。遇到容器之间不通先确认Pod/容器IP能不能ping通不能ping就用traceroute或ip route看路由是不是少了再确认宿主机之间是不是有防火墙挡了VXLAN或Overlay端口。容器网络排查的本质还是那三板斧IP、端口、路由只是多套了一层命名空间而已。5.3 SSH连接卡顿、中断与命令后台化SSH问题也是全栈工程师经常遇到的。连接卡在输入密码之前八成是DNS反查问题服务端/etc/ssh/sshd_config里加上UseDNS no基本能解决。连上之后经常断要么是网络链路不稳定要么是TCP keepalive设置太短。可以在客户端配置里加ServerAliveInterval 60 ServerAliveCountMax 3这样客户端每60秒发一个保活包连续3次没回应才断开。还有一个经典问题SSH执行过程中退出命令还会继续吗这个要分情况。如果你执行的是sleep 10然后直接关掉终端命令进程会收到SIGHUP信号被终止但如果用了nohup把命令放后台nohup long-running-command /tmp/out.log 21 命令就会在退出SSH后继续跑。理解这个原理后线上需要长时间执行的任务我都会老老实实加nohup或者直接上tmux/screen避免人走命令断。排查SSH问题history命令也能派上用场。有时候你会突然忘了自己上次对某台机器做过什么改动先敲history看看之前的操作记录会比满世界翻配置更快。还有xshell用户常见的“回退目录”操作其实只是cd -这个命令会自动在两个最近切换的目录之间来回跳效率很高。5.4 Windows环境与系统维护类排查虽然我们是全栈但偶尔也会被Windows服务器或者自己电脑的网络问题绊住。Windows下最基本的排查命令是ping、ipconfig、netstat -ano很多Linux命令用不了但思路一样。比如端口占用Windows上找哪个进程占用了8080netstat -ano | findstr 8080 tasklist | findstr PIDWindows下DNS刷新是ipconfig /flushdns重置网络栈的终极手段是netsh winsock reset和netsh int ip reset执行完要重启才会生效。有时候你发现C盘满了导致服务起不来命令行顺手清理临时文件也方便比如cleanmgr打开磁盘清理或者直接用del /q /f /s %TEMP%\*。还有经典场景gpedit.msc打不开多半是系统版本不支持或者环境变量缺失先确认是不是专业版及以上再确认C:\Windows\System32路径下面有没有这个文件没有就去别的机器拷贝或者修复组件。Windows下脚本闪退也比较常见。双击.bat一下窗口就消失看不出报错我一般会先打开cmd手动执行脚本或者用cmd /k保留窗口cmd /k script.bat这样窗口不会关闭报错信息能完整显示。脚本跑完关闭则是用exit。这些小命令不算网络排查的核心但遇到“自己的电脑先挂了”的时候很有用。6. 常见问题与排查技巧速查表6.1 症状与命令对照速查表为了减少你自己翻上面内容的时间我整理了一个对照表。它不代表所有场景但能覆盖常见的90%问题。症状优先排查命令可能原因ping不通ip addr、ip route、iptables -L -n -v网卡未启用、路由缺失、防火墙丢包能ping通但端口不通ss -lntp、telnet ip port、nc -zv服务未监听、防火墙挡了、监听地址错误端口通但业务超时curl -v、tcpdump、mtrMTU问题、中间设备丢包、应用卡死域名解析正常但访问异常dig 8.8.8.8、curl -4、curl -6DNS缓存、IPv6路由不通、hosts配置错误延迟高mtr -r -c 20、ping -i 0.2链路拥塞、路由绕路、带宽打满SSH经常断客户端加ServerAliveInterval、服务端UseDNS no连接超时、DNS反查、网络抖动容器服务外部访问不了docker inspect、nsenter -t PID -n ss -lntp端口映射错误、容器内监听127.0.0.16.2 多平台命令对照指南日常用的机器五花八门我经常会同时操作Windows跳板机和Linux服务器所以整理了一份对照表方便你快速切换。功能LinuxWindows查看IP地址ip addripconfig /all查看路由ip routeroute print查看连接ss -tnpnetstat -ano测试端口nc -zv/telnettelnet/Test-NetConnection域名解析dig/nslookupnslookup/Resolve-DnsName清DNS缓存systemd-resolve --flush-cachesipconfig /flushdns抓包tcpdumppktmon/ Wireshark防火墙iptables -L -n -vnetsh advfirewall show allprofiles测连通性ping -c 4ping -n 4macOS和Linux大部分命令类似只是默认没有ss可以用lsof -i :端口来查端口占用netstat -anv也能看连接状态。6.3 一些值得坚持的排查习惯把排查命令背得再熟也不如养成一套自己的排查流程。我的流程大概是这样先记录现场时间、报错、改动再复现问题然后分层排查每查完一层就记录结果最后定位到根因并修复修复后还要验证并写进文档。写文档是我特别想强调的习惯。很多人排查问题很厉害但解决完就忘了下次遇到类似问题又要重新排查一遍。我现在会把每次线上故障的排查过程和最终根因写成简短笔记包括命令和关键输出下次直接搜索关键词就能找到。这个习惯帮我在很多重复问题上省了至少一半时间。还有一个细节排查过程中不要同时改多个变量。很多人因为着急一会儿改配置文件一会儿重启服务一会儿加防火墙规则结果问题解决了也不知道是哪一个改动生效的。正确的做法是每次只改一个地方验证一次这样即使改错了也能快速回滚。6.4 安全地使用排查命令排查网络问题时有些命令是不能随便在别人的网络或生产环境里乱跑的。比如arpspoof这类工具是用来做ARP欺骗测试的属于渗透测试范畴没有授权的情况下使用会有很大的风险也会影响其他用户。作为普通开发者和运维我们的目标是定位和解决自己系统的问题而不是去探测别人的网络。渗透方向的内容比如sqlmap、CTF里的passthru漏洞利用这类技巧是安全研究人员在合法授权范围内使用的。日常开发排查根本用不到也不应该用。我们掌握网络排查命令的初衷是为了让自己负责的应用和服务更稳定不是为了绕过限制或攻击他人。把这个边界守好既是对自己负责也是对他人的系统负责。还有一个小提醒在用命令查看系统信息或抓包的时候注意别把敏感信息泄露到公共平台。比如数据库IP、密码、Token这类内容打日志或者截图分享前要打码。生产环境的抓包文件更要注意保管因为里面可能含有真实的业务数据。我在实际排查过程中还养成一个习惯安全地记录命令历史。history命令在bash里默认最多保留1000条但线上环境的操作我还是会保留到单独的分级日志里方便审计和回溯。合理使用命令History并保留足够的审计时间是做网络排障的基本职业素养。最后再分享一个小技巧当你实在不知道从哪查起的时候从头到尾走一遍ping - telnet - curl - 日志这条链路。这个顺序看着简单但能稳定地把问题从低层到高层过滤一遍至少能排除掉80%的干扰项。剩下的问题靠tcpdump抓包和日志基本都能定位。把这些命令用熟了你会发现网络排查没有想象中那么难它和写代码一样是有套路、有规律可循的技能。
我一直觉得全栈工程师最值钱的技能不是会多少个框架而是遇到问题的时候能不能快速把范围缩小到某一个具体的层。尤其是网络问题它不会只属于运维写接口的人会遇到“前端说后端连不上”写前端的人会被问“为什么请求超时”做部署的人要解释“为什么容器起来了但访问不了”。网络排查命令手册这种东西看着像给网工准备的实际上是我们每天都在用的救命工具。今天我就把日常用得最多的排查命令和思路整理出来按“从下往上、从近到远”的顺序讲尽量说人话每一步都告诉你为什么要这么做以及踩过的坑在哪里。不管是刚转全栈的新手还是已经被线上问题折磨过几轮的老人这篇都值得收藏。1. 网络排查的整体思路与必备准备1.1 先分层再动手别急着敲命令很多人一遇到网络不通就直接拿起telnet冲上去结果端口通着业务还是报错人就懵了。我个人的习惯是先把问题放在一个分层模型里一般简单划分为四层网络接口层网卡通不通、网络层IP通不通、传输层端口通不通、应用层服务和协议正不正常。排查顺序不是固定的但绝大多数场景都可以按“从底层到高层”去做先把不用猜的确认掉再往上层查。举一个很常见的例子浏览器打开页面提示连接被重置。如果你先在应用层折腾比如重装Nginx、调后端超时时间大概率白费力气。正确的思路是先ping一下对端IP如果不通查网卡、路由和防火墙如果通再telnet对端80或443端口看传输层端口也通最后才会切到应用层看Nginx日志、后端日志和证书。每次先定位到某一层排查范围就会缩小很多而不是到处敲一通命令然后看谁顺眼就去查谁。我还会先把问题复现一遍记录下时间点、报错信息、涉及的服务和链路。很多排查做不好不是因为缺少命令而是因为没有把故障现场记录下来。后面你会发现在多个服务互相调用的时候精确到秒的时间戳就是破案的关键。1.2 本机状态检查从网卡到连接状态在开始远端排查之前先确认本机的基本状态。Linux下我喜欢用ip addr来看网卡IP和启没启动然后ip route查看默认路由Windows下对应的是ipconfig和route print。很多所谓“网络不通”其实是网卡被禁用、IP配置错误或者默认网关丢了。连接状态用ss或netstat我个人习惯用ss因为输出更快、更直观。ss -tnp可以列出所有TCP连接以及对应的进程ss -uanp看UDP。这里有个很实用的技巧当你说“连不上Redis”的时候先看本机是不是已经建立了到Redis端口的连接如果连TIME_WAIT和ESTABLISHED都没有那就不是应用层的问题而是更底层就被挡了。系统资源也要顺手看别忽略top命令它虽然不直接查网络但能帮你确认CPU和内存是否异常因为有些网络故障其实是资源耗尽导致的。比如句柄数满了、连接数满了表现跟网络不通很像但看top和ss -s就能发现端倪。1.3 排查工具的准备与选择排查工具不需要装太多但建议提前把常用的准备好避免故障时才发现没装。Linux一般自带ping、telnet很多发行版默认没有需要yum install telnet或apt install telnet、traceroute、dig、curl、tcpdump这些齐全了90%的排查都能完成。如果没有traceroute可以装mtr用起来更顺手。抓包工具用tcpdump加tshark或者本地用Wireshark可以快速分析包内容。容器场景下docker exec进容器后未必有网络排查工具这时候可以在宿主机上用nsenter进入容器的网络命名空间复用宿主机的工具非常方便。containerd环境也一样用ctr命令找到容器PID再nsenter -t pid -n进入网络命名空间。这个方法比在容器里装包要快得多而且是临时排查不会污染容器镜像。有一个容易忽略的点是命令要能追溯。每次排查完我会把用到的命令和关键输出放到一个本地文件里尤其是线上问题。以后遇到相似的故障直接搜索自己的排查记录比重新敲一遍命令、瞎猜半天要高效得多。2. 端口连通性排查从telnet到更可靠的替代2.1 telnet命令怎么用返回结果怎么看telnet应该是大家最早接触的端口排查命令最基础的用法就是telnet ip 端口。比如要确认某台机器能不能访问数据库的3306端口直接执行telnet 192.168.1.10 3306如果端口通屏幕会显示连接成功甚至进入一个空白的交互界面这时按Ctrl]再输入quit退出。如果不通通常有两种表现一直卡着直到超时或者直接提示Connection refused。前者的意思是包发出去了但没人回应大概率是防火墙丢弃、IP不可达或者路由问题后者说明目标主机收到了请求但目标端口没有服务在监听所以主动回了RST包。很多新手分不清这两种情况其实区别特别重要。超时属于“无声无息”的丢包拒连则说明“我能找到你但你的门没开”。顺着这个思路你能立刻判断下一步是查网络路径还是查服务状态。不过telnet有两个缺点一是很多环境默认没装二是它不适合自动化脚本因为要处理交互式终端。所以在写自动化检查脚本时我更推荐用下面几种方式。2.2 nc、curl与bash /dev/tcp更适合作脚本的替代方案ncnetcat是我最常用来替代telnet的工具一条命令就能完成TCP端口检测而且适合脚本nc -zv -w 3 192.168.1.10 3306-z表示只扫描不发送数据-v输出详细信息-w 3指定超时时间为3秒。端口通会输出类似Connected to 192.168.1.10的信息不通会返回非零退出码这样在shell脚本里就可以直接用$?判断结果。curl也能测端口尤其适合HTTP服务curl -v telnet://192.168.1.10:3306这个命令会建立TCP连接输出详细的握手过程哪怕不是HTTP服务也能看出连接能不能建立。如果你连nc都没有用bash自带的伪设备也可以timeout 3 bash -c echo /dev/tcp/192.168.1.10/3306 echo port open这个方法不依赖额外包很多精简版系统上很好用。不过它有个限制只能判断TCP端口开不开拿不到更复杂的响应内容所以适合快速确认。2.3 UDP端口排查的特殊性很多人会在UDP上栽跟头因为UDP没有三次握手端口通不通不能靠“建立连接”来判断。比如DNS用的53端口、NTP用的123端口用telnet去测根本没有意义。nc加-u参数可以发UDP包但结果不太直观nc -vzu 192.168.1.10 53有些时候只是显示“Connection succeeded”但实际对端并没有应答因为UDP的“通”只是代表本机能发包没收到ICMP端口不可达而已。所以排查UDP更靠谱的办法是抓包看有没有应答或者直接问业务方“你期望的协议交互是什么样的”。另外可以用ss -uanp查看本机UDP监听状态确认服务是不是真的在监听。比如NTP没同步先看UDP 123端口有没有监听再配合抓包看服务端有没有回应链路才清晰。2.4 端口排查的几个高频误区这些年我见过不少“telnet能通但业务不通”的怪事总结下来有几个高频误区。第一服务监听的地址是127.0.0.1而不是0.0.0.0。这种情况从外部telnet必然失败但在本机却能通。遇到“外网访问不了本机正常”第一反应就是看监听地址。用ss -lntp可以看到具体绑定的是哪个IP如果一个服务只监听127.0.0.1你又希望它能被远端访问就得改配置文件里的bind地址。第二云平台安全组和主机防火墙双重限制。你telnet不通可能是云平台的安全组没放行也可能是主机上iptables或者firewalld拦了。光查一层往往会漏。我习惯两边都看用iptables -L -n -v查看规则用systemctl status firewalld看防火墙状态再登录云控制台确认安全组顺序别乱。第三IPv6的问题。有时候你ping的是IPv4地址但DNS解析返回的是IPv6地址而链路上IPv6路由不通表现为“解析正常但连接超时”。解决思路是先用ping -4和ping -6分别测试再用curl -4或curl -6强制指定IP协议族确认是不是IPv6的锅。3. 数据链路与路由排查不只是ping通就完事3.1 ping的进阶用法延迟、丢包与MTUping可以说是网络排查的起点但它不只是“能通就行”。我一般会看三个指标丢包率、延迟和延迟波动。丢包率长期大于0就说明链路不稳定延迟突然升高有可能是带宽被打满或者路由绕路。连续ping几百个包再统计比ping三五个包就下结论靠谱得多。ping -c 100 -i 0.2 目标IP-c 100表示发送100个包-i 0.2表示每0.2秒发一个这样可以比较快地得到统计结果。Windows下对应的是ping -n 100。还有一个非常实用但容易被忽略的参数-M do用来测MTU最大传输单元ping -c 3 -M do -s 1472 目标IP这个命令会发送不允许分片、大小是1472字节的数据包。1472这个数字怎么来的以太网默认MTU是1500减去IP头20字节和ICMP头8字节剩下1472。如果通则说明MTU没问题如果不通或者提示需要分片说明链路上某个设备MTU小于1500可能出现“网页打不开但ping能通”的诡异现象。3.2 traceroute与mtr分段定位丢包点当ping发现丢包或高延迟时下一步就是确认丢包发生在哪一跳。traceroute的原理是发送TTL从1开始递增的包让每一跳的路由器都告诉你“我收到了但我不知道最终主机在哪”。输出结果会显示路径上的每一跳IP和响应时间。不过traceroute一次只发几个包抖动大的时候很难判断。我更推荐mtr它相当于traceroute和ping的结合体会持续探测每一跳并统计丢包率和延迟mtr -r -c 10 目标IP-r是report模式-c 10是探测10次结束后直接输出报告。看输出时有一个重要经验最后一跳之前的中间路由丢包往往不代表链路有问题因为很多路由器的ICMP响应是限速的丢包率高但最终目标不丢包就很正常。真正的判断标准是看最后一跳目标主机的丢包情况最终目标丢包才算链路有问题。还记得有一次线上调用变慢我ping外网IP延迟只有1ms但访问某个内部服务却要卡好几秒。用mtr一看发现流量绕到了另一个网段的网关估计是路由策略问题最后通过调整静态路由解决。没有mtr这个问题可能要排查半天。3.3 tcpdump抓包思路不靠猜看数据说话当排查到“端口通、服务通但业务就是不对”的时候就该上抓包了。tcpdump是Linux下最经典的抓包工具我常用的几个过滤写法是tcpdump -i eth0 host 192.168.1.10 and port 3306 -nn -w /tmp/mysql.cap-nn表示不解析域名和端口名-w指定保存文件。抓完把文件拖到本地用Wireshark打开或者直接在服务器上用tshark -r查看。如果是临时快速查看可以不加-w直接打印包内容tcpdump -i eth0 tcp port 80 -nn -c 10抓包的时候重点看TCP三次握手SYN、SYN-ACK、ACK是否完整有没有大量重传有没有RST包。我见过一种情况客户端与服务端三次握手成功但数据传输时客户端频繁重传最后连接被RST。这种问题靠telnet完全看不出来只能通过抓包看到“包已经发出去了但对端没有ACK”最终定位到是中间链路MTU问题。另外抓包时要注意网卡和网段本机有多块网卡的先确认流量走的是哪一块。使用ip route get 目标IP可以查看发往某个IP的流量会从哪个网卡出去避免抓错网卡导致什么都看不到。3.4 防火墙与iptables排查顺序防火墙导致的网络问题非常隐蔽因为很多服务看起来正常但请求就是进不来。遇到这种情况我习惯按这个顺序排查先确认服务监听地址ss -lntp再查宿主机防火墙iptables -L -n -v或firewall-cmd --list-all最后查云平台安全组。三层都放行才能通。iptables输出里我主要看INPUT链的Policy是ACCEPT还是DROP以及有没有匹配的规则。如果Policy是DROP且没有放行规则那端口不通毫无悬念。这里有个细节iptables -L默认不显示规则匹配次数加上-v才能看到每个规则被命中多少次能帮你判断到底是哪条规则在起作用。修改防火墙规则要特别谨慎线上的机器最好先备份原有规则并且不要一口气清空链。改之前用iptables-save /tmp/iptables.rules.$(date %F)备份改完单独验证验证完再固化。很多线上事故就是因为改防火墙时手滑把规则清空了导致服务瞬间全断。4. DNS与应用层排查域名解析的坑4.1 DNS解析第一步dig与nslookup域名解析是应用层最容易出问题又最容易被忽略的环节。我的习惯是先确认“域名到底解析到了哪个IP”再用这个IP去做连通性测试。dig是Linux下最顺手的工具dig short example.com这会返回A记录IPv4或者AAAA记录IPv6。想看更完整的信息可以去掉short能看到查询的DNS服务器、TTL、返回结果等。用dig 8.8.8.8 example.com可以指定某个DNS服务器比如你想确认是不是本地DNS缓存的问题就用公共DNS直接把解析结果拉出来对比。Windows环境下没有dig一般用nslookupnslookup example.comnslookup也会显示当前使用的DNS服务器和解析结果适合快速排查。但输出格式不如dig易读所以我的建议是如果有条件装一个digWindows也可以装或者用在线DNS查询工具辅助。4.2 本地域名配置与缓存/etc/hosts和resolv.conf解析不对不一定是DNS服务器的问题也有可能是本机配置被改过。Linux下/etc/resolv.conf定义的是DNS服务器顺序/etc/hosts则可以直接指定域名到IP的映射。有时候开发环境会往hosts里加一条测试映射忘了删上线后就会“域名解析到内网IP”或者“解析到旧IP”表现就是服务访问异常但别的地方都正常。DNS缓存也是个经典坑。systemd-resolved、nscd、dnsmasq都有自己的缓存改完DNS记录后线上总是有一批机器还在用旧IP。排查时可以手动清一下缓存systemd-resolve --flush-caches或者nscd -i hosts在CDN场景下这个现象尤其常见。你改了一条DNS记录刷新后自己电脑上解析正常但服务器上还是旧IP大概率就是服务器上有DNS缓存。所以遇到“为什么我本地能通服务器不能通”的奇怪问题顺手查一下服务器DNS解析结果和缓存能省很多时间。4.3 应用层请求排查curl、openssl、redis-cli应用层的问题工具要跟着协议走。HTTP服务用curl最多尤其要会用-v和-w。curl -v https://example.com/api/health-v会显示TLS握手过程、请求头、响应头能很直观地看到连接建立在哪一步出现问题。如果只想看耗时用-w输出时间明细curl -o /dev/null -s -w DNS解析:%{time_namelookup}s 连接:%{time_connect}s TLS握手:%{time_appconnect}s 总耗时:%{time_total}s\n https://example.com这一条命令把网络耗时拆开了是排查“接口响应慢”的利器。如果DNS解析耗时很高就查DNS如果连接耗时长就查端口和防火墙如果TLS握手慢就要看证书链和双方密码套件协商了。数据库和其他中间件也有自己的命令比如Redis用redis-cli ping如果返回PONG说明端口和服务都正常如果超时或者DENIED再根据报错查网络或者ACL。Kafka有kafka-broker-api-versions之类的工具可以检测Broker连通性。总之不要停留在“端口能通就行”的层面要试着用对应的客户端工具确认协议层面也正常。HTTPS证书问题用openssl来排查openssl s_client -connect example.com:443 -servername example.com这条命令会输出证书链、有效期和握手结果如果证书不匹配或过期这里会报错。很多“App无法访问”的诡异问题最后查出来就是证书链少发了一张中间证书。4.4 从日志反推网络问题当应用层命令也看不出问题的时候日志就是最后的突破口。我一般会把时间点作为联合主键拿客户端报错的时间去查负载均衡的访问日志再查应用的access log最后查中间件日志和系统日志。每一步都对不上就继续往下挖如果某一层日志有异常网络排查就变成日志排查了。Linux系统日志一般看journalctl -u 服务名nginx看/var/log/nginx/access.log和error.logTomcat看catalina.out。有一个技巧是先grep出错误前后各几秒的日志而不是只看那一条错误。很多网络故障是连锁反应错误前后的日志能帮你理清因果链。5. 高频故障场景实战把命令串起来用5.1 远程数据库不通或者很慢以MySQL为例假设应用报错“无法连接数据库”我会这样串命令排查。第一步在本机确认MySQL端口telnet 192.168.1.20 3306如果不通再去数据库服务器上看监听地址和防火墙ss -lntp | grep 3306 iptables -L -n -v | grep 3306如果通但连接慢多半是DNS反查或者连接数满了。MySQL默认会做反向解析DNS有问题的时候连接就会卡。解决办法是在配置里加skip-name-resolve。如果连接直接被拒绝且应用账号没问题就要查max_connections是不是满了用mysqladmin -u root -p status看Threads和Connections。记住端口通只是第一关连接数、权限、ACL都可能成为下一道坎。5.2 容器环境里的网络排查容器环境比传统虚拟机多了一层网络排查思路略有不同。首先要分清问题发生在容器内、宿主机还是跨主机。在宿主机上用docker ps和docker inspect 容器名看端口映射和网络模式。进入容器内的方式我用得比docker exec多的是nsenterPID$(docker inspect -f {{.State.Pid}} 容器名) nsenter -t $PID -n ip addr nsenter -t $PID -n ss -lntp这样能直接在宿主机的命名空间里看到容器内部的IP和端口省去在容器里装工具的麻烦。containerd环境下先ctr c list拿到容器ID再用ctr c info拿到PID同样用nsenter进入网络命名空间。跨主机容器通信的问题往往要看CNI插件配置和宿主机路由。比如weave、flannel这些网络插件都有对应的命令像weave status可以看连接状态。遇到容器之间不通先确认Pod/容器IP能不能ping通不能ping就用traceroute或ip route看路由是不是少了再确认宿主机之间是不是有防火墙挡了VXLAN或Overlay端口。容器网络排查的本质还是那三板斧IP、端口、路由只是多套了一层命名空间而已。5.3 SSH连接卡顿、中断与命令后台化SSH问题也是全栈工程师经常遇到的。连接卡在输入密码之前八成是DNS反查问题服务端/etc/ssh/sshd_config里加上UseDNS no基本能解决。连上之后经常断要么是网络链路不稳定要么是TCP keepalive设置太短。可以在客户端配置里加ServerAliveInterval 60 ServerAliveCountMax 3这样客户端每60秒发一个保活包连续3次没回应才断开。还有一个经典问题SSH执行过程中退出命令还会继续吗这个要分情况。如果你执行的是sleep 10然后直接关掉终端命令进程会收到SIGHUP信号被终止但如果用了nohup把命令放后台nohup long-running-command /tmp/out.log 21 命令就会在退出SSH后继续跑。理解这个原理后线上需要长时间执行的任务我都会老老实实加nohup或者直接上tmux/screen避免人走命令断。排查SSH问题history命令也能派上用场。有时候你会突然忘了自己上次对某台机器做过什么改动先敲history看看之前的操作记录会比满世界翻配置更快。还有xshell用户常见的“回退目录”操作其实只是cd -这个命令会自动在两个最近切换的目录之间来回跳效率很高。5.4 Windows环境与系统维护类排查虽然我们是全栈但偶尔也会被Windows服务器或者自己电脑的网络问题绊住。Windows下最基本的排查命令是ping、ipconfig、netstat -ano很多Linux命令用不了但思路一样。比如端口占用Windows上找哪个进程占用了8080netstat -ano | findstr 8080 tasklist | findstr PIDWindows下DNS刷新是ipconfig /flushdns重置网络栈的终极手段是netsh winsock reset和netsh int ip reset执行完要重启才会生效。有时候你发现C盘满了导致服务起不来命令行顺手清理临时文件也方便比如cleanmgr打开磁盘清理或者直接用del /q /f /s %TEMP%\*。还有经典场景gpedit.msc打不开多半是系统版本不支持或者环境变量缺失先确认是不是专业版及以上再确认C:\Windows\System32路径下面有没有这个文件没有就去别的机器拷贝或者修复组件。Windows下脚本闪退也比较常见。双击.bat一下窗口就消失看不出报错我一般会先打开cmd手动执行脚本或者用cmd /k保留窗口cmd /k script.bat这样窗口不会关闭报错信息能完整显示。脚本跑完关闭则是用exit。这些小命令不算网络排查的核心但遇到“自己的电脑先挂了”的时候很有用。6. 常见问题与排查技巧速查表6.1 症状与命令对照速查表为了减少你自己翻上面内容的时间我整理了一个对照表。它不代表所有场景但能覆盖常见的90%问题。症状优先排查命令可能原因ping不通ip addr、ip route、iptables -L -n -v网卡未启用、路由缺失、防火墙丢包能ping通但端口不通ss -lntp、telnet ip port、nc -zv服务未监听、防火墙挡了、监听地址错误端口通但业务超时curl -v、tcpdump、mtrMTU问题、中间设备丢包、应用卡死域名解析正常但访问异常dig 8.8.8.8、curl -4、curl -6DNS缓存、IPv6路由不通、hosts配置错误延迟高mtr -r -c 20、ping -i 0.2链路拥塞、路由绕路、带宽打满SSH经常断客户端加ServerAliveInterval、服务端UseDNS no连接超时、DNS反查、网络抖动容器服务外部访问不了docker inspect、nsenter -t PID -n ss -lntp端口映射错误、容器内监听127.0.0.16.2 多平台命令对照指南日常用的机器五花八门我经常会同时操作Windows跳板机和Linux服务器所以整理了一份对照表方便你快速切换。功能LinuxWindows查看IP地址ip addripconfig /all查看路由ip routeroute print查看连接ss -tnpnetstat -ano测试端口nc -zv/telnettelnet/Test-NetConnection域名解析dig/nslookupnslookup/Resolve-DnsName清DNS缓存systemd-resolve --flush-cachesipconfig /flushdns抓包tcpdumppktmon/ Wireshark防火墙iptables -L -n -vnetsh advfirewall show allprofiles测连通性ping -c 4ping -n 4macOS和Linux大部分命令类似只是默认没有ss可以用lsof -i :端口来查端口占用netstat -anv也能看连接状态。6.3 一些值得坚持的排查习惯把排查命令背得再熟也不如养成一套自己的排查流程。我的流程大概是这样先记录现场时间、报错、改动再复现问题然后分层排查每查完一层就记录结果最后定位到根因并修复修复后还要验证并写进文档。写文档是我特别想强调的习惯。很多人排查问题很厉害但解决完就忘了下次遇到类似问题又要重新排查一遍。我现在会把每次线上故障的排查过程和最终根因写成简短笔记包括命令和关键输出下次直接搜索关键词就能找到。这个习惯帮我在很多重复问题上省了至少一半时间。还有一个细节排查过程中不要同时改多个变量。很多人因为着急一会儿改配置文件一会儿重启服务一会儿加防火墙规则结果问题解决了也不知道是哪一个改动生效的。正确的做法是每次只改一个地方验证一次这样即使改错了也能快速回滚。6.4 安全地使用排查命令排查网络问题时有些命令是不能随便在别人的网络或生产环境里乱跑的。比如arpspoof这类工具是用来做ARP欺骗测试的属于渗透测试范畴没有授权的情况下使用会有很大的风险也会影响其他用户。作为普通开发者和运维我们的目标是定位和解决自己系统的问题而不是去探测别人的网络。渗透方向的内容比如sqlmap、CTF里的passthru漏洞利用这类技巧是安全研究人员在合法授权范围内使用的。日常开发排查根本用不到也不应该用。我们掌握网络排查命令的初衷是为了让自己负责的应用和服务更稳定不是为了绕过限制或攻击他人。把这个边界守好既是对自己负责也是对他人的系统负责。还有一个小提醒在用命令查看系统信息或抓包的时候注意别把敏感信息泄露到公共平台。比如数据库IP、密码、Token这类内容打日志或者截图分享前要打码。生产环境的抓包文件更要注意保管因为里面可能含有真实的业务数据。我在实际排查过程中还养成一个习惯安全地记录命令历史。history命令在bash里默认最多保留1000条但线上环境的操作我还是会保留到单独的分级日志里方便审计和回溯。合理使用命令History并保留足够的审计时间是做网络排障的基本职业素养。最后再分享一个小技巧当你实在不知道从哪查起的时候从头到尾走一遍ping - telnet - curl - 日志这条链路。这个顺序看着简单但能稳定地把问题从低层到高层过滤一遍至少能排除掉80%的干扰项。剩下的问题靠tcpdump抓包和日志基本都能定位。把这些命令用熟了你会发现网络排查没有想象中那么难它和写代码一样是有套路、有规律可循的技能。
