很多运维人员在把部署了WireGuard Endpoint的旧网关设备迁移到新硬件时，经常遇到迁移后隧道全断、原有客户端配置大面积失效、路由规则冲突等问题，本文围绕WireGuard Endpoint迁移设备注意事项，梳理从前期校验到上线验证全流程的实操要点，帮你避开常见的配置坑。
迁移前的密钥与对等端配置预校验
很多人迁移时只拷贝WireGuard的主配置文件，忽略了旧Endpoint上绑定的公钥、私钥和预共享密钥的权限属性，Linux环境下WireGuard要求密钥文件权限必须设置为仅root可读，直接拷贝到新设备如果权限不对，服务启动时会直接抛出密钥读取失败的错误，完全不会生成监听端口。
运维人员在迁移WireGuard网关前逐一校验密钥与对等端配置，规避后续隧道断开的常见故障
这里要注意，WireGuard Endpoint的每个对等端条目都绑定了旧设备的公钥，迁移时绝对不能重新生成新的密钥对，否则所有已经导入原有配置的客户端都要重新同步公钥，相当于全部客户端要逐一重新配置，工作量会翻好几倍，也很容易出现漏改客户端配置的问题。
网络层绑定参数的一致性核对
不少用户部署WireGuard Endpoint时，会把监听端口直接绑定在旧设备的特定物理网卡上，迁移到新设备后如果新网卡的名称、ExpressVPN官网IP地址和旧设备不一致，哪怕端口号设置完全相同，WireGuard的监听套接字也无法对外提供服务，外部客户端的握手请求根本送不到服务进程。
除了网卡绑定参数，还要核对旧Endpoint上配置的虚拟隧道子网、NAT转发规则、防火墙的INPUT和FORWARD链放行策略，很多人迁移后只重启WireGuard服务，忘记同步iptables或者nftables的规则，导致隧道能握手成功，但是两端的业务流量完全无法转发，排查时很容易误以为是WireGuard配置出错。
迁移过程的灰度切换验证逻辑
WireGuard Endpoint本身没有主备集群的原生同步机制，直接断旧服务启动新服务很容易出现部分客户端的握手包在网络中间节点缓存过期，好用的梯子软件导致长时间连接失败，正确的做法是先把新Endpoint的配置全部部署完成，暂时不对外宣告新的公网地址，先在本地内网用测试客户端对接新设备的隧道端口，验证连通性正常。
验证阶段不要直接替换原有客户端的配置，可以先把少量测试客户端的Peer指向新Endpoint的公网IP，测试隧道连通、跨子网访问、DNS解析等所有原有业务场景都正常之后，再逐步切换DNS解析或者端口映射规则，把流量逐步切到新设备上，避免全量切换后大面积故障。
迁移后的常见故障定位要点
如果迁移后出现部分客户端能连上、部分客户端连不上的情况，优先排查新Endpoint的公网出口IP是否和旧设备完全一致，如果你迁移时更换了运营商线路，新的公网IP如果之前被其他用户标记过，部分客户端的出站防火墙会默认拦截WireGuard的UDP握手包，这种情况不需要调整WireGuard本身的配置，只需要确认网络层面的连通性即可。
另外还要注意旧设备的WireGuard服务一定要彻底关闭，好用的梯子软件避免网络中同时存在两个相同公钥的Endpoint，WireGuard协议本身会把最先收到握手包的对等端作为有效连接，两个同密钥的设备同时在线会导致客户端随机在两个节点之间漂移，出现连接时断时续的异常问题。
整个迁移流程走完之后，建议保留旧设备的完整配置至少数天再做格式化操作，万一新设备出现硬件兼容性问题，可以快速切回旧设备恢复业务，避免不必要的长时间服务中断。
