Linux网络诊断需按协议层选用工具：L3/L2用ping、mtr、arp查连通性；L4用telnet、nc、ss、lsof验端口；DNS问题用dig、nslookup、systemd-resolve；路由分析用ip route get、ip rule、tcpdump。
Linux网络诊断不是靠猜，而是用对工具——关键在理解每个命令的定位和适用边界。 丢包、连不通、DNS慢、端口不通、路由绕路……不同现象对应不同层级的排查入口，盲目轮番执行 ping、curl、netstat 只会浪费时间。下面按实际问题场景归类，列出最常用、最不可替代的命令及其典型用法。
一、连通性与基础链路检测（L3/L2 层）
判断“能不能通”，区分是本地配置、网关、中间链路还是目标主机的问题。
-
ping -c 4 www.example.com：验证ICMP可达性，快速确认目标是否响应；加-I eth0指定出口网卡，排查多网卡环境下的路径选择问题 -
mtr -r -c 10 example.com：比traceroute更强，持续探测每跳延迟与丢包率，适合定位中间某跳异常（如运营商节点抖动） -
arp -n或ip neigh show：检查本地ARP表是否正确解析网关MAC，网关不通时优先查此项，常见于VLAN错配或交换机端口down
二、端口与服务可用性验证（L4 层）
IP能通但服务没响应？重点查TCP/UDP端口状态、监听配置和服务进程本身。
-
telnet example.com 80或nc -zv example.com 443：轻量级端口连通测试，不依赖应用层协议，适用于防火墙策略验证 -
ss -tuln | grep :22：查看本机所有监听端口（比netstat更快更准），-tuln分别代表 TCP/UDP、监听、数字地址、不反解 -
lsof -i :3306：定位占用某端口的进程（需root权限查其他用户进程），配合kill -9或服务重启解决端口冲突
三、DNS与域名解析问题定位（应用层前置）
DNS失败会导致所有基于域名的操作卡住，必须单独剥离验证，避免误判为网络或服务故障。
-
dig @8.8.8.8 google.com A +short：指定上游DNS服务器查询A记录，排除本机/etc/resolv.conf配置错误或本地DNS缓存污染 -
nslookup -debug example.com：显示完整查询路径（包括递归过程、权威服务器响应），适合分析CNAME链过长或TTL异常 -
systemd-resolve --status（systemd系统）或resolvectl status：查看当前DNS解析器实际使用的服务器、搜索域及启用状态，确认NetworkManager或systemd-resolved是否接管
四、路由与策略路由分析（网络层转发逻辑）
数据包为何走了不该走的路径？为何从eth1发却从eth0回？策略路由、源地址选择、多宿主配置都可能干扰预期行为。
-
ip route get 192.168.5.100：模拟内核路由决策，输出精确匹配的路由条目、出接口、源IP，比ip route show更直接 -
ip rule show：查看策略路由规则（如基于源地址/标记的路由表选择），多ISP或多网卡场景下常被忽略的关键点 -
tcpdump -i eth0 host 10.1.1.5 and port 53 -w dns.pcap：抓包确认DNS请求是否发出、是否收到响应、源/目的IP是否符合预期，是验证路由+防火墙+NAT协同问题的最终手段
掌握这些命令的核心不在背参数，而在建立“现象→协议层→工具”的映射习惯。一次完整的诊断往往需要组合使用：比如访问超时，先 ping 看连通性，再 dig 确认DNS，接着 telnet 测端口，最后 ss 和 ip route get 查本机状态。工具只是眼睛，逻辑才是大脑。
