Shadowrocket
协议参数与选型

01 / 分层判断

协议、传输与规则各管什么

先区分四个不同的问题

在 Add Server 中选择协议，回答的是客户端应当怎样与服务器交换认证和业务数据。填写地址与端口，回答的是连接发往哪里。选择 TCP、WebSocket 或其他传输，回答的是数据外层怎样承载。配置 TLS，则决定这一层连接如何验证服务器身份并保护数据。这些字段彼此关联，但不是同一件事；只把 Type 改成另一个名称，服务器并不会随之支持另一种协议。

规则分流位于另一条判断链上。Global Routing 使用 Config 时，客户端按当前配置判断请求应当走哪一种策略；请求被交给代理之后，所选服务器的协议才参与通信。规则写得正确，不等于服务器认证正确；服务器能够连接，也不等于每个域名都命中了预期策略。排查时应把“选择了哪条出口”和“出口能否完成连接”分别记录，避免反复修改互不相关的字段。

地址、身份与目标域名不要混用

服务器地址是客户端首先拨号的目标，可以是域名，也可以是地址值。TLS 的 Server Name 通常用于服务器身份校验及握手中的名称声明。WebSocket 的 Host 和 Path 则属于相应传输的请求信息。三者在一些配置里相同，在另一些部署里不同。不要因为某个字段都能填域名，就把它们全部替换为同一个值；应逐项照原始参数核对，并保留服务端所要求的大小写与路径结构。

用户最终访问的网站又是另一层目标。代理服务器负责连接该目标，并不意味着它的名称应当写入客户端的 Server Name。类似地，连接服务器时发生的域名解析，与代理建立后访问网站时发生的解析，可能处在不同路径。出现网页打不开而 Connectivity Test 有结果时，应先确认测试到底检查了哪一段，而不是据此判定所有解析与业务请求均已成功。

用配置姿态划定检查范围

Global Routing 的 Config、Proxy、Direct 分别适合检查规则分流、代理路径与直接连接的差异。这里的“代理”不是承诺每一种系统流量都一定经过同一路径；本地网络、排除项及应用行为仍应按实际配置检查。切换姿态只是诊断手段，不能修复错误的密码、证书或端口。排查结束后，应恢复原本需要的姿态，避免把一次临时验证变成长期设置。

以下片段属于 .conf 的 Rule 段，用来演示分流顺序，不是服务器配置，也不能代替订阅。第一条匹配指定域名及其子域名，第二条匹配相应地址归属，最后一条承接未命中的请求。示例中的 PROXY 仍需对应实际可用的代理策略；复制规则之前，应先确认当前配置采用的策略名称与用途。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY

规则自上而下匹配，命中即停。把范围较大的规则提前，可能使后面的精确规则失去作用。协议排错期间尽量不要同时更改这一顺序，否则一次访问成功或失败会同时受到出口与传输的影响，无法判断变化来自哪里。更多关键字的范围可查阅规则关键字与匹配顺序，首次连接仍以使用说明中的步骤为准。

先记录原配置，再改变单一变量。名称相同不代表字段可以互换，测试有结果也不代表整条业务路径已经验证。

03 / 认证与外层承载

VMess 与 VLESS：相近字段，不同约定

UUID 相同不意味着协议相同

VMess 将身份认证、数据封装与协议自身的安全处理结合在一起，常见配置使用 UUID 标识用户。VLESS 则采用更轻的协议层设计，其协议本身不提供与 VMess 相同的载荷加密机制，通常依赖外层安全传输保护连接。这两种设计的关注点不同，因此不能只保留同一个 UUID，再把 Type 从 VMess 改为 VLESS，便期待服务端继续识别。

两者经常与其他传输方式组合出现，这也是它们在界面里字段较多的原因。协议类型解决认证及格式问题，外层传输解决承载问题，TLS 等机制处理相应的连接保护。实际部署可能只接受其中一种组合。用户已有信息如果明确写出协议与传输，就应完整保留；只拿到地址、端口和 UUID 时，材料可能尚不足以还原配置，需要从原始配置中确认其余条件。

先核对身份，再核对传输字段

UUID 应完整保留其字符与连字符结构，不要将备注、订阅分组名或服务器域名填入这一位置。VMess 配置还可能包含安全方式及历史兼容字段；旧材料中的额外认证参数并不是新配置都要照填的默认值。不要为了与某张旧说明图一致而添加数值。应以当前服务器给出的配置和应用实际可选字段为准，无法对应时先确定材料是否属于同一协议类型。

对于使用 WebSocket 的连接，Path 是服务端接受连接的路径，通常包含开头的斜杠；Host 则属于请求主机信息。路径是否区分大小写、是否含查询部分，都由部署约定决定。把路径清空或只保留最后一段，可能使服务器返回普通网页而非建立代理传输。遇到能够解析地址、端口也可达，但连接很快结束的情况，应优先检查这一层是否与服务端一致。

TLS 开关、Server Name 与证书校验应当单独核对。使用域名连接时，服务器地址与证书名称可能一致；使用指定地址连接时，Server Name 仍可能需要填写证书覆盖的域名。不能因为 TCP 已连通就跳过身份检查，也不应通过关闭验证掩盖名称错误。若原配置包含额外安全机制或 Flow 等条件，必须确认双方都支持该组合，不能从协议名称自行推导。

外层传输改变连接成本

WebSocket 为代理数据增加了一层适合相应服务架构的封装，能够与已有的 HTTP 服务接入方式配合，但会引入握手与帧处理。直接使用 TCP 时，层次可能更少，却要求服务器入口与网络路径满足不同条件。这里不存在对所有设备都成立的优劣排序：一个参数完整、路径稳定的组合，往往比一个理论层次较少但频繁失败的组合更适合日常使用。

在丢包环境中，多个可靠传输层叠加可能增加等待与缓冲，实际影响还取决于连接复用及服务器实现。并不是看到 WebSocket 就能断定速度慢，也不是看到 VLESS 就能断定耗电低。iPhone 处理一个长连接与反复重建许多短连接时，握手开销占比不同；网络切换后是否顺利恢复，也会影响无线模块的活跃时间。应以相同任务的重复结果评估，而不是按名称排序。

将故障定位到具体阶段

如果所有业务都失败，先确认当前选中的 SERVER 记录确实是正在编辑的那条，再核对协议、端口和 UUID。如果部分站点可用、部分失败，应将规则命中、解析和目标站点单独检查。如果只在切换网络后异常，可以先停止再重新建立连接，观察是否为旧会话恢复问题；不要立即改写身份字段，因为同一配置先前已经成功这一事实，本身就是有价值的排错依据。

VLESS 的轻量协议层不等于整条连接没有成本。TLS、传输、重连与业务请求仍然参与速度和电量表现。

手动配置不应成为不断试填字段的过程。较可靠的做法是先导入一条已知完整的原始记录，保留可工作的基线，再逐项查看它如何映射到界面。若订阅更新后字段改变，应比较更新前后记录，而不是把旧记录的某几个字段混入新记录。配置文件的分流设置与服务器记录也应分开保存，结构关系可参阅.conf 各段作用说明。

05 / 通用代理接口

HTTP 与 SOCKS5：转发能力不等于链路加密

从应用代理需求发展出的两条路线

HTTP 代理最初围绕 HTTP 请求的中转展开，也可以通过 CONNECT 方法建立到指定目标的隧道。SOCKS5 则提供较通用的代理协商机制，让客户端向服务器表达目标地址与端口，支持的命令及认证方式由双方共同决定。两者都能成为代理入口，但请求语义和握手格式不同，不能因地址与端口相同，就把一个 HTTP 入口按 SOCKS5 添加并期待兼容。

这类协议常见于用户已经管理的网络环境或明确提供通用代理接口的服务器。它们的重点是代理转发，不是默认提供与现代加密隧道相同的链路保护。是否存在 TLS、如何认证、是否允许特定目标，都需要单独确认。一个允许 CONNECT 的 HTTP 代理也可能对端口或访问范围设有限制，因此浏览网页成功并不能推出所有应用和所有目标都能经过该入口。

HTTPS 网站与安全代理不是同一个概念

通过 HTTP 代理访问 HTTPS 网站时，CONNECT 建立的隧道里可以承载网站自己的 TLS。网站内容可能因此得到端到端保护，但客户端与代理之间的代理握手及其他元信息，不会仅因目标网站用了 HTTPS 就全部变成加密。应将“网站连接使用 TLS”和“连接代理入口使用 TLS”分别判断；已有配置明确要求哪一种，客户端就应选择相应类型。

SOCKS5 本身也不等同于加密传输。用户名和密码认证负责识别使用者，不代表认证内容及后续数据自动获得机密性。不能把设置了密码理解成整段链路已经加密，也不应在不了解网络环境的情况下，把敏感认证材料当成普通备注传播。连接是否适合当前使用范围，需要结合底层网络、外层保护与服务端访问控制一起判断。

认证、解析与 UDP 是独立维度

HTTP 代理可能要求用户名和密码，也可能使用其他接入限制；SOCKS5 也有自己的认证协商。认证失败时，先确认服务器要求的方式是否受当前配置支持，再检查字符串本身。端口能够建立 TCP 连接不等于认证通过，因为端口连通只是连接初期的一步。服务端明确拒绝认证与连接超时不同，前者应查身份参数，后者还需检查地址、端口和网络路径。

目标域名在哪里解析，会影响可达性及排错方向。SOCKS5 能在请求中表达域名或地址，但具体使用哪一种，还受客户端解析策略和请求来源影响。不能仅凭协议名称推断每次解析必然发生在服务器端。如果某些域名失败而地址访问正常，应检查解析路径及返回结果；直接把域名替换成地址测试时，还要留意 HTTPS 的证书名称和虚拟主机可能因此改变。

SOCKS5 协议定义了 UDP 相关机制，但实际入口不一定启用或允许相应转发；普通 HTTP CONNECT 也不应被直接当成通用 UDP 通道。对实时应用，应先确认原始服务说明中是否包含需要的能力。若网页正常而实时功能异常，不要把 HTTP 与 SOCKS5 来回切换作为默认修复。两种协议所需的服务端支持不同，错误切换只会引入新的握手问题。

怎样判断是否适合保留

这类通用接口的优点是语义清楚、许多受控环境已有对应服务，适合按照既有网络设计使用。限制则在于安全保护、认证及转发范围可能需要其他机制补足。选型时先确认用途是少量网页请求、特定应用转发，还是需要更广的业务覆盖，再核对服务端实际允许的范围。不要根据协议名字简短，就判断它一定更快或一定更省电。

在 iPhone、iPad 上，实际成本还取决于连接数量、服务器响应和无线网络。代理层较少时，某些任务的处理可能简单；但如果目标限制导致频繁失败重试，总体活动反而可能增加。检查时应使用相同目标任务，分别记录解析、认证与内容加载结果。仅有列表中的测试结果不足以说明目标业务可用，常见现象与进一步检查路径可在常见问题中继续查阅。

07 / QUIC 与拥塞控制

Hysteria2：先验证 UDP，再讨论吞吐

围绕变化链路组织传输

Hysteria2 基于 QUIC 构建代理传输，QUIC 本身通常运行在 UDP 之上，并将安全握手与可靠传输等能力结合。它的设计关注点包括在延迟和丢包变化时组织数据发送，而不是单纯减少一个密码字段。UDP 是底层承载方式，不代表交付给应用的数据都不可靠；QUIC 可以在其上提供可靠流，因此应把底层数据包与上层业务语义分别理解。

这一背景说明它为什么值得在某些变化较大的链路中测试，也说明它为什么不是所有网络的默认答案。网络必须允许相应 UDP 路径，服务器也必须提供 Hysteria2 入口。若网络策略不允许该路径，客户端无法仅靠改变带宽数值完成连接。若业务本来受目标站点限速，换一种拥塞控制方式也不会消除目标端的限制。

认证、证书与附加字段仍是前提

基础参数包括服务端地址、端口、认证材料及 TLS 相关信息。认证文本应与原始配置一致；若服务端使用特定的组合格式，不要自行拆分为用户名和密码。Server Name 需要符合服务端证书及部署要求，其用途与前文 TLS 章节相同。设备时间、证书信任链和名称不一致，都可能使握手失败，这类错误不应通过提高发送速率来处理。

部分配置包含额外的混淆信息，这只在服务端启用相应机制时才需要。填写了错误的附加密码，可能使服务器无法正确识别初始数据。不能因为另一条记录有这一字段，就给所有 Hysteria2 记录补上。导入后应核对完整参数集，并确认分享材料属于 Hysteria2，而不是仅凭相近名称判断兼容；协议代际不同，认证与封装约定也可能不同。

带宽参数不是测速结果

某些配置方式允许声明上行和下行带宽，这些值可能影响发送行为或相应拥塞控制模式，不是服务器承诺的速率。把数值填得很大，不会增加无线容量或服务器出口容量，反而可能造成排队、丢包与重传。参数是否需要填写、如何与服务端协商，应以已有部署要求和当前应用可用选项为准；不能把某个示例数字作为所有网络的最佳值。

若需要评估带宽设置，应区分上行与下行，并观察其他业务是否受到影响。单次大文件传输看似更快，但同时打开网页明显变慢，可能意味着队列积压，而不是综合体验改善。蜂窝网络容量会随位置和负载改变，固定参数很难覆盖全部条件。较稳妥的做法是保留原始配置，采用保守且可验证的变化，每次只改一个方向，再重复同一组任务。

丢包、网络切换与电量

QUIC 的流机制可以减少某些跨流等待，但无法消除无线链路自身的丢包成本，也不能让同一可靠流绕过所有缺失数据。拥塞控制需要根据反馈组织发送，服务器实现与网络条件都会影响结果。因此，“基于 UDP”不等于“任何情况下都更快”。如果某个网络中的 UDP 质量较差，传统 TCP 路径在实际业务中也可能更稳定，应通过测试而非口号判断。

在 iPhone 上持续高吞吐时，无线收发和设备温度可能成为重要因素。激进发送导致的重传会消耗数据活动，频繁重连又会增加握手。电量比较应在相同信号、相近温度和一致任务下进行，避免把一次长时间测速与另一种协议的空闲状态比较。设备发热或网络切换期间的短暂结果，只能说明当时条件，不能形成固定的协议电量排名。

如果只有 Hysteria2 在某个网络失败，而同一服务器提供的其他已确认入口可用，先检查 UDP 路径、端口与证书，再核对认证和附加字段。不要同时改写 DNS、规则和带宽参数，否则无法定位原因。若出现连接成功但网页加载异常，则继续检查目标解析、规则命中及实际业务请求。本节提供的是选型和诊断方法，不对某条连接作速度承诺，也不替代服务器端的参数说明。

先建立参数正确的基线，再观察持续传输。更高的声明带宽不等于更高的可用带宽。