Shadowrocket 协议手册

01 / Model

协议分层与选型前提

协议名称不等于完整连接方案

在 Add Server 中选择 Type，首先是在声明客户端应按哪一种格式与服务器通信，而不是给同一条连接更换性能档位。服务器提供 Shadowsocks 时，不能只把客户端改成 VLESS 就获得另一种协议的能力。双方必须在协议、端口、认证材料以及外层传输上达成一致。订阅导入通常会携带这些信息，但导入成功仅说明内容可以被解析，不代表远端配置仍然有效，也不代表当前网络可以到达对应端口。

理解一条连接，可以依次拆成目标请求、代理协议、承载传输和实际网络路径。目标请求说明要访问哪个域名与端口；代理协议负责表达请求、认证身份，部分协议同时提供加密；承载传输决定这些数据如何通过 TCP、UDP、TLS 或其他封装传递；实际路径则包括无线接入、运营网络、服务器接入和服务器到目标的后半程。某一层表现异常，不能直接归因于协议名称，排查时应沿这条链逐层缩小范围。

认证、加密与路由是不同问题

密码、UUID 和密钥都可能用来证明身份，但含义并不相同。UUID 不是域名，WireGuard 的 Public Key 也不是可以填入密码栏的替代文本。加密用于保护传输内容，认证用于识别通信对象或使用者；二者可能由同一机制完成，也可能分布在不同层。TLS 的证书验证属于服务器身份核对的一部分，不能因为账号密码正确就省略。字段名称相似时，仍应按服务端提供的协议说明确定对应关系。

Global Routing 则位于另一条判断线上：Config 按当前配置分流，Proxy 将可代理的流量交给代理策略，Direct 直接连接。它们不会把服务器的协议类型转换成另一种协议。选择正确的 Type 后，还需要保证请求确实走到了预期策略；否则访问成功可能只是 DIRECT 生效，访问失败也可能只是规则选择了不可用的目标。术语含义可配合术语表查阅，避免把模式切换误认为协议调优。

把可选范围限制在真实能力内

选型的起点是服务端实际提供什么，而不是协议列表中看起来更新的名称。先记录可用类型、是否支持 UDP、认证方式和所需传输，再比较当前客户端是否提供对应字段。相同协议也可能存在不同功能组合，某个字段缺失不应通过随意填写其他栏位解决。若订阅与手工说明冲突，应从你的服务商处确认当前有效参数；不清楚的扩展保持原状，避免一次修改多个条件后失去可复现的基线。

Shadowrocket 是 Apple 平台的付费商业应用，获取与系统要求以 App Store 页面标注为准。需要核对购买入口时，使用App Store 正版核验说明。客户端一次性买断 ≠ 线路套餐：购买应用并不产生服务器地址、认证材料或订阅。这一边界也决定了本页的选型含义——在已有条件内选对连接方式，并用证据判断是否适合当前网络，而不是承诺某种协议在所有环境下都更快。

02 / Shadowsocks

Shadowsocks：共享密钥与轻量封装

设计取向与适用边界

Shadowsocks 的设计起点是以相对简洁的方式传递代理请求，常见部署使用共享密码和指定加密方法。客户端知道目标地址，随后按协议封装发送给服务器，由服务器建立后续连接。它不以完整虚拟网络为主要抽象，因此通常更适合从“某个请求需要怎样转发”理解，而不是把它看成一块远端网卡。协议实现和加密方法会影响具体细节，不能把所有标为 Shadowsocks 的记录视为完全相同。

现代部署常见 AEAD 加密方法，它们同时处理机密性与完整性验证。较新的协议变体还可能对密钥格式、会话组织或重放防护作进一步约束。这里的关键不是记住哪一种名称更长，而是保证客户端所选方法与服务器逐字一致。共享密码也不总是任意可读短语：某些方法需要符合规定长度和编码的密钥。不能把旧配置中的密码直接迁移到另一种方法，再期待服务端自动兼容。

按字段核对，不按印象填写

在 Add Server 中，先确认 Address 与 Port 指向服务端实际监听位置，再核对 Method 和 Password。Address 可以是域名或地址，但解析结果必须能到达正确服务；Port 是服务端监听端口，不是访问网页使用的默认端口。Method 不是本地安全强度滑块，而是双方协议的一部分。Password 中的大小写、末尾空格和复制时夹入的换行都可能导致认证失败，修改前应保留原记录，逐项对照来源。

如果已有记录包含额外传输参数，应把它们视为连接方案的一部分。协议本体与额外封装不能混为一谈：增加外层可能改变握手过程、域名要求和网络适应性，也会增加排查环节。只有服务端明确要求且当前客户端支持对应选项时才配置。若手工建立的记录无法连接，而同一来源导入的记录可以使用，优先比较两者字段差异，不要先切换加密方法或删除看不懂的选项。

速度、电量与常见失败分支

在 iPhone 上，较少的封装层通常意味着更容易定位问题，但不能直接等同于更低耗电。加密计算只是消耗的一部分，屏幕、无线信号、重传和后台活动可能占据更大比例。现代设备对部分加密算法有较好的执行效率，而最终吞吐仍受服务器负载与链路拥塞影响。若日常以网页和短连接为主，应观察首个请求是否及时完成；若以持续传输为主，再观察稳定阶段的吞吐和温度变化。

TCP 请求可用而 UDP 业务异常时，应分别核对客户端记录、服务端支持和当前网络的 UDP 可达性，不能用网页打开成功证明全部传输都正常。域名访问失败但直接使用目标地址有响应，也要考虑 DNS 所处位置和解析结果差异。对于连接建立后才卡住的情况，记录失败发生在发送请求、接收响应还是持续传输阶段，并在相同网络下复测。把这些现象分开，通常比不断更换 Method 更有诊断价值。

03 / VMess · VLESS

VMess 与 VLESS：认证和传输分开看

两种设计的职责差异

VMess 将用户身份识别、请求封装及相关安全机制组织在协议中，常见记录以 UUID 作为用户标识。它在较早的代理协议演进中强调可识别的用户与连接处理方式，后来也出现了不同的认证格式。对使用者而言，重点是服务器采用的实际组合，而不是根据一条旧教程猜测兼容参数。订阅中出现的额外字段可能对应历史兼容或特定实现行为，应优先保留来源提供的值。

VLESS 则采取更精简的协议职责，基础协议本身不承担内容加密，需要结合适当的安全传输使用。它仍然需要认证信息，但“有 UUID”并不意味着内容已经得到加密。判断保护来自哪里，应继续检查外层是否使用 TLS 或服务端指定的其他安全机制。不能因为界面中存在同名认证栏，就认为 VMess 与 VLESS 可以互换；两者的握手与封装并不相同，服务器必须支持所选类型。

建立参数对应关系

UUID 应完整复制，不添加引号、说明文字或多余分隔符。服务器地址与 TLS 的 Server Name 可能不同：前者决定连接目的地，后者参与 TLS 握手中的名称表达和证书验证。若来源明确给出不同值，就按对应字段填写；若没有说明，不应自行用另一个可访问域名替换。系统时间也值得检查，错误时间可能影响证书有效期判断，并可能干扰依赖时间条件的认证过程。

传输选项决定协议请求如何被承载。使用 WebSocket 时，Path 是服务端用于区分入口的路径，Host 可能参与外层请求路由；它们不是备注栏，斜杠、大小写和路径前缀都可能影响结果。某些部署通过反向代理将同一地址上的不同服务分开，端口可达却路径不符时，远端可能返回网页响应而非协议握手。此时继续调整 UUID 通常不会解决问题，应先检查传输与入口字段。

扩展参数不能单独移植

部分 VLESS 记录还会包含 Flow 或其他安全握手参数，它们属于特定连接组合，不是通用加速开关。一个组合在服务器上成立，并不意味着当前客户端提供所有对应能力。应检查 Add Server 实际可用的字段和来源说明；缺少必要选项时，先确认兼容性，不要把某个值塞入备注或其他看似相近的栏位。导入后也要打开记录核对，确认客户端确实识别了关键参数，而非只保存了名称。

在速度方面，额外的握手与传输封装可能增加首个请求的等待，但稳定连接建立后，瓶颈可能转向网络与服务端。WebSocket 并不天然比其他承载更快，VLESS 的精简也不意味着一定比 VMess 更省电。弱信号下不断重连的影响，常常超过两种协议之间的计算差异。比较时应保持同一网络、近似目标与相同使用任务，分别记录冷启动和持续访问，不能只用一次 Connectivity Test 排序得出结论。

排错可按“地址与端口、外层握手、传输入口、认证、目标访问”逐段推进。外层证书错误先检查时间与 Server Name；能返回普通网页却无法代理时检查入口路径；连接成功后特定业务失败时检查 UDP 能力和路由。若只在长时间闲置后出现首次请求缓慢，还应记录是否发生连接重建。关于字段之外的常见现象，可继续查阅疑难解答，不要通过关闭证书验证掩盖前一层错误。

04 / TLS · Proxy

Trojan、HTTP 与 SOCKS5

Trojan 把安全传输交给 TLS

Trojan 的常见设计是先建立 TLS 连接，再在受保护的通道中完成协议认证和请求转发。它的参数表面上可能比多层组合更短，但 TLS 本身仍有完整的身份验证要求。服务器证书、连接地址和 Server Name 必须形成合理对应，密码正确并不能弥补证书名称错误。对于用户而言，可以把问题先拆为“TLS 是否成功”与“协议认证是否成功”，这样比将所有失败统称为密码错误更容易定位。

Address 可以指向服务端地址，Server Name 则应与服务端要求及证书相符。直接使用地址连接时，也可能仍需指定域名用于 TLS 验证。证书过期、证书链不完整、设备时间错误或名称不匹配，都可能阻止握手。跳过验证会削弱对通信对象的确认，不能作为日常修复方式。若服务端使用特殊信任安排，应依据明确的管理说明处理，而不是在公共网络上临时关闭检查来换取一次连接成功。

HTTP 和 SOCKS5 的基础职责

HTTP 代理源于应用层代理需求，常见 CONNECT 方法用于请求代理建立到目标的通道。名称中的 HTTP 描述代理交互方式，并不自动说明客户端到代理之间使用了 TLS。访问 HTTPS 目标时，目标 TLS 与代理链路保护是两件事：目标加密并不表示代理认证信息在每一种配置下都受到同等保护。应明确区分普通 HTTP 代理和使用 TLS 连接代理的方案，按服务器实际能力填写。

SOCKS5 采用较通用的请求表达，可以描述目标地址与端口，并定义认证和 UDP 关联等机制。它本身不提供通用的内容加密保证，用户名密码认证也不等于加密传输。它适用于已有受信网络或明确配套保护的环境，选择前应知道客户端到服务器之间由谁保护数据。对于是否支持 UDP，也不能只看协议规范允许什么：服务器实现、认证方式与当前客户端支持的实际组合仍需逐项确认。

代理认证与目标认证不要混淆

代理用户名密码用于访问代理服务，不是目标网站账号。若远端要求认证，留空可能导致拒绝；若服务端没有启用相应认证，随意填入账号也不会增加保护。遇到返回认证相关错误时，应先确认响应来自代理还是目标网站。普通网页可以打开而某些应用失败，还可能是应用请求方式、目标端口、UDP 需求或规则所致，不能据此推断用户名密码只对部分网站有效。

在 iPhone 上，这几类协议的实际能耗取决于握手次数、连接复用与无线活动。TLS 建立涉及额外计算与往返，但已建立连接可以承载后续请求；不断断开后重连，可能比保持适当的现有连接更费资源。反过来，为了持续保活而频繁唤醒无线链路也有成本。因此不能仅凭“使用 TLS”就判定耗电高，也不能认为缺少加密的一类必然值得选择，应先满足安全与兼容条件。

排查时先确认服务端声明的是哪一种代理，再检查是否需要 TLS、认证和 UDP。Trojan 的证书错误沿 TLS 分支处理；HTTP 代理的拒绝响应检查认证或 CONNECT 权限；SOCKS5 能建立会话但特定业务失败时检查命令支持与数据报路径。对于工作网络中的既有代理，还应遵守网络管理要求，不随意更改认证方式或目标端口限制。性能测试应在允许的业务范围内进行，避免将权限限制误判为协议速度问题。

05 / WireGuard

WireGuard：密钥、地址与隧道路由

从虚拟网络而不是单个请求理解

WireGuard 以加密的三层隧道为主要模型，与前面围绕目标请求建立代理会话的类型不同。它使用公私钥识别通信双方，通过 UDP 传递封装后的网络数据包。其设计强调较小的协议面与明确的密码学组合，不让用户在大量加密算法之间逐项协商。对客户端使用者而言，这减少了算法选择，却把关注点转向密钥归属、隧道地址、对端端点和路由范围；这些字段任何一项错误都可能影响最终访问。

Private Key 属于本端身份材料，应保持私密；Public Key 用于识别对应的对端。填写时必须弄清来源配置中的“本端”和“对端”分别指谁，不能把服务器公钥填成本地私钥。可选的 Preshared Key 是额外共享材料，不是替代公私钥的普通密码。订阅或配置若已经给出这些内容，应完整保留，分享排错记录时则应移除私钥与其他认证材料，不能只遮住服务器名称就认为已经处理完毕。

Endpoint、Address 与 Allowed IPs

Endpoint 是用于到达对端的实际地址与 UDP 端口；隧道 Address 是设备在隧道内部使用的地址，两者处于不同网络层次。将公网服务器地址填进隧道地址栏，或把隧道内部地址当作 Endpoint，都可能导致连接无法建立。若 Endpoint 使用域名，还依赖隧道启动前可用的解析路径。出现刚开启就无法解析端点的现象，应检查解析是否产生依赖循环，而不是先调整密钥。

Allowed IPs 描述对端相关的地址范围，在 WireGuard 的模型中与路由选择及接收源地址校验有关。它不是网站白名单，也不是随意扩大就能提高成功率的范围。客户端怎样把这些范围与自身策略结合，应按当前配置核对。范围太窄可能遗漏业务地址，范围太宽则可能使不相关流量进入隧道；即使隧道握手成功，服务器没有提供相应转发能力时，目标访问仍然会失败。

移动网络切换与保活取舍

移动设备在 Wi-Fi 与蜂窝网络间切换时，外部地址和 NAT 映射可能改变。WireGuard 的设计可以在认证数据包到达后更新对端端点信息，但这不等于所有切换都瞬间完成；新网络仍需允许 UDP，服务器也要能收到有效流量。闲置较久后首次访问变慢，可能与映射过期或重新建立通信有关。应分别记录持续使用、闲置恢复和切网恢复，不把三种现象合并成一个稳定性评分。

Persistent Keepalive 用来在需要时维持网络映射，代价是周期性发送数据。它不是越频繁越好，也不应对所有记录统一套用固定值。设备处于蜂窝弱信号环境时，小包也可能引起无线活动，影响待机表现；若并不需要维持入站可达性，额外保活未必有益。应按服务器要求与实际网络条件决定，并用同等闲置时长比较恢复情况，而不是观察开关刚启用后的瞬时耗电。

握手正常但部分页面卡住时，需要考虑路由、DNS 和 MTU。隧道封装会占用额外字节，若路径不能妥善处理较大数据包，可能出现小请求正常、大响应停顿的现象。MTU 调整应保留基线并小步验证，避免凭经验填一个极端数值造成吞吐下降。WireGuard 适合已有完整隧道参数、需要地址层连接的场景；若手中只有其他协议的服务器信息，则不能仅凭一对自建密钥把它转换为 WireGuard 服务。

06 / Hysteria2

Hysteria2：QUIC 与丢包链路

QUIC 改变了哪一层

Hysteria2 基于 QUIC 构建代理传输，QUIC 通常运行在 UDP 之上，并结合安全握手、流管理和拥塞控制。理解它的价值，应从链路条件出发：当往返时间较高、链路存在丢包或可用带宽变化时，传输层怎样恢复和分配发送节奏会显著影响体验。它不是简单地把 TCP 数据改装进 UDP 后就自动更快，也不是绕过物理带宽限制；服务端接入、无线质量和目标响应仍然构成上限。

在基于单条 TCP 连接复用多个业务的设计中，底层丢失数据可能影响后续交付。QUIC 的流机制可以减少不同流之间由可靠传输顺序引起的相互阻塞，但单个可靠流内的数据仍需按要求恢复，拥塞控制也仍会影响共享连接。对于应用本身依赖的可靠传输，封装后还可能存在多层反馈。因此不能把“基于 QUIC”理解为丢包没有代价，更不能仅凭协议描述预测某次网页加载时间。

认证、证书与带宽参数

手工核对时，先确认 Address、Port、认证字符串与 TLS 的 Server Name。Hysteria2 的服务端必须实际提供对应协议，名称相近的其他记录不能直接互换。证书验证仍然重要，错误名称、过期证书或设备时间异常都可能影响建立连接。若来源提供混淆等附加参数，应确认双方同时启用且内容一致；这类字段不是密码的备用栏，遗漏或错配会在认证之前就导致通信不符合预期。

部分配置允许声明上下行带宽，用于特定拥塞控制行为。这里的数值是传输调度的输入，不是限速被解除后的目标承诺。填入远高于实际链路的数字，可能导致持续拥塞、丢包与重传，甚至让其他应用的体验变差。不同拥塞控制方式对声明值的使用并不相同，应按来源说明与客户端实际选项理解。最初测试应采用保守、可解释的配置，再通过连续观察决定是否有调整理由。

UDP 可达是前提，不是保证

某些网络对 UDP 有限制、质量波动或不同于 TCP 的处理方式。在同一地点，普通网页直连可用并不能证明 QUIC 路径也可用；端口没有明显报错也不代表协议握手完成。若 Hysteria2 只在某个 Wi-Fi 下失败，应先用已有的其他可用类型作路径对照，再核对服务端是否收到请求。不要同时修改认证、Server Name 和带宽参数，否则无法区分是网络限制还是字段错误。

在 iPhone 上，高吞吐会让无线与处理器保持活跃，功耗可能上升；但更快完成同一任务也可能缩短活跃时间。因此，既要比较传输期间的温度，也要比较任务完成后的总耗电和恢复空闲速度。高丢包环境中更积极的发送策略可能改善吞吐，也可能消耗更多电量。结论只能限定在测试设备、网络和任务内，不能推广成“Hysteria2 固定更耗电”或“QUIC 总是更省电”。

适合尝试的前提是已有 Hysteria2 服务、当前网络 UDP 质量可接受，且业务确实受高时延或丢包影响。若网络本身稳定、任务以短请求为主，收益可能没有持续传输那么明显。进一步原理可阅读Hysteria2 与 QUIC 技术笔记。测试遇到间歇停顿时，记录发生时的网络类型、是否切网和是否刚从闲置恢复，再检查丢包、拥塞与服务器负载，避免把所有问题归为带宽声明不足。

07 / Measurement

iOS 上的速度与电量测试

先定义要完成的任务

“速度快”至少包含首次响应、持续吞吐和交互稳定三个维度。首次响应影响打开新页面的等待，持续吞吐影响大体积传输，交互稳定则关系到实时业务和短请求是否反复停顿。Connectivity Test 的结果只能反映其测试方式涉及的部分链路，不代表所有目标、UDP 业务或长时间使用。开始比较前先写清任务，例如连续浏览同一组页面，或传输同一份已有测试资料，避免每次操作不同却直接比较感受。

要隔离协议差异，理想条件是接近的服务器位置、资源和后半程路径。若两个记录使用不同服务器，观察到的差别只能称为两套连接方案的差别，不能严格归因于协议。即使地址相同，服务端对不同入口的资源安排也可能不同。手中没有这些控制条件时，仍然可以做实用选择，但结论应写成“这条记录在当前网络更适合”，而不是宣布某个协议具有普遍性能优势。

建立可重复的测量顺序

保持相同设备、网络、位置和近似测试时段，暂停明显影响结果的后台传输。先测试基础网络是否正常，再启用一条记录完成任务，随后换另一条重复。顺序可以交替，以减小网络随时间变化造成的偏差。每种条件重复数次并记录范围，不只保留最快的一次。冷连接和热连接应分开：前者包含解析与握手，后者可能受连接复用和缓存帮助，两者不能混在同一列平均。

Wi-Fi 与蜂窝网络应分别记录，移动过程中信号变化尤其容易干扰判断。测试时不要一边切换位置一边调整参数；若必须验证切网恢复，应把它作为独立任务，记录切换前后请求恢复所需时间及是否手动重连。遇到偶发失败，要保留原条件再重复，而不是立即更换多个字段。连续几次稳定完成的方案，通常比偶尔得到漂亮峰值但经常停顿的方案更适合作为日常选择。

功耗比较要区分活动与待机

电池百分比是粗粒度读数，几分钟内的细小变化不足以证明协议差异。屏幕亮度、温度、信号强度和后台应用都可能覆盖协议开销。比较活动耗电时，固定屏幕与任务，关注完成同一工作量的总表现；比较待机时，则固定闲置时长与网络环境，观察是否出现持续流量或频繁恢复。不要把一次长时间视频任务与另一条记录的纯待机放在一起，再据此判断谁更省电。

系统电池统计和 Shadowrocket 的 Data 可以辅助观察，但统计口径不同。流量字节数并不能直接换算电量，系统对扩展与应用活动的归属也未必精确反映某个协议的独立成本。发现异常后，先看是否存在大量重试、周期性请求、保活或反复断连，再检查 On Demand 的触发条件。保持合理的自动连接设置有助于符合使用需求，但规则越复杂并不意味着越省电，触发结果仍需要实际验证。

排错记录应只保留必要证据：网络类型、协议类型、失败时间段、请求阶段和处理结果。对外提供日志前，检查其中是否包含订阅地址、认证材料、访问域名或个人网络信息。订阅链接往往具有访问凭据性质，不应整条贴出。需要整理多个来源时，可参考多个订阅的分组与清理，先保证测试记录对应明确的服务器，再讨论性能，否则重复名称可能让比较对象在不知不觉中发生变化。

08 / Decision

按场景选型与最终验证

先排除不满足条件的组合

选择顺序应是可用性、安全边界、业务兼容，再到性能和电量。先列出已有服务器真实支持的类型，排除当前网络无法承载或客户端无法表达必要字段的组合。接着确认认证与证书验证完整，检查目标业务是否依赖 UDP、是否需要访问隧道内部地址。只有这些条件成立，速度比较才有意义。较短的参数表并不自动更可靠，较复杂的方案也不自动更安全，关键是每一层都能被清楚解释和正确验证。

日常网页与一般应用访问，可优先保留已经稳定使用、字段来源明确的方案；没有必要仅因协议名称变化就重建所有记录。需要地址层隧道和特定内部网段时，完整的 WireGuard 配置更贴近这种模型。高丢包或高时延环境下，已有 Hysteria2 服务可以作为实测候选。只有 HTTP 或 SOCKS5 信息时，则必须先理解链路保护及业务支持范围，不能假定名称简单就适用于所有敏感访问。

把协议验证与规则验证接起来

导入完成后先在 Home 核对选中的服务器，再检查 Global Routing。临时使用 Proxy 可以帮助判断部分问题是否来自分流，但不能因此跳过最终 Config 验证。回到 Config 后，确认启用的是预期文件，查看目标请求最终采用的策略。规则遵循自上而下匹配，首个命中决定处理方式；如果前面的宽泛规则已经命中，后面的精确规则就不会继续执行。协议可用与规则正确是两个独立验收项目。

下面仅是 Shadowrocket 文本配置的规则片段，用于说明职责，不是服务器参数，也不应直接覆盖现有完整文件。示例域名用于讲解，PROXY、DIRECT 与 REJECT 表示不同处理策略。IP-CIDR 可以表达局域网地址范围，FINAL 则处理前面未命中的连接。采用这些片段前，应确认现有配置中的策略含义与实际业务一致；不要通过盲目扩大 DIRECT 范围掩盖代理失败，也不要把所有本地请求交给远端。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN,ads.example.net,REJECT
IP-CIDR,192.168.0.0/16,DIRECT
FINAL,PROXY

DNS 也应纳入最后验证。域名规则与地址规则依赖的信息不同，解析结果、缓存以及 IPv4 / IPv6 可达性都可能改变命中表现。某个域名偶尔走向不同地址，并不一定是协议参数变化。先确认日志中请求的域名或地址、实际命中项及使用策略，再判断是否需要调整规则。更详细的顺序说明见规则优先级与 FINAL 兜底，避免把协议手册中的连通性测试当作分流配置教程。

形成可以回退的日常配置

最终保留一套已验证的基线：协议类型与关键参数来源明确，日常目标可用，闲置与切网后能按预期恢复。尝试新方案时复制记录并清楚命名，不要直接覆盖唯一可用项。订阅更新后再次核对选中记录，因为服务端可能调整地址或字段；重复名称也可能造成选错。换机前应保留必要的配置备份，恢复后重新验证授权、当前 Config 和实际策略，不假设所有本地状态都会随应用购买记录一起恢复。

如仍无法定位，按顺序整理“基础网络是否正常、端点是否可达、TLS 是否成功、认证是否通过、目标是否命中预期策略”这几项，再进入疑难解答。需要重新走导入与首次连接流程时，返回使用教程。选型的最终结果应是一份能够解释、复测和回退的配置，而不是一张脱离网络条件的协议排名。客户端与系统要求以 App Store 页面标注为准，服务器参数则从你的服务商处确认，两类事实不要混用。