子网网关不可达的根本原因是IP与网关未处于同一逻辑子网，须通过“IP&掩码=网关&掩码”验证网络号是否一致；若一致，则排查ARP解析失败、物理链路异常、交换机隔离策略及网关自身状态（如接口绑定错误、代理ARP关闭、资源过载等）。

子网划分出问题，往往不是算错了数字，而是逻辑没对齐、配置没落地、验证没到位。真正卡住人的，常是那些“看着没问题，但就是不通”的细节。

子网掩码与IP不匹配：最隐蔽的“同网段”幻觉

很多人看到IP是192.168.1.50、网关是192.168.1.1，就默认“肯定在一个子网”，却忽略掩码可能是255.255.252.0（/22）甚至255.255.0.0（/16）。一旦掩码过大，实际网络号可能变成192.168.0.0，而另一台设备配的是192.168.1.0/24，表面IP相近，实则跨网段。

• 务必用“IP & 掩码 = 网关 & 掩码”做二进制与运算，结果必须完全一致
• Windows执行ipconfig /all，Linux执行ip addr show，逐字核对掩码值，别只扫一眼
• 虚拟机、容器、多网卡设备要特别注意——不同接口可能配了不同掩码，互相干扰

ARP解析失败：通了物理链路，却卡在“找不到人”

即使IP和掩码都对，若客户端发不出去数据包，大概率是没拿到网关的MAC地址。ARP请求没人应答，所有流量就停在二层，ping自然超时。

• 运行arp -a | grep [网关IP]，无输出或显示incomplete即为异常
• 检查交换机是否启用了端口安全、DHCP Snooping或DAI（动态ARP检测），这些功能会拦截非法ARP
• 确认网关设备对应接口已UP、IP已生效、且未被ACL或防火墙策略静默丢弃ARP请求

多网卡/虚拟网卡引发的路由错乱

笔记本连WiFi又插网线、VMware开了NAT和桥接、Docker创建了自定义网络……多个接口共存时，系统可能选错出口，把本该走内网的包发去了外网网关。

• 执行route print（Win）或ip route show（Linux），看默认路由指向哪个接口
• 用tracert 192.168.1.1或mtr -r 192.168.1.1观察第一跳是否落在预期网关上
• 临时禁用非必要网卡，排除干扰；生产环境建议用策略路由（policy-based routing）精确控制走向

网关自身状态被忽视：它“在线”，但不“可用”

路由器管理页面能打开、LED灯亮着、甚至SSH能登录——但这不代表它正在正确转发流量。常见陷阱包括：

• 网关IP实际绑定在错误接口（如WAN口而非LAN口）
• 启用了“仅响应本接口ARP”或“关闭代理ARP”等高级选项，导致跨VLAN或特殊拓扑下失联
• CPU过载、内存溢出、或内核模块异常，使ICMP响应延迟极高或直接丢弃