2、网络层故障排查：IP地址配置错误、子网掩码与网关问题、DNS解析失败、路由追踪实战
网络层出问题，说白了就是你的CMS系统跟外界“失联”了。我干运维这些年，碰到的通讯故障里，十有七八都卡在这一层。很多开发同事一上来就查应用日志，折腾半天发现是IP配错了，你说冤不冤？
这一章，咱们就把网络层这几个“硬骨头”啃下来。我会结合自己踩过的坑，带你走一遍排查流程。
2.1 IP地址配置错误——最基础的“门牌号”问题
IP地址就像你家门牌号。写错了，快递员肯定找不着门。CMS服务器之间通讯，第一步就是看IP对不对。
常见症状：
- ping 对方IP，返回 “Destination Host Unreachable”
- 应用日志里报 “Connection refused” 或 “No route to host”
- 同一网段内能通，跨网段就不行
排查三板斧：
- 先看自己： 在服务器上执行
ip addr或ifconfig，确认本机IP、子网掩码、网关是否跟规划一致。我见过最离谱的一次，有人把测试环境的IP写到了生产配置里，结果两台机器IP冲突，整个CMS前端挂了半小时。 - 再看邻居： 用
arp -a查看ARP缓存。如果目标IP的MAC地址是incomplete，说明二层就没通，别急着往上层找。 - 最后看配置： 检查CMS的配置文件（比如
application.properties或config.php），确保数据库、缓存、API网关的IP地址没写错。尤其是微服务架构，服务发现中心的地址一旦配错，整个集群都连不上。
2.2 子网掩码与网关问题——你家的“小区大门”
子网掩码决定了你的“小区范围”，网关则是“小区大门”。这两个参数配错了，你连小区都出不去，更别说访问外网或其他网段的服务了。
典型场景：
- CMS管理后台能打开，但无法从外网访问API接口
- 应用服务器能ping通数据库服务器IP，但数据库客户端连不上
排查方法：
| 检查项 | 命令/方法 | 预期结果 |
|---|---|---|
| 子网掩码 | ip addr | grep inet |
掩码与规划一致（如 255.255.255.0） |
| 默认网关 | ip route | grep default |
网关IP存在且可达 |
| 网关连通性 | ping 网关IP |
能收到回复 |
避坑指南： 我曾经遇到一个案例，CMS的图片服务器突然无法上传文件。查了半天，发现是运维同事在调整网络时，把网关的掩码从24位改成了16位。结果服务器以为网关跟自己不在同一个广播域，所有跨网段流量都走了错误的路由。嗯，这种低级错误，往往最隐蔽。
systemctl restart network 或 ifdown/ifup），否则配置不会生效。别问我怎么知道的……
2.3 DNS解析失败——你记不住门牌号，总得有个“电话本”
CMS系统里，很多组件之间是通过域名通信的，比如 db.cms.internal 或 redis.cluster.local。DNS就是那个“电话本”。电话本坏了，你喊破嗓子也没用。
症状表现：
- 应用日志报 “UnknownHostException”
- curl 域名超时，但 curl IP 地址正常
- nslookup 或 dig 命令返回 “server can't find”
排查步骤：
- 检查本地DNS配置： 查看
/etc/resolv.conf，确认 nameserver 地址是否正确。我习惯至少配两个DNS服务器，一个主一个备。 - 测试解析： 用
nslookup your-cms-domain.com或dig your-cms-domain.com。看返回的IP是不是你预期的那个。 - 检查hosts文件： 有时候运维为了临时调试，会在
/etc/hosts里写死域名映射。如果写错了，DNS解析就会被“劫持”。 - 检查DNS缓存： 有些系统会缓存DNS结果（比如 nscd、systemd-resolved）。可以执行
systemctl restart nscd或resolvectl flush-caches清一下缓存。
实战经验： 有一次CMS的搜索服务突然变慢，查了半天发现是DNS解析耗时从1ms飙升到了500ms。原因是上游DNS服务器挂了，备用的DNS响应极慢。最后我们在本地部署了一个DNS缓存服务器（dnsmasq），问题才彻底解决。你想想看，一个DNS问题，差点让整个搜索功能瘫痪。
2.4 路由追踪实战——顺着网线找“断点”
当网络不通，但IP和网关看起来都没问题时，就该路由追踪上场了。它能告诉你数据包走到哪一步“迷路”了。
常用工具：
traceroute（Linux）tracert（Windows）mtr（更强大，结合了 ping 和 traceroute）
实战案例：
假设你的CMS应用服务器（192.168.1.10）连不上数据库服务器（10.0.0.20）。我们来跑一次路由追踪：
# 在应用服务器上执行
traceroute -n 10.0.0.20
# 输出示例
traceroute to 10.0.0.20 (10.0.0.20), 30 hops max, 60 byte packets
1 192.168.1.1 0.5 ms 0.4 ms 0.4 ms
2 172.16.0.1 1.2 ms 1.1 ms 1.1 ms
3 * * *
4 10.0.0.20 5.3 ms 5.2 ms 5.1 ms
看到第3跳全是 * * * 了吗？这说明数据包在 172.16.0.1 之后丢失了。可能是防火墙拦截，也可能是路由表没配好。
解读技巧：
- 如果前几跳正常，中间某跳超时，大概率是那台设备的问题（防火墙、ACL、路由黑洞）
- 如果最后一跳超时，但前面都通，可能是目标主机自己没回包（比如防火墙禁ping）
- 如果第一跳就超时，检查本机网关配置
mtr -r -c 10 10.0.0.20。跑完一看，哪个节点丢包多，一目了然。
知识体系总览
下面这张图，帮你把网络层排查的核心逻辑串起来。遇到问题，按这个流程走，基本不会漏掉关键点。
这张图把排查顺序理得很清楚：从IP配置开始，一步步往下走。记住，别跳步骤。我见过太多人一上来就 traceroute，结果发现是IP写错了，白白浪费时间。