应按物理层→链路层→网络层→传输层→应用层自下而上分层排查：先用ip link和ethtool确认物理连通性，再ping网关验证IP可达性，接着用ss和nc检查端口与服务，最后通过curl、dig等定位DNS或应用问题。
要判断 Linux 网络连接性能问题出在哪一层，不能靠猜，得按协议栈从底向上、由近及远地系统排查。核心思路是：先确认物理通路是否正常，再验证 IP 层可达性，接着检查传输层端口和服务，最后落到应用行为本身。
物理与链路层：确认硬件和本地通信基础
很多“网络慢”或“连不上”的问题，其实卡在最底层。网线松了、光模块异常、网卡协商失败，都会直接导致丢包或高延迟。
- 用 ip link show 查接口状态，重点关注是否为 UP、LOWER_UP，以及 RX/TX errors/dropped 是否持续增长
- 运行 ethtool eth0（替换为实际网卡名），确认 Link detected: yes、Speed 和 Duplex 是否匹配对端设备；若 Speed 显示 10Mb/s 或 Duplex 为 Half，极可能是双工不匹配
- 执行 arping -I eth0 192.168.1.1（目标网关）测试二层可达性。若无响应但 ping 同网段其他 IP 成功，说明 ARP 解析或网关 MAC 存在异常
网络层：验证路由、IP 分配与转发路径
这一层决定数据包能不能“找对门”。子网掩码错一位、默认路由缺失、防火墙策略拦截，都可能让流量在中途消失。
Linux Ai Server
下载
Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。
- 用 ip addr show 检查 IP 是否获取正确——避免出现 169.254.x.x 这类链路本地地址，那说明 DHCP 失败或静态配置有误
- 执行 ip route show default 确认默认网关存在；再用 ip route get 8.8.8.8 查看去往外部地址的实际出口路径
- 运行 mtr -r 8.8.8.8（或 traceroute），观察哪一跳开始出现高延迟或 100% 丢包。若第一跳就失败，问题在本机或网关；若中间某跳断开，需联系对应网络管理员
传输层：聚焦端口监听、连接建立与状态异常
能 ping 通 IP 不代表服务可用。TCP 三次握手失败、端口未监听、连接队列满、防火墙封端口，都是常见瓶颈。
- 在服务端执行 ss -tuln | grep :80（替换端口号），确认进程确实在监听且绑定正确地址（0.0.0.0 或具体 IP）
- 从客户端用 nc -zv example.com 443 测试端口连通性。若超时，再用 tcpdump -i any port 443 -c 20 抓包，看是否有 SYN 发出、是否收到 SYN-ACK
- 检查内核统计：netstat -s | grep -A 5 "Tcp:" 关注 retransmits、connection resets 和 timeouts，数值突增往往指向链路不稳定或远端拒绝
应用与 DNS 层：排除解析失败、协议行为与缓存干扰
用户感知的“打不开网站”，大概率不是网络不通，而是域名没解析、TLS 握手卡住、或应用自身响应慢。
- 用 dig baidu.com @114.114.114.114 +short 绕过本地 DNS 直接查询，对比 nslookup baidu.com 结果，确认是否 DNS 配置错误或污染
- 执行 curl -v https://example.com，观察卡在 DNS 解析、TCP 连接、TLS 握手还是 HTTP 响应阶段；加 --connect-timeout 5 可隔离连接耗时
- 若使用 systemd-resolved，可运行 systemd-resolve --statistics 查看缓存命中率；必要时 sudo systemd-resolve --flush-caches 清理
