两张虚拟网络各自运行正常，互相连接后却无法访问对方设备，常见原因是网段重叠。处理虚拟网络子网地址冲突的排查与调整，应先确认实际地址范围和路由，再决定改动哪一侧；只改设备 IP 而不检查掩码、网关和 DHCP 地址池，往往会留下新的故障。
先确认冲突发生在哪里
子网由网络地址和掩码共同确定。例如，192.168.1.0/24 覆盖 192.168.1.0 至 192.168.1.255；192.168.1.128/25 是它的一部分，两者存在重叠。即使两端设备使用不同的主机地址，只要所属网段重叠，路由器也可能无法判断目标地址应从本地网络发送，还是转发到远端。
冲突可能出现在虚拟机网络、容器网络、办公局域网、云端虚拟网络或 VPN 连接之间。Docker 默认 bridge 网络常使用 172.17.0.0/16，但实际配置可能被调整；不能仅凭默认值判断，需检查当前网络配置。排查虚拟网络子网地址冲突的排查与调整，第一步是记录每个网络的 CIDR、网关、DHCP 地址池，以及连接关系。
按顺序排查，避免盲目改址
收集地址信息。在各虚拟网络管理界面或主机网络配置中查看 CIDR、掩码、网关和地址池。Linux 可用 ip addr 和 ip route 查看接口地址与路由；Windows 可用 ipconfig /all 和 route print 查看配置。记录信息时注明网络名称和用途。
列出需要互通的网络。将本地网络、远端网络、VPN 对端及容器或虚拟机网段放在同一张表中，重点检查地址范围是否相交。若只要求单向访问，也要确认返回流量有对应路由。
核对路由与实际症状。查看路由表中目标网段走向，并分别测试同网段网关、远端地址及名称解析。若同一目标地址被本地路由直接判定为可达，流量可能不会进入 VPN；若网段不重叠但仍不通，还应检查防火墙规则、路由传播和访问控制。
小范围验证。调整前保存原配置，并选一台测试设备确认新地址、网关、DNS 和跨网访问。DHCP 环境还需检查租约与地址池，避免静态地址落入动态分配范围。
选择调整方式：优先让地址规划清晰
改动一侧子网
若网络仍在建设阶段，或能控制其中一侧，通常直接更换其中一个网段更稳妥。选择新网段时，要同时检查现有局域网、VPN 对端和已有虚拟网络，避免只避开眼前冲突却与其他网络再次重叠。改址的优点是路由关系直观；缺点是可能需要更新网关、DHCP、静态地址、防火墙规则及依赖地址的配置。
使用地址转换或隔离路由
若两端地址都难以变更，可在受控网关上使用网络地址转换，让一侧以映射后的地址访问另一侧。它适合短期兼容或无法协调改址的场景，但会增加排障复杂度，且可能影响端到端连接、日志识别或部分协议。若业务无需互通，保持网络隔离并只开放必要入口更简单，也更容易控制访问范围。
调整后，逐项核对网段、路由、DHCP、DNS 和访问策略，并测试正向与返回流量。把最终 CIDR 和用途纳入地址台账，后续新增网络先查重再分配，能减少同类问题复发。虚拟网络子网地址冲突的排查与调整，应以明确的地址记录和变更验证收尾，而不是以“设备能连上”作为唯一标准。
常见问题
不同掩码也会发生子网冲突吗？
会。只要两个网段的地址范围有交集就属于重叠，例如 /24 与其中一段 /25。比较时应看完整 CIDR 范围，不能只比较网络地址是否相同。
能否只修改路由来解决？
部分场景可用更具体的路由或地址转换绕开问题，但若两侧终端使用相同目标地址，路由选择可能仍然含糊。能协调时改成不重叠网段通常更清晰。
调整子网后哪些配置要复查？
至少检查网关、DHCP 地址池、静态 IP、路由、VPN 配置、DNS 记录和防火墙规则；还要确认旧租约已更新，并验证业务所需的访问方向。