Shadowrocket 协议详解
与参数参考

一、协议选型与连接层次

选择协议的首要依据不是名称，而是服务器实际接受的连接方式。Shadowrocket 中的协议类型必须与已有订阅或服务器信息一致；把同一地址改选另一种类型，并不会让服务器获得相应能力。只有服务端同时提供多种入口，且每组认证与传输参数都完整时，才存在可比较的选择。导入后应先核对类型、地址与端口，再判断是否需要调整附加设置，而不是从速度印象出发逐项试改。

把一次访问拆成四层

第一层是本地网络，负责让设备接入无线网络或蜂窝网络，并具备到服务器的基本可达性。第二层是传输与安全封装，决定连接使用 TCP 还是 UDP，是否建立 TLS，以及是否叠加 WebSocket 等承载方式。第三层是协议认证与数据格式，例如密码、UUID 或公钥身份。第四层才是客户端路由与目标访问，决定请求走所选服务器还是直接发出。前一层失败时，修改后一层通常不能解决问题。

这也解释了为何“能测到响应”与“网页可用”不是同一件事。某个测试可能只验证地址可达、握手成功或指定目标返回结果，并不覆盖所有目标、DNS、UDP 和应用行为。反过来，单次测试失败也可能是测试目标自身不可达。阅读结果时要保留测试方法、当前网络、所选服务器和路由姿态这几个条件，避免把不同条件下的数字并排比较。

速度与电量必须在相同条件下比较

协议开销只是速度的一部分。服务器距离、可用带宽、拥塞、丢包、目标站点限制和设备无线信号，都可能比加密算法的差异更显著。在同一网络、相近时间和同一目标下，分别观察首次打开、持续传输与空闲恢复，才能区分握手成本和稳定吞吐。不要把一次短测试的结果当成持续速度，也不要把多个任务同时运行时的体验归因于某一种协议。

在 iPhone 与 iPad 上，电量还受到无线模块唤醒、后台重连、信号质量、屏幕亮度和前台任务影响。握手较少不必然更省电，连接保持更积极也不必然更耗电；实际影响取决于访问频率和网络切换。评估时保持相似使用时长，记录设备是否发热、连接是否频繁中断，并区分应用传输与系统后台任务。本文不按协议名称给出固定的速度或电量排名。

整理配置时可以保留一份已验证可用的基线，每次只修改一个变量，并记录修改原因。认证信息、订阅地址和私钥属于敏感内容，不应放进公开截图或诊断文本。协议字段以当前应用实际显示及服务端说明为准；某个选项没有出现时，不要用名称近似的字段代替。系统要求一律以 App Store 页面标注为准，本文不把设备兼容性与协议性能混为一谈。

二、Shadowsocks：共享密钥与加密方式

Shadowsocks 的设计从较轻量的代理转发出发，使用双方预先约定的密码与加密方式处理通信。它不是依靠证书链确认服务器身份的 TLS 协议，因此“密码正确”和“加密方式一致”是连接成立的重要条件。其设计取舍是保持代理协议相对精简，把服务器部署、账户管理和承载扩展留给配套实现。对用户而言，应把服务端提供的配置作为完整组合，而不是只保存地址与密码。

地址、端口、Password 与 Method

地址可以是域名，也可以是 IP 地址；域名是否能正确解析属于连接前置条件。端口标识服务器的具体入口，同一地址的不同端口可能使用不同密码或加密方式。Password 必须逐字一致，尤其要留意复制时的首尾空格、换行与全角字符。Method 则决定如何处理加密数据，不是可随意切换的性能档位；即使名称相近，不同方法之间也不能互相替代。

较早的流加密设计与后来的 AEAD 设计在完整性保护、报文处理和重放防护等方面存在差异。AEAD 同时处理机密性与认证，但这并不意味着名称含有某个算法就一定适合当前服务器。不同方法对密钥格式也可能有不同要求，某些方法所需的材料不能按普通口令理解。遇到导入后的长字符串，应先确认它是否是规定格式的密钥，不要自行缩短、重新编码或替换成便于记忆的文字。

导入链接通常已经包含类型、加密方式、密码、地址和端口，但链接外观紧凑不代表信息可以省略。先用原始配置建立基线，若需手动核对，再逐项比较应用中显示的字段。备注名称只是本地辨认标签，不能作为协议或服务器能力的证据。订阅中的名称即使带有某种网络描述，也不应据此开启额外传输选项；实际入口以配置字段和服务端说明为准。

UDP 与附加承载不是自动兼容

需要实时音视频或其他 UDP 业务时，必须同时核对客户端设置、服务器转发能力和中间网络。TCP 网页能打开，不足以证明 UDP 路径可用。若配置包含附加承载或混淆参数，它们也是双方约定的一部分；只匹配主协议而漏掉这些参数，可能表现为建立连接后没有有效数据。附加选项应按当前应用支持情况填写，不能把另一组入口的参数拼接进来。

Shadowsocks 的实际资源消耗与方法实现、设备硬件、数据量和连接数量有关。轻量封装可能减少部分处理工作，但在弱信号或高丢包环境中，无线传输与重试的成本仍可能占主导。判断是否与协议有关，应比较同一服务器可用入口，避免把不同线路或不同负载服务器之间的差距解释为算法差异。短时间下载后设备升温，也可能主要来自无线与存储活动。

排错顺序可以固定为：核对地址和端口，确认 Method 与 Password，再检查附加承载，最后验证 UDP 和路由。若一组原本可用的订阅突然失败，先确认更新是否改变字段，以及服务器信息是否仍有效，不要连续修改多个选项。更新订阅前记录本地手动改动，因为后续刷新可能重新写入条目。需要重走添加流程时，使用入门指南，本章用于解释字段而不重复整条操作主线。

三、VMess 与 VLESS：认证、传输与安全封装

VMess 与 VLESS 都经常使用 UUID 作为用户身份材料，但两者不是同一种协议的两个开关。VMess 在自身设计中处理认证与数据保护，VLESS 则采用更精简的协议结构，通常结合另外的安全传输层使用。它们的设计背景体现了不同取舍：一种在协议内部承担更多职责，另一种把部分职责交给外层。已有 UUID 并不意味着可以在两个类型之间直接切换。

UUID 有效，只代表格式成立

UUID 的字符与分隔符要完整保留，复制时不要包含引号、空格或说明文字。即使格式符合要求，服务器也可能因为账户停用、身份不匹配或入口配置不同而拒绝请求。对于 VMess，还应留意设备时间是否准确；认证过程可能受到明显时间偏差影响。自动日期与时间有助于排除这一变量，但时间恢复正常后仍失败，就应继续核对服务端参数，而不是反复重置时间。

VMess 配置中的加密相关选项应按服务器约定填写，不能因为外面已经使用 TLS 就自行推断内部设置。历史配置可能带有不同的附加字段，导入后应以当前应用实际解析的结果为准。某些旧字段缺失或出现默认值时，需要回到原始配置与服务端说明确认，而不是把网上不同年代的参数组合到一起。协议演进与服务器配置差异不能仅凭条目名称识别。

传输方式决定连接如何到达协议入口

同一种协议可能通过不同承载传送。直接 TCP 连接、WebSocket 以及其他受支持的承载，对路径、主机名和服务端处理方式有不同要求。选择 WebSocket 时，Path 与 Host 等参数可能参与请求路由，路径中的斜杠、大小写和字符都需要准确。服务器端若通过中间代理分配入口，仅连接到同一地址与端口并不保证会到达正确服务。

TLS 的 Server Name 用于握手中的服务器名称指示及相关身份核对；传输层的 Host 则可能用于上层请求路由。二者在某些配置里相同，但职责不同，不能把一个字段缺失的值机械复制到另一个字段。证书校验也不是连接失败时应优先关闭的项目：域名不匹配、证书链异常和系统时间错误都应先定位，否则只会把明确错误变成难以察觉的风险。

VLESS 的精简不等于可以省略外层安全

VLESS 本身不承担与 VMess 相同的数据加密职责，实际保护取决于完整安全方案。若已有配置指定 TLS 或其他受支持的安全参数，应整体保留。某些服务端还会要求特定 Flow 或相关安全字段；这些值涉及双方协议行为，不是普通备注。字段是否可用、组合是否受支持，要以当前 Shadowrocket 实际界面和已有配置为准，不能为了消除错误而随意置空。

在 iOS 上，首次访问的等待可能包含 DNS、外层连接与安全握手，持续传输则更多受路径质量与拥塞影响。增加封装可能带来额外处理，但也可能是服务端正确接入所必需。空闲后慢、持续下载正常时，应关注连接重建与网络切换；全程都慢时，再比较路径和服务器负载。判断 VMess 或 VLESS 是否合适，应看已有入口能否完整匹配，而非只看“精简”或“加密”这样的单个描述。

四、Trojan、HTTP 与 SOCKS5：安全边界不同

Trojan 把 TLS 作为重要外层，结合自身认证与转发格式；HTTP 与 SOCKS5 则来自更通用的代理需求，侧重告诉代理服务器应连接哪个目标。把三者放在一起查阅，是为了区分代理功能与安全通道：能转发连接，并不自动意味着客户端到代理服务器的这一段已经加密。选择时既要核对代理类型，也要确认现有入口是否提供相应的安全封装。

Trojan：先确认 TLS，再确认 Password

Trojan 配置通常需要服务器地址、端口、Password 和 TLS 名称相关信息。连接地址负责实际到达服务器，Server Name 则与 TLS 握手和证书身份核对有关，二者可以相同，也可能因部署方式而不同。使用 IP 地址作为连接目标时，更不能直接推断证书就应匹配这个 IP；应根据已有配置保留名称参数。身份验证通过仍不代表后续转发一定成功，目标可达性还要单独检查。

证书相关失败应按系统时间、名称匹配、证书链和服务端部署逐项核对。跳过证书验证会削弱服务器身份确认，不适合作为长期排错结果保留。若局部网络中存在需要先完成网页登录的接入过程，应先处理本地网络条件，再测试代理。TLS 错误、认证错误和目标访问错误属于不同阶段，最好保留错误原文，以免中文概括掩盖实际差异。

HTTP：CONNECT 建立隧道，不替代 TLS

HTTP 代理可以处理代理请求，也常通过 CONNECT 为目标建立字节隧道。目标网站使用 HTTPS 时，网站自身的 TLS 通常在应用与目标之间建立；这不等于代理握手、认证信息与目标元数据都自动受到客户端到代理这一段的保护。是否使用加密代理入口，要看服务器提供的方式以及应用中的对应配置，不能仅凭目标网址以 HTTPS 开头就作判断。

HTTP 代理的用户名和密码可能与服务器登录凭据完全不同，应使用服务端明确提供的代理认证材料。认证失败时先确认是否需要用户名、是否包含特殊字符以及导入时是否正确还原。某些代理对目标端口、请求方式或账户使用范围有限制，表现可能是连接成功但部分目标被拒绝。此时持续更改 DNS 或规则未必有帮助，应先核对代理的访问边界。

SOCKS5：协商目标与认证，UDP 另有条件

SOCKS5 提供目标连接协商，可支持不同认证方式，并在协议层定义 UDP 转发机制，但它本身不保证数据加密。客户端支持某项能力，也不代表当前服务器启用了它。使用域名作为目标时，解析发生的位置还取决于请求交给代理的形式与客户端处理过程，因此需要结合 DNS 设置检查，不能仅从 SOCKS5 这个名称推导所有解析都在远端完成。

SOCKS5 的 UDP 转发往往需要额外的关联过程，并依赖双方以及中间网络允许相关流量。网页可访问而实时业务失败时，要分别检查 TCP 与 UDP，而不是反复更换用户名。若用户已有的是本地或受控网络中的普通代理入口，还要考虑离开该网络后地址是否仍然可达。地址可达范围是部署条件，不会因为把条目保存进客户端而自动扩展。

比较这几类入口时，应先排除配置差异，再考虑握手、连接复用和路径质量。Trojan 的 TLS 握手可能影响短连接初始等待，普通代理的封装较少却不意味着整体更快或更合适。对于 iOS 的间歇访问，连接是否能稳定恢复同样重要。若只有某个目标失败，先验证目标本身与服务器访问限制；若所有目标都失败，再返回地址、认证和安全层检查。

五、WireGuard：密钥身份与三层隧道

WireGuard 面向网络层隧道设计，与逐个请求协商目标的代理协议不同。它通过公钥识别对端，承载 IP 数据包，并使用 UDP 传输。这样的设计把身份、隧道地址和可发送的网段放进同一套配置关系中。添加时不能只拿一个服务器地址和密码套用；必须拥有服务端分配的完整材料，同时理解哪些字段属于本机，哪些字段属于远端。

PrivateKey 与 PublicKey 的方向

PrivateKey 是本地身份的私密材料，不应公开、发送到不明诊断页面或出现在分享截图中。对端配置里的 PublicKey 用于标识远端，而服务端通常也需要知道本地私钥对应的公钥。若替换了本地私钥，却没有同步更新服务端认可的身份，外观完整的配置仍然不能正常通信。复制密钥时要保留完整编码，避免把备注或换行一起粘贴。

若配置包含 PresharedKey，它属于额外的双方共享材料，不替代公私钥关系，也不能由用户随意填一个字符串。不同密钥字段即使都表现为一串相似字符，也有不同用途。不要因为应用接受输入就认定材料正确；格式校验只检查表示形式，无法证明远端有相应配置。排错时可以核对密钥对应关系，但不应把私钥全文加入反馈内容。

Address、Endpoint 与 AllowedIPs

Address 通常指隧道内本地接口使用的地址，而 Endpoint 是设备用来联系远端的公网地址与端口。二者不应互换：隧道地址不是可直接拨通的服务器入口，远端公网地址也不是本地隧道地址。若服务端分配了特定地址，应按原值填写，并留意前缀长度。自行改成另一个看似空闲的地址，可能破坏服务器路由或访问控制。

AllowedIPs 在 WireGuard 语义中参与对端与 IP 范围的对应关系，同时涉及发送选择和接收来源校验。它不是一张简单的网站域名名单，也不等同于 Shadowrocket 的域名分流规则。具体流量最终如何进入该条目，还取决于客户端的路由处理。不要直接套用其他环境的全局路由结论，应同时核对隧道允许范围、服务器转发能力和当前 Global Routing 设置。

MTU 与连接保持需要有依据地调整

MTU 影响隧道内单个数据包的大小。外层封装需要额外空间，路径能够承载的包大小也可能不同；数值不合适时，可能出现小请求正常、大传输停顿的现象。但降低 MTU 不是所有连接问题的通用修复。应先排除地址、密钥和路由错误，再在可重复的相同任务中观察修改前后的变化，避免同时调整多个参数后无法判断原因。

连接保持用于在特定网络条件下维持映射或促进可达性，间隔过于积极会增加空闲传输与无线活动。是否需要设置、如何设置，应参考服务端安排和实际网络表现，不宜照抄固定数字。在 iOS 上，前台访问、设备锁屏和无线切换的行为也不同；握手可见不代表隧道内目标可达，仍需核对服务端转发、返回路由与 DNS。更具体的字段阅读顺序见WireGuard 参数说明。

六、Hysteria2：QUIC、UDP 与拥塞条件

Hysteria2 的设计利用 QUIC 与 UDP 承载代理通信，关注复杂传输条件下的数据传送。QUIC 在 UDP 上实现安全连接、可靠传输与多路复用等机制，因此“基于 UDP”不等于把所有业务都变成不可靠数据。它与基于 TCP 的入口有不同的传输行为，但最终表现仍取决于网络是否允许 UDP、路径拥塞程度、服务器资源与参数是否合理，不能仅凭协议名称承诺速度。

先确认 UDP 路径，再讨论性能

本地网络允许网页访问，并不保证到指定服务器的 UDP 端口可用。某些接入环境会限制 UDP，或者对长时间、较大流量的 UDP 通信表现不同。若入口始终无法建立，应先核对地址、端口和网络条件，必要时在另一种可信网络下做对照。若网络切换后结果明显不同，说明应继续调查路径，而不是优先更换认证字符串或证书名称。

QUIC 的连接与重传机制能够应对部分丢包和路径变化，但不能消除物理带宽、远端拥塞或持续丢包的限制。高丢包时，更多重试可能增加无线传输和设备处理负担。即使前台任务完成得更快，电量结果也需要结合传输时长与空闲活动判断。对于短消息式访问，首次握手与唤醒成本可能更显著；对于长传输，则应观察稳定阶段而不是开头的一次峰值。

认证、TLS 名称与附加参数

Hysteria2 的认证信息必须与服务器约定一致，可能表现为密码或特定形式的认证材料。不要因为字段看起来像普通口令，就将其中的分隔字符删除。TLS 相关名称仍需要正确核对，连接地址与证书名称的职责也仍然不同。若原始配置包含特定安全或附加参数，应确认当前应用支持并完整导入；不应把不同协议代际的条目仅靠改名转换。

部分部署会要求额外的混淆参数或其他约定。这些内容既不是提高速度的通用开关，也不是可任意省略的装饰字段。服务端要求而客户端缺失时，可能在认证之前就不能完成有效通信。导入后应逐项比较原始材料与实际显示值，特别注意特殊字符、编码和参数名称。若手动填写与订阅导入结果不同，先查清差异来源，再决定保留哪一组。

带宽参数不是速度保证

当当前配置提供上行、下行或拥塞相关设置时，数值可能参与发送行为或带宽协商，并不等于服务器为账户分配的固定能力。上行与下行的方向、计量单位和服务端限制都需要确认。把数值不断调大，不会增加本地无线链路的物理容量，反而可能使拥塞、丢包和延迟更明显。若没有可靠依据，应保留原有有效配置，而不是按某次速度测试的瞬时峰值填写。

在 iPhone 上评估电量，可以先观察固定时长的真实任务，再观察同等时长的空闲连接，记录信号状态与是否发生网络切换。后台保持、频繁重试和高强度传输都会影响结果；不同服务器之间的比较还混入了线路差异。设备发热时，应先停止重复大流量测试，让条件恢复一致，否则后续结果可能受到设备温度与系统调度影响。

适用判断应回到已有资源：服务器明确提供 Hysteria2、UDP 路径可用、认证与 TLS 参数完整，才具备测试前提。若同一服务端同时提供其他类型，可保留另一组已验证入口作为对照，但不应把一次失败概括为协议永远不可用。只出现部分目标异常时，应继续检查 DNS、规则与目标本身；入口层成功，并没有替后续各层完成验证。

七、Global Routing、规则与 DNS 的关系

协议条目描述如何连接一个服务器，Global Routing 则决定请求是否使用这些条目。两者属于不同层次。配置/代理/直连分别对应界面中的 Config / Proxy / Direct：Config 按当前配置规则处理，Proxy 用于按所选代理处理通常的请求，Direct 用于直接连接。具体访问还可能受到配置细节、系统处理与应用行为影响，因此验证时应观察实际请求记录，不只看 Home 上的状态。

用三种姿态缩小问题范围

如果 Direct 下目标可用，而 Proxy 下失败，可以优先检查所选服务器、协议认证和服务器到目标的路径。如果 Proxy 可用，而 Config 下失败，应重点检查当前激活的配置与规则命中，特别是是否指向另一条策略或被 REJECT。若三种姿态都失败，先检查本地网络、目标服务和 DNS。这样的比较是一种定位工具，不意味着应长期用某种姿态覆盖所有需求。

在多个配置文件并存时，先确认当前生效的是哪一份。修改了未激活文件，不会自动改变正在使用的规则；订阅中的服务器更新，也不等于规则文件已经更新。排错前记录所选服务器、Global Routing 与配置名称，可以避免把三处独立变化混在一起。恢复日常配置时，也要把临时用于测试的姿态切回原先需要的状态。

规则顺序与兜底规则

规则通常依顺序匹配，前面的适用规则会影响后续规则是否有机会处理同一请求。DOMAIN 适合精确域名，DOMAIN-SUFFIX 适合域名及其子域范围，IP-CIDR 与 IP-CIDR6 面向地址网段，GEOIP 依据地址数据库判断，FINAL 提供兜底处理。选择关键字时要先确定匹配对象是域名还是 IP，不要为了覆盖更多请求而任意扩大范围。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY

这段示例展示规则结构与顺序，不是一份完整可直接替代现有配置的文件。example.com 是说明用域名；PROXY、DIRECT 是处理方向，不能用中文文字代替。GEOIP 的结果依赖地址数据库与实际目标地址，不保证等同于网站主体所在地区。FINAL 必须按自身需求决定，且应放在兜底位置；更改它会影响此前没有命中的请求，而不仅是某一个测试目标。

DNS 不是一个独立的“加速开关”

DNS 把域名解析为地址，解析器选择、请求发送路径与返回地址都会影响后续访问。系统 DNS、自定义解析器和 DNS over HTTPS 各有部署条件。DoH 为解析通信提供 HTTPS 封装，但是否通过代理、解析器本身是否可达，以及是否产生连接前的依赖，仍要结合配置检查。切换解析方式时应确认新路径能够建立，而不是一次改掉所有解析项。

域名规则与 IP 规则也可能依赖不同阶段的信息。若只有域名访问失败，直接使用地址的测试只能证明一部分路径，因为证书名称、上层主机名与目标服务可能仍然需要域名。IPv4 与 IPv6 返回结果不同，也可能使同一目标在不同网络下表现不同。不要仅凭某次解析得到一个地址就认为问题已排除，应观察失败请求实际使用的地址族与规则处理。

调整 DNS 后，既有连接和缓存可能暂时沿用先前结果；需要在可控条件下重新发起访问，再比较记录。避免一边刷新订阅一边更换解析器和规则，否则无法确定是哪一项改变了结果。关于解析路径的详细取舍，可继续阅读系统 DNS、自定义 DNS 与 DoH 说明；术语含义见概念速查。

八、按场景选择与分层排错

选型结论应来自可用配置与实际任务。若只有一组完整服务器信息，先正确使用这一组，而不是更换协议类型。若已有多个可用入口，按相同条件比较短请求、持续传输、空闲恢复与网络切换，并保留一个稳定基线。不同用途的最佳结果可能不同：前台大文件传输看稳定吞吐，间歇浏览更关注首次等待，实时业务还要检查 UDP、抖动与持续可达性。

场景判断先看限制条件

当本地网络对 UDP 的可达性不确定时，应先验证路径，再评估 Hysteria2 或 WireGuard；测试不通时，不要用提高带宽或缩短保持间隔代替网络检查。若已有配置依赖特定域名、路径和 TLS 名称，应优先保证 VMess、VLESS 或 Trojan 的整组参数一致。若用户已有 HTTP 或 SOCKS5 入口，还需要明确其可达范围、安全封装与访问限制。

设备经常在无线与蜂窝网络之间切换时，应分别测试两个网络，并观察切换后的恢复情况。切换导致短暂中断并不自动说明认证失效；地址解析、映射和既有连接都可能需要重建。锁屏后失败而前台正常时，则应记录锁屏时长、恢复方式与是否有 On Demand 条件参与。不要把按需连接规则的触发行为误判为某个协议天然不能在后台使用。

连接失败：从入口向目标推进

第一步确认本地网络能完成正常接入，必要时先完成网络自身要求的网页登录。第二步核对服务器地址、端口和协议类型，检查订阅是否已经更新以及条目是否仍有效。第三步核对认证、安全层与传输字段，包括密码、UUID、公钥关系、Server Name、Host、Path 和可能的附加参数。每次只处理一个可验证问题，不要为了让状态变化而同时切换多项设置。

第四步区分握手、认证与目标访问。保留应用实际显示的错误原文，在当前可用的记录或诊断功能中确认失败发生在哪一阶段。第五步检查 Global Routing、规则与 DNS，再使用不同目标对照。若仅单一目标失败，服务器到目标的路径、目标限制和解析结果都需要考虑；若全部目标失败，继续回到前面的公共层次，不必逐条改网站规则。

速度慢：把测试做成可重复任务

测试前关闭同时进行的大流量任务，选择同一目标与相近任务长度，记录所用网络和服务器。先比较直接访问与所需代理访问，再在同一服务端可用入口之间比较。Connectivity Test 的结果只代表该测试方法与当时条件，不应直接换算成下载速度。连续进行多次极限测试会引入发热、拥塞与后台活动差异，适度间隔更有助于得到可解释的结果。

若慢只出现在首次打开，重点检查 DNS、握手与连接恢复；若开始正常、持续后下降，检查拥塞、负载、热状态与路径变化；若小请求成功、大传输停住，才进一步考虑 MTU 或分片相关问题。所有判断都需要用相同任务复测。分层方法与测试结果的解释可参考速度慢的分层排查，不要只凭一次数字决定删除全部配置。

恢复基线与整理反馈

当修改变多时，优先恢复已验证的配置副本，再逐项加入必要变化。更新订阅前确认本地手动改动是否会被覆盖，不能把更新后的字段变化误认成客户端随机失效。反馈问题时提供协议类型、网络条件、失败阶段、错误原文及可重复步骤即可；删除订阅完整地址、Password、UUID、PrivateKey 和可识别账户的信息，不要为了便于复现而公开认证材料。

本手册不替代服务端配置说明，也不把协议名称作为质量保证。应用获取、已购恢复与正版信息见正版核对；首次系统权限见首次打开与 VPN 配置权限；已知症状可继续在问答中查找。完成排查后，应记录实际有效的配置关系，而不是只留下“换了某个协议就好了”的结论，这样下次更新或换网络时仍能按层次复核。