## 症状现象
服务器迁移到新机房或新可用区之后，公网访问正常，内网却互相 ping 不通：应用连不上数据库，内网接口全部超时。迁移前一切正常，机器本身的网络配置没人动过，问题看起来莫名其妙。
## 定位过程
迁移后内网失效，十有八九出在两处平台侧配置。第一查防火墙规则：内网放行规则通常按网段或按实例绑定，机器换了位置后原规则可能没有跟随，或者新网段不在放行列表里。第二查路由：新机房是独立网段，两边的路由表若没有互相指向，流量根本没有路可走，表现为路由不可达错误而非被防火墙静默丢弃。
ping -c 3 192.168.20.10 ip route get 192.168.20.10 traceroute -n 192.168.20.10
区分两类失败有诀窍：超时类多半是被防火墙丢弃，路由不可达类是没路。traceroute 一跳都不走的与走到一半断的，指向不同环节。
## 解决方法
对端与新位置逐项核对：防火墙规则的内网段覆盖、两台机器互相方向的规则都要查，规则是分方向的，一边放行另一边没放行照样不通；跨机房场景确认两边路由表有互通条目，没有则按平台方式添加。改完先 ping 再测端口，通到端口才算业务可用。
## 预防建议
迁移清单里把防火墙规则与路由列为固定检查项，迁完立即验证内网连通性。顺云云服务器迁移前导出规则清单，迁移后逐条比对，内网依赖多的业务安排停机窗口内的连通性冒烟测试。
迁移后的验证清单值得展开成通用模板：内网连通性双向验证、防火墙规则逐条核对、路由表与迁移前对比、解析记录更新、监控重新纳管，五项全绿才算迁移完成。跨机房的迁移还要加一项带宽与时延的基准测试，内网互通了但时延翻倍，对延迟敏感的业务同样是事故。这份模板放进团队知识库，每次迁移复用并补充条目，第三轮之后就是团队的固定资产。