Shadowrocket 协议参考

01 / Connection Model

连接模型：先区分四层参数

选择协议的第一原则是与服务端一致，而不是从名称推断性能。Shadowrocket 中的一个连接条目通常同时描述服务器地址、身份认证、传输方式和安全设置；规则则决定哪些请求交给这个条目。四者任何一处不匹配，都可能表现为连接超时。开始修改前，先保留现有可用配置，并确认信息来自用户已有的服务商或自行管理的服务器，避免凭记忆补全字段。

协议、传输与 TLS 不是同一项

Shadowsocks、VMess、VLESS 和 Trojan 描述的协议机制不同；TCP、UDP、WebSocket 则涉及承载数据的方法；TLS 负责特定连接层的加密和身份验证。一个条目可以同时包含协议名称、WebSocket 和 TLS，这并不表示要在三者之间任选其一。应按提供的连接资料逐层对应，不能因为启用了 TLS 就忽略协议认证，也不能因为填写了 UUID 就认定传输层已经正确。

地址和名称也有不同用途。Server 一般决定客户端向哪里建立连接，Port 决定访问哪个服务端口，SNI 则在 TLS 握手时声明服务器名称。WebSocket 的 Host 属于 HTTP 请求信息，Path 指向服务器约定的路径。这些字段有时碰巧相同，有时刻意不同；它们不是可以互相替换的备用输入框。连接资料没有要求的字段，应保持导入值或默认值，而不是全部填成服务器地址。

Global Routing 决定流量是否进入条目

Global Routing 的 Config 按当前配置文件匹配规则，Proxy 将进入客户端处理范围的流量交给代理策略，Direct 则用于直连。三种姿态改变的是路由选择，不会改变服务端协议。若切换到 Proxy 后可以访问、回到 Config 后失败，应先检查规则和实际命中策略，而不是立即重建服务器条目。反过来，Direct 下访问成功也不能证明代理连接已建立。

DNS 是贯穿这些层次的前置条件。客户端可能需要先解析服务器域名，目标网站也可能有独立的解析过程。服务器域名解析失败时，认证尚未开始；目标域名解析错误时，连接条目本身仍可能可用。因此应区分“无法找到服务器”和“通过服务器访问某个目标失败”，保留报错涉及的域名及发生阶段，不要把所有解析问题都归为协议不兼容。

iPhone 与 iPad 上的实际表现还受到无线信号、网络切换、后台任务和服务器负载影响。低延迟只说明某种测试的往返成本较小，不等于大文件吞吐量更高；一次快速加载也不能说明待机耗电更低。协议比较应在同一设备、同一接入网络、相近时段和相同目标下进行，并记录是否启用了额外传输层，否则结果很难重复。

本页介绍的是字段的职责与验证顺序，不替代服务端配置说明。若导入后出现文中未列出的扩展选项，应先查明它是否为当前服务端所需，再修改。不同传输组合可用的字段并不相同，应用内实际可见项目为准。保存时一次只调整一组有关联的参数，并记录原值，才能在下一次测试中判断变化来自哪一层。

02 / Shadowsocks

Shadowsocks：加密方法与密码配对

Shadowsocks 的设计背景是以较少的协议交互完成代理转发，把加密与数据传送结合起来。它不是完整的设备组网协议，也不靠证书名称识别用户。对客户端使用者而言，最基本的配置关系是地址、端口、加密方法和密码共同对应服务端。名称相同的服务器条目不一定共享这些值，尤其在服务端更换端口或认证资料后，旧条目仍可能存在但已不能使用。

Method 决定密码怎样参与连接

Method 不是可随意调整的性能档位。不同方法规定密钥派生、数据封装和校验方式，客户端与服务端必须兼容。现代认证加密方法可以同时保护数据并检测篡改，但这不代表任何一个名称都适用于所有服务端。应逐字核对提供的加密方法，不能看到同属某个算法系列就替换，也不能以“更长的名称应该更安全”为依据自行选择。

Password 同样需要按原值使用。复制时容易带入空格、换行或看起来相近的字符；某些协议变体的密钥有特定编码与长度要求，不能当作普通文字密码重新输入。若链接导入后显示出的密码较长，应保留其结构，不要做大小写转换或手动去掉末尾符号。需要重新确认时，应通过已有资料的管理入口核对，避免把完整密码贴入截图或公开讨论。

常见的 AEAD 方法包括 AES-GCM 与 ChaCha20-Poly1305 系列。它们的运行成本与设备的硬件指令、实现方式及流量形态有关，因此不能单凭算法名称断定 iPhone 上谁始终更省电。持续传输时，处理器效率可能影响吞吐；零散访问时，唤醒次数和无线电活动时间可能更重要。只有在服务端同时提供兼容选项时，比较算法才有实际意义。

TCP 可用不代表 UDP 已经可用

Shadowsocks 可以承载不同类型的目标流量，但实际 UDP 转发需要服务端、客户端设置和当前网络共同支持。网页通常能通过 TCP 建立连接，部分实时应用则依赖 UDP；因此“网页可以打开，另一个应用仍失败”并不矛盾。应先确认该业务是否需要 UDP，再查看现有服务是否允许转发，而不是用网页加载结果替代对 UDP 的单独验证。

如果连接资料还包含额外的插件或传输参数，它们也是完整连接的一部分。基础协议名称一样，不代表带有额外封装的条目可以删掉这些设置后使用。与此同时，不应为一个普通条目主动增加未被要求的 TLS、Host 或 Path。叠加更多字段只会引入新的匹配条件，不会自动修复地址错误、密码失效或端口不可达的问题。

在 iPhone 上怎样判断是否值得保留

若现有 Shadowsocks 条目已能稳定处理日常业务，单纯换成名称更复杂的协议没有必然收益。可以先记录冷启动访问、持续传输和锁屏后恢复三类体验：首次访问主要观察连接建立，持续传输观察稳定吞吐，恢复测试观察系统网络变化后的重新连接。每类测试解决的问题不同，不宜合并成一个笼统的“速度分数”。

出现失败时，先看服务器域名是否能解析、端口是否正确，再核对 Method 和 Password，最后检查 UDP 或额外传输要求。如果同一条目在同一网络中所有目标都失败，优先检查入口和认证；如果只有特定目标异常，再检查规则、目标解析和服务端到目标的路径。逐层缩小范围比不断改加密方法更容易得到可复现结果。

维护订阅导入的条目时，还要区分订阅更新与手动修改。更新可能覆盖服务商维护的字段，也可能新增名称相近的条目。测试前确认当前选中的确实是刚核对过的连接，避免修改甲条目却测试乙条目。需要长期保留自定义设置时，先明确应用内该类条目的更新行为，并保存原始连接资料作为恢复依据。

03 / VMess · VLESS

VMess 与 VLESS：认证与承载分别核对

VMess 与 VLESS 都经常与不同传输方式组合出现，但不能视为可互换的两个名称。VMess 具有自己的认证与数据保护机制；VLESS 更强调简化协议本身，把安全保护交给配套的安全层。它们反映了不同设计取舍，而不是一个简单的速度升级关系。已有服务端使用哪种协议，客户端就应选择对应类型，不能只保留 UUID 后切换协议名称。

UUID 是身份资料，不是完整配置

UUID 常用于标识连接身份，但正确的 UUID 只解决认证资料的一部分。Server、Port、传输类型及相关安全选项仍必须匹配。导入失败后，若仅重新输入 UUID，却保留错误的 WebSocket Path，连接结果不会改变。也不要把另一个条目的 UUID 借来测试，因为不同用户身份可能绑定不同权限、有效状态或服务端入口。

VMess 的认证过程涉及时间因素，设备时间明显偏差可能造成失败。排查时可在系统日期与时间设置中确认自动校准状态，并检查是否存在时区或手动时间误差。时区显示不同本身不必然意味着系统时间错误，关键是实际时刻是否正确。不要通过反复改动认证相关旧字段来补偿时间问题，应先让设备与服务端的时间基础恢复正常。

VLESS 自身不提供与 TLS 等价的传输加密保护，因此不能把“认证通过”理解为连接链路已受到充分保护。应使用现有服务明确指定、客户端能够支持的安全组合。若资料要求 TLS，就必须核对名称验证和证书链；若包含其他专门安全参数，应逐项按资料设置。不要因为客户端允许保存空白字段，就推断该组合在实际网络中合适。

WebSocket 的 Host 与 Path 要保留语义

WebSocket 常用于把数据放入约定的连接承载方式中，建立过程可能经过 HTTP 请求、TLS 或反向代理。Host 帮助入口识别请求对象，Path 区分服务端路径，两者都不是装饰字段。Path 通常区分大小写，前导斜杠和查询部分也可能有意义；从资料复制时不应擅自简化。收到网页或普通 HTTP 错误内容，往往需要先检查入口路由，而非 UUID。

有些连接资料还会涉及特定流控或复用行为。它们通常与服务端实现、协议类型和传输组合共同约束，不应跨条目照搬。特别是从网上找到某个字段名后，直接加到不同组合里，可能让原本有效的条目失效。当前应用是否呈现相应字段、服务端是否明确要求，是决定是否设置的两个前提，而不是字段听起来是否先进。

额外封装的成本如何观察

在移动网络上，额外握手可能影响首次访问，但长连接建立后这部分成本会被后续流量摊薄。传输层经过的入口、路径长度以及服务端负载，也可能比协议头开销更显著。因此比较 VMess 和 VLESS 时，应尽可能保持同一服务入口和传输组合；若连服务器位置都不同，测出的差异不能归因于协议本身，更不能推广到其他用户。

建议按“类型与身份、传输参数、安全参数、设备时间”的顺序复核，并用同一个目标重复测试。若更新订阅后字段变化，应先确认变化来自资料更新，再考虑恢复旧值。关于超时与时间校准的具体顺序，可继续阅读连接失败的三步排查，不要在尚未定位阶段时同时改动多个层次。

04 / Trojan · TLS

Trojan 与 TLS：先完成服务器身份验证

Trojan 的设计把代理认证和数据传送放在 TLS 连接之内，借助成熟的安全传输机制保护通信。配置时需要同时满足两套条件：TLS 连接能正确建立，随后协议密码得到服务端接受。密码准确并不能修复证书名称不匹配；TLS 握手成功也不能证明 Trojan 认证通过。把这两个阶段分开，是理解该类连接错误的关键。

Server、SNI 与证书名称的关系

Server 表示连接的网络入口，SNI 是客户端在握手中发送的名称信息，证书则用于证明服务器身份。在部分部署中，入口地址与证书对应域名不同，因此已有资料会单独指定 SNI。此时应保持提供的对应关系，而不是为了看起来统一，把所有名称都改成入口地址。证书验证检查的是预期身份，不能仅凭某个地址可以连通就省略。

使用 IP 地址作为入口时尤其需要留意名称验证。证书如果签发给域名，并不当然覆盖该 IP 地址；应按服务端提供的名称设置连接，而非自行猜测。反过来，也不能随便填写一个熟悉的域名作为 SNI，因为入口未必为这个名称提供服务。名称错误可能在认证之前就结束连接，此时继续修改 Password 通常没有帮助。

证书验证还依赖证书链、有效期和设备信任状态。系统时间明显错误，会让本来有效的证书显示尚未生效或已经过期；服务器未正确提供中间证书，也可能让不同设备出现不同表现。排查时记录错误所指向的名称与验证阶段，再让服务器管理方核对证书部署。不要把长期跳过证书验证当作一般修复步骤，这会削弱对服务器身份的确认。

Password 与 ALPN 各自解决什么

Password 是协议认证资料，应与当前服务端完全一致。它与 TLS 证书私钥不是同一个东西，也不应被放进 SNI、Host 或 Path。复制后注意字符完整性，但不要为了排除输入问题而在公开记录中展示原值。若需要请他人协助，应只描述字段是否已核对、错误发生在哪个阶段，并遮盖完整认证内容。

ALPN 用于 TLS 内的应用层协议协商。某些部署对协商结果有明确要求，另一些则使用默认行为。它不是所有连接都需要手动填写的加速开关，也不能通过任意添加协议名提高兼容性。若现有资料指定 ALPN，应保留顺序与内容；若未指定而导入值为空，先维持原状，只有确认服务端需求后再调整。

握手、电量与连接复用

TLS 首次握手需要网络往返和加密计算，但不能据此认定 Trojan 在 iPhone 上必然更耗电。持续连接能摊薄握手成本，设备对密码算法的支持也会影响处理效率。实际耗电还与弱信号下的重传、频繁切换网络、不断重建连接有关。比较时应区分偶发访问和持续传输，避免用一次启动耗时推断整天的电量表现。

如果小请求正常而大文件经常中断，要检查链路质量、超时及可能的 MTU 问题；如果所有请求都在建立阶段失败，则先检查入口与 TLS。若只有特定域名异常，还需确认 Global Routing、规则和目标解析。协议具有安全层，并不意味着所有后续业务问题都属于证书问题，仍应按错误发生的位置缩小范围。

维护时建议保留原始导入条目，再对副本做受控测试。服务器更换证书或入口后，应优先核对已有资料是否同步更新，而不是积累多个跳过验证的条目。确认连接恢复后，删除不再需要的测试副本，避免名称相近时误选。购买和系统兼容性信息仍应在App Store 正版核验说明对应入口确认，不由协议配置决定。

05 / HTTP · SOCKS5

HTTP 与 SOCKS5：代理能力不等于加密能力

HTTP 代理和 SOCKS5 的设计背景是让应用通过中间服务器访问目标资源，它们与面向设备组网的隧道有明显区别。HTTP 代理围绕 HTTP 请求和连接隧道工作；SOCKS5 则提供更通用的目标地址与连接请求表达。选择时应先看已有服务器实际提供哪种服务，再确认是否带有安全传输，不能把“支持代理”直接等同于“客户端到代理的链路已经加密”。

HTTP 代理中的 CONNECT

HTTP 代理可以处理普通 HTTP 请求，也可以通过 CONNECT 请求建立到目标的字节隧道。目标网站使用 HTTPS 时，网站内容通常由客户端与目标之间的 TLS 保护，但这与客户端到代理这一段是否另有 TLS 是两回事。代理仍需要知道连接目标等信息，因此不能只看网页地址栏的 HTTPS，就判断代理入口本身的认证和元数据传送方式。

如果服务器提供的是带 TLS 的 HTTP 代理入口，客户端必须按该入口要求选择对应安全设置。把普通 HTTP 代理条目直接指向一个要求 TLS 的端口，或反过来，都可能在协议协商阶段失败。端口数字没有统一保证，同样的数字可以被不同服务采用；应依赖明确的服务器资料，而不是根据常见端口猜测协议类型。

Username 与 Password 是否必填取决于代理服务的认证要求。空白可能表示该服务未要求这组认证，也可能只是导入资料不完整，不能凭空下结论。若收到认证相关失败，应先确认账号属于当前入口、字符是否完整，以及服务器采用的认证方式是否受当前组合支持。不要把网站登录密码填进代理认证字段，两者的身份范围不同。

SOCKS5 的连接与 UDP 边界

SOCKS5 能表达目标域名或 IP 地址，并支持不同命令，其中 UDP 转发通常涉及 UDP ASSOCIATE。但协议规范具有这项能力，不代表每个服务端都开放，也不代表每条接入网络都能通过。实际测试时应确认服务器允许 UDP、客户端配置支持当前用途，并检查防火墙与返回路径。仅凭 SOCKS5 名称不能断定实时业务一定可以使用。

SOCKS5 的常见认证机制不等于加密机制。即使服务器要求用户名和密码，也需要单独评估客户端到入口的传输保护。目标应用自身的 TLS 可以保护相应业务内容，却不能替代对代理入口的信任判断。已有服务如果要求通过可信内部网络访问，应遵循这个边界，不应把内部用途的代理地址直接用于不符合其设计条件的环境。

域名由谁解析，需要看实际设置

代理请求可能携带域名，也可能使用客户端已经解析的地址，具体行为取决于应用、规则和 DNS 配置。因此遇到内部域名或分区解析问题时，不能只更换 HTTP 与 SOCKS5 类型。应先确认域名需要在哪个网络环境解析、解析结果是否适用于服务端，再核对实际请求路径。入口可达但内部站点失败，可能是解析或访问权限问题，而不是认证失败。

在 iPhone 与 iPad 上，这两类协议也没有脱离环境的速度结论。简单的握手可能降低某些短连接成本，但目标距离、代理服务器能力与网络质量依然决定主要体验。适合的场景是已有明确可用的代理服务、认证与安全条件已知，并且业务类型与服务能力吻合；不适合仅凭配置字段少，就把它们当作所有连接的替代方案。

验证时先选择一个允许访问的固定目标，检查认证与 TCP 转发，再测试需要的其他业务。若只有内部资源失败，向现有服务管理方核对权限、目标解析和访问范围。保存诊断信息时只记录状态与目标类型，不附上完整账号或内部地址清单。协议选择解决的是客户端如何与入口交谈，不会自动授予原本不存在的资源访问权限。

06 / WireGuard

WireGuard：把密钥、地址与路由一起理解

WireGuard 面向加密的 IP 隧道，设计重点是用较精简的密码套件和对等端模型完成通信。它与逐个目标建立代理连接的协议不同，因此配置里除了服务器入口，还会出现本地隧道地址、密钥和路由范围。选择 WireGuard 不是把某个 Password 换成另一种写法，而是需要一套服务端已分配、彼此对应的隧道参数。

Private Key 与 Public Key 的方向

客户端的 Private Key 用于证明本端身份，服务端对应配置中保存的是客户端的 Public Key；客户端条目中的对端 Public Key 则用于识别服务器。把这两种公钥的位置对调，即使地址与端口正确，也无法完成预期握手。Private Key 属于敏感认证资料，不应出现在公开截图、日志附件或求助文字中，重建前应确认是否需要同步更改服务端。

部分配置还会提供 Preshared Key，它在已有密钥交换基础上增加一项共享秘密。只有服务端要求并配置了相同值时才填写，不能自行生成一个值期待服务器自动接受。若服务端没有这项要求，保持资料原状即可。密钥长度、编码和字符都具有结构意义，不能手动删改，也不能把一串看起来相似的密钥当作可替换密码。

Address、Endpoint 与 Allowed IPs

Address 是分配给本端的隧道地址，Endpoint 是联系对端使用的网络地址与端口。前者属于隧道内部，后者属于外部接入，两者不能互填。多个设备通常需要各自的身份与地址安排；将同一套客户端密钥同时复制到多台设备，可能导致服务端观察到的端点不断变化，出现互相影响。应使用已有服务为各设备分配的资料。

Allowed IPs 在 WireGuard 模型中既参与对等端路由选择，也限制相应对等端可接受的来源地址范围。它不是网站域名列表，更不能用 DOMAIN-SUFFIX 语法填写。Shadowrocket 的 Global Routing 和配置规则还处在另外一层，不能认为填了一个广泛的隧道路由，就必然让所有业务经过它。应用如何把请求交给条目，与隧道如何处理 IP 包需要分别验证。

DNS 选项用于指定相应解析行为，但是否应用于某类查询还与客户端的整体 DNS 设置有关。连接成功后只能访问 IP、不能访问名称时，应检查 DNS 可达性及规则，而不是立刻重建密钥。如果隧道内存在私有地址网段，还应检查它与当前 Wi-Fi 局域网是否冲突；地址重叠可能把请求送向错误接口，看起来像目标服务器没有响应。

MTU 与 Persistent Keepalive 的代价

WireGuard 通常通过 UDP 承载隧道数据。额外封装会占用包空间，MTU 设置不适合实际路径时，可能出现小请求正常、大传输停顿的现象。MTU 不是越大越快，也不是越小越稳定；调整应有症状和可重复测试作为依据。优先采用服务端提供或已验证的设置，记录原值后小范围验证，避免同时修改 DNS、路由和 MTU。

Persistent Keepalive 用于在需要时维持网络地址转换设备中的映射。它可能改善某些空闲后的可达性，但定期发送数据也会增加移动设备的网络活动。不是所有客户端场景都需要主动设置，更短的间隔也不必然更可靠。应根据现有服务要求和实际空闲断连现象判断，不能把它当作通用的省电或提速选项。

WireGuard 的精简设计有利于减少部分处理开销，但移动端电量仍由流量规模、重传和保活共同决定。Wi-Fi 与蜂窝网络切换后，端点变化还可能与网络策略相关。排查时依次核对密钥方向、Endpoint、隧道地址、路由范围和 DNS；只有出现包尺寸相关症状时才重点测试 MTU。若主要需求是访问已有私有网络，应先明确服务端允许的网段，而非追求覆盖范围越大越好。

07 / Hysteria2

Hysteria2：UDP 路径与带宽设置

Hysteria2 建立在 QUIC 等机制之上，面向具有延迟、丢包和带宽变化的网络条件设计传输策略。它与主要依赖 TCP 的连接存在不同取舍，但不能据此得出“任何网络都更快”的结论。首先需要当前接入网络能够到达服务端所需的 UDP 入口，其次需要认证、安全和带宽相关配置匹配。入口不可达时，改变应用内的速度预期没有意义。

先确认 UDP 入口，再看认证

Server 和 Port 应指向已有资料给出的实际入口。某些网络允许常见网页连接，却限制其他 UDP 流量，因此网页可以直连并不能证明 Hysteria2 入口可达。若同一条目在 Wi-Fi 可用、蜂窝网络不可用，应保留认证设置，先比较网络路径。不要在每次切换网络时重新生成密码，否则会把网络问题与认证问题混在一起。

认证信息必须按当前服务端的要求填写；若同时提供额外的混淆设置，它与登录认证仍是不同层次。混淆类型、相关密码和是否启用应成组匹配，不能只打开客户端选项。缺少其中任一必需部分，都可能让连接在更早阶段失败。导入后看见两个不同用途的秘密字段时，不应为了简化管理，把它们改成相同内容。

TLS 名称和证书验证原则与前文一致。服务器入口使用某个地址，不代表证书就覆盖该地址；服务端指定的 SNI 应保留。QUIC 使用 UDP 不意味着可以忽略 TLS 身份验证，也不意味着所有握手失败都是网络丢包。时间、名称、证书链和认证错误仍需分别排除，错误发生阶段比笼统的“超时”描述更有诊断价值。

带宽字段不是测出来的保证值

Hysteria2 的带宽相关配置可能影响发送行为和拥塞控制选择，具体取决于服务端及应用提供的选项。应区分上行与下行，并确认输入单位。把运营商宣传的接入带宽、无线连接速率或某次测速峰值直接填入，并不能代表实际可持续的路径能力。填写明显高于真实链路的数值，可能引入额外丢包、重传和抖动，反而影响交互请求。

上行带宽尤其容易被忽略。下载过程仍需要发送确认与控制信息，如果上行被后台任务占满，即使下行容量充足，体验也可能下降。应在网络相对空闲时测试，并观察后台同步是否同时进行。若服务明确支持自动处理或给出了建议值，优先按其要求使用，不要把手动指定带宽当作所有场景都必须完成的优化步骤。

吞吐、延迟和电量要分别观察

较积极的传输策略可能帮助某些受损链路维持吞吐，但持续发包、丢包恢复和用户态处理也会占用资源。在 iPhone 上，下载完成得更快有时能缩短无线电活动时间；若网络不断丢包，额外重传又可能增加发热与电量消耗。这些作用方向不同，不能只凭协议名作结论。应同时记录任务完成时间、交互稳定性和设备状态。

测试大文件时，不要只看开始几秒的峰值。先确认连接能持续完成任务，再在下载进行中观察普通网页或其他交互是否明显受影响。吞吐提高但所有短请求都变慢，可能意味着队列积压或链路被占满，需要调整测试条件与带宽预期。对移动网络而言，信号变化还会让可用容量随时间波动，同一个固定值未必适合所有地点。

如果小请求可用而大流量停顿，应继续检查包尺寸、网络丢包、带宽设置和服务端资源；如果完全不能建立连接，则回到入口与安全层。若只在某一接入网络失败，使用相同条目换网验证比连续改参数更有意义。最终保留的应是能稳定完成实际业务、设置来源明确且可以复现的组合，而不是某次测试中瞬时数字最大的组合。

08 / Selection · Diagnostics

选型与排查：用同一条件验证结果

实际选型从已有服务支持的组合开始。只有一个可用入口时，任务是准确配置它；有多个由用户已有服务提供的选项时，才有比较协议的空间。优先满足业务所需的 TCP、UDP、私有网段和安全条件，然后比较连接稳定性与操作成本。不要为了减少一个字段放弃必要的身份验证，也不要为了使用某个协议名称增加不被服务端支持的封装。

按业务约束缩小选择范围

日常网页和应用访问，应关注首次连接、持续可用性以及网络切换后的恢复；持续传输应观察吞吐与并发时的交互表现；访问已有私有网络，则要确认地址分配、目标网段和 DNS。需要 UDP 的业务要单独验证转发能力。不同业务可有不同合适组合，但一切都建立在服务端已经提供并允许使用的能力之上，客户端不能自行补出缺失功能。

用规则确认测试请求走向

测试前确认 Global Routing 选择 Config，并确认当前启用的是要修改的配置文件。以下片段只演示规则匹配，不包含任何服务器资料；PROXY 需要在当前配置中对应有效的代理策略。把具体域名放在较宽泛规则前面，最后用 FINAL 处理剩余流量。若希望其余请求直连，应按自己的目的调整末尾策略，而非直接照搬。

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

规则自上而下匹配，先命中的条目决定后续走向；GEOIP 判断地址所属范围，不是根据网站显示语言推断位置。以上保留域名用于说明语法，不是速度测试目标。正式验证请使用自己有权访问、结果稳定的实际资源，并在连接记录中核对命中策略。更细的写法见规则关键字与匹配范围，只代理部分站点可参考指定网站分流说明。

按错误发生阶段排查

第一阶段是入口解析与连通：确认 Server、Port 和当前网络，再核对服务器域名是否得到预期地址。第二阶段是安全与认证：按协议检查证书名称、设备时间、密码、UUID 或密钥。第三阶段是业务与路由：检查规则、DNS、UDP、目标权限及大包传输。若尚未进入认证阶段，不要重建身份资料；若入口已经建立，也不要只盯着端口重复修改。

Connectivity Test 的结果应按具体测试含义理解。它可能反映某种连接或请求的耗时，不一定覆盖实际业务的所有路径，更不等于持续吞吐。出现测试成功但应用失败时，应观察实际请求使用的域名、协议和策略；出现测试失败但部分业务正常时，也要确认测试目标本身是否可达。用多个相关证据交叉判断，而不是把单次结果作为唯一结论。

比较速度时，每轮只改一个变量，使用同一设备和同一网络，保持相近测试时长。尽量避免后台同步、系统更新或其他设备占用带宽，记录是否冷启动、是否已建立连接及是否处于弱信号区域。比较电量则需要更长、可重复的固定任务；系统电池统计能提供线索，但不能直接把全部网络耗电归给某个协议。短时发热也应结合传输量理解。

完成验证后，恢复日常需要的 Global Routing 和规则，删除不再使用的测试副本，保留原始资料与有效设置的对应关系。初次连接流程见使用教程，常见使用问题见新手问题快速解答。本页用于解释选择与字段，不代替服务器管理，也不改变 App Store 购买范围；系统要求仍以 App Store 页面标注为准。