Shadowrocket 协议手册

01 · 协议选型与连接分层

类型必须与服务端一致

协议选型首先是兼容性核对，而不是速度排名。同一个服务器地址可以监听不同端口，每个端口背后可能对应不同协议；只有地址相同，不代表认证和传输可以互换。在 Add Server 中选择 Type 时，应以已有服务器说明或订阅解析结果为依据。把 Shadowsocks 改成 Trojan，并不能让原来的服务自动支持 TLS；把 VMess 的认证信息放进 VLESS，也不能据此建立连接。若订阅内容与文字说明冲突，先确认是否指向同一入口，再调整字段。

理解连接可以分成四层：最外层是当前 Wi-Fi 或蜂窝网络能否到达服务器；其后是 TCP、UDP 或 QUIC 等承载方式；再后是协议认证、加密与可选的 TLS；最后才是目标请求与规则策略。一次超时可能发生在任何一层，不能单凭提示认定密码有误。例如端口不可达时还没有进入认证，证书不匹配时也未必已经发送目标请求。分层的意义是缩小检查范围，避免同时更改多个互不相关的选项。

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

连接速度通常包含建连等待、首个响应和持续吞吐三个不同指标。浏览短页面更容易感知 DNS、握手与首个响应的差异；传输大文件则更受链路带宽、拥塞控制和服务端负载影响。一次 Connectivity Test 不能代表所有应用的实际体验，更不能直接换算为下载速度。比较已有的多个入口时，应保持同一设备、同一接入网络、同一测试目标与相近时间，并分别记录冷启动和连接已建立后的表现。

iPhone 与 iPad 上的耗电也不能只按协议名称判断。加密计算会消耗处理器资源，但无线模块持续活跃、丢包重传、频繁握手和过密保活，同样可能占据更大比例。信号较弱时，重复发送数据可能比算法本身更影响电量。测量时保持屏幕亮度、前台应用和测试时长接近，避免把屏幕或后台同步的消耗归给协议。低延迟与低耗电也不总能同时获得，应先确定实际使用目标。

如果已有服务端只提供一种类型，就不需要为了“选型”而重新填写另一种协议。正确的选择是使用兼容类型，并检查其必填字段；只有在用户自己的服务器确实配置了多个入口时，比较才有意义。传输与安全选项还取决于服务端具体配置及当前应用支持情况，界面没有对应选项时，不要把相似名称当作等价替代。应保留原始说明，确认参数能否被当前客户端完整表达。

02 · Shadowsocks 的加密与转发

简化转发结构的设计取舍

Shadowsocks 的设计背景是提供较轻量的加密代理转发，把目标地址和应用数据封装后交给远端处理。与完整的网络层隧道不同，它关注的是代理连接，不要求给设备分配一整套隧道地址。结构较简洁有利于部署与排错，但也意味着不能只凭“加密代理”四个字推断所有安全属性。具体的加密方式、认证强度、UDP 行为和附加传输要求，需要结合服务端配置分别核实。

在 Shadowrocket 中手动添加时，先选择 Shadowsocks，再填写服务器地址和端口，随后核对 Method 与 Password。Method 是协议兼容条件，不是随意选择的性能档位；双方选用不同方式，即使密码相同也不能正常解释数据。复制 Password 时要检查首尾空格、换行和大小写，不要把订阅备注当成密码，也不要把分享信息中编码后的整段内容直接塞进 Password 字段。完整分享信息应通过对应导入方式处理。

AEAD、兼容性与额外参数

采用 AEAD 的方式会同时提供加密和数据完整性验证，接收方能够发现数据被篡改或无法正确认证的情况。这与单纯“把内容变得不可读”不同，但不应据此把所有带有相似算法名称的方案视为互通。不同协议变体可能对密钥、会话和用户信息有额外要求。服务端给出的类型、算法名称与凭据应作为一组保留；若订阅包含附加字段，优先检查原始配置说明，而不是靠删字段让表单通过。

有些已有配置还附带额外的传输组件、主机名或路径。这些不是通用的 Shadowsocks 必填项，只有服务端实际启用时才需要匹配。额外组件可能改变外层数据形态，也会增加握手或配置复杂度；不能为普通入口凭空打开。遇到“导入成功但连接失败”，要检查导入是否完整保留了这些要求，以及当前客户端是否支持该组合。能够显示一条记录，仅说明内容被解析，不等于双方已经完成协议协商。

TCP、UDP 与 iOS 上的表现

TCP 请求成功而依赖 UDP 的应用失败，是需要单独处理的分支。原因可能是服务端未启用 UDP 转发、路径不允许 UDP，或当前规则没有把相关流量交给预期策略。此时反复改 Password 往往没有帮助。先用普通网页确认基本 TCP 转发，再检查应用实际使用的流量类型与客户端记录。不要把一次网页成功扩大解释为所有网络功能都已具备，也不要用单次失败推断整个协议都不适用。

在 iPhone 和 iPad 上，较少的附加层通常有利于降低配置复杂度，但实际吞吐还取决于设备对所选算法的处理效率、服务端性能和网络丢包。不同设备可能对不同算法有不同表现，不能直接套用另一台设备的结果。若持续传输稳定而首次访问偏慢，应优先检查 DNS 和建连；若只有高负载时速度下降，再观察处理器负载与链路限制。更改算法必须同时得到服务端支持，不能只改客户端一端。

建议保存一份能够连接的记录，再复制一份用于验证单项调整。先核对 Address、Port、Method、Password，再检查确实存在的附加选项，最后验证 UDP 与规则路径。订阅更新后若问题出现，可对照更新前后的类型与关键字段，但不要把包含凭据的完整记录公开。需要学习导入和更新操作时，转到Subscribe 更新说明；本章只负责解释协议字段和判断顺序，不替代服务端参数来源。

03 · VMess 与 VLESS 的认证和传输

把协议身份与传输方式分开

VMess 与 VLESS 都使用 UUID 作为常见的用户标识，但二者不是可以只改 Type 就互换的格式。VMess 把认证与数据保护纳入自身协议设计，部分认证过程还依赖时间窗口，因此系统时间明显不准可能导致失败。VLESS 则采用更精简的协议结构，基础协议本身不承担载荷加密，通常需要依靠部署中配套的安全层保护数据。二者的取舍是结构与职责划分的不同，不应简单理解为一个名称必然比另一个更快。

UUID 应从用户已有的服务器配置中获取，完整保留字符与分隔符。随机生成一个格式正确的 UUID 并不代表服务端认可这个用户。服务端地址、端口和 UUID 对了，也还没有完成全部核对：传输方式、TLS、Server Name、路径等仍可能决定连接能否建立。订阅里存在多个相似入口时，不能把一条记录的 UUID 与另一条的路径拼接使用，除非服务端说明明确表示它们属于同一组配置。

TCP、WebSocket 与 gRPC 是不同层

协议决定如何表达认证和目标请求，传输决定这些数据如何承载。使用 WebSocket 时，客户端要完成相应的握手，Path 与 Host 等参数必须符合服务端要求；使用 gRPC 时，需要核对对应的服务名称和 TLS 等设置。普通 TCP 入口不需要凭空填写 WebSocket Path。看到同一个域名并不能证明这些传输共享一个接入点，反向代理可能根据路径、主机名或服务名称把请求交给不同后端。

Host、Server Name 和服务器地址也不应混为一谈。服务器地址决定连接目标；TLS 的 Server Name 用于握手中的名称指示和证书匹配；WebSocket 的 Host 属于应用层请求信息。某些部署让它们相同，只是配置结果，并非协议要求所有场景都相同。按说明分别填写，才能区分“连到了正确服务器，但进入错误后端”和“连服务器本身都到不了”。不要通过随意替换名称来掩盖某一层的错误。

安全选项与性能边界

VMess 的 Security 等字段属于其自身协议配置，不能与 TLS 开关等同；VLESS 的某些安全或流控扩展也只适用于特定部署组合。服务端没有声明支持时，不应凭名称勾选扩展。对于导入后出现的不认识字段，先核对当前应用的对应设置及服务端要求，保留原始记录。删除看不懂的参数可能把一个完整配置变成不兼容配置；填写一个“常见值”也不比保留证据更可靠。

多一层 TLS 或应用层传输通常会增加握手和封装，但这不能直接推导出最终速度较慢。持久连接可以摊薄握手成本，网络中的中间设备也会影响不同传输的实际表现。短连接密集的场景更容易暴露建连开销，长时间传输则更看重拥塞与服务端负载。在 iOS 上反复失败后重连可能比稳定维持连接更耗电，因此先修复参数不一致，比一开始就追求减少某个封装层更有意义。

排错时先检查设备自动日期与时间，再确认地址和端口可达；随后按 UUID、协议安全字段、传输方式、TLS、名称与路径逐层核对。如果 TLS 已经成功但请求仍失败，应把注意力转向认证和后端路由，而不是继续关闭证书验证。若只在订阅更新后失效，对照传输字段是否改变；若同组所有记录同时失效，则先排查当前网络和共有域名解析。此处的检查顺序与节点超时与连接失败笔记可以结合使用。

04 · Trojan、HTTP 与 SOCKS5 的边界

Trojan：认证放在 TLS 连接之内

Trojan 的设计把代理认证和请求放在 TLS 连接内处理，利用成熟的 TLS 机制提供传输保护。配置时 Password 与 TLS 参数分别承担不同职责：密码用于服务端识别用户，证书与名称验证用于确认安全连接所指向的身份。密码正确不代表证书可以忽略，证书有效也不代表账号一定通过认证。先理解这两条独立检查线，才能对“握手失败”和“认证失败”采取不同处理。

Server Name 应对应服务端证书和部署要求，而不是随意填入一个熟悉的域名。使用 IP 作为服务器地址时，服务端仍可能要求指定域名参与 TLS 握手；此时连接目标与验证名称不同是正常的配置方式，但必须来自已有服务器说明。若证书报错，检查设备时间、名称拼写、证书有效期和证书链。通过忽略验证把错误提示隐藏，并不能证明连接到了预期服务端，也不应作为长期解决方案。

HTTP：代理请求不等于全链路加密

HTTP 代理最初围绕应用层请求转发形成，HTTPS 目标常通过 CONNECT 建立到目标的字节通道。这里必须区分“目标网站使用 HTTPS”和“设备到代理入口使用 TLS”：前者保护网站会话，后者保护到代理的这一段连接，两者不是同一个开关。若入口本身采用明文 HTTP，不能因为目标地址以 HTTPS 开头，就推断代理认证信息及入口元数据也获得了同样的保护。

填写 HTTP 类入口时，需要核对服务器地址、端口、是否启用 TLS，以及是否要求 Username 和 Password。不要把网站登录账号当作代理认证账号，也不要把 URL 中表示路径的部分随意写进地址栏。服务端若只提供普通 HTTP 代理，不应在客户端打开 TLS 后期待自动升级。相反，要求 TLS 的入口若按明文连接，往往会在早期就失败。两端必须对第一批字节的解释达成一致。

SOCKS5：灵活转发不自带载荷加密

SOCKS5 定义了目标地址表达、认证协商和转发请求等机制，可以表达域名或 IP 目标，部分部署还支持 UDP。它本身不提供通用的载荷加密保障，Username 与 Password 认证也不能被等同于加密通道。选择这种类型时，应明确已有网络环境提供了什么保护，以及入口是否另有安全封装。不能把“有密码”当作“数据已经加密”的证据，也不能把应用目标自身的安全性扩大到所有传输内容。

SOCKS5 的 UDP 能力需要服务端、路径与客户端处理共同配合。服务端允许建立 TCP 连接，并不自动意味着 UDP 转发也可用；域名在本地还是远端解析，则取决于实际请求形式与客户端 DNS 配置。若域名访问失败但同一目标的 IP 请求能到达，应先检查解析路径；若普通网页成功而实时应用异常，再检查 UDP 与规则。没有足够证据时，不应把所有差异归结为认证方式。

在 iPhone 与 iPad 上，这三类协议的比较仍应以已有入口为前提。Trojan 的 TLS 握手、HTTP 的连接复用、SOCKS5 的转发路径都可能影响首个响应，但持续速度主要由实际链路决定。对于需要明确传输保护的场景，先查入口安全层，而不是仅看协议标签；对于特定应用的 UDP 需求，先验证端到端支持。若用户只有一组可用参数，正确填写比在不兼容类型之间切换更重要。

05 · WireGuard 的密钥、地址与 MTU

网络层隧道与代理入口的区别

WireGuard 的设计围绕精简的网络层隧道展开，使用公私钥识别对端，通过 UDP 承载经过保护的数据。与主要转发应用连接的代理协议不同，它还涉及隧道内地址和路由范围。因此配置不能只理解成“服务器加密码”：设备端需要自己的密钥身份，对端也需要登记相应公钥，同时双方还要知道哪些地址应进入隧道。认证成功与目标可达之间，多了地址分配和路由规划这一组检查。

PrivateKey 属于当前端点的私钥，应保留在可信的本地配置中；PublicKey 在对端配置项里通常指远端的公钥，不是把本机私钥复制过去。由本机私钥导出的本机公钥需要被远端允许，远端公钥则用于确认连接的对方。若双方公钥填反或服务端未登记本机身份，地址和端口正确也不会形成有效会话。可选的 PresharedKey 是额外共享材料，只有双方明确配置时才填写，不能凭空生成一端独有的值。

Address、Endpoint 与路由范围

Address 指隧道内分配给本端的地址，通常带有前缀长度；Endpoint 指远端在外层网络中的可达地址与端口。二者所处层次不同，不能把公网服务器地址直接当作隧道内地址。若已有配置包含 IPv4 与 IPv6 两类 Address，应分别保留其前缀。任意更换隧道地址可能与其他端点冲突，或超出远端允许范围，表现为握手存在但实际数据无法按预期返回。

AllowedIPs 在 WireGuard 模型中同时关联允许的隧道地址范围与对端选择，客户端中的具体呈现应以实际界面为准。进入 Shadowrocket 后，还要区分该端点内部的路由范围与应用整体的规则策略：前者决定隧道如何处理地址，后者决定哪些请求被交给这个策略。不能因为远端允许较大的地址范围，就推断所有设备请求都已经走入隧道。先确认请求被规则选中，再检查隧道内的回程和目标路由。

MTU、DNS 与保活的连带影响

MTU 表示相应接口可承载的数据包尺寸上限。隧道封装会增加额外开销，如果路径不能正确处理较大的包，可能出现小请求成功、较大响应卡住的现象。此时适度降低 MTU 可以作为有记录的验证，但不能把某个数值当作所有网络通用答案。应保存原值，每次只调整一档，复测相同目标；过低会增加包数量和处理成本。若问题本质是 DNS 或目标路由，改 MTU 通常无法修复。

DNS 配置用于回答域名应解析成什么地址，不会自动修补错误的隧道路由。解析服务器若位于隧道内，必须保证到它的路径先可达，否则容易形成“域名失败但部分 IP 可达”的情况。保活则用于在需要时维持 NAT 映射，不是提高带宽的选项。过密保活会让移动设备更频繁地唤醒无线模块；过疏又可能让闲置后的首个请求等待重新建立路径，应以网络环境与服务端建议为依据。

观察 WireGuard 时，可以把握手、收发计数和实际请求分开判断。有握手说明对端身份与外层路径至少在当时可以协作，不代表隧道内目标已经可达；只有发送增长而接收不增长，需继续检查远端路由、地址许可和回程。Wi-Fi 切换蜂窝后出现短暂恢复过程，也不能立刻归咎于密钥。更细的字段关系与调整边界见WireGuard 配置参数笔记，操作前应备份当前可用配置。

06 · Hysteria2 的 QUIC 与带宽参数

以 UDP 承载的连接结构

Hysteria2 基于 QUIC 构建代理传输。QUIC 在 UDP 之上实现安全握手、连接管理和可靠的数据流，因此“外层是 UDP”并不等于内部所有数据都按不可靠方式发送。它的设计取舍之一，是把连接与拥塞处理放在这一套传输结构内完成。在某些丢包或时延变化环境中可能体现不同于 TCP 承载的行为，但最终结果仍受链路策略、服务端带宽和实现配置影响，不能仅凭名称保证速度。

选用 Hysteria2 的前提，是用户已有服务器确实提供这一协议。不能把其他类型的地址与密码直接迁入，也不能假定名称相近的协议代际可以互换。先核对 Type、服务器地址和 UDP 端口，再核对认证内容与 TLS 参数。某些部署还包含额外的混淆配置，只有服务端实际启用时才需要匹配。漏掉这类字段可能使数据在进入正常握手前就被丢弃，表现为持续超时而没有明确认证错误。

UDP 路径比网页连通性更关键

当前 Wi-Fi 能打开普通网页，并不能证明它允许到目标端口的 UDP 通信。有些网络对 UDP 的限制与 TCP 不同，部分路径还会对持续 UDP 流量进行不同处理。若 Hysteria2 在一个网络超时，而同一组参数在另一个网络可用，应先比较外层 UDP 可达性，而不是立即更换密码。测试必须使用相同记录，防止把网络变化与参数变化混在一起，导致无法确认真正起作用的因素。

TLS 在这里仍要求正确的名称和证书验证。Address 决定到哪里发送数据，Server Name 则关联握手中的名称指示与身份核对。若服务端证书只覆盖域名，按 IP 连接时也可能需要提供相应名称；具体值必须由已有配置确认。设备日期明显错误、域名指向错误入口或证书链不完整，都可能导致握手问题。QUIC 不会自动绕过这些安全条件，关闭验证也不能证明其他参数正确。

带宽填写不是提速开关

带宽相关字段应按当前实现、服务端配置和用户实际链路理解。某些拥塞控制模式会利用带宽信息决定发送行为，填写明显超出可用链路的值可能增加排队、丢包和重传，反而损害交互响应。不要把订阅备注中的宣传速度直接当成准确参数，也不要只按家庭接入标称带宽填写蜂窝环境。单位同样重要：位每秒与字节每秒不能混用，上传和下载方向也应对应字段说明逐项核对。

如果持续下载较快但网页点击反而迟缓，可能是拥塞时排队过长，而不一定是 DNS 本身慢。可以在停止大流量传输后复测短请求，观察差异是否消失；再按已有服务端建议检查带宽与拥塞设置。对于电量，较高吞吐会增加无线模块和处理器活动，较差路径上的反复发送也会提高消耗。应比较完成同等任务的总耗时与总消耗，而不是只比较瞬间电量变化或一个最高速度数值。

移动网络切换后，QUIC 的连接标识与路径机制并不等于所有应用会话都必然保持。是否恢复还取决于客户端处理、远端状态、NAT 映射及应用自身的超时。验证时记录切换前后的连接结果，不要仅观察图标是否仍显示连接。若只有这一类型在某网络失败，而已有的其他入口可用，应保留这条对照证据；若所有类型都失败，则优先检查基础网络、解析与全局路由，而不是继续局限在 QUIC 设置。

07 · 参数字段与分层排错

保留原始信息，再检查导入结果

订阅或分享信息导入后，应把“解析成功”和“连接可用”分开确认。前者只表示客户端识别了数据格式，后者需要网络、认证、安全层和转发共同工作。先检查 Type 是否与来源一致，再检查地址、端口及关键凭据，最后检查传输扩展。若发现字段缺失，不要立即手动补成惯用值，应回到用户已有配置核对。对于不支持的组合，修改显示名称或重复导入都不会创造兼容能力。

最常见的混淆是把多个“名字”当成一项。备注仅用于本地辨认；Address 决定实际连接目标；Server Name 参与 TLS；Host 可能影响应用层入口；Path 或服务名称则指向具体传输后端。一个入口中这些值可以相同，也可以不同。排错记录应分别写下其角色，而不是只记“域名正确”。如果服务器使用多个后端，同一地址能够建立 TCP 连接，也可能因为名称或路径错误而进入错误服务。

按失败范围缩小问题

只有单条记录失败，优先检查这条记录特有的地址、凭据和传输参数；同一组记录一起失败，检查它们共享的域名、认证来源和服务端状态；所有记录在一个网络失败，换一个已知可用的网络进行对照。若所有网络都失败，还应检查当前 Config、设备时间和系统连接状态。这样的分支比连续点击测试更有效，因为每一步都在判断问题属于局部入口、共同配置还是设备环境。

超时表示在等待期限内没有取得所需结果，不直接说明密码错误；连接被拒绝可能意味着目标端口没有对应监听，也可能来自路径设备的处理；证书错误指向 TLS 身份验证；认证错误则应回到协议凭据。具体提示仍要结合上下文解读，不要把所有英文错误归成同一类。查看记录时保留错误发生前的阶段信息，但对外描述只需提供类型、网络条件和脱敏错误，不应公开完整凭据。

区分测试成功与实际使用成功

Connectivity Test 的结果取决于测试方法和目标，不能证明每个网站、每个 UDP 应用或每条规则都正常。若测试成功但浏览失败，应检查实际域名的 DNS、命中策略和目标响应；若只有某个应用失败，则观察它是否访问了不同域名或使用了不同传输。出现“连接开关已打开”也只代表系统隧道状态，不能替代目标请求验证。至少用一个已知目标完成真实请求，再判断配置是否可用。

DNS 排错应特别留意依赖关系：服务器地址本身若是域名，建立连接前通常就需要得到可用解析；目标网站的解析则可能受当前 Config 影响。若把解析服务设在只有隧道内才可访问的位置，却没有可用的启动解析路径，可能出现循环依赖。先确认服务器域名能被正确解析，再检查目标域名与请求策略。不要一次更换所有 DNS 选项，具体操作可查DNS 设置教程。

最后建立一份最小复测记录：当前网络、协议类型、实际测试目标、错误阶段，以及这次仅修改了哪个字段。每次修改后使用相同目标复测，确认结果后再决定保留或恢复。订阅整体获取失败与单条入口认证失败属于不同流程，前者应检查订阅地址的有效性与获取结果，见订阅失败检查。完成参数检查后，若仍只有特定请求异常，就转入下一章检查规则与连接触发。

08 · Global Routing、规则与 On Demand

协议可用之后，再验证策略选择

协议决定如何连接远端，Global Routing 决定请求采用什么处理方式，这两者不能互相替代。Config 按当前配置中的规则选择策略，Proxy 适合在确认含义后临时缩小规则变量，Direct 则用于直接连接。排错时应先记住当前姿态，再检查请求实际走向，避免在 Direct 下验证远端协议后得出错误结论。测试结束要恢复原来的 Config，否则临时调整会影响后续对照，也可能改变局域网访问行为。

规则通常按顺序匹配，较具体的条件应放在适当位置，FINAL 负责前面未匹配时的兜底。DOMAIN-SUFFIX 匹配域名后缀，IP-CIDR 匹配地址范围，GEOIP 依据相应地理数据判断地址；它们的判断对象不同，不能只因目标网站名称相近就相互替换。PROXY、DIRECT、REJECT 表达不同处理结果，规则指向的策略名还必须能在当前配置中正确解析。真实结果应结合请求记录确认，而不是仅凭列表位置推测。

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

这段 .conf 片段仅展示规则语法和顺序，不是一份完整配置。example.com 用作说明域名，私有地址范围的 DIRECT 表示直接访问，GEOIP 的结果依赖相应数据，最后由 FINAL 兜底。应用到自己的 Config 前，需要确认现有策略、DNS 与局域网范围；不要直接用示例覆盖整份配置。尤其不要把示例地区规则理解成适合所有人的推荐，也不要以为更换规则就能修复错误的 Password 或 TLS 名称。

On Demand 只负责何时触发连接

On Demand 用于按网络或其他已配置条件触发系统连接行为，并不决定每个请求最终采用哪一种协议。Wi-Fi、Cellular 和域名条件需要结合当前界面与规则能力设置；有的条件影响连接是否建立，有的判断还涉及解析环境。配置之前先确保手动连接已经稳定，再添加触发条件。若手动连接本身失败，自动触发只会重复同一个问题，也会增加对故障现象的干扰。

按 Wi-Fi 条件配置时，应核对 SSID 的实际字符串，注意名称相似但并非同一个网络的情况；设置蜂窝条件时，应分别验证从 Wi-Fi 切出和切回的行为。多条条件并存时，要检查优先顺序与兜底动作，避免宽泛条件先匹配，使后面的特定条件没有机会执行。手动关闭后又自动出现连接，可能是条件再次满足，而不一定是开关失效。应先检查 On Demand 的规则，再判断系统连接状态。

按场景验证，而不是按名称排名

日常浏览应关注首次响应、解析稳定和闲置后恢复；持续传输应关注有效吞吐、排队和重传；依赖 UDP 的应用应先确认端到端转发能力；隧道内资源访问则更应检查 WireGuard 地址与路由。若已有多个兼容入口，按这些目标分别测试，比宣布某个协议“全面更快”更有参考价值。同一协议在不同服务器上的差异，往往可能大于协议名称之间的差异，比较时要明确不能控制的变量。

电量验证也应贴近实际任务：让两组已有配置完成相近的数据量和使用时长，分别观察稳定前台使用与闲置状态。后台同步、信号强度和屏幕时间会影响结果，应一并记录。若闲置时消耗明显增加，检查是否频繁失败重连、保活过密或 On Demand 条件反复切换；若只在持续传输时增加，则结合吞吐和处理负载判断。不要根据一次系统电量统计就推导固定的协议耗电排名。

最终应形成三项可核对结果：记录的 Type 与服务端一致，实际请求命中预期策略，网络切换后的连接行为符合 On Demand 设置。完成后保存可用配置，再逐项加入自动化条件。按需连接的具体场景可继续阅读Wi-Fi 与 Cellular 触发规则笔记；需要重新走一遍添加、连接和验证主线时，返回使用教程。协议手册的用途是解释差异与定位边界，配置值始终以用户已有服务器信息为依据。