Shadowrocket 协议参考

01 / CONNECTION MODEL

协议层次与参数核对顺序

协议类型只是连接链条的一部分

一次请求从设备到目标服务，通常会经过本地路由判断、服务器地址解析、底层连接、协议认证和目标转发。Shadowsocks、VMess、VLESS 等名称主要说明客户端与服务端怎样交换代理请求，并不直接说明服务器距离、出口带宽或拥塞程度。两个同名协议可以表现差异很大；反过来，两种不同协议在同一网络、相近服务器条件下，也可能具有接近的实际体验。

理解参数时，应把服务器地址、认证、传输、安全和路由分开。服务器地址决定连接发往哪里；密码、UUID 或密钥证明连接身份；TCP、UDP 及其上层封装决定数据怎样承载；TLS 负责相应连接的加密与证书验证；规则则决定哪些请求使用这条连接。某一层通过，不代表后面的层也通过，因此“能测到延迟”不能代替完整访问验证。

按资料来源填写，不把猜测当作默认值

在 Add Server 中选择类型前，先核对已有资料标明的协议。端口相同不代表协议相同，使用 TLS 也不代表类型必然是 Trojan。订阅导入后，应检查类型、服务器与端口是否合理，再检查认证字段和传输选项。字段名称与排列可能随类型不同，以当前应用内显示为准；没有收到某项参数，不应仅凭网上示例补入一个看似常见的值。

服务器域名、TLS 的 SNI 和 WebSocket 的 Host 可能相同，也可能因服务部署方式而不同。域名用于找到连接地址；SNI 用于 TLS 握手中的服务选择，并通常参与证书名称核对；Host 用于应用层请求分发。修改其中一项不一定会改变另两项，不能把它们视作三个可随意互换的服务器地址。

区分 UDP 支持与具体应用可用性

“支持 UDP”至少涉及客户端协议实现、服务端转发权限、中间网络与目标服务四个条件。有些协议把 UDP 数据封装在流式连接里，有些直接使用数据报，还有些取决于额外扩展。语音、实时交互或 HTTP/3 的表现，不能只根据协议名称判断。即使普通网页正常，也要为实际使用的应用单独验证，避免把网页成功误认为全部连接能力已通过。

后续章节中的“选型”指在你已经拥有、且服务端明确支持的配置之间选择，并不是把客户端菜单切换为另一类型就能改变服务端协议。若导入结果与原始资料不同，应先核对分享链接是否完整、解析后字段是否保留，再决定重新导入或向资料提供方确认，避免在错误类型上反复调整。

02 / SHADOWSOCKS

Shadowsocks：加密方法与转发边界

以较少的协议层完成代理转发

Shadowsocks 的基本思路，是在客户端与服务端之间建立带加密保护的代理转发通道，将目标地址和应用数据交给服务端处理。它不是完整的虚拟局域网协议，也不会自动决定系统里每个请求的路由。Shadowrocket 在设备上接收需要处理的流量，再按 Global Routing 与当前配置决定是否交给选中的 Shadowsocks 连接；协议本身与本地分流是不同职责。

较少的封装层有助于减少部分握手与处理成本，但不能据此承诺速度更快。真实吞吐仍受加密实现、设备负载、服务器性能和链路质量限制。若服务端本身拥塞，换一种加密方法通常不能解决；若连接使用了额外传输机制，也应把这些机制的成本一并计算，而不能仅凭类型名称推断实际路径。

Method 与 Password 必须成对核对

最核心的信息是服务器、端口、加密方法和密码。Method 不是任意选择的性能档位，而是双方必须共同使用的算法与消息格式。AEAD 方法除了保密，也对数据完整性提供验证；不同方法的密钥长度和派生方式可能不同。Password 正确但 Method 错误，仍会造成认证或解密失败，表现可能是连接建立后没有有效响应，而不是明确的“密码错误”。

对于使用固定长度编码密钥的协议变体，不能把普通短密码直接当作密钥填入。原始资料若包含多个认证部分或特殊格式，应完整保留，不能自行删除分隔符。复制时还要注意末尾空格、换行以及输入法替换的标点；重新手输一遍并不必然更准确，优先从可信的原始资料复制，再逐项比对导入后的结果。

TCP 正常不代表 UDP 已经验证

Shadowsocks 可以承载不同类型的应用流量，但 UDP 是否可用仍取决于两端支持与网络条件。网页加载成功通常只验证了部分路径。若语音连接失败、实时应用只在特定网络异常，应先确认服务端允许 UDP 转发、客户端相关选项与资料一致，以及当前 Wi-Fi 或蜂窝网络是否能传送对应数据，而不是先改动密码和加密方法。

UDP 数据报通常没有与 TCP 相同的可靠传输语义，丢包后是否重传由上层应用决定。因此，某个测试显示较低延迟，但通话仍断续，并不矛盾：延迟只反映收到响应的那部分请求，不能说明所有数据报都及时到达。排查时需要同时观察丢失、抖动和持续会话，而不是只看最小延迟数字。

在 iPhone 与 iPad 上怎样评价

在已有配置都可用的情况下，Shadowsocks 适合作为结构相对直接的比较基线。测试短网页请求时看首次响应与重复访问；测试大文件时看稳定吞吐；测试实时应用时看长时间抖动。不要把不同地区、不同出口的配置放在一起后，把差异全部归因于协议。服务位置和负载常常比封装层数更显著。

如果希望降低设备电量消耗，先减少不必要的持续传输与反复失败重连，再观察加密处理的影响。长时间保持连接但几乎没有业务，与持续高吞吐下载的耗电来源不同。前者更多受后台唤醒和网络保活影响，后者还包含无线传输、加密计算与设备温度变化；仅看电池页面的一个百分比不足以定位协议问题。

03 / VMESS & VLESS

VMess 与 VLESS：认证、传输与 TLS

名称接近，但不是可以互换的类型

VMess 将代理请求认证与数据处理结合在自身协议中；VLESS 则采用较精简的请求与身份描述，把连接安全更多交给配套的安全传输层。二者都可能搭配不同承载方式，因此资料中出现 TCP、WebSocket 或 TLS 时，仍需要继续核对具体组合。把 VMess 条目直接改成 VLESS，不会自动转换认证语义、消息格式或服务端配置。

VLESS 本身不提供与 TLS 等价的数据加密保护。看到某个条目使用 VLESS，不能只核对 UUID 就认为安全层已经完整。应确认原始资料要求的安全机制及其参数确实启用；若资料没有说明，应先补齐部署信息，而不是凭猜测关闭证书验证。相应扩展是否支持，还需要以当前客户端与服务端的实际能力为准。

UUID、时间与认证信息

UUID 是此类配置中常见的身份字段，应视作敏感信息。它不是服务器域名，也不应与备注名称混用。VMess 的认证机制涉及时间条件，设备时间偏差明显时可能影响认证，所以出现“同一资料在另一设备正常”的情况，应检查自动设置时间是否正常，而不仅是重装应用。VLESS 的认证机制不同，不能把 VMess 的每条排错结论照搬过去。

如果导入资料包含额外的认证或流控参数，只填写 UUID 可能不足以建立连接。某些旧资料中的字段在当前组合下可能不适用，不能为了让表单看起来完整而填入任意值。正确处理方式是对照服务端提供的连接说明，核实该字段是否参与当前协议；若它只属于另一种传输或安全组合，应停止套用。

WebSocket 增加了哪些核对点

WebSocket 可以把连接承载在相应的应用层会话中，常用于已有 HTTP 服务转发结构。它会引入路径、Host 和中间转发行为等额外条件。路径通常需要精确匹配，大小写、末尾斜杠或遗漏的前缀都可能导致服务端没有把请求转交给正确处理程序。收到 HTTP 响应也不等于代理认证通过，可能只是到达了普通站点。

当外层使用 TLS 时，先发生的是安全握手，之后才是 WebSocket 建立及代理协议交换。证书错误、路径错误与 UUID 错误发生在不同阶段，观察现象时应按层判断。若中间转发对长连接有空闲超时，连接可能在闲置一段时间后被关闭；这与刚开始就无法认证不同，也不能简单用增加密码长度解决。

速度取舍与排错顺序

多一层承载可能增加握手次数、消息开销或中间设备处理，但它也可能是服务部署必须的一部分，不能为了减少开销而在客户端单独关闭。比较性能时，应使用完整、正确的配置组合。短连接多的场景更容易感知建连成本；持续连接则更容易受带宽、丢包和复用行为影响，二者不能只用一次延迟测试代表。

推荐依次检查地址解析、端口、TLS、传输路径、认证与实际目标访问。若所有目标都失败，先看共同的连接层；若只有一个域名失败，再看规则、解析和目标状态。已有配置从订阅更新后突然异常时，还要检查该条目的传输选项是否改变，以及手工修改是否被更新覆盖，避免只对照更新前记忆中的参数。

04 / TROJAN · HTTP · SOCKS5

Trojan、HTTP 与 SOCKS5：安全层与代理语义

Trojan 依赖正确的 TLS 连接

Trojan 的设计把代理协议放在 TLS 连接之内，使用相应认证信息让服务端识别代理请求。理解它时，重点是把外层 TLS 与内层认证分开。服务器地址能建立 TCP 连接，仅说明端口可达；TLS 握手通过后，仍需认证和目标转发成功。Password、SNI、端口及服务端部署方式必须共同正确，不能只保留一个密码就期待连接成立。

证书验证用于确认连接对象的身份。若出现名称不匹配，应检查资料给出的 SNI、服务器域名及证书覆盖范围；若提示证书有效期问题，应检查设备时间和服务端证书。把跳过验证作为日常默认设置，会丢失身份核对这一层保护，也会掩盖真正的配置问题。应修正名称、证书链或时间，而不是仅让错误提示消失。

HTTP 代理不等于目标网站使用 HTTP

HTTP 代理描述客户端与代理服务怎样交互。访问普通 HTTP 目标时，代理可以处理相应请求；访问 HTTPS 目标时，常用 CONNECT 方法建立到目标的通道，目标网站的 TLS 会话再通过该通道进行。因此，“HTTP 代理”不表示浏览器只能打开普通 HTTP 网站，也不表示客户端到代理服务器的这一段必然受到 TLS 保护。

若资料明确提供 HTTPS 代理，客户端与代理之间还会有相应 TLS 连接，需要核对其证书与名称。用户名和密码通常用于代理认证，但认证本身不是完整的加密机制。要判断安全边界，应分别问清“设备到代理这一段是否加密”和“应用到目标这一段是否加密”，不能因为网页显示安全连接，就推断中间每一层都相同。

SOCKS5 提供通用的目标转发描述

SOCKS5 通过协商告诉代理服务目标地址、端口和所需操作，能够表达域名或 IP 目标。基础 SOCKS5 并不自带 TLS 级别的传输加密；用户名与密码认证也不能替代安全通道。它适用于服务部署已经明确提供此类接口的场景，选择前应了解连接所在网络与额外保护条件，而不是仅根据配置项较少就认为更适合移动设备。

SOCKS5 的 UDP 转发涉及额外协商与数据报路径，实际是否可用取决于服务端实现、客户端配置以及网络可达性。TCP 请求正常并不能证明 UDP 关联已经建立。同样，目标域名在哪里解析也会影响结果：如果在本地先转换为 IP，代理服务收到的就可能不是原始域名，解析差异与域名规则匹配都需要结合实际链条理解。

怎样根据已有环境选择

若组织或自有服务器已经提供固定代理接口，应按其协议填写，而不是自行换成名称更熟悉的类型。服务端监听端口相同也可能使用不同握手格式。对于有明确证书与域名部署的 Trojan 配置，应优先把 TLS 核对做完整；对于 HTTP 或 SOCKS5，则应确认接口的信任边界、认证要求与允许的目标范围。

实际排错时，如果 CONNECT 被拒绝、只有部分端口失败或认证持续不通过，还要考虑服务端访问策略。目标权限限制不是无线信号差，也不是所有协议共有的问题。记录错误发生的目标类型和阶段，有助于区分认证失败、目标不可达与请求被服务端策略拒绝；不要在缺乏证据时同时修改所有字段。

05 / WIREGUARD

WireGuard：密钥、隧道地址与 IP 路由

从目标代理转向 IP 隧道

WireGuard 的工作模型与前面几类目标代理不同：它以加密隧道承载 IP 数据包，双方围绕密钥和对端信息建立通信关系。设计强调较精简的协议与固定密码学组合，不通过一长串可选算法让用户逐项协商。对 Shadowrocket 用户而言，这意味着参数核对重点从“代理账号与目标地址格式”转向密钥、Endpoint、隧道地址及可达网段。

协议使用 UDP 作为底层承载，因此外层 UDP 路径必须可用。隧道里面可以承载不同应用的 IP 流量，但这不表示外部网络允许所有 UDP 通信。若同一配置在某个 Wi-Fi 可用、换蜂窝网络失败，应检查外层路径与地址解析，而不是先修改隧道内的目标规则。内层应用的 TCP 正常与外层 UDP 可达是两个不同层面。

Private Key 与 Public Key 的方向不能颠倒

Private Key 属于本端身份，应保密；Public Key 用于让对端识别本端。客户端配置中的对端公钥应对应服务端身份，不能随手复制成本端公钥。若资料还提供 Preshared Key，则两端也必须保持一致。密钥内容通常具有固定编码格式，复制遗漏字符、混入空格或把私钥发到公开截图里，都会分别带来连接或安全问题。

Endpoint 是发起通信时使用的外部地址与端口，不是隧道内部地址。Address 一类参数则描述本端在隧道中的地址，需与部署规划一致。把 Endpoint 的公网地址填进隧道地址，或者给两端设置冲突的内部地址，都可能导致握手后无法正常转发。填写时应按字段角色核对，不要只看它们都长得像 IP 地址。

Allowed IPs 与本地分流不是同一张表

Allowed IPs 在 WireGuard 的模型中同时参与对端的地址归属与出站选择。它不是远端站点名单，也不能直接替代 Shadowrocket 的 Rule。客户端本地规则先决定请求是否进入相应连接；进入 WireGuard 后，隧道地址范围和服务端转发又决定数据是否能到达目标。某一侧写得很宽，不代表另一侧会自动允许相同范围。

若目标是访问你已有的远程内部网络，应核对目标网段、回程路由以及服务端是否允许转发。若本地 Wi-Fi 与远程网络使用相同私有网段，还可能发生地址重叠：相同目标看起来既像本地设备又像远程设备。此时需要结合网络规划与规则处理，不能仅通过更换 DNS 解决所有冲突。具体修改前应先确认哪一侧拥有该地址。

Keepalive、MTU 与移动网络

Keepalive 可以帮助维持网络设备上的映射状态，适用于确实需要外部主动到达或保持映射的部署，但更频繁的保活会增加后台网络活动。不要把任意较小间隔当作通用优化。移动网络切换后，外部地址和映射可能改变；协议具有相应对端更新机制，也仍然需要当前网络允许有效数据到达，并给系统时间恢复路径。

MTU 描述可承载的数据包大小。封装需要额外空间，路径允许的大小不足时，可能出现小请求正常、大响应停滞的现象。处理时先排除服务器与目标问题，再根据实际路径谨慎调整，并保留原值。并非所有超时都来自 MTU，盲目调得很小会增加包数量与处理开销，也不保证改善速度。应使用可复现目标验证变化。

06 / HYSTERIA2

Hysteria2：QUIC、带宽参数与丢包环境

基于 QUIC 的连接思路

Hysteria2 采用基于 QUIC 的传输设计。QUIC 在 UDP 之上提供安全连接、流管理与可靠传输等机制，可以把多条流的管理放在同一个连接框架中。与把所有数据放进单条有序字节流相比，不同流在传输层的交付可以更独立，但它们仍共享链路带宽、拥塞反馈和设备资源，不能理解成每条流都有独立的网络容量。

这一设计常被用于讨论高往返时延或存在丢包的路径，但不能推出“有丢包就一定更快”。丢包来源可能是拥塞、无线信号、网络设备限制或路径变化，合理的发送行为必须适应这些条件。如果外层 UDP 无法稳定传送，建立在其上的协议也无法凭空恢复可达性。协议能力与当前网络允许的通信条件需要同时满足。

认证、TLS 与服务名称仍需核对

Hysteria2 的连接资料通常包含服务器、端口、认证信息及 TLS 相关设置。认证通过与证书验证仍是不同任务：前者让服务端确认客户端权限，后者让客户端核对服务端身份。Server、SNI 和证书名称是否一致，应按部署资料确认；不能因为底层采用 QUIC，就省略证书检查或把任意名称都当成可用值。

若部署使用额外的混淆设置，应核对双方类型与相应参数。它不是认证密码的别名，也不是填写任意字符串便会生效的性能开关。Hysteria2 与其他协议或不同协议代际不应只凭名字相似而混用参数。导入后如果出现无法解释的空字段，应回到原始资料核实其含义，不要把另一类型的字段逐项复制过去。

带宽值不是保证得到的速度

某些配置会提供上传、下载带宽参数，用于相应发送控制或带宽协商。它们表达的是运行条件或控制输入，不是购买权益，也不是设备可以直接获得的吞吐保证。单位尤其需要仔细区分：位速率与字节速率并不相同，界面显示和资料单位不一致时，要先换算，再按字段规定填写，避免因数量级错误影响行为。

把带宽填得远高于实际可用容量，不会扩大物理链路。相反，发送过于积极可能使队列累积，增加其他应用的等待与丢包，也可能造成明显的速度波动。填得过低则可能限制可用吞吐。是否需要显式填写、参数在当前组合中怎样生效，应以双方实现和部署说明为准，不建议把别人的数值当作固定推荐值。

在移动设备上评估额外成本

QUIC 的加密、包管理和恢复逻辑需要处理资源；外层 UDP 在弱信号或受限网络下反复重试，也可能增加无线活动与电量消耗。高吞吐期间更明显的发热不能仅归因于某个协议名称，还可能来自屏幕、目标应用和持续数据传输。比较时应保持任务、亮度、设备温度及测试时长大致一致，避免把环境差异算作协议差异。

如果已有的 Hysteria2 配置在一个网络连续失败、另一网络稳定成功，应优先做网络对照，并记录是否连握手都无法完成。若握手正常但长时间负载不稳定，再检查带宽参数、服务器资源与路径丢包。只有某个应用异常时，则先确认其请求是否真的经过该连接，以及目标服务是否正常，不要从单一现象推导整体协议不可用。

07 / IOS & IPADOS

iPhone 与 iPad：速度、电量与网络切换

把速度拆成三个可观察部分

第一部分是建连时间，包括地址解析、到底层服务器的连接及安全握手；第二部分是目标首次响应，包括服务端访问目标的耗时；第三部分是持续吞吐，取决于带宽、丢包、拥塞控制和两端处理能力。日常网页可能更受前两项影响，大文件更受第三项影响。一次延迟数字不能同时代表三项，也不能直接换算成视频、通话或交互体验。

Connectivity Test 的结果应结合当前测试方法理解，不同方法可能只验证服务器可达，也可能尝试经过代理访问目标。不要在不知道测量对象时，把数字视为完整业务往返时间。地区名称同样只是一条备注信息，不能代替实际路径测量。关于测试含义与地区判断，可继续阅读延迟、地区与协议类型的关系。

电量来自整个工作链条

连接运行涉及应用产生流量、系统网络处理、协议加密、无线收发和必要的后台维护。高吞吐时，处理与无线传输成本都增加；空闲时，保活、自动检查与失败重连可能更值得观察。电池统计中显示的占比还受其他应用使用量影响，不能把两个不同使用日的百分比直接作为协议效率结论。

合理的比较应先让设备回到相近温度，保持网络、屏幕亮度与任务相同，运行相近时长，再记录电量变化、传输量与连接失败情况。如果一次测试在充电、另一次处于低电量模式，或后台正在同步大量资料，结果就难以解释。更应关注是否存在持续异常活动，而不是追求几分钟内极小的百分比差。

Global Routing 会改变测试前提

Global Routing 的 Config、Proxy、Direct 分别对应配置、代理、直连姿态。使用 Config 时，规则可能让某个目标直接连接；使用 Proxy 进行对照时，仍需理解客户端对系统与特殊流量的处理边界；使用 Direct 则不能验证远端代理是否可用。比较前应确认同一个目标走的是同一类路径，否则测到的是路由差异，而非协议差异。

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

上面是规则顺序示例：目标域名属于 example.com 时使用 PROXY，指定私有网段使用 DIRECT，其余交给 FINAL。示例没有提供连接服务器，不能独立完成连接。规则按顺序匹配，前面的条件会影响后面的机会；修改规则前应确认当前启用的 Config，必要时参阅配置文件分段说明。

切换网络后为什么需要重新观察

从 Wi-Fi 切换到蜂窝网络时，本地地址、默认路由、DNS 和网络设备映射都可能变化。旧连接即便还显示为已开启，也可能需要重新建立传输路径。QUIC 或 WireGuard 的相关机制可以处理部分路径变化，但是否顺利还取决于双方实现与当前网络，不能承诺所有会话都连续保留。先等待路径稳定，再用新请求验证，比连续快速切换更容易判断。

On Demand 处理的是符合条件时的连接触发行为，不会修复错误密码、失效证书或不可达服务器。若在网络切换后反复连接，应把自动触发与协议重试分开观察，核对是否同时存在规则变化或网络尚未完成接入。Settings 中的相关设置说明可查阅功能与设置，避免为解决暂时断连而改变所有自动连接条件。

最后还要区分 IPv4 与 IPv6 路径。某个域名可能返回不同地址族，网络切换后使用的地址也可能改变。若只有部分目标失败，应检查解析结果、服务端出口与对应路由条件，而不是立即关闭某一种地址族。DNS 只能改变名称解析环节，不能自动修复证书、协议认证、服务器权限或目标服务本身的故障。

08 / SELECTION & DIAGNOSTICS

按场景选型与分层排错

先筛选可用条件，再比较体验

选型第一步不是给协议排名，而是确认你已有的服务器支持什么。只有一个有效配置时，应先把它配置正确；已有多种配置时，先排除认证不完整、安全层不明确和网络条件不满足的选项。剩余配置再根据常用任务比较。协议名称无法弥补服务端不可达、出口拥塞或错误路由，客户端也不能把一个服务端变成它未部署的协议。

用固定任务建立可重复比较

选择两三个你实际使用的目标，分别进行短请求、持续传输和需要时的实时任务测试。每轮保持同一网络、同一设备和相近时间段，确认目标走向一致，再更换已有配置。记录典型表现和失败次数，不要只保存最好的一次结果。若配置所在地区和服务器不同，应明确这是一场整体连接体验比较，不能声称只证明了协议性能。

对电量敏感时，应在稳定可用的前提下比较空闲维护与业务传输两种状态。经常失败重连的配置即使偶尔很快，也可能不适合长时间保持。对交互敏感时，更应观察负载期间的响应变化；对远程网段访问，则优先确认地址规划与权限。不同任务的权重不同，没有适合全部网络、全部设备与全部目标的固定协议顺序。

故障发生后按四层缩小范围

第一层检查本地网络：设备是否完成 Wi-Fi 接入，普通直连目标是否正常，网络切换是否结束。第二层检查服务器连接：Server 的解析结果、Port 和所需 TCP 或 UDP 路径是否可达。此时不要急着改 UUID，因为认证信息不能修复地址错误。若只在一个网络失败，应先保留配置不动，用另一网络做对照。

第三层检查安全与认证：TLS 名称、证书、设备时间，以及 Password、UUID 或密钥是否完整。若日志能区分握手和认证阶段，就按发生位置处理，不把所有错误都归为“连接超时”。第四层检查实际转发：Global Routing、当前 Config、目标 DNS、服务端权限、UDP 条件及回程路由。握手成功但目标失败，重点通常已经不在第一步的服务器端口。

更新、回退与问题记录

Subscribe 更新可能改变服务器字段或条目内容，手工修改不一定会被永久保留。更新前后出现差异时，应比较实际字段，而不是只看备注名称。不要把订阅地址直接粘贴到公开讨论中，其中可能包含访问凭据。排错记录保留协议类型、网络、失败阶段、目标类型和经过遮蔽的错误信息即可；私钥与完整认证内容不属于公开诊断所需资料。

如果一次修改没有改善，应恢复原值，再验证其他假设。需要继续求助时，提供“什么网络、什么目标、何时失败、已经排除什么”，比提供大量未整理截图更有效。首次导入问题可回到入门指南的完整操作主线；购买、重装与已购恢复问题请看下载指南，不要把商店获取问题与协议连接问题混在同一排错过程中。

最终应保留一份经验证可用的基线配置，并清楚知道它的协议、认证方式、安全层和路由姿态。理解这些边界，比记住某个参数组合更能应对环境变化：配置必须与服务端一致，测试必须对应真实任务，结论必须限定在实际观察到的网络条件内。