iOS 更换代理客户端，最重要的是把旧连接、系统授权和新配置分开交接。安装新应用不等于旧连接已经退出，导入订阅也不等于每个节点都能由新客户端正确使用。保留可恢复的旧配置，逐步验证，比一次删除所有配置更稳妥。
迁移前写清三类信息
第一类是服务信息，包括订阅来源、套餐状态和可用节点，不要把含令牌的完整链接写进公开笔记。第二类是客户端本地设置，例如自定义规则、策略组选择和解析偏好。第三类是系统层的连接授权或设备管理配置。三者不一定能通过同一个导出文件迁移。
苹果部署文档说明平台具有不同的 VPN 配置与管理方式，因此个人应用创建的连接和组织管理的连接不能混为一谈。对于公司或学校管理的设备，先向管理员确认允许的连接方式，不要为了切换个人客户端删除工作所需描述文件。
记录旧客户端版本及最后一次正常使用时间。对新应用，核对开发者身份、官方文档和获取渠道，不要只凭相似图标认定它与某个项目有关。应用商店可获得性可能随地区变化，教程不应给出未经核验的购买承诺。
先完成配置准备，再交出连接
在旧连接仍可用时查看新客户端支持哪些订阅格式、协议和导入方式。如果官方没有说明某格式受支持，不应假设复制链接就能自动转换。在线转换服务可能接触订阅凭证，不能把它当作无风险的文本排版工具。
准备好新配置后，选择不影响工作和通话的时间停止旧连接，再由新应用按系统提示建立连接授权。这里强调操作阶段，而不固定某一版本的按钮名称。授权后仍需检查新应用是否实际启动，而不是只看到系统允许就结束验证。
首次测试可以只选择一个此前确认可用的节点，关闭不必要的自定义规则。保持服务、网络和目标不变，让客户端成为主要变化项。若同时换节点、换解析服务并启用新的过滤规则，失败时很难知道需要回退哪一项。
不要把导入成功当作兼容成功
配置文件被接受，只能说明它通过了客户端某一阶段的处理。一个订阅可能包含多种协议，新客户端也可能只支持其中一部分。需要分别查看节点数量、名称、关键参数是否保留，以及是否存在被忽略的字段提示。
如果列表中少了节点，先对照服务商提供的客户端说明和新应用文档，不要手工猜测缺失参数。名称相同也不一定代表完整连接参数相同。可以向支持人员描述“原有多少类节点、新客户端出现何种提示”，但提交材料前应先脱敏，方法见客户端日志处理。
本地规则也需要重新审查。旧客户端中的规则表达式、策略组名称或脚本不一定能原样复制到另一个内核。迁移时先确定需求，例如办公域名直连、指定服务走指定策略，再把需求翻译为新客户端支持的规则。具体过程见客户端分流规则实战。
用日常任务验收新连接
建议依次验证普通网页、日常使用的登录服务、视频或语音、局域网设备，再观察切换无线与移动网络后的恢复。测试应使用自己的正常账户和合法访问场景，避免为了验证而频繁触发登录风控。
以下为示例：新客户端可以打开网页，但家中的投屏设备无法发现。这并不直接说明订阅错误，可能是接管范围或本地网络权限与旧方案不同。应先查看权限和局域网规则，再决定是否调整；不要把全部流量改成某一策略来掩盖局部问题。
如果只有一个应用失败，记录该应用是否有自己的连接方式或缓存。退出并重新建立请求后再观察，避免将旧连接遗留的结果算到新客户端头上。一次测试成功不能证明全部场景已覆盖，验收表应保留未测项目，而不是统一标为通过。
失败时如何退回
回退顺序是停止新连接、恢复旧应用需要的授权状态、启动原先可用配置并验证同一任务。不要让两个应用反复自动抢占连接。若旧方案也失败，再检查套餐、底层网络和目标服务，不要继续假定问题一定来自迁移。
旧配置至少保留到常用场景验证完成，但这不等于让旧应用持续后台运行。确认不再需要后，按系统和应用提供的方式移除过时配置，并再次检查连接列表。不要删除自己无法识别的管理项目。
最后保存一份不含秘密的迁移记录：新旧版本、导入来源、保留与放弃的本地规则、已测场景、回退步骤。以后的维护可以沿着这份记录进行配置对照测试，而不是再次从零猜测。迁移真正完成的标准，是新方案能够承担自己的日常任务，且旧方案不再产生意外干扰。
还可以为订阅到期和凭证失效各留一个检查项。更换客户端不会延长套餐，也不会让已经撤销的订阅令牌重新有效。遇到认证失败时先核对服务状态，避免在两个客户端之间来回操作而忽略账户层原因。
参考资料
- Apple：设备部署中的 VPN 概览，核验日期：2026-10-15。文中的个人迁移清单为编辑建议，不代表某一付费应用的具体界面。