换路由器，VPN 服务器没搬：迁移它的公网入口

你插上新路由器，网络恢复了，但手机上的 VPN 客户端仍然指向一个不再响应的地址。VPN 服务器上什么都没变，因为服务器从未移动。路由器才是公网入口，换掉它同时换掉了地址、转发规则，可能还有动态 DNS 更新程序。

把这次更换当成两次交接而不是一次，并在施工期间保留一条本地进入管理界面的通路。

拔线之前先把交接写下来

记下 LAN 前缀、服务器地址及其分配方式、VPN 实际使用的监听与传输协议、对外发布它的入站规则，以及客户端保存的名称。然后写下今天由哪台机器更新动态 DNS 记录：可能是路由器、服务器本身，或另一台主机上的独立代理。趁旧管理页面还打得开时做完。入站规则的截图比记住的端口号更可靠。

补上客户端应当能够访问的私网前缀，以及 LAN 内设备如何把回包送回它们。这两点都容易被忘掉，因为更换向导谈的是上网，而不是回程路径。如果厂商支持恢复，也把旧配置导出，同时接受一个型号的备份很少能干净地导入另一个型号。

把这份记录放在受保护的地方。路由器备份可能含有 WAN 线路的凭据。把导出文件当密码看待，而不是当设置备忘。

先搬地址，再搬转发

如果新路由器保留同一个 LAN 前缀，就给服务器原来那份保留地址，或等价的静态分配。如果前缀变了，先更新服务器地址以及任何指名它的监听绑定，因为指向旧地址的转发会悄悄把流量送到虚空。

然后只为 VPN 使用的传输协议重建一条入站规则。厂商指南中描述的向本地服务器转发展示的是机制，不是通用配方，所以要把规则对应到你真实的协议和端口，而不是博客上的清单。新路由器上的转发去不掉上游的运营商级 NAT，如果运营商已经把公网地址与别人共享，任何本地规则也无法让私网地址从互联网可达。

确认服务器自身的防火墙仍然放行这部分流量。检查路由器与互联网之间是否还坐着一台二级网关，因为很多运营商发放的是调制解调器与路由器一体的设备。读取新设备上的 WAN 地址，并与客户端解析到的地址对比。两者不一致，说明你的转发落在了不是边缘的地方。

确定由谁更新公网名称

端点更新只能有一个主人，且只有一个。如果旧路由器在发布名称，就在替代设备上配置受支持的更新程序，并确认记录确实变了。如果服务器本来就在发布，就保持原样，不要再加一个在两个地址之间摇摆的竞争更新程序。

当部署同时发布两类地址时，A 记录和 AAAA 记录都要读。每一条都必须指向真正在监听、并且在其自身防火墙路径上被放行的服务；IPv4 映射正常工作，并不能说明 IPv6 一侧的情况。还要保留客户端配置里的身份校验：公网地址变了，不是接受不匹配的证书或对端密钥的理由。

从外部证明这次更换

用经过授权的外部连接和全新会话测试，而不是在 LAN 内部。针对公网地址的内部测试依赖发夹行为，走的是和真实客户端不同的一条路。

按客户端的顺序走一遍：解析名称、协商隧道、完成认证，然后对一项私网资源执行一次操作。最后这一步恰恰最常被跳过，而它也是唯一能证明回程路径的一步。如果登录成功但私网操作失败，就把新的 LAN 前缀、客户端选中的路由，以及资源的回包路径，与你的交接记录逐一对照。

四个步骤全部通过之后，退役旧路由器才是安全的。拔掉它，再把外部测试重复一次。仍然解析到旧地址的过期记录会在第一步就失败，而趁旧设备还在架子上时诊断这一点更容易。

把新的对应关系与恢复记录放在一起

把最终的服务器分配、入站规则和更新负责人的名字，归档在本地进入路由器的流程旁边。下一次更换应当从那一页开始，而不是从一次 traceroute 开始。

如果以上都做完后隧道从外部仍然失败，就检查路由器上报的公网地址是否与客户端解析到的地址一致。仅这一项对比就能把 DNS 问题和转发问题分开，而且比再读一份端口转发指南更省时间。