Shadowrocket 协议选型与参数参考

01 / SELECTION

协议选型：先确认服务端，再比较传输条件

把协议、传输、安全与路由分开理解

在 Shadowrocket 中选择协议类型，首先是在声明客户端将用什么格式与服务器交谈，而不是选择一个可以任意互换的速度档位。服务器提供 Shadowsocks，就需要对应的 Shadowsocks 类型与认证资料；服务器提供 Trojan，也不能仅把类型改为 VLESS 继续使用。地址和端口相同，只能说明连接目的地相同，不能证明服务器接受相同的握手、认证或数据封装。选型的第一依据始终是已有资料中的明确类型。

一个可用连接通常涉及四层信息。第一层是地址与端口，决定数据送到哪里；第二层是协议与身份认证，决定服务器是否接受请求；第三层是传输和安全参数，例如 TLS、WebSocket 或 UDP；第四层才是本地路由，决定哪些请求进入该连接。某些协议把其中几层组合在一起，另一些则允许多种搭配。排查时必须分层，否则容易把 DNS 错误当成密码错误，或把规则未命中当成协议不兼容。

速度与电量没有固定排名

实际速度受接入网络、往返时延、丢包、服务器负载、出口带宽及目标服务共同影响。增加一层封装通常会带来额外字节与处理，但不代表它在所有环境中都更慢：如果某种传输更适合当前网络，减少重传的收益可能超过封装成本。反过来，同一协议在两个不同服务器上的差距，也可能远大于同一服务器上两种协议的差距。因此，本页不按协议名称给出固定的快慢顺序。

iPhone 与 iPad 上的电量消耗也需要结合使用方式观察。持续大流量会同时使用无线链路、加解密与应用处理能力；零散请求则容易受到连接建立次数、后台保活和网络唤醒影响。频繁自动测速、短间隔更新、反复失败重连，都可能掩盖协议本身的差别。比较时应保持设备、网络、服务器与目标一致，并把屏幕亮度和其他后台任务纳入考虑，不能把一次电量下降直接归因于某个协议。

建立可以复现的比较方法

先保存一个已知可用的配置作为基线，再逐项调整。用同一目标分别观察首次打开、重复访问、持续传输和休眠恢复，不要在每轮测试中同时更换 DNS、协议和服务器。Connectivity Test 适合作为连接状态的一个观察入口，但测试结果不等于所有业务都可用。网页访问、视频播放、实时语音对传输的要求不同，应测试真正需要使用的业务，而不是只比较一个数字。

如果已有资料只提供一种协议，正确做法是把这组信息完整导入并验证，而不是凭名称寻找另一种类型。确需切换时，应先取得服务端为新协议准备的完整参数。订阅解析后列表为空，与协议选型属于不同层面，可先查阅订阅导入后列表为空的自查说明。本页后续章节假定至少已有一条可编辑的服务器记录，界面字段是否出现，以当前应用中的实际选项为准。

03 / VMESS · VLESS

VMess 与 VLESS：身份字段相似，不等于协议相同

设计取舍与类型边界

VMess 将身份认证和数据处理组织为专门的代理协议，其配置通常包含 UUID 以及与安全、传输有关的参数。VLESS 则采用更精简的协议层设计，本身不提供内容加密，需要结合安全传输方案理解完整连接。两者都可能出现 UUID，也都可能与不同外层传输组合，因此只看链接中的身份字段无法判断类型。应以原始订阅或服务端明确标注为准，不能把同一个 UUID 当成跨协议通用的连接凭证。

VLESS 的精简不代表完整连接一定消耗更少资源，也不代表可以省略安全层。若连接叠加 TLS、WebSocket 或其他传输，实际字节开销和握手流程由整套组合决定。VMess 的表现同样取决于服务端配置与网络条件，而不是只由协议名决定。选型时应同时记录协议、传输、安全层三个维度，再讨论兼容性和使用场景；把其中一个维度抽出来比较，容易得到与实际运行不符的结论。

UUID、传输类型与路径

UUID 用于标识服务端允许的用户身份。复制时需要完整保留字符和分隔形式，不能使用备注名替代。备注只帮助用户识别记录，不参与协议认证。VMess 的部分参数还与协议实现和历史配置形式有关，不应根据网上的单一截图批量修改。对于协议认证过程涉及时间的情况，设备时间明显偏离可能导致失败；应先确认系统日期与时间正常，再判断服务器是否拒绝了身份。

传输字段决定协议数据如何承载。使用 WebSocket 时，Path 是握手请求路径，Host 与 HTTP 层主机信息有关；它们不是服务器备注，也不能把完整网址随意拆入各个字段。路径中的前导斜杠、大小写和查询部分是否需要保留，应按服务端资料核对。选择其他传输时，字段集合可能变化，不应把 WebSocket 的参数机械填入另一个传输类型中。界面没有显示的字段，也不等于可以用名称相似的字段代替。

TLS 名称与其他扩展参数

连接地址负责找到服务器，TLS 的 Server Name 用于握手中的名称信息，并与证书名称验证相关；二者可以相同，也可能由服务端资料明确指定为不同值。Host 又属于另一层，不能因为内容看起来都是域名就互相覆盖。若资料还包含其他安全扩展或特殊握手参数，应确认当前应用实际支持对应组合。字段能被填写，只表示存在输入位置，不足以证明任意组合都能与服务端互通。

已有配置中的 Flow 等可选参数属于特定协议组合的约定，不是通用提速开关。只有服务端明确要求且客户端提供兼容选项时才应启用。不要通过反复尝试多个安全参数来替代核对原始资料，这会同时改变握手条件，使排错缺少基线。对订阅导入的记录，先保留原始结果，再建立独立测试副本，更容易确认是导入信息不完整，还是后续编辑导致连接变化。

移动网络中的比较方式

在 iPhone 或 iPad 上评估这两类连接，应区分首次握手和已建立连接的数据传输。多层握手会让短请求更敏感于往返时延，而长时间传输可能主要受带宽与拥塞影响。网络切换后旧连接失效、应用重新建立连接，也会造成短时等待。若只是某种传输恢复较慢，应记录发生在锁屏恢复、无线网络切换还是普通连续使用期间，而不是直接把结论归为 VMess 或 VLESS 的整体差异。

出现失败时按地址与端口、协议与 UUID、外层传输、安全层、目标访问的顺序逐项排除。若连接记录显示请求根本没有选中该服务器，应先检查 Global Routing 与当前配置。更多通用现象可查阅疑难解答，避免在路由尚未确认时反复修改身份字段。

05 / HTTP · SOCKS5

HTTP 与 SOCKS5：先识别代理入口，再确认保护范围

两种通用代理接口的出发点

HTTP 代理围绕 HTTP 请求转发发展，处理网页请求时可以使用代理形式的请求目标；对于 HTTPS 等场景，常通过 CONNECT 请求建立到目标的隧道。SOCKS5 则提供更通用的代理会话协商，用于表达目标地址、端口和连接请求。两者都是代理入口的协议约定，不代表入口天然具有相同的加密保护、认证机制或 UDP 能力。已有服务器写明 HTTP，就不能只因为地址不变而改选 SOCKS5。

这里尤其要区分目标网站使用 HTTPS，与客户端到代理入口使用 TLS。HTTPS 网站的内容保护通常延伸到目标网站，但客户端与 HTTP 代理之间的连接若未使用 TLS，代理协商信息及某些认证信息的保护范围与加密代理入口不同。目标网站采用安全连接，不等于外层代理链路的每一部分都具有相同属性。判断保护范围时应逐段看连接，而不是只看浏览器地址栏或服务器备注中的一个词。

地址、端口与认证模式

HTTP 与 SOCKS5 的基础信息通常包括服务器地址、端口，以及可能需要的 Username 和 Password。是否需要认证由服务端决定，不能假设留空就能连接，也不能把其他协议的 UUID 填入用户名后期待自动兼容。认证失败与网络不可达的现象可能接近，需要结合连接错误和已有资料区分。手工输入时还要注意某些账号包含域或其他前缀，是否保留应以服务端提供的完整格式为准。

如果代理入口要求 TLS，应选择与之对应的安全设置，并核对证书名称。端口数字本身不能证明该入口是明文或加密，也不能证明它接受 CONNECT。部分服务端会限制可访问目标、目标端口或认证方式，即使客户端成功连到入口，后续请求仍可能被拒绝。遇到某些目标端口失败时，应先确认授权范围与服务端策略，而不是反复修改本地 DNS 或误认为所有 HTTP 代理都只能访问网页。

域名解析与 UDP 的条件

SOCKS5 的目标地址可以用域名形式表达，但一次实际请求是否把域名交给代理侧解析，仍取决于客户端处理、DNS 策略和目标信息是否已经被转换为 IP。不能只凭选中了 SOCKS5 就认定所有 DNS 请求都在远端完成。HTTP 代理同样可能在请求中获得目标主机名，但应用产生的其他 DNS 查询需要单独考察。排查域名问题时应观察实际连接目标与 DNS 结果，而不是只检查服务器类型。

SOCKS5 规范包含 UDP ASSOCIATE，并不意味着每个服务端、每个接入网络和每种客户端组合都能完成 UDP 转发。相关协商通常还涉及控制连接和转发地址，网络侧可能限制其中一部分。若 TCP 业务可用而 UDP 业务失败，应分别验证服务端是否启用、返回地址是否可达以及规则是否选中同一记录。不能把一个网页测试结果直接外推到语音、游戏或其他 UDP 业务。

适用场景与移动使用判断

这两类入口常用于已有组织代理、授权网络接入或明确提供通用代理协议的环境。用户应按管理方给出的类型与安全要求配置，而不是根据参数数量少就认为更适合长期使用。对 iPhone 和 iPad 而言，连接稳定性仍受网络切换、认证有效期和服务端限制影响。某个代理持续提示认证失败时，先检查凭据状态与授权范围，不要用频繁重连替代确认。

如果业务需要持续低时延或 UDP，应先确认入口能力确实覆盖该需求；如果只是访问特定授权资源，则更应重视目标路由和认证范围。协议选择应服务于已有连接条件，不负责创造服务端没有提供的能力。保存记录时可在备注中标明用途与网络条件，但备注不要包含密码；这样在多个入口之间切换时，能够识别场景，又不会在列表截图中暴露认证信息。

07 / HYSTERIA2

Hysteria2：基于 QUIC 的传输需要先确认 UDP 条件

设计目标与网络前提

Hysteria2 以 QUIC 为基础组织代理传输，关注复杂网络条件下的数据传递与拥塞处理。QUIC 运行在 UDP 之上，并结合 TLS 完成安全握手。它可以在一条连接中组织多个数据流，流之间的处理方式与单一 TCP 字节流不同，但共享连接仍受到整体带宽、拥塞和服务器资源限制。不能把多流特性理解为某一个请求完全不受其他流量影响，也不能仅凭协议名称推断实际吞吐。

使用前最重要的前提是 UDP 路径可用。某些网络可以正常浏览网页，却对 UDP 入口存在限制或不同的处理方式，此时基于 TCP 的记录正常，并不能证明 Hysteria2 的入口也应该正常。失败时应先核对域名解析、端口与 UDP 可达性，再看认证和 TLS。若底层路径不成立，修改带宽参数或添加保活通常不能补足缺失的网络条件。

认证、TLS 与混淆参数

已有 Hysteria2 资料通常包含服务器地址、端口、认证信息和 TLS 相关设置。认证字段需要按服务端要求完整保留，不能拿其他协议的密码直接尝试。TLS 的名称与证书验证原则和前文一致：连接目标、Server Name 与证书覆盖名称应形成正确关系。即使底层使用 UDP，证书时间、名称和信任链仍然重要，不能把握手失败一概归类为 UDP 被限制。

如果服务端启用了混淆，客户端需要对应的类型与密码等参数。混淆与认证、TLS 是不同层次，各自承担不同作用，不应因为其中一个字段正确就忽略另外两个。没有启用混淆的入口，也不应添加不明参数。导入后若出现一个可用记录和一个手工重建记录结果不同，优先逐项比较字段，特别是那些在简略资料中容易被省略的可选设置。

带宽字段不是测速结果

某些配置会出现上行与下行带宽字段，它们可能参与具体拥塞控制模式的行为。字段里的数值不是客户端实时测得的速度，也不表示服务器承诺持续提供该吞吐。服务端策略及协商方式可能影响这些值是否生效，不能通过把数值填得很大来增加物理带宽。录入时还应确认应用字段使用的单位，不要把字节每秒与比特每秒混用，或把自己的下行能力误填到上行位置。

如果设定明显高于实际接入能力，在相关模式下可能形成排队、丢包和不稳定；设定过低又可能限制可利用的传输能力。应以真实网络条件和服务端说明为依据，保留原始配置作为基线。测试时同时观察下载持续性、交互请求等待和其他应用是否受到排队影响。某次短暂达到较高速度，不足以说明参数合理，更不能代替长一点的稳定性观察。

iPhone 与 iPad 上的资源观察

QUIC 的协议处理、加密与数据收发都会占用设备资源。具体电量表现受实现、流量、丢包与无线信号强度影响，没有适用于所有设备的固定结论。大流量测试时，应用处理和无线传输同时活跃，设备温度上升并不能独立证明配置错误。更有参考价值的是同等业务量下的持续表现、后台是否反复重连，以及弱信号或锁屏恢复时是否出现明显异常。

若仅在特定无线网络失败，可换一个已获授权的接入网络验证路径差异；若所有网络都失败，再检查原始认证、TLS 与服务端状态。若连接可以建立但大流量停顿，检查路径丢包、数据包大小、带宽设置与远端资源，而不是立即改用另一个协议类型。服务端必须实际提供新协议，切换才有意义。保留失败发生的阶段与简短错误信息，比只记录“不能用”更有助于后续判断。

完成测试后，停止重复测速与无必要的持续传输，恢复日常配置再观察电量。若问题只在更新订阅之后出现，应先比较记录参数变化，区分服务端调整与本地网络变化。配置来自已有订阅时，手动修正还可能被后续更新覆盖，因此应明确测试副本与订阅记录的管理关系，避免同一个问题在更新后再次出现。