跨IP段访问服务器失败，九成以上不是服务器本身宕机，而是路由可达性、防火墙策略或NAT映射三条链路中某一环断了。先别急着重启服务，按下面的顺序排查，多数问题在十分钟内能定位到具体环节。
先判断是”完全不通”还是”通但连不上”
这两种现象指向完全不同的故障域,混在一起查只会浪费时间，在源端机器上依次执行：
ping 目标IP看是否有回包，跨网段场景下，很多网络设备默认禁ICMP，ping不通不代表服务不可用，但ping通基本说明三层路由没问题。tracert 目标IP（Windows）或traceroute 目标IP（Linux） 观察数据包停在哪一跳，如果卡在源网关之后的第一个三层设备，多半是路由表或ACL问题；如果能走到目标网段的网关但最后一跳不通，问题往往在目标主机侧。telnet 目标IP 端口或nc -zv 目标IP 端口端口通不通才是业务层面的真相，ping通但端口不通，是跨IP段场景里最常见的一类故障。
把这三个结果记下来,后面的排查就能对号入座，业内专家指出，跨网段故障中”能ping通但业务端口拒绝”的比例远高于”完全无响应”，因为前者往往只差一条安全组或ACL规则。
三层路由：跨网段访问失败的第一嫌疑
路由表里到底有没有目标网段
跨IP段通信的本质是两台主机各自把包交给自己的网关,由网关完成转发，源端执行 ip route 或 route print，确认默认网关存在且指向正确的下一跳，目标端同样要确认回程路由：目标服务器必须知道怎么把响应包送回源网段，否则会出现”请求到达、响应回不来”的半通状态。
用 ip route get 源IP 在目标机上验证回程路径，如果返回的是默认网关而非预期的内网出口，说明回程走了错误链路，在多层网络架构里这是高频坑点。
不同VLAN之间无法通信是什么原因
这是搜索量很高的一个具体场景,常见成因有三类：
- 三层交换机上缺少对应VLAN的SVI接口,或SVI处于down状态。
- 交换机未开启IP路由功能（
ip routing），VLAN间流量无处转发。 - 网关掩码配置错误,把本应同网段的主机划到了错误广播域。
排查路径很直接：登录核心交换设备，show ip route 看目标网段是否存在，show interface vlan X 看接口状态，show ip interface brief 确认各网关地址，行业共识认为，VLAN间故障中掩码或网关配错占相当一部分比例，尤其在新上线的网段割接之后。
大网段与小网段混用导致的掩码陷阱
一个容易被忽略的细节：源段是 10.0.0/16，目标段是 10.5.0/24，从配置上看像是”跨网段”，实际上二者存在包含关系，如果主机按/16配置，它会认为目标地址就在本地链路，直接发ARP而不走网关，结果自然是访问失败，反过来，/24的主机访问/16网段内的地址则必须经过网关，路由配置不完整就会断。
判断方法：用 ipcalc 或在线子网计算工具确认两段地址是否真的互不包含，真正跨IP段的通信一定经过三层设备，这一点决定了后续所有排查的方向。
防火墙与安全策略：放行规则要两头看
主机防火墙与网络防火墙都要查
跨段流量会依次穿过源主机防火墙、源网段出口设备、中间安全设备、目标网段入口设备、目标主机防火墙，任何一环丢弃都会表现为超时，实操上从两头往中间夹：
- 源端：
iptables -L -n -v或firewall-cmd --list-all，看OUTPUT链是否有出向限制。 - 目标端：同样命令看INPUT链，重点看是否有针对源网段的drop规则。
- 中间设备：在防火墙上查会话表或丢包计数，
show session类命令能直接看到流量是否被策略拒绝。
云环境里的安全组和网络ACL是独立两层
在公有云上,安全组是实例级、有状态的，网络ACL是子网级、无状态的，跨IP段访问失败时两处都要核对：
- 安全组入方向是否放行了源网段的业务端口,注意安全组规则里的源地址填的是CIDR不是单个IP。
- 网络ACL的入方向和出方向都要放行,因为无状态意味着回程流量不会被自动允许，很多人只配了入方向，结果请求出去、响应被拦。
据主流云厂商的公开文档,网络ACL的默认规则通常是拒绝所有，新建子网后如果只调整了安全组，跨子网访问大概率失败，这个细节在跨IP段场景里排查成本很低、命中率却很高。
跨IP段访问数据库连接失败是怎么回事
数据库类服务有额外一层限制：服务端自身的监听地址和访问控制，以MySQL为例，bind-address 若配置为 0.0.1，则只接受本机连接；用户表中的host字段若是 localhost，则只允许本机登录，跨段访问必须同时满足：监听 0.0.0 或目标网卡地址、授权用户的主机部分匹配源网段（如 'user'@'10.20.%'）、防火墙放行3306端口。
三层都通之后仍连不上,用 mysql -h 目标IP -u 用户 -p 加 --connect-timeout 参数测试，报错信息会直接指出是拒绝连接还是认证失败，比盲猜高效得多。
NAT与映射：跨公网或跨专线时的隐藏关卡
当两端不在同一内网、需要经过NAT设备时，排查重点转移到地址转换表，SNAT要确认源地址转换后的公网地址能被对端接受，DNAT要确认外部端口正确映射到内部服务器的IP和端口，常见故障形态：
- 端口映射只配了TCP没配UDP,而业务恰好走UDP。
- 映射表中的内网IP是旧地址,服务器换IP后映射未同步更新。
- 双向NAT场景下,源端看到的响应来自错误的地址，被主机防火墙当作异常包丢弃。
验证手段：在NAT设备上开启日志或抓包，确认包进入后是否被正确转换并转发出去，跨IP段访问服务器超时怎么排查，走到NAT这一层时，抓包几乎是唯一可靠的判断依据看请求包有没有出、响应包有没有回、回包的源地址是否符合预期。
一套可复用的排查顺序
压缩成可执行的清单,遇到问题按序执行，命中即停：
- 源端
ping与tracert，确定三层是否可达、断点在哪一跳。 - 两端各自
ip route，确认去程与回程路由对称。 - 两端主机防火墙核对入/出方向规则。
- 云环境补查安全组与网络ACL两个层面。
- 跨公网场景检查NAT映射表与端口协议。
telnet/nc测端口，必要时两端同时抓包对比。
抓包命令用 tcpdump -i any host 目标IP and port 端口，两端同时开，对比请求与响应的时间戳和地址，能最快锁定是哪一侧在静默丢包。
收束
跨IP段访问失败的排查逻辑可以概括为一句话：先确认包能不能到，再确认到了之后让不让进。路由解决”到”的问题，防火墙和映射解决”进”的问题，两条线分开查，故障定位速度会快很多。
关于跨IP段访问的常见疑问
跨IP段访问服务器失败但同网段正常，说明什么
同网段正常而跨段失败,几乎可以排除服务器进程本身的问题，故障域锁定在网关、路由、中间安全设备或NAT这四类环节，同网段通信走二层交换，不经过三层转发，所以这个对比结果本身就是最有价值的定位线索。
跨IP段访问超时和连接被拒绝有什么区别
超时通常意味着包被丢弃且没有回应,问题在路由不可达或防火墙静默drop；连接被拒绝则说明包到达了目标主机，但端口没有监听或主动拒绝，问题在服务配置或主机防火墙的reject规则，前者往网络层查，后者往主机层查，方向不同。
跨IP段访问服务器需要放行哪些端口才能排查成功
排查阶段可临时放行ICMP以便ping测试,业务端口按实际服务放行（如HTTP 80/443、数据库3306/5432、远程管理22/3389），正式环境中应遵循最小权限原则，只放行必要端口和必要源网段，排查用的临时规则在问题解决后及时回收。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/795864.html
