你以为重命名 Pritunl 服务器就会改变它的端点吗？

重命名 Pritunl 服务器只会改变控制台中的一个标签。它不会改变客户端配置文件拨号的地址，也不会创建 DNS 记录。真正重要的是主机的公网地址，而它接受名称和接受地址一样自然。

客户端拨号的名称只存在于一个主机字段中

Pritunl 通过主机的 公网地址 设置暴露端点，该设置接受公网 IP 地址或 DNS 名称。把 vpn.example.net 放在那里，生成的配置文件和经过认证的同步就会把这个名称交给客户端。记录必须已经存在，并解析到接受 VPN 传输的监听器；这个字段只是声明目的地，并不发布它。服务器对象的显示名称属于管理元数据，永远不会进入客户端的连接尝试。

所以第一步不是重命名任何东西。打开主机设置，修改公网地址，并通过受支持的界面保存。

三个看似相同、其实不同的字段

本地地址 用于 Pritunl 主机之间的复制和路由。链接地址 描述互联服务器之间如何互相到达。两者都不是客户端拨号的地址，把公网名称复制进去会破坏它们所描述的拓扑。公网 IPv6 地址 是拥有独立记录和路径的另一个字段；IPv4 的 A 记录并不能建立 IPv6 可达性。

DNS 名称也不携带端口映射，也不提供监听器。如果服务在 1194 UDP 上监听，名称仍然解析到一台必须接受 1194 UDP 的主机。在 443 端口上为 Web 控制台提供服务的 HTTP 反向代理不是 VPN 传输端点，即使两者共用同一个名称。

隧道内基于域名的路由又是另一层。为外部端点命名，并不能说明客户端可以到达哪些私有目的地。

把新名称推送给已存在的客户端

修改字段不会重写已经离开服务器的配置文件。Pritunl 的认证配置同步可以把主机地址和端口变化送达兼容的客户端，文档中记录的 CLI 客户端会在连接或重连之前先同步。导入到 NetworkManager 或独立 OpenVPN 客户端中的配置文件没有这种通道，需要经过批准的替换。现有会话什么也证明不了，因为它们是按旧值建立的。

当 Web 控制台位于负载均衡器之后时，Pritunl 记录了用于同步路径的独立 同步地址 设置。不要仅仅因为两者都是 Pritunl，就把控制台主机名复用给 VPN 监听器。

按以下顺序交付变更：保存主机设置，导出或同步当前配置文件，替换客户端的副本，然后重新连接。记录哪些客户端由同步管理、哪些持有导入的文件，因为第二组不会自动跟随。在这里，一份客户端归属清单比再加一条 DNS 记录更有用。

用真实连接验证变更

名称解析是最弱的测试。dig +short vpn.example.net 能返回地址，只能证明记录存在。

验收测试是：从持有新配置文件的客户端发起一次新的认证连接，然后请求一个应当能通过隧道到达的私有资源。在客户端日志里查看它实际使用的端点，而不是你打算使用的端点。保留一条不依赖名称被正确修改的管理路径，以免一个错误把你锁在控制台之外。

稍后当公网地址迁移时，更新记录，并规划客户端缓存与重连行为。主机名让客户端与数字地址解耦；它不会搬移一个活动套接字，也不会让不可达的监听器应答。