Shadowrocket 协议参考类型、参数与连接判断

一、协议选择：先分清认证、传输与路由

Shadowrocket 中的协议类型决定客户端如何与服务器交换数据，不决定服务器所在位置、出口带宽或服务质量。选择必须以你已有的服务器信息为前提：服务端提供什么类型，客户端才填写什么类型，不能只修改 Add Server 中的选项就把一项连接变成另一种协议。订阅链接从你的服务商处获取；导入后仍应核对类型、地址和认证信息。客户端一次性买断 ≠ 线路套餐，购买应用与连接服务分别管理，获取应用请查阅App Store 正版核验说明。

把一条连接拆成四个层次

第一层是身份与消息格式，例如密码、UUID 或密钥，以及服务器怎样理解请求。第二层是承载方式，例如 TCP、UDP、WebSocket 或基于 QUIC 的传输。第三层是安全会话，可能由协议自身的加密提供，也可能依赖 TLS 等外层机制。第四层才是路由：某次访问选择 PROXY 还是 DIRECT。四层会共同影响结果，却不能相互替代。把 Global Routing 改为 Proxy，可以改变访问去向，但无法修复填错的密码；把 TLS 打开，也不能自动让服务端接受不匹配的传输格式。

同一个协议名不代表所有扩展都一致。服务端可能要求特定传输、路径、证书名称或附加参数，客户端也可能只实现其中部分组合。因此，看到 VMess 或 VLESS 时，还需要继续确认外层传输；看到 HTTP 时，要问清楚代理入口本身是否受 TLS 保护。界面中的可用字段会随所选类型变化，判断依据应是当前客户端实际显示的选项与服务端说明，而不是另一份配置截图上的排列位置。

速度、电量与稳定性不是单一排名

网页打开快慢通常包含 DNS 查询、建立连接、认证、首个响应和内容传输几个阶段。长时间下载则更容易受到出口带宽、丢包恢复和服务器负载影响。一个方案可能在小文件访问时更快，却在长下载中没有优势。iPhone 与 iPad 的电量还会受蜂窝信号、屏幕亮度、无线电保持活跃的时间和后台重连影响。少一层封装不等于必然更省电，较高吞吐也不等于整次任务耗电更少，必须在相近条件下比较。

网络切换也是单独的变量。设备从 Wi-Fi 转到蜂窝网络时，本地地址和路径都可能变化，已建立的会话是否恢复，取决于传输机制、服务器行为以及应用自身的重试。不能把一次切网后的短暂停顿直接判断为协议失效，也不应通过不断切换多个开关来掩盖问题。先固定一个可复现的访问任务，记录失败发生在建立连接之前还是传输过程中，再决定检查哪个层次。

本文只解释客户端选型与配置边界，不对服务商作评价。系统要求以 App Store 页面标注为准，具体协议与字段支持以当前客户端为准。对于无法确认来源的附加选项，保留导入值通常比凭名称猜测更合适；只有理解它与服务端哪个设置对应后，才进行修改。

二、Shadowsocks：轻量代理与加密方法匹配

Shadowsocks 的设计重点是提供相对精简的加密代理通道。客户端把目标地址和负载交给服务器，服务器再访问目标，因此它属于代理协议，而不是给两端直接建立完整私有网段的网络层隧道。它的基础配置通常容易辨认：服务器地址、端口、加密方法和密码。但字段少不代表可以省略核对，尤其加密方法是协议交互的一部分，不是客户端单方面决定的性能偏好。与服务端不一致时，连接可能表现为超时、立即断开或认证失败。

加密方法与密码必须成对核验

现代 Shadowsocks 部署常使用带认证的加密方法，使接收端既能解密，也能检查数据是否被修改。不同方法可能有不同的密钥长度和派生规则；部分方法要求使用符合格式的编码密钥，而不是任意文本密码。导入时应逐字保留方法名称和密码，不要把编码字符串再次解码后粘贴，也不要把末尾符号当作多余字符删除。若订阅更新后连接突然失效，先确认密码是否轮换、类型是否发生变化，再考虑网络层问题。

在 Add Server 中手动录入时，应先选 Shadowsocks，再按原始资料填写。地址字段只放主机名或 IP 地址，端口单独填写；不要把整个分享链接当成服务器地址。如果资料包含插件或额外封装，应继续核对当前客户端是否提供对应选项，以及导入是否完整。基础协议名称相同，不意味着不同插件组合可以直接互通。无法确认附加参数时，应回到已有配置的说明，而不是尝试在几种选项之间随机轮换。

TCP 可用与 UDP 可用需要分别验证

网页经常通过 TCP 访问，但部分实时应用、语音以及其他业务会用到 UDP。Shadowsocks 可以涉及 TCP 与 UDP 转发，两者在服务端启用情况、网络可达性和客户端处理方式上都可能不同。网页能打开只能证明某条访问链路成功，不能证明 UDP 路径也正常。反过来，单个应用失败也不一定是协议缺陷，它还可能受到 DNS、规则或目标服务本身影响。诊断时先确认该应用实际使用的流量类型，再查看相应请求有没有进入代理。

UDP 没有 TCP 那样的连接语义，网络设备可能较快清理空闲映射。后台停留后第一次请求失败、再次请求恢复，有时与映射过期或路径变化有关。不要立刻增加保活频率，因为这可能让蜂窝网络持续活跃，增加耗电。先观察问题是否只在长时间空闲之后出现，是否只发生在某个网络，再判断是否需要调整。若持续传输稳定而唤醒后失败，调查方向应与从一开始就无法认证的情况不同。

移动设备上的性能判断

Shadowsocks 的基础封装相对精简，可能减少额外协议层的开销，但实际速度仍受加密实现、设备能力、服务器出口和往返时延制约。不同加密算法在不同处理器上的表现可能不同；不能因为名称中包含更大的数字就推断更安全或更快，也不应为追求速度改成服务端未提供的方法。电量测试应关注完成同一任务所需时间、重连次数和后台状态，而不是只比较一瞬间显示的吞吐。

它适合已有相应服务器、希望用明确的地址与认证参数建立代理连接的情况。若你的需求包含私有网段互通、双端密钥身份或完整的网络层路由，应继续阅读 WireGuard，而不是把这些需求强加给 Shadowsocks。两者解决的问题不同，选型先看访问模型，再看性能。对于订阅内已经稳定工作的条目，保留原始配置通常比为了统一类型而重新编辑更合理。

三、VMess 与 VLESS：身份协议和外层传输分开看

VMess 与 VLESS 常被同时提及，因为它们都可能出现在包含用户身份和外层传输设置的配置中，但两者不能互换。VMess 将用户认证、请求格式与加密机制结合起来；VLESS 则采取更精简的身份与请求表达方式，通常需要依靠所选外层安全机制保护传输。后者不是把 VMess 的名称改一下，也不是在任何网络上都更快。选择时先看服务端提供哪一种，再核对完整组合，不能只复制 UUID 就认为配置已经齐全。

UUID 是身份，不是服务器地址

UUID 用于标识用户，服务器地址用于定位连接入口，二者属于不同层次。手动填写时应保留 UUID 的完整字符与连接符，注意复制时混入空格或换行。服务端删除了对应用户、修改了身份，或者订阅仍保留旧值，都可能造成端口可达但认证失败。某些旧配置还会出现历史兼容参数；这类值必须依据原始配置保留，不能根据不相关的教程统一设置，也不应把历史字段当成每个部署都需要填写的必选项。

VMess 的认证过程涉及时间相关校验，设备日期或时间明显不准时，可能出现持续失败。先检查系统是否采用正确的自动时间，再排查其他参数，通常比反复更换端口更有效。VLESS 的身份与外层安全安排不同，不能把 VMess 的全部排错结论直接照搬过去。共同的检查原则是区分“连不上入口”“外层会话失败”和“身份未被接受”，尽量从日志或连接记录中确定失败阶段，而不是只依据连接开关的状态。

WebSocket、路径与服务器名称

外层使用 WebSocket 时，客户端与服务端必须在传输类型和请求路径上达成一致。路径中的大小写、开头斜杠以及附带参数都可能参与匹配；看起来只是说明文字的内容，也可能是真正的配置值。HTTP Host 用于请求层的主机识别，TLS 的服务器名称则参与安全会话中的名称处理，两者可能相同，也可能由部署方式决定而不同。服务器地址又可能是第三个值，因此不能把三个字段一律填成连接入口地址。

使用 TLS 时，要验证证书是否与预期的服务器名称匹配。连接目标为 IP 地址而证书签给域名时，仍需按服务端资料填写相应名称；把证书验证关闭并不是字段匹配的替代方法。如果入口前面存在转发层，请求可能先到达该层，再被分配给实际服务。此时路径或 Host 不符，会使请求到达一个能响应的入口，却没有进入正确的服务。它与密码错误看起来都可能是失败，检查顺序却不同。

封装带来的成本与边界

多一层传输通常会增加握手、头部和状态维护，但其影响取决于连接复用、网络时延和请求大小。短连接密集的访问更容易感受到建立会话的成本，持续大流量则可能主要受服务器吞吐限制。比较 VMess 与 VLESS 时，如果一个使用不同的外层传输或不同入口，测得的差异就不能全部归因于协议自身。至少应固定服务器位置、网络、任务与测试时段，并把传输组合写进记录，而不是只记协议名。

在 iOS 上，频繁重连、失败重试和网络切换可能比少量协议头部更影响电量。某个条目显示连接成功却反复无法完成请求，应优先排查身份、时间、路径与 TLS，再观察是否存在持续重试。对于服务端要求的特殊流控或扩展参数，只能在当前客户端实际支持且资料明确时使用。订阅解析出的条目缺少必要字段时，刷新原订阅或核对原始资料，比手动添加一个名称相似的字段更可靠。

四、Trojan、HTTP 与 SOCKS5：入口能力与安全边界

Trojan、HTTP 和 SOCKS5 都可以承担代理访问，但认证方式、传输保护和目标表达方式并不相同。Trojan 的设计把代理请求放在 TLS 保护的连接中，常以密码进行身份验证。HTTP 代理沿用常见的请求与隧道语义，SOCKS5 则提供通用的代理协商方式。后两者的基础协议并不自动保证客户端到代理入口之间的加密，因此填写时必须知道服务端实际提供的是哪种入口，不能因最终访问的是安全网页就忽略代理入口的保护方式。

Trojan：先确认 TLS，再确认密码

Trojan 的常见配置包含服务器、端口、密码和 TLS 相关设置。TLS 会话建立在认证请求之前，因此证书问题可能让密码根本没有机会被验证。地址可达却握手失败时，应检查系统时间、证书有效性、服务器名称与服务端的安全设置。若证书与名称都正确而认证失败，再确认密码是否完整、是否已轮换、是否复制了不可见字符。不要把所有失败统一理解为密码不正确，也不要通过修改路由模式处理证书错误。

某些部署会在同一入口上结合不同服务，名称与请求处理方式便尤其重要。端口响应只能说明该位置有服务，不证明响应者就是预期的代理入口。在客户端选择 Trojan 后，还应检查导入资料是否包含额外传输设置，以及当前客户端是否支持该组合。没有资料时不要给密码添加引号、编码或前缀；表单通常需要原始字段值，而不是包含协议标识的完整分享文本。

HTTP：隧道与入口加密是两件事

HTTP 代理可以转发普通请求，也可以通过 CONNECT 建立到目标的字节通道。目标使用 TLS 时，目标内容仍可能在通道内部保持加密，但客户端向代理发出的协商信息与代理认证是否受保护，取决于连接代理本身时有没有使用 TLS。把“访问安全网页”和“安全连接代理入口”混为一谈，会导致对认证暴露范围的误判。若资料明确是带 TLS 的代理入口，需按实际类型与安全选项配置，不能只更换端口。

HTTP 代理常适用于已有明确访问策略的环境，但不应默认它能承载所有 UDP 业务。某个网页正常而实时应用失败，可能是入口能力不涵盖相应流量，而非客户端规则写错。用户名和密码也可能受到访问范围、并发或有效期约束。遇到认证被拒绝，应核对账户状态与原始资料；遇到部分目标被拒绝，则继续区分入口策略和目标服务响应。两者都不应靠反复刷新订阅来替代原因分析。

SOCKS5：通用协商不等于内置加密

SOCKS5 能表达目标地址和端口，也定义了身份协商与 UDP 转发机制，但服务器是否启用认证、是否开放 UDP，都要单独确认。基础用户名密码认证本身不提供内容加密，使用环境必须有与需求相符的保护措施。目标以域名还是 IP 地址交给代理，也会影响 DNS 在哪一侧发生。不能仅看到类型是 SOCKS5，就断言所有域名查询都会远端完成；还要看客户端解析策略、规则需求和实际连接记录。

对于这三类入口，选型重点是已有服务的准确能力，而不是笼统的快慢比较。Trojan 的安全会话有建立成本，HTTP 的隧道可能受入口策略影响，SOCKS5 的 UDP 可能受到网络设备限制。移动设备上应分别检查短请求、持续传输和空闲后恢复。若访问范围或安全要求不明确，先向自己的服务商核实字段用途，不要通过关闭验证、填空密码或改用相似类型来试探。

五、WireGuard：密钥、隧道地址与网络层路由

WireGuard 以网络层隧道和对等端身份为中心，设计目标强调精简协议与明确的加密组合。它与逐个请求目标的代理模型不同：进入隧道的是网络数据包，连接配置还需要描述本地隧道身份、对端位置和允许的地址范围。因此，拥有一个服务器域名和密码并不足以配置 WireGuard，也不能把其他协议的密码填入密钥字段。使用前应取得完整且对应当前设备的资料，并确认服务端已登记匹配的公钥。

Private Key 与 Public Key 的角色

Private Key 属于本地身份材料，应保密；Public Key 用于让对端识别相应身份。客户端填写的对端公钥应该来自服务器资料，而不是本机公钥。服务端也需要知道客户端公钥，双方配置不对应时，即使 UDP 数据可以到达，也无法完成预期的安全通信。若资料还包含预共享密钥，它是附加的共同秘密，不代替任何一端的密钥对。不要为了让字段看起来相同而在多个位置粘贴同一串内容。

更换设备时，应区分“恢复配置”和“多台设备同时复用身份”。两个设备使用相同身份与地址，可能让服务端观察到的端点反复变化，造成连接不稳定或流量落到另一设备。是否允许复用由服务端部署决定，不能因为文件能导入就认为并发一定可用。排错时记录当前有多少设备使用该身份，并按已有服务说明为设备分配独立资料，通常比在客户端反复切换服务器更能定位问题。

Endpoint、Address 与 Allowed IPs

Endpoint 表示通过当前网络能够联系的对端地址与端口，Address 表示隧道内部的本地地址，两者不能互换。Allowed IPs 在 WireGuard 的协议模型中与对等端关联的地址选择和接收校验有关；在客户端集成里，它还需要与应用的路由机制共同理解。某个网段没有被正确涵盖时，隧道握手可能正常，目标却不可达。反之，范围写得过宽，也可能把原本需要本地访问的流量纳入不合适的路径。

访问私有网络时，需要同时考虑返回路径。客户端发出的数据到了对端，并不表示对端后的设备知道如何回应客户端隧道地址；服务端的转发、回程路由和访问策略都可能参与结果。若只能访问对端自身，无法访问其后的网段，检查重点应转向服务端网络安排，而不是重新生成客户端密钥。DNS 也是单独问题：私有域名可能需要指定解析来源，但指定了解析器也不等于相应地址已经可路由。

UDP、MTU 与保活的实际影响

WireGuard 基于 UDP，当前网络是否允许相应 UDP 流量，是基本前提。路径的有效 MTU 不足时，小请求可能正常，大响应或部分业务却卡住，因为封装增加了数据包开销。出现这种现象，应先核对部署建议与路径条件，再有依据地调整，不要把某个固定数值当作所有网络的通用答案。每次调整后，用同一个大文件或固定请求验证，并保留原值，以便确认改善是否真正来自修改。

Persistent Keepalive 用于在需要时维持网络映射，并非越频繁越稳定。移动网络下，额外的周期性数据可能增加无线电活跃时间；没有维持映射需求时，过度设置可能只增加后台工作。WireGuard 的精简设计有利于控制协议成本，但耗电仍取决于流量、信号和重连。适合它的场景通常是已有完整对等端资料、需要明确网络层地址关系的访问，而不是仅凭一个协议名称追求更低电量。

六、Hysteria2：QUIC、拥塞控制与带宽预期

Hysteria2 面向基于 QUIC 的代理传输，设计关注点包括在丢包或往返时延较高的路径上维持有效传输。QUIC 以 UDP 为承载，并在其上实现安全会话、可靠传输等机制，因此它不是把 UDP 原样转发那么简单，也不能理解成完全不需要拥塞控制。使用它的首要前提是已有兼容的服务端资料，并且当前网络能够承载相应 UDP 流量。名称相近的不同协议代际并不保证互通，导入时必须保留准确类型。

先检查 UDP 与 TLS 的前提

连接入口、端口、认证信息和 TLS 服务器名称仍然需要匹配。网络允许 TCP 网页访问，不代表同一位置的 UDP 入口就一定可用；某些网络会限制 UDP，或对持续传输采取不同处理。若所有请求都在建立会话阶段超时，首先排查 UDP 可达性和服务端监听，而不是立即修改带宽参数。若会话报出证书问题，则回到系统时间、服务器名称与信任链，不能靠更高的速率设置绕过安全会话失败。

服务端资料可能还带有额外处理参数，必须确认当前客户端是否支持并正确导入。认证值是请求权限的一部分，不能拿网站登录密码或其他协议的密码替代。对于带端口变化安排的部署，也应完整核对服务端说明与客户端能力；单个端口偶尔连通，并不能说明全部配置都正确。资料不完整时，应停止猜测，先补齐准确字段，再测试性能，否则每次失败都同时包含多个不确定因素。

带宽字段不是实际速度保证

某些配置组合会涉及上行与下行带宽预期，这些值可能参与传输行为或拥塞控制安排，但客户端填写的数字不会创造链路容量。把期望设得明显高于真实可用带宽，可能导致队列堆积、丢包增加，并挤占同一网络上的其他业务。数值设得过低，则可能限制可利用的吞吐。是否需要填写、如何解释以及与服务端设置怎样配合，应以当前实现与已有服务说明为依据，不能沿用任何一个固定数值。

方向也需要分清：从设备发出数据与向设备接收数据是不同方向，不要因为测速页面突出显示下载结果，就把相同数值复制到两个字段。蜂窝网络的可用容量还会随位置、信号和时段变化，实验室条件下合适的预期并不一定适合移动途中。调整时保留保守的基线，先观察任务完成时间与其他应用是否受影响，再逐步变化；若吞吐增加但交互明显卡顿，这通常不应视为整体表现改善。

丢包恢复优势与资源成本

QUIC 能在同一连接内组织多个数据流，避免不同流完全共享传统有序字节流的交付限制，但所有流仍共享底层路径与拥塞资源。一个数据包丢失，依然需要恢复相应数据，实际好处取决于任务结构与路径状态。它可能在某些网络条件下优于其他传输，也可能在稳定、低时延网络上体现不出明显差异。把某次测速结果推广为所有场景的排名，会忽略服务器配置和网络条件这两个主要变量。

在 iPhone 与 iPad 上，用户态协议处理、加密、持续高吞吐和丢包后的恢复都需要资源。一次任务更快完成可能缩短网络活跃时间，但如果持续把链路推到高负载，也可能增加发热与耗电。评估时应同时观察稳定性、任务完成时间、后台恢复和设备状态。长时间等待并反复重试的连接，通常不适合作为电量测试对象，应先修复可达性。协议选型最终服务于真实访问任务，而不是让某个参数达到最大。

七、参数核对：把协议连接与规则分流分开验证

协议参数负责连接服务器，Global Routing 负责决定流量如何使用这条连接。二者必须分开验证，否则容易把规则问题误判为协议问题。先在 Home 中确认当前选中的服务器，再核对 Global Routing。Config 按配置规则处理，Proxy 作为统一代理去向的诊断姿态，Direct 用于直连。它们描述的是路由选择，不会重写服务器的认证或传输能力。相关操作主线见使用教程，三种姿态的解释见Global Routing 专题。

地址、名称和认证逐层核对

服务器地址可以是主机名或 IP 地址。使用主机名时，入口本身需要被解析；入口解析错误会发生在协议认证之前。TLS 服务器名称则用于安全会话中的名称处理，不应与目标网站域名混淆。端口只接受对应服务监听的端口值，不能通过改成常见端口就让服务端自动提供另一种协议。用户名、密码、UUID 和密钥分别属于不同认证体系，空值、编码变化、前后空格都可能改变含义，应按原资料核对而非重新解释。

不要把完整分享链接直接填进单个参数框，也不要把订阅链接当作服务器地址。订阅是一份条目集合的获取入口，里面的每个条目才可能包含协议与认证字段。更新订阅后，旧条目可能被替换、重命名或移除，手动修改也可能被后续刷新覆盖。需要长期验证一个调整时，应建立独立副本并清楚命名，同时避免在名称中写入密码。关于导入入口的差别，可查阅订阅导入说明。

规则只决定去向，不修复服务器

下面是用于说明匹配顺序的 Shadowrocket .conf 规则片段，不包含服务器定义，也不是可以直接代替你现有配置的完整文件。域名规则先判断指定后缀，本地网段规则处理相应地址，FINAL 为剩余请求提供兜底策略。把它复制进已有配置前，应理解原有规则结构与默认策略，避免覆盖原本的私有网络安排。这里使用保留的示例域名，只用于展示语法，不表示任何连接服务。

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

规则通常按顺序匹配，较宽泛的条件放得过早，会遮盖后面的精确条件。DOMAIN-SUFFIX 按域名后缀判断，IP-CIDR 按地址网段判断，它们依赖的信息不同。某些地址判断可能涉及解析，因此 DNS 的结果会影响后续行为；但 DNS 成功本身并不能证明代理出口可访问目标。排错时先用明确的域名规则验证去向，再检查当前记录中的实际目标地址，不要同时添加多条互相重叠的测试规则。

用对照实验区分规则与协议

若同一服务器在 Proxy 姿态下可以完成固定访问，而在 Config 下失败，优先检查规则命中、策略引用与 DNS，而不是立即修改协议。如果两种姿态都失败，则继续检查服务器参数与入口路径。Direct 可用于确认当前网络的基础连通，但直连成功不代表代理服务器可达。测试结束后应恢复原先需要的姿态，避免诊断设置长期改变所有访问去向，导致后续观察与日常配置不一致。

涉及 IPv6 时，还要确认目标解析结果、规则与服务器能力是否一致。只处理 IPv4 的规则不一定涵盖 IPv6 请求，单个域名在不同网络上取得不同地址，也可能带来表面上随机的差异。不要看到部分请求失败就直接改写所有 DNS 设置；先记录实际地址族、命中策略和失败时间，再逐项验证。常见概念可在概念速查中查阅，避免把不同层次的术语当成同一个开关。

八、场景选型：用可复现的流程判断结果

协议选择的第一优先级是与你已有的服务端一致，其次才是任务与网络条件。已有一项稳定配置时，不需要为了追逐协议名称而更换。日常网页与消息访问更关心首个响应、后台恢复和连接成功率；持续传输更关注吞吐与长时间稳定性；私有网络访问则要先确认地址关系和回程路径；依赖 UDP 的业务需要核验完整 UDP 链路。只有服务端确实提供多种兼容选择时，同条件比较才有意义。

建立一份能重复的测试记录

先固定设备、网络、目标和测试任务，关闭会改变结果的其他实验设置，保留当前配置副本。记录协议与外层传输、Global Routing 姿态、是否刚切换网络，以及失败出现在哪一步。测试网页时使用相同目标与相近内容，测试持续传输时固定文件与持续时间，并留意缓存。不能把一条新连接的建立时间与另一条已经复用会话的请求直接比较，也不能把不同时段的服务器负载差异全部算在协议上。

Connectivity Test 可以帮助判断选中条目的可达性或测试请求表现，但单次成功不等于全部业务正常，单次数字也不代表完整吞吐。应结合实际目标访问与连接记录，区分入口连通、认证通过、请求发出和响应完成。首次连接的具体操作见第一次连接检查清单。如果连接开关已开启却打不开网页，先不要同时更新订阅、修改 DNS 和切换协议，否则无法知道哪一步产生影响。

按失败阶段缩小范围

1. 入口之前：检查本地网络、服务器域名解析、地址与端口，确认当前选中的条目就是测试对象。
2. 建立会话：检查协议类型、TCP 或 UDP 前提、TLS 名称、系统时间及证书问题。
3. 认证阶段：检查密码、UUID、密钥与服务端登记状态，确认订阅没有保留失效资料。
4. 请求阶段：检查 Global Routing、规则命中、目标解析、UDP 能力和地址族。
5. 持续传输：检查丢包、有效 MTU、服务器负载、带宽预期与空闲映射变化。

阶段判断不是要求你必须看到某一种固定错误文字，而是把证据放到正确位置。入口根本没有响应时，检查密码通常没有帮助；握手已完成但只有某个网段失败时，应转向路由和回程；所有目标都能开始加载却在较大响应时停住，应考虑路径与数据包大小。若日志只给出笼统超时，就利用对照实验补充证据，例如在相同网络与姿态下测试另一个已确认可用的条目，而不是立即得出协议不适合的结论。

电量比较要覆盖后台与切网

电量应以完成同一类任务和一段相近使用过程为单位，尽量保持屏幕亮度、信号、后台应用与测试时长一致。记录是否发热、是否频繁重连、空闲后能否恢复，以及从 Wi-Fi 转到蜂窝网络后的表现。短时间电量百分比变化较粗，不能据此声称某个协议固定省电多少。若连接持续失败并重试，先解决失败原因再比较；如果任务提前完成，剩余空闲时间也应纳入观察，才能更接近日常使用。

需要长时间后台连接时，保活与 On Demand 应按实际需求安排，而不是全部打开。保活可能维持映射，也可能增加网络活动；On Demand 负责按条件触发连接，不负责纠正认证或规则错误。出现“每次切网都要手动恢复”时，应分别检查系统触发条件、传输重建与服务器状态。一次切网测试只能提供线索，最好在相同条件下重复确认，并保留恢复前后的连接记录。

给出结论前，写清适用条件

合理的结论应描述“在这台设备、这个网络、这项任务和这套服务端配置下，哪种组合更稳定”，而不是宣布某种协议永远最快。日常使用优先考虑参数清晰、恢复可靠且易于维护的条目；需要特殊网络能力时，再选择与需求相符的类型。保留一项已确认可用的基线，定期通过原入口更新自己的订阅，并避免同时维护多个意义不明的副本。进一步问题可查阅问答或连接后无法访问的逐项排查。