迁移设备配置 WireGuard 时，MTU 不匹配主要导致大包传输失败或间歇性断连。核心原则是遵循“客户端 MTU 不高于服务端 MTU”，且需考虑底层链路开销。若直接复用旧配置而未调整 MTU，银河可能出现小数据正常但大文件卡顿的现象。
检查服务端实际有效 MTU
先确认服务端当前生效的 MTU 值。不要仅查看网卡默认值，需考虑虚拟接口或封装开销。在 Linux 服务端，执行 ip link show 查看 wg0 接口的 MTU 属性。若服务端运行在云服务器或 Docker 容器中，底层宿主机的链路 MTU 可能小于 1500，需通过 traceroute -M 测试确定实际最大包长。预期现象是获取到一个确定的数值，例如 1420 或 1400。
配置客户端 MTU 参数
根据服务端结果设置客户端 MTU。WireGuard 客户端配置中，MTU 字段值应小于或等于服务端值，且预留 TCP/IP 头部开销。通常建议设为 1400 或 1380。修改需同步到配置文件中。注意，Windows 下修改后需重新加载接口或重启网络服务；Linux 下需重新 up 接口。预期现象是配置加载无报错，且 wg show 中 MTU 字段显示为新值。
验证分片与连通性
使用 ping 测试大包连通性，命令为 ping -M do -s 1400 <服务端内网IP>（-M do 禁止分片）。若服务端 MTU 为 1400，则载荷 1380 左右应通；若不通则说明 MTU 仍偏大。观察现象：若 ping 通但大文件传输慢，检查是否因 ICMP 不可达导致 DF 位被错误清除；若完全不通，需复查 AllowedIPs 路由是否覆盖目标网段。
在迁移网络配置时，精确校验底层链路开销是确保连接稳定的关键步骤。
核对路由与 AllowedIPs 范围
确认 AllowedIPs 配置是否包含目标网络。AllowedIPs 既决定数据包是否走隧道，也参与接收源校验。若配置了 0.0.0.0/0，则所有流量都经隧道，此时 MTU 限制影响全局；若仅配置特定网段，则仅该网段受 MTU 影响。检查 ip route 确认默认路由或特定路由指向 wg0 接口。预期现象是目标 IP 的路由下一跳为 WireGuard 接口，而非物理网卡。
避免端口与混淆误区
注意 UDP 与 TCP 同号端口并非同一监听端点。若客户端同时启用 TCP fallback 和 UDP 原生协议，两者 MTU 行为独立，需分别配置。字段名注意是 PersistentKeepalive（单数），勿误写为复数导致解析失败。若客户端在隔离网络中无法接收 ICMP，银河需依赖 TCP 分片或降低 MTU 至 1280 以确保基本连通，而非依赖路径 MTU 发现。
