Shadowrocket
协议详解与选型
先匹配服务器，再比较传输、速度与电量。
本页是系统查阅手册，适合已经持有自己的订阅或服务器信息、需要核对协议类型与参数的用户。首次添加和连接请先按快速上手完成主线，再回到对应章节解释差异；教程也可作为本页各项检查的操作入口。
连接层次与判断顺序
把协议、承载、安全层与规则拆开，避免一次改动多个变量。
协议类型不是速度档位
在 Add Server 中选择 Type，实际是在指定客户端与远端交换数据时遵守的格式，而不是选择某种快慢等级。服务器运行哪一种协议，客户端就必须选择与之兼容的类型，并填入匹配的认证信息。同一个地址可以开放多个端口，但每个端口背后的服务不一定相同；把 Shadowsocks 条目的类型改成 Trojan，不会让服务器自动切换协议。选型的第一步应是确认已有服务器明确支持什么，再讨论这些可用选项之间的取舍。
一个完整条目往往包含四类信息：地址和端口负责找到服务，协议和认证负责建立会话，TCP、WebSocket 或基于 UDP 的承载负责传递数据，TLS 等安全层负责相应的加密与身份验证。有些协议自行提供加密，有些依赖外部安全层；有些只需少量字段，有些还要匹配传输路径。名称相同但传输不同的两份配置，不能只凭地址与密码相同就互换，订阅导入时也要检查这些附加信息是否保留。
应用请求经过哪些环节
在 iPhone 或 iPad 上启用 Shadowrocket 后，系统将相应流量交给网络扩展处理，客户端再依照当前设置决定连接方式。Global Routing 的 Config 表示按当前配置规则处理；Proxy 表示对接管范围内的请求使用代理路径；Direct 表示使用直连路径。它们控制的是路由选择，不会修复协议认证错误，也不会替服务器补齐能力。若请求已经命中 DIRECT，调整远端协议通常不会改变这个请求的出口。
DNS 解析、规则判断、客户端到服务器的连接，以及服务器到目标地址的连接，属于不同的失败位置。网页打不开可能是名称解析失败，也可能是 TLS 验证失败、认证不通过或目标本身不可达。Connectivity Test 只能反映指定测试过程的结果，不能证明所有目标、所有端口和 UDP 应用都正常。判断时应记录发生在哪一步，而不是只用“连上了”或“没速度”概括整个链路。
| 层次 | 核对对象 | 常见误判 |
|---|---|---|
| 服务入口 | Address、Port 与可达性 | 地址可解析就等于端口可连接 |
| 协议认证 | Type、Password、UUID 或密钥 | 端口相同就能共用认证方式 |
| 传输与 TLS | 传输类型、路径、SNI、证书 | 所有协议都只需要一个密码 |
| 路由与 DNS | Global Routing、规则命中、解析结果 | 所有请求都会走选中的条目 |
用可重复条件比较表现
协议对速度和电量有影响，但路径距离、服务器负载、无线信号、目标服务和数据类型往往更显著。比较时应固定设备、网络、目标和测试时段，先观察打开短页面的等待，再观察持续传输的稳定性。只比较一次延迟，容易把 DNS 缓存或连接复用的差别当成协议优势；只看大文件峰值，又可能忽略日常频繁唤醒与短连接的开销。记录这些条件，比列出抽象的协议排名更有帮助。
对于电量，重点是无线连接活跃时间、后台保活、重试次数与传输效率。加密算法较轻不代表一定省电，持续失败重连也可能使看似简单的配置消耗更多资源。先停留在同一种网络上观察，避免边切换 Wi-Fi 与蜂窝边下结论。若要理解具体请求为何选中某条路径，可结合 Global Routing 三种姿态说明；若刚开始操作，则回到 快速上手按顺序验证。
Shadowsocks
字段相对集中，关键在于加密方法、凭据格式与远端能力一致。
设计背景与主要取舍
Shadowsocks 围绕加密代理连接设计，常见配置由服务器地址、端口、加密方法与密码组成。它不像完整的虚拟网络隧道那样要求用户配置接口地址与整套路由，而是让客户端将相应请求转交到远端。简洁的字段有利于人工核对，但这种简洁不等于所有方法都可互换；不同协议代际、加密方法与扩展选项会改变兼容条件。收到一份条目时，应先识别完整方法名，而不是只记住 Shadowsocks 这个总名称。
常见的 AEAD 方法在提供保密性的同时对消息进行认证，用来发现被修改的数据。更新的协议设计可能调整会话、重放防护及密钥格式，因此不能把任意文本密码填入所有方法。尤其是要求特定长度编码密钥的方法，凭据必须符合该方法的格式。这里不根据名称判断某一种一定更快或更安全；实际可选范围首先受远端实现与当前应用支持情况限制，再由设备和网络测试决定。
Address、Port、Method 与 Password
Address 填域名或 IP 地址，Port 填服务监听端口，两者应来自同一份有效信息。域名写法不要夹入网页路径，也不要把完整订阅链接粘进服务器地址栏。Method 必须与远端完全一致，Password 则应原样保留，特别留意复制时的首尾空格、换行与全角符号。若订阅中有同名条目，不要只按显示名称判断它们相同；可以分别核对地址、端口和方法，避免修改了另一个已失效的条目。
某些已有配置还包含插件或额外传输参数，这些内容不是统一适用于所有 Shadowsocks 连接的必填项。只有远端明确使用相应能力、且当前应用能够表达对应参数时才填写。不能根据别人的截图随意添加 TLS、路径或 Host，以为层数越多越可靠。若导入后出现未知字段或信息缺失，应向原信息提供方确认兼容格式，不要通过连续猜测参数来代替核对。
TCP、UDP 与移动设备表现
网页浏览通常主要使用 TCP，也可能涉及基于 UDP 的应用协议。Shadowsocks 条目能够处理哪些流量，取决于客户端、远端与中间网络是否共同支持相应转发。一个网页可以打开，不足以证明 UDP 链路正常；反过来，某个实时应用失败，也不能直接证明密码错误。应先用普通页面确认基础连接，再用确实需要 UDP 的目标单独验证，并检查远端相关端口及网络策略。
在 iOS 上，连接结构较直接时，日常短请求可能容易获得稳定表现，但延迟和吞吐仍由实际路径决定。持续传输时，加密处理、无线信号与服务器发送能力共同影响电量；少量访问时，建立连接和无线唤醒可能更重要。若网络较差导致反复超时，换一个加密方法未必有帮助。先区分“连接尚未建立”和“建立后传输缓慢”，再决定检查入口可达性还是持续传输条件。
适用场景与排错边界
如果已有服务器只提供 Shadowsocks，正确选择就是按原信息完整导入，不必为了协议名称而迁移。若同一服务器提供多个兼容选项，可把它作为字段较少、便于定位基础问题的比较对象。发生失败时先检查 DNS、端口、Method 和 Password，再确认 UDP 与附加选项；如果更换网络后恢复，应继续检查网络条件而非反复重置凭据。规则分流也要分开核对，避免已命中 DIRECT 的请求被误当作 Shadowsocks 测试结果。
VMess 与 VLESS
分别识别认证协议、传输方式与安全层，UUID 不是全部配置。
两种协议解决的问题不同
VMess 的设计将用户认证与数据保护等机制纳入协议，常见身份信息是 UUID。VLESS 则把协议本身做得更精简，通常将数据保护交给配套的安全层；VLESS 本身不提供与 VMess 相同的内建加密语义。二者即使使用相同形式的用户标识，也不是可以互相切换的类型。客户端的 Type 必须对应服务器实际监听的协议，不能只看条目中有没有 UUID 就推断选择。
这类连接经常与 TCP、WebSocket 以及 TLS 等配置一起出现，容易让用户把协议与承载混为一谈。实际可以把它们理解为分层组合：UUID 解决相应身份问题，承载方式决定如何交换数据，TLS 提供对应的安全通道。服务器只接受某一种组合时，客户端即使 UUID 正确，路径或安全层不一致仍会失败。介绍中的组合只是理解方法，具体可选项应以应用当前界面与远端说明为准。
认证字段与时间条件
UUID 应原样复制，不能用显示名称、普通密码或订阅标识代替。订阅链接里的访问凭据与单个服务器的 UUID 作用不同，前者用于获取配置，后者用于连接相应服务。VMess 的部分历史配置还包含额外的认证参数，不能将旧示例中的数值当作所有服务器通用值。若信息来源给出了这些字段，应逐项比对；若只提供链接，优先检查导入解析是否保留，而不是自行补齐猜测值。
VMess 的认证机制涉及时间条件，设备时间严重不准可能导致连接异常。可以检查系统日期与时间是否正常同步，再重试同一条目，但不要把所有失败都归结为时钟。VLESS 的字段更少，也不意味着它能忽略 TLS 或其他配套验证。对于两种协议，用户标识错误、端口指向错误服务、传输路径不一致与安全层不匹配，都可能表现为很快断开，单看等待时长通常无法可靠区分。
WebSocket、Host、Path 与 TLS
使用 WebSocket 时，Path 是服务端用于处理连接的路径，应保留开头斜杠、大小写和必要的查询内容。Host 可能参与 HTTP 请求的路由，而 TLS 中的 SNI 参与握手时的名称选择，两者有时相同，有时由部署结构决定而不同。不要为了“统一”而把它们都改成 Address。Address 可以负责连接某个入口，Host 与 SNI 则表达不同层次的名称，只有远端部署信息能够确定正确组合。
TLS 证书验证应与预期服务器名称一致。出现证书错误时，先检查 SNI、设备时间、证书有效性和连接地址，不应通过跳过验证把报错隐藏。VLESS 若使用额外安全机制或特定传输选项，还需要当前应用与远端共同支持；不能把其他配置中的字段直接挪入。导入成功只说明客户端读懂了部分信息，不代表所有组合都能建立连接，也不代表远端已经启用这些能力。
速度、电量与比较方法
当 WebSocket 外再使用 TLS 时，会有相应的握手与封装开销，但不能据此断言日常一定更慢。连接复用、入口位置、路径质量及远端负载可能抵消或放大差异。短请求较多时观察首次打开与后续打开的区别，持续下载时观察速度能否稳定维持；不要把第一次握手与已复用的连接直接对比。iOS 的耗电也应在相同网络条件下观察，连接持续重试往往比字段数量更值得关注。
如果已有信息同时提供 VMess 与 VLESS，优先选择参数明确、当前应用支持、远端维护状态清楚的一组，而不是按名称新旧决定。排错时先固定一份完整条目，依次核对 Type、UUID、传输、Path、Host 与 TLS；每次只改一个与原始信息确有差异的字段。若导入后列表缺项，可参考 订阅解析与空列表自查，把获取配置的问题与建立协议连接的问题分开处理。
Trojan 与 TLS 核对
密码认证之外，证书名称与握手条件同样决定连接能否成立。
以 TLS 为基础的设计取舍
Trojan 将代理会话放在 TLS 连接中，并通过相应的密码认证识别用户。理解它时应把外层 TLS 与内部认证分开：TLS 负责建立安全通道并验证对应的服务器身份，密码负责协议层的访问认证。能够完成 TLS 握手，不代表密码一定正确；密码正确，也不能补救证书名称不匹配。相较于只核对一个加密方法的配置，Trojan 更需要关注域名、证书与入口之间的对应关系。
这种设计利用了成熟的 TLS 生态，但也继承了证书有效期、名称验证和握手协商等要求。它并不等于普通网页连接，也不能把任何支持 HTTPS 的地址当成 Trojan 服务器。只有远端实际提供对应服务并配置好认证，客户端才可能完成整个会话。用户需要的是一份完整的已有服务器信息，而不是根据网站地址和常见端口自行拼出条目。
Address、Password 与 SNI 分别负责什么
Address 是建立网络连接的入口，Port 是服务端口，Password 应与远端认证配置一致。SNI 在 TLS 握手时传递目标名称，服务器可能据此选择证书与处理路径。连接到 IP 地址时仍可能需要指定域名形式的 SNI；反过来，Address 已经是域名，也不意味着可以忽略原配置要求。若已有信息中明确写出了 SNI，就应保留，不要简单地将其替换成当前显示的服务器名称。
证书验证通常需要证书链可信、证书处于有效期内，且证书覆盖预期验证的名称。报错时先看设备时间与名称，再检查服务端证书是否正确部署。若只是连接入口变更，应由服务器配置说明确认相关字段，而不是在客户端关闭验证。跳过验证会削弱服务器身份检查，既不能修复密码错误，也不能保证连接到了原本期望的服务。
握手、应用请求与 UDP 的边界
一次成功的 TLS 握手只覆盖链路中的一段。随后还要通过 Trojan 认证、由远端连接目标，并返回数据。因此“能握手但页面不加载”应继续检查认证与远端访问，而“握手前就超时”更适合先查解析和入口可达性。若只有特定站点失败，也应观察规则命中与 DNS 结果。把这些阶段拆开，可以避免将全部问题都归咎于证书，或在密码栏反复修改本来正确的信息。
Trojan 的 UDP 转发能力需要客户端与服务端协同实现，实际表现还会受其承载方式影响。TCP 页面访问正常，不足以推断实时交互流量也合适；在某些承载结构中，丢包可能使等待集中表现出来。应使用目标应用的真实业务测试，而不是拿单一网页结果代替。存在额外传输层的条目还应按原配置核对，不能把基础 Trojan 的字段清单当作全部变体的通用清单。
iOS 上的速度与电量判断
TLS 握手需要网络往返和计算，远距离路径上的首次连接可能更容易感受到等待；后续连接是否能降低成本，取决于具体会话和实现。持续传输时，路径质量、拥塞情况与远端性能往往比首次握手更重要。对电量而言，稳定连接与减少重试通常有帮助，但长时间保活也会增加无线活动。不能仅凭“用了 TLS”就推断它耗电高，也不能承诺它在所有网络中都优于其他协议。
已有服务器提供稳定的 Trojan 配置，并且证书名称、密码与传输信息齐全时，可将它作为一个可验证的选择。比较时保持目标与网络不变，先看能否可靠建立会话，再看持续传输与后台表现。若出现更新后连接失败，应核对订阅是否同步了证书相关名称或入口变更；需要了解更新流程时，可继续阅读 订阅手动与自动更新说明，不要通过猜测新参数代替配置同步。
HTTP 与 SOCKS5
通用代理接口不等于加密隧道，名称解析与 UDP 能力需要分别确认。
通用代理协议的出发点
HTTP 代理源于对 HTTP 请求进行中转的需求，处理 HTTPS 目标时通常使用 CONNECT 建立到指定目标的字节通道。SOCKS5 则提供更通用的代理协商机制，可以表达目标地址与端口，不局限于网页语义。这两类协议常用于已有的内部网络或明确管理的代理入口，字段看起来简单，但其安全性与可用能力必须结合实际部署判断，不能将“支持代理”自动理解为“提供加密保护”。
普通 HTTP 代理与 HTTPS 代理需要区分：前者描述客户端到代理之间使用的基础协议，后者在这段连接外使用 TLS。访问的目标是 HTTPS 网站，并不能自动让客户端到 HTTP 代理之间的所有协商信息都获得相同保护。SOCKS5 的基本协议同样不自带覆盖整段传输的加密。若所在网络对保密性有要求，应确认已有入口的安全层，而不是仅凭目标网址中的 HTTPS 作出判断。
用户名、密码与允许的目标范围
Address 与 Port 指向实际代理入口，Username 和 Password 只有在远端要求相应认证时填写。留空认证与填写错误认证可能导致不同结果，不能把任意账户凭据当作代理密码。HTTP 代理可能对 CONNECT 允许的目标端口有限制，也可能只允许特定目标；因此某个网页成功并不能证明邮件、实时通信或其他端口都能通过。排错前应先了解已有代理的访问范围，避免把策略限制误判成客户端故障。
SOCKS5 可以协商不同认证方式，但客户端与服务器需要支持同一种方式。导入时检查类型是否被识别为 SOCKS5，而不是仅凭端口数值判断。常见端口只是约定，实际服务可以使用其他端口；同样，一个常见端口上也可能运行完全不同的服务。连接被拒绝时先确认地址与监听，认证不通过时再检查对应账户，不要同时更改端口、类型和密码，使原本能够定位的问题变得难以复现。
| 项目 | HTTP | SOCKS5 |
|---|---|---|
| 主要机制 | HTTP 请求转发或 CONNECT | 通用代理协商与目标连接 |
| 基础协议加密 | 普通 HTTP 本身不提供 TLS | 基础协议本身不提供加密 |
| UDP | 普通 CONNECT 不能直接视为通用 UDP 转发 | 协议定义了 UDP ASSOCIATE，仍需双方支持 |
| 目标限制 | 可能限制 CONNECT 端口与目标 | 可能受认证、地址策略及转发能力限制 |
DNS 在哪一侧完成
代理协商可能携带域名，也可能携带已经解析的 IP 地址，这会影响由哪一侧进行名称解析。具体行为受客户端配置、规则需求与协议用法共同影响，不能仅凭选择 SOCKS5 就断定 DNS 一定交给远端。若配置需要依据解析结果匹配 IP 规则，本地仍可能发生相关查询。诊断时应分别观察域名是否能解析、解析结果是否合理，以及代理端能否连接目标，避免只改一个 DNS 地址就期待解决全部问题。
SOCKS5 定义了 UDP ASSOCIATE，但远端可能没有启用、网络可能不允许相应返回路径，客户端配置也可能没有使用它。HTTP 代理的普通 CONNECT 则不能被当成通用 UDP 转发能力。若网页访问正常而实时应用失败，先确认业务是否依赖 UDP，并核对远端明确支持的功能。不要通过反复更换用户名来处理一个实际由转发能力缺失造成的问题，这两类问题处于不同层次。
速度、电量与使用边界
较少的封装可能降低部分处理开销，但不会消除路径拥塞、认证等待与远端限制。在 iOS 上，短时间测试容易因缓存或目标差异得到相反结论；应固定目标，分别记录连接建立与传输表现。已有的 HTTP 或 SOCKS5 入口适合其明确支持的业务范围，不应被假定可替代任何隧道协议。若需要继续核对名称解析，可阅读 DNS 与 DNS over HTTPS 设置说明，再结合当前规则判断请求实际经过的位置。
WireGuard
以密钥与虚拟网络地址建立隧道，不能照搬普通代理的密码思路。
隧道协议与代理条目的区别
WireGuard 的设计目标是建立结构精简的加密网络隧道，使用固定的密码学组合，并通过公钥识别对端。它处理的是网络层数据包，因此配置中会出现接口地址、对端密钥与路由范围等概念，而不只是一个代理密码。Shadowrocket 中如何使用相应条目，还要结合客户端的接管与规则机制理解；不能把独立隧道配置中的每个选项，未经核对就视作与应用内某个字段完全等价。
与提供用户名或 UUID 的协议不同，WireGuard 需要本端私钥和远端公钥形成正确关系。远端也必须认识本端相应的公钥，并为其安排合适的地址和可达范围。仅复制一个 Endpoint，或只拿到远端公钥，都不足以组成完整连接。若已有信息来自配置文件，应先识别 Interface 与 Peer 各自描述哪一端，再按照当前应用支持的入口导入，保留原文件用于逐项比对。
密钥、Endpoint 与地址字段
PrivateKey 属于本端秘密信息，不应发布在公开截图或求助正文中；PublicKey 在 Peer 中通常指远端的公钥，不能把两者互换。有些配置还包含 PresharedKey，它是额外的共享秘密，也必须双方一致。这里不展示密钥示例，避免把格式示意误当作可用凭据。向他人说明问题时，只需说明字段是否存在、导入是否报错及错误类别，不需要提交真实密钥。
Endpoint 表示远端可联系的地址与 UDP 端口，Address 则通常表示隧道内分配给本端的地址，它们不在同一个地址空间中承担同一职责。DNS 决定相应名称解析的配置，AllowedIPs 在 WireGuard 语义中关联对端可处理的地址范围与路由选择。远端若只允许一个内部网段，不能靠客户端把范围扩大为全部地址就获得额外转发能力；服务器端的路由、转发与返回路径仍然必须成立。
UDP、Keepalive 与移动网络
WireGuard 通常使用 UDP 传输，网络必须允许客户端与 Endpoint 的相应端口交换数据。Wi-Fi 上正常、蜂窝网络下异常，可能涉及 UDP 路径、地址变化或网络映射，而不只是密钥失效。观察时先看是否存在有效握手，再看实际业务能否通过；有握手不意味着 DNS、目标路由和返回路径都正确。特别是访问内部网段时，应检查该网段有没有与当前本地网络发生重叠。
PersistentKeepalive 用于在需要时维持网络映射，但不是数值越小越稳定。频繁发包可能增加无线活动与电量消耗，完全不需要时开启也未必有收益。是否设置、如何设置应依据已有部署要求与实际空闲断连现象，不应套用所有场景同一个值。移动设备在锁屏、切网与重新唤醒后的表现也应单独观察，不能用屏幕常亮时的一次成功测试替代后台稳定性判断。
MTU 与适用范围
MTU 反映相关接口能承载的数据包大小。封装后若超过路径能力，且必要的反馈不能正确返回，可能出现握手正常、小请求成功、大响应停住的现象。但这只是一个排查方向，不应在任何慢速问题上首先改 MTU。先确认路径、DNS 与路由，再按远端说明做有限调整，并记录原值；随意改得过小会增加分包与包数，改得过大又可能延续原有问题。
如果已有需求是访问明确管理的内部网段，且管理员提供完整的 WireGuard 配置，它的地址与对端模型便于表达这类需求。若目标是普通代理业务，也要确认远端确实承担相应转发，而不是仅建立了一条通往内部网络的隧道。速度和电量仍依赖无线条件、包大小、Keepalive 与业务量。最终判断标准是握手、路由、DNS 和目标响应同时正确，而不是配置里出现了某个隧道名称。
Hysteria2
基于 QUIC 的传输需要可用 UDP 路径，带宽设置应符合实际链路。
围绕不稳定路径的设计取舍
Hysteria2 使用基于 QUIC 的传输结构，着重处理高延迟、丢包等条件下的数据传递问题。QUIC 建立在 UDP 之上，但可以提供可靠的流式传输，因此“底层使用 UDP”不等于“所有应用数据都不保证到达”。它也不意味着任何弱网络都会变快：当 UDP 不可达、被严格限速，或入口本身负载很高时，协议设计不能绕过这些基础条件。选型前首先要确认已有服务器支持的是 Hysteria2。
Hysteria2 与名称相近的早期协议不能仅按显示名称视为兼容，导入格式与认证字段也应对照当前应用。某些配置还带有混淆或其他扩展参数，只有远端启用同样机制时才需要填写。额外选项不是普遍的性能开关，单方面添加会改变通信条件并可能导致连接失败。客户端能够保存条目，也不代表远端接受该条目实际组合，仍需通过完整会话验证。
认证、TLS 与服务器名称
基础核对包括 Address、Port、认证信息与 TLS 相关名称。认证信息应来自同一份已有配置，不能用订阅链接中的凭据替代；若导入工具将不同部分拆成多个字段，需要检查是否完整解析。SNI 与证书名称的关系仍然重要：即使传输改为 QUIC，证书验证也不会失去意义。设备时间不正确、预期名称不匹配或证书部署有误，都可能导致连接在认证前后中止。
若远端配置要求特定混淆类型和密码，应按原信息保留，并确认当前应用支持对应选项。不要因为网络不通就依次尝试所有混淆方式，这会让原始问题与新引入的问题叠加。更换端口也需要远端实际监听相应端口，客户端不能单方面创造新入口。对于来源明确但字段解释不完整的信息，应先补齐说明，再开始比较性能，避免将一个配置错误的条目纳入测试。
带宽参数不是测速结果
某些配置会涉及上行、下行或拥塞控制相关设置。它们表达发送策略或预期链路条件，不是对实际速度的保证，也不是填写得越大越好。数值高于可持续能力时，可能增加拥塞、丢包与波动；过低则可能限制可用吞吐。若界面提供自动协商或默认行为，应先按远端说明使用，只有观察到可重复的问题且理解对应参数时，再做有记录的调整。
蜂窝网络的可用带宽会随信号、位置与小区负载变化，短时测速得到的峰值不一定适合作为长期参数。Wi-Fi 的名义连接速率也不等于到服务器的实际可用带宽。比较时应看持续传输中的稳定范围，而非只取最高一瞬间；上行也不能忽略，因为确认与控制流量同样需要路径资源。若带宽设置变化后电量上升或波动加大，应恢复原值并重新确认条件。
iOS 的性能观察与失败分支
在一些存在丢包的路径上，合适的传输与拥塞控制可能改善持续传输，但实际收益取决于两端实现与网络环境。更积极地使用链路，也可能增加无线活动、计算与电量消耗，不能把高吞吐直接等同于更省电。建议分别观察短页面等待、长传输稳定性和空闲后的重新连接，并在同一时段与已有其他可用条目比较。只看一次延迟不足以反映 QUIC 会话的整体行为。
如果仅某种网络下失败，先保持条目不变切换到另一种自己可用的网络，判断是否与 UDP 路径有关；如果所有网络都失败，回到地址、端口、认证、证书与附加参数逐项核对。若普通页面正常而某个实时应用失败，要进一步区分应用流量转发能力与底层 QUIC 是否已建立。Hysteria2 适合作为已有可用选项中的实际测试对象，不应被当作无需条件即可改善任何连接的通用答案。
场景选型与逐层排错
从已有可用条件出发，用一致的验证步骤收敛问题。
按可验证条件缩小选择范围
日常网页与应用访问应优先使用参数完整、能够稳定建立会话的已有配置，再比较首次响应和持续传输。内部网段访问可重点核对 WireGuard 的地址、路由与对端权限；需要 UDP 的业务，则要确认协议、远端和当前网络三者都支持相关转发。弱网络下可以测试已有的 Hysteria2 等选项，但不要以此代替入口可达性检查。所有选择都应以远端已经提供的能力为边界，而不是按协议名称追求统一答案。
电量敏感的场景，应观察真实使用周期中的空闲连接、后台重试与网络切换。On Demand 控制何时触发连接，规则控制流量去向，它们与协议选择相关但不是同一问题。只有需要的请求进入适当路径、连接又能稳定维持时，比较协议成本才有意义。若持续出现失败重试，先解决失败原因；单纯换成字段更少的协议，可能保留同样的网络问题。
| 场景 | 先确认 | 比较重点 |
|---|---|---|
| 短页面与日常应用 | 认证、DNS、规则命中 | 首次响应、后续响应与重连 |
| 长时间持续传输 | 远端负载与可持续链路能力 | 稳定吞吐、波动、设备发热 |
| 实时交互业务 | UDP 转发及双向可达性 | 延迟波动、丢包与恢复时间 |
| 明确的内部网段 | 地址、路由与返回路径 | 目标可达、网段重叠与 DNS |
先确认请求确实经过测试条目
在 Config 下，规则的先后顺序决定请求如何匹配。下面只演示 Shadowrocket 的 .conf 规则片段，不是完整配置：域名后缀先交给 PROXY，所列私有网段交给 DIRECT，其余由 FINAL 指定最终策略。实际使用前要确认当前配置中的策略引用可用，并理解 FINAL 的影响。不要为了测试一个域名就覆盖整份原配置；先保存原设置，再做范围最小的验证。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
FINAL,PROXY若相同请求在 Direct 下正常、Proxy 下失败，可以继续检查远端连接，但这不是对整个网络的最终诊断；两种路径可能使用不同解析结果与目标入口。若在 Config 下异常而 Proxy 下正常，则优先检查规则和 DNS 关联。关于 Home、Config、Data 与 Settings 的位置，可查阅 界面英文对照，避免进入错误页面寻找并不存在的协议选项。
按失败阶段建立最小排错记录
第一步核对订阅是否获取成功、条目是否完整，再检查地址能否解析与端口是否可达；第二步核对 Type、认证和传输；第三步核对 TLS 与名称；第四步才检查目标访问和业务能力。若列表本身为空，尚未进入协议连接阶段，应先处理订阅获取或解析。若已经握手成功但没有目标响应，则继续检查服务器到目标的路径、目标限制与返回数据，而不是重新导入同一条订阅反复尝试。
记录应包含设备使用的网络类型、失败时的 Global Routing、所选协议、是否刚更新订阅及可复现的错误阶段。可以保留错误类别与经过脱敏的字段名称，不要附带真实密码、密钥或完整订阅链接。每轮只改一个明确存在差异的字段，并记录原值；确认无效后恢复，再检查下一层。遇到跨网络差异时保持服务器条目不变，遇到跨条目差异时保持网络与目标不变，才能减少变量干扰。
何时结束调参并返回基础检查
当所有协议在同一网络都失败，应先检查设备网络、DNS 与系统授权；当只有一个条目失败，应优先核对它的认证和远端状态；当只有某个目标失败，应检查规则与目标自身。不要把所有故障都转化成协议选型问题。相关常见疑问可继续查阅 问答，首次建立连接则按 快速上手重新核对授权和开关。应用获取、购买与兼容性统一在 下载核验页说明，价格与系统要求以 App Store 页面标注为准。