北京独立服务器网络故障，九成出在链路和路由两层，按从物理到逻辑的顺序排查，才能真正定位问题。
刚接触北京独立服务器的朋友，遇到网络不通常常一脸懵，有人急着重启，有人反复重装系统，结果问题依旧，这其实是因为没找对排查的起点，网络数据从你的服务器出发，到用户终端，中间要经过网卡、交换机、路由器、运营商骨干网等无数节点，任何一个环节出问题，表现都是“连不上”，但不同层级的故障，排查方法和判断依据完全不同，如果把网络比作一条送快递的路，链路层是路况和路障，路由层是导航和分岔口，今天咱们就把这两层拆开,一步步看看到底怎么查。
链路层的排查思路：先确认路是通的
链路层指的是从服务器网卡到交换机、再到对端设备这一段物理链路，这个层面的问题，通常表现为“彻底不通”或“疯狂丢包”，排查链路问题,遵循由近及远的原则。
第一步：看网卡和物理连接状态
这是最基础的一步，但很多人会跳过，登录服务器后，先执行 ip a 或 ethtool eth0 查看网卡状态，重点看网卡是否处于 UP 状态，以及 Link detected: yes 是否出现，如果显示 DOWN 或 no carrier，说明物理链路断了可能是网线松了、光模块坏了,或者交换机端口被关了。
业内专家指出，机房物理线路故障导致的服务中断，占比相当高，如果是托管服务器，直接联系机房值班人员检查跳线是最快的办法，如果是云服务器，控制台通常有“监控”或“状态检测”页面,能直接看到底层物理链路是否正常。
第二步：检查IP配置与ARP解析
物理链路通了，不代表IP能通，执行 ip addr 查看当前IP配置，确认IP、掩码、网关是否配置正确，一个常见的坑是：IP和网关不在同一网段，导致数据包发不出去，此时可以执行 arp -a 查看网关的ARP解析记录，如果只有网关的ARP条目，但无法解析外部IP的MAC地址，说明二层通信有问题，尝试 ping 网关IP，如果网关都不通,问题基本锁定在链路层或交换机端口配置上。
第三步：用traceroute区分链路瓶颈
链路层的问题不一定表现为“完全不通”，也可能是“慢”，此时用 traceroute -n -T -p 80 目标IP（TCP模式）或 mtr 目标IP 来逐跳探测。mtr是排查链路问题的利器，它持续发送探测包并显示每一跳的丢包率和延迟，如果第一跳（通常是网关）丢包率就很高，说明服务器出口带宽被打满或交换机端口有错包，可以登录交换机或机房后台查看端口流量和CRC错误计数，统计数据显示，
大量北京独立服务器客户的所谓“高延迟”问题，其实是本地机房出口拥堵造成的,与远端无关。
路由层的排查思路：查看导航怎么走
链路层通了，数据能到达网关，但用户依然访问不了，就要看路由层了，路由决定数据包从服务器出发后，下一步跳转到哪里，路由错误的表现很典型：内网通、外网不通，或者某些地区能访问、某些地区超时。
第一步：查看本机路由表
执行 ip route 查看完整路由表，默认路由（default via 网关IP dev eth0）必须存在，如果默认路由丢失，所有非本网段的访问都会失败，部分IDC会分配多个IP或配置策略路由，需要检查 ip rule 里的策略是否正常，行业共识认为，配置双IP或双网卡时，路由表冲突是最常见的故障源，此时可以对比同机房其他正常服务器的路由表,找出差异。
第二步：使用BGP视角看跨网路由
北京地区有多个运营商网络，电信、联通、移动之间互联互通，路由策略复杂，当用户反馈“移动宽带打不开，电信秒开”时，问题多半出在跨网路由的回程路径上，此时可以在本地执行 traceroute 看去程，但回程路径本机看不到，需要借助第三方工具，比如在服务器上安装 besttrace 或使用在线多地拨测工具，从不同运营商节点反向探测服务器IP，观察回程走向，如果回程绕路严重，比如从北京绕到上海再回北京，延迟必然高，解决思路是联系服务商调整BGP路由策略，或者考虑使用BGP多线线路的北京独立服务器，租用这类机器时，价格通常比单线略高,但换来的是跨网访问的稳定性。
第三步：检查防火墙与安全组规则
路由层还有一个经常被忽略的“隐形关卡”防火墙，很多情况是路由表正常，数据包也到了服务器，但被本机防火墙丢弃，执行 iptables -L -n -v 或 firewall-cmd --list-all 查看规则，重点检查 INPUT 链是否有针对源IP的DROP策略。一个典型场景是：服务器被DDoS攻击后，机房加了黑洞策略或防火墙封禁了特定IP段，此时外部访问超时，但本机路由和链路都正常，解决方法是联系机房确认是否触发黑洞,或登录云控制台查看安全组入方向规则。
链路和路由排查区别：两手抓，两手都要硬
很多人会把链路和路由混为一谈，觉得都是“网络不通”，其实两者的排查侧重点完全不同,写下来对比更清楚。
| 排查维度 | 链路层 | 路由层 |
|---|---|---|
| 关注对象 | 物理连接、网卡、交换机端口 | IP路径、路由表、策略 |
| 常见故障 | 网线松动、光模块故障、端口down | 路由丢失、BGP震荡、防火墙拦截 |
| 排查命令 | ethtool、arp、ping网关 | ip route、traceroute、iptables |
| 判断标准 | 链路是否up、延迟是否稳定 | 路径是否最优、是否可达远端 |
如果你发现 ping 网关 正常，但 ping 公网IP 超时，问题大概率在路由层，反之，如果网关都ping不通，再查路由表就是浪费时间。先链路后路由，这个顺序不能乱。
高频故障场景的实战排查
套用上面的思路,来看几个北京独立服务器用户最常遇到的场景。
服务器被DDoS，IP被黑洞
现象：所有外部访问超时，服务器CPU和带宽正常，排查时先看链路，网卡UP，网关通，再看路由，默认路由在，最后检查防火墙规则，发现来自公网的SYN包全被丢弃，联系机房确认，答复是“IP因攻击被封禁2小时”，这种场景下，链路和路由排查均无异常，问题出在机房的流量清洗策略上，长期被攻击的话,建议配置高防IP或启用CDN分流。
北京访问快，外地访问慢
现象：本机测试一切正常，但外地用户反馈延迟高，用mtr从服务器反向追踪到外地节点，发现中间某一跳在北京联通骨干网处丢包率攀升，这通常不是服务器的链路问题，而是运营商互联带宽满载，解决思路是：如果服务器是单线，考虑切换为BGP多线，让不同运营商用户走各自最优路径，如果已经是BGP线路，可以尝试联系服务商优化路由前缀,让回程路径更加直连。
更换IP后，部分区域无法访问
现象：刚更换了IP，ping不通，但机房说线路正常，此时先查链路，网关通，再查路由，发现去程路径正常，但回程路径在某一跳丢失。根因是新的IP段尚未被各运营商的路由器完全学习，或者被部分小运营商过滤了，等待几小时到24小时，路由传播完成后通常自动恢复，如果持续不通,让机房检查是否在防火墙里对旧IP做了永久封禁规则。
北京独立服务器网络排查的通用工具箱
把上面用到的命令和工具整理成清单,方便你实际操作时对照。
- 链路排查：
ethtool eth0（查看网卡速率和链路状态）、mii-tool eth0（老系统查物理连接）、arp -a（查看二层邻居表） - 路由排查：
ip route show table all（查看所有路由表）、ip rule list（查看策略路由）、traceroute -n -T -p 443 目标IP（TCP探测,绕过ICMP限制） - 综合诊断：
mtr -rw 目标IP（持续追踪并生成报告）、ping -f -s 1472 网关IP（测MTU值,防止分片丢包） - 第三方工具：besttrace（回程路由测试）、ITDOG在线多节点拨测（查看不同地域的访问情况）
一个容易被忽略的细节：MTU值
链路和路由都正常，但大包就是不通，小包却没事，这多半是MTU不匹配，北京一些老机房交换机默认MTU为1500，但部分线路启用了PPPoE或VXLAN封装，导致实际可用MTU变小，排查方法：ping -M do -s 1472 目标IP，如果提示 Frag needed，说明路径上存在MTU限制，此时调整服务器网卡MTU为1450或1400,问题就能解决。
常见问题快速解答
Q：北京独立服务器网络延迟突然变高，一定要先看路由吗？
A：不一定，建议先看链路层的丢包率，用 ping -c 100 网关IP 测试到网关的稳定性，如果网关延迟都飘忽不定，说明本地链路或机房出口有问题，此时查路由是徒劳的，只有当网关延迟稳定在1ms以内，而到公网延迟变高时,才需要进入路由层排查。
Q：链路和路由排查都正常，但网站就是访问不了，还能查什么？
A：检查应用层和系统层，执行 ss -lntp 查看80/443端口是否监听，curl -I 127.0.0.1 测试本机Web服务是否响应，另外确认系统负载是否过高，uptime 和 free -h 能快速判断，如果以上都正常，最后检查DNS解析是否生效,新租用的北京独立服务器经常因为域名未备案或解析未生效导致访问失败。
Q：如何判断是机房线路问题还是服务器自身问题？
A：在服务器上执行 mtr -rw 8.8.8.8，观察前几跳（本地网关和机房出口）的丢包情况，如果前几跳丢包率就高，而后面恢复正常，说明是机房出口拥塞，如果前几跳正常，后面开始丢包，说明是运营商骨干网或远端问题，如果所有跳都正常，但最终目标不可达，那问题出在服务器本机的防火墙或应用层，这个逻辑适用于绝大多数场景,也是判断责任方的有效依据。
网络排查没有捷径，但一定有章法，链路层管“通不通”，路由层管“走不走得对”，按这个思路逐层排除，绝大多数北京独立服务器的网络故障都能在半小时内定位，下次再遇到连不上，先别急着重启，从网卡开始,一步步来。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/565042.html
