物理层连通性是网络诊断前提：先确认网线、网卡、指示灯正常，再用ip link show或lspci检查识别状态；若接口DOWN且无LOWER_UP，需排查网线连接、BIOS启用、固件缺失及虚拟机适配器类型。
确认物理层连通性：网线、网卡、指示灯
物理层不通，上层诊断全是徒劳。先看网卡是否被系统识别：ip link show 或 lspci | grep -i ethernet。如果 ip link 中对应接口状态是 DOWN 且无 LOWER_UP 标志，别急着查路由——先检查：
• 网线是否插牢，交换机端口指示灯是否亮
• 服务器是否启用板载网卡（BIOS 中可能被禁用）
• dmesg | grep -i "eth\|enp\|firmware" 是否报固件缺失（如 e1000e: Firmware not found）
• 虚拟机场景下，确认虚拟网络适配器类型（e1000 兼容性好，vmxnet3 需装 VMware Tools）
验证 IP 层配置与本地通信：地址、子网、ARP
能 ping 通自己但 ping 不通同网段其他机器？重点查三件事：
• ip addr show 输出中该接口是否有有效 IPv4 地址，掩码是否正确（常见误配成 /32）
• ip route show 是否存在直连路由（如 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.10），缺了就说明子网配置失效
• arp -n 查目标 IP 是否有对应 MAC 条目；若为空，执行 ping -c1 192.168.1.1 后再查 —— 没反应说明 ARP 请求发不出去，大概率是防火墙丢包或交换机 ACL 限制
排查路由与转发：本机路由表、IP 转发、策略路由
跨网段不通时，不能只盯着默认网关。分步验证：
• ip route get 8.8.8.8 显示实际选中的出接口和下一跳，比 ip route show default 更可靠（尤其有多网卡时）
• 若返回 RTNETLINK answers: No such process，说明无匹配路由，需检查静态路由或 DHCP 是否下发失败
• sysctl net.ipv4.ip_forward 必须为 1（仅当本机作网关/转发用途）
• 有策略路由（ip rule）时，ip route show table 100 等对应表必须存在且含有效路由，否则流量静默丢弃
抓包定位传输层问题：tcpdump 过滤关键字段
应用连不上（如 curl 超时、telnet 拒绝连接），光看 netstat 不够。直接抓包看三次握手是否完成：
tcpdump -i eth0 -nn 'host 10.0.2.15 and port 22' -w ssh.pcap
更高效的做法是边抓边过滤：
• 只看 SYN 包：
tcpdump -i eth0 'tcp[tcpflags] & tcp-syn != 0 and tcp[tcpflags] & tcp-ack == 0'• 确认是否收到 SYN-ACK：
tcpdump -i eth0 'tcp[tcpflags] & (tcp-syn|tcp-ack) == (tcp-syn|tcp-ack) and dst port 80'• 如果客户端发出 SYN，服务端没回 SYN-ACK，但服务端抓包也看不到 SYN → 流量在中间被防火墙/DROP 规则拦截
• 注意：容器或 NetworkManager 管理的接口名可能是
ens33、enp0s3，别硬写 eth0
层层递进的关键在于「每层只验证本层职责」：物理层不管 IP，IP 层不猜端口，传输层不查 DNS。最容易被跳过的是 ARP 和策略路由这两环，一不留神就卡半天。
