不少用户在更换网络设备时，会把原本部署在旧设备上的WireGuard服务迁移到新硬件，比如从旧树莓派转移到新的x86软路由，或是从闲置手机迁移到随身WiFi路由器，很多人直接复制公私钥配置就完成操作，后续却频繁出现隧道握手失败、内网资源无法访问、流量走向混乱等问题，本文围绕WireGuard接口地址迁移设备注意事项梳理全流程的实操要点，帮大家避开常见的配置陷阱。
迁移前的接口地址配置前提校验
很多用户迁移时只拷贝WireGuard的.conf配置文件，完全忽略原有接口地址段和旧设备系统规则的绑定关系，比如旧软路由上的wg0接口配置的是10.0.5.1/24，旧设备的LAN口网段刚好也在10.0.5.0/24区间，迁移到新设备后新设备的LAN段默认是192.168.31.0/24，如果直接沿用原有接口地址，clash没有调整对应的转发规则，WireGuard客户端接入后根本无法正常访问新设备的内网共享资源。
迁移WireGuard服务前需提前校验新旧设备的接口地址段绑定规则，规避后续隧道握手失败等常见问题
迁移正式启动前，要先导出旧设备上所有和WireGuard接口地址段绑定的SNAT、FORWARD规则，不管是用iptables还是nftables的系统，都要单独把这类规则标记出来，不要只留存WireGuard服务本身的配置内容，很多迁移后的故障都是因为漏了系统层面的转发规则配置，哪怕接口地址填写完全正确，clash隧道流量也会被系统防火墙直接拦截。
同网络环境下的地址冲突排查步骤
如果是在同一个家庭或办公内网里迁移WireGuard服务，比如之前服务运行在旧NAS上，现在要转移到新更换的主路由上，要是旧设备的WireGuard进程没有完全关停，新设备又配置了完全相同的WireGuard接口地址段，就会出现两个服务同时响应客户端握手包的情况，表现出来就是客户端连接状态时断时续，有时候能正常握手有时候直接超时无响应。
对应的验证操作非常简单，迁移配置导入新设备之前，先在旧设备上执行停止WireGuard服务的指令，再用ip addr类的查询指令查看旧设备上的wg虚拟接口是否已经被完全移除，确认旧设备不再占用对应的接口地址段之后，再在新设备上启动WireGuard服务加载配置。
还要额外核对新设备本身的所有物理网卡、虚拟网卡的现有网段，确认WireGuard要使用的接口地址段没有和内网其他DHCP分配段重叠，比如内网本身的主网段就是10.0.0.0/24，那迁移时必须把WireGuard的整个接口地址段更换为其他未被使用的网段，不然客户端连入隧道后，内网路由指向会出现混乱，根本没法正常访问指定的内网设备。
对等端配置的联动同步要求
很多用户迁移时只修改服务端的WireGuard接口地址，忘了所有已接入的客户端对等端配置里的关联规则也要同步调整，比如部分客户端的peer配置里的AllowedIPs字段，单独写了服务端WireGuard接口的单个地址，要是迁移后服务端接口地址发生变更，这个规则没有对应修改的话，客户端只会把指定旧地址的流量往隧道里发送，其他流量直接走本地网络，完全达不到预期的转发效果。
如果你的WireGuard服务端接口地址本身被设置成了所有客户端的默认网关，那迁移完成后不仅要核对服务端的地址配置，还要逐个检查每个客户端的对等端参数，避免出现客户端显示握手成功，却完全无法访问任何网络资源的异常情况。
迁移后的连通性验证逻辑
迁移操作全部完成后，不要直接把旧设备断电收纳，先拿一台测试客户端尝试发起连接，首先查看WireGuard的运行日志有没有正常输出握手记录，确认没有报错的前提下，先ping服务端的WireGuard接口地址，确认双向连通正常，这一步验证通过之后，再尝试访问服务端所在内网的其他设备地址，确认转发规则全部生效。
如果连服务端的WireGuard接口地址都ping不通，首先排查新设备的系统防火墙有没有放开WireGuard的监听端口，clash verge其次检查新设备的系统是否正常加载了WireGuard内核驱动，部分精简定制的第三方固件默认没有包含完整的WireGuard驱动组件，直接导入配置会出现虚拟接口创建失败、接口地址绑定出错的问题。
不少用户容易踩的典型误区是，觉得新设备沿用和之前完全一致的WireGuard接口地址，就可以直接照搬旧设备的所有路由规则，实际上不同硬件设备的默认路由表优先级存在差异，哪怕使用完全相同的接口地址，也要在新设备上重新配置对应接口段的路由转发规则，不能直接复用旧设备导出的规则，不然很容易出现流量走向异常的隐性故障。
