全栈工程师必备：网络排查命令实战手册

我一直觉得，全栈工程师最值钱的技能不是会多少个框架，而是遇到问题的时候能不能快速把范围缩小到某一个具体的层。尤其是网络问题，它不会只属于运维，写接口的人会遇到“前端说后端连不上”，写前端的人会被问“为什么请求超时”，做部署的人要解释“为什么容器起来了但访问不了”。网络排查命令手册这种东西，看着像给网工准备的，实际上是我们每天都在用的救命工具。今天我就把日常用得最多的排查命令和思路整理出来，按“从下往上、从近到远”的顺序讲，尽量说人话，每一步都告诉你为什么要这么做，以及踩过的坑在哪里。不管是刚转全栈的新手，还是已经被线上问题折磨过几轮的老人，这篇都值得收藏。

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：更适合作脚本的替代方案

nc（netcat）是我最常用来替代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的进阶用法：延迟、丢包与MTU

ping可以说是网络排查的起点，但它不只是“能通就行”。我一般会看三个指标：丢包率、延迟和延迟波动。丢包率长期大于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，一般用nslookup：

nslookup example.com

nslookup也会显示当前使用的DNS服务器和解析结果，适合快速排查。但输出格式不如dig易读，所以我的建议是：如果有条件，装一个dig，Windows也可以装，或者用在线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.log，Tomcat看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多的是nsenter：

PID=$(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 2>&1 &

命令就会在退出SSH后继续跑。理解这个原理后，线上需要长时间执行的任务，我都会老老实实加nohup，或者直接上tmux/screen，避免人走命令断。

排查SSH问题，history命令也能派上用场。有时候你会突然忘了自己上次对某台机器做过什么改动，先敲history看看之前的操作记录，会比满世界翻配置更快。还有xshell用户常见的“回退目录”操作，其实只是cd -，这个命令会自动在两个最近切换的目录之间来回跳，效率很高。

5.4 Windows环境与系统维护类排查

虽然我们是全栈，但偶尔也会被Windows服务器或者自己电脑的网络问题绊住。Windows下最基本的排查命令是ping、ipconfig、netstat -ano，很多Linux命令用不了，但思路一样。比如端口占用，Windows上找哪个进程占用了8080：

netstat -ano | findstr 8080 tasklist | findstr <PID>

Windows下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、mtr	MTU问题、中间设备丢包、应用卡死
域名解析正常但访问异常	dig @8.8.8.8、curl -4、curl -6	DNS缓存、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.1

6.2 多平台命令对照指南

日常用的机器五花八门，我经常会同时操作Windows跳板机和Linux服务器，所以整理了一份对照表，方便你快速切换。

功能	Linux	Windows
查看IP地址	ip addr	ipconfig /all
查看路由	ip route	route print
查看连接	ss -tnp	netstat -ano
测试端口	nc -zv/telnet	telnet/Test-NetConnection
域名解析	dig/nslookup	nslookup/Resolve-DnsName
清DNS缓存	systemd-resolve --flush-caches	ipconfig /flushdns
抓包	tcpdump	pktmon/ Wireshark
防火墙	iptables -L -n -v	netsh advfirewall show allprofiles
测连通性	ping -c 4	ping -n 4

macOS和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抓包和日志基本都能定位。把这些命令用熟了，你会发现网络排查没有想象中那么难，它和写代码一样，是有套路、有规律可循的技能。