Shadowrocket 协议技术参考

01 / 选型框架

先分清协议、传输与路由

协议类型首先是兼容性条件，其次才是性能选择。服务器使用 Trojan，客户端就应选择 Trojan；把类型改成 Hysteria2，并不会使同一个端口自动接受另一种连接。订阅导入通常已经包含类型、地址、端口与认证信息，手动编辑应以服务端说明为依据。如果用户只有一组可用信息，首要目标是准确还原它，而不是在协议列表里寻找看起来更新的名称。

一条连接至少涉及四层条件

第一层是地址可达性，包括域名解析、目标端口与当前网络是否允许对应流量。第二层是传输方式，例如 TCP、基于 UDP 的 QUIC，或者承载在 TCP 上的 WebSocket。第三层是协议认证与加密，例如密码、UUID、TLS 证书或密钥。第四层才是应用目标与路由策略。前面一层失败，后面一层通常没有机会执行；因此，规则命中正确也不能证明服务器握手已经成功。

这些层次可以组合，但不能随意互换。VMess 或 VLESS 的某些部署会另外配置 TLS 与 WebSocket，Trojan 的常见部署依靠 TLS，Hysteria2 则以 QUIC 为基础。看到导入信息同时出现 Type、TLS、Host 和 Path，并不表示有四种协议需要选择，而是同一连接的不同条件需要同时满足。字段相同也不意味着含义相同，应按所属协议阅读。

速度、电量和隐私不是同一指标

速度至少包括首次连接耗时、小请求响应和持续吞吐。一个协议可能下载大文件很快，却因为握手、域名解析或链路绕行，让网页首屏较慢。电量还取决于无线信号、重传、后台保活和设备温度。不能把一次 Connectivity Test 的数字解释成全天体验，更不能从名称推导固定耗电排名。对比必须保持服务器区域、网络和测试任务基本一致。

加密范围也应单独理解。客户端到代理服务器的保护，并不等于代理服务器到所有目标网站都自动加密；网站本身的 HTTPS 仍然重要。服务器能够观察哪些连接信息，取决于协议、目标流量与 DNS 路径。本文讨论的是正确配置和可解释的性能，不把某种协议描述为适用于所有场景的隐私保证。

在 Shadowrocket 中保留可回退的基线

修改前记录节点所属订阅、当前 Type 与关键字段，并备份 Config。订阅条目可能在更新时被重新生成，直接改动后应确认是否会被覆盖；用于实验的副本要与日常条目区分。日志或截图里隐藏密码、UUID、私钥及订阅地址，分享排错信息时只保留字段名、错误阶段和经过处理的主机信息。先建立一个确认可用的基线，后续比较才有参照。

02 / 密码与加密方法

Shadowsocks：较短的配置链路

Shadowsocks 的设计起点是轻量的加密代理：在客户端与服务器之间建立受保护的转发，而不承担完整的虚拟网络管理。它通常需要地址、端口、密码与加密方法，配置链路相对直接。这里的“轻量”描述结构，不表示任何网络下都更快，也不表示所有 Shadowsocks 部署彼此兼容。双方对加密方法、扩展与 UDP 的支持仍需一致。

Method 与 Password 必须成对核对

Method 决定如何加密和认证数据，不是可按喜好切换的性能档位。服务端采用某个 AEAD 方法，客户端就要使用相同方法与密码。AEAD 同时提供加密和完整性验证，数据被改动或密钥不符时，连接可能直接失败，而不是显示一个清楚的“密码错误”页面。把握手中断直接归因于网络速度，会跳过最基础的字段核对。

不同方法对密钥材料的要求可能不同。有些采用普通密码派生密钥，有些要求特定长度并以特定编码表示的密钥，因此不能把所有 Password 都当成可任意替换的短语。复制时应避免多出换行、全角符号或首尾空格；若导入链接带有编码内容，应交给客户端解析，不要依据肉眼看到的字符串重新拼装。订阅能正常解析，也仍需确认服务器端参数没有变更。

TCP 可用不代表 UDP 已经可用

Shadowsocks 的 TCP 与 UDP 转发涉及不同的数据路径。网页能打开，只说明相应的 TCP 请求完成；语音、游戏或部分 DNS 请求仍可能因 UDP 转发条件不满足而失败。需要同时确认节点允许 UDP、客户端相关设置、服务器监听与网络放行。若当前任务没有使用 UDP，测试结果本身就不足以评价 UDP 能力。

还要区分“应用使用 UDP”与“协议通过 UDP 连接服务器”。某些代理协议可以把应用数据放进其他承载方式，两者并非一一对应。对于 Shadowsocks，排查时应具体记录是网页访问失败、UDP 业务失败，还是所有流量失败。只写“节点不能用”会把不同问题混在一起，降低后续定位效率。

在 iOS 上如何判断它是否合适

配置条件较少，意味着人工填写时需要核对的项目通常更少；但移动设备的体验仍受服务器负载和无线链路影响。设备具备适合相应算法的硬件能力时，加密开销可能较低，不过日常耗电往往更受持续传输、信号弱与重传支配。不要仅凭 CPU 算法讨论，忽略同一房间内蜂窝信号与 Wi-Fi 的差别。

若已有服务器支持明确的 Shadowsocks 参数，且目标是稳定使用常见 TCP 应用，可以先把它作为基线。出现长时间空闲后首个请求失败，应区分连接已被回收、域名解析变化和服务器状态，不要立刻更换 Method。若部署额外要求扩展功能，应核对当前客户端是否提供对应字段；缺少字段时向自己的服务提供方确认，而不是把其他协议的 Host 或 Path 生搬过来。

03 / 身份与承载分离

VMess / VLESS：类型相近不等于互换

VMess 将用户身份认证、代理请求与数据保护组织在同一套协议机制中，并允许结合不同传输方式。VLESS 则采取更精简的协议层设计，把连接保护更多交给外部安全层或相应部署方案。两者常使用 UUID 表示用户身份，容易让人误以为只改 Type 即可互换；实际上，服务端监听类型与配套传输必须匹配，相同 UUID 并不能解决协议不一致。

UUID 不是服务器地址，也不是传输设置

UUID 是识别用户的一项认证材料，应完整复制，不能因字符较长而删改。Address 和 Port 决定连接入口，UUID 决定请求使用哪组身份，而 TLS、WebSocket 等设置决定这组请求怎样被承载。排错时把它们分栏记录，可以避免不断重复粘贴 UUID，却没有检查实际连向了哪个端口。

VMess 的认证机制与时间有关，设备时间明显偏离会造成连接问题。应先启用系统自动设置时间并检查时区，而不是随意修改认证相关高级项。若订阅包含额外字段，应按服务器当前配置保留；从其他时期的教程复制默认值，可能造成导入能成功但连接失败。VLESS 也不是“省略认证”的模式，身份验证仍然需要，只是协议组织方式不同。

WebSocket 的 Host 与 Path 为什么重要

当服务器通过 WebSocket 接收请求，Path 往往参与入口路径匹配，Host 可能用于 HTTP 主机路由。Path 的大小写、前导斜杠和路径内容应与部署一致；Host 也不是填写任意网站域名就能提高速度的参数。如果服务端没有使用 WebSocket，开启它反而会把原本正确的连接变成不兼容的请求。

TLS 的 Server Name 通常用于服务器名称指示与证书名称验证，不能默认等同于 WebSocket 的 Host。两者在很多部署中相同，但作用层次不同。Address 可以是 IP，而 Server Name 仍是证书对应域名；也可能全部使用同一个域名。应依照服务端明确给出的组合填写，不因三处内容看起来重复就删除其中一项。

速度和电量需要按具体组合评价

“VMess 的速度”并不是一个独立常数。同一协议配合直接 TCP、WebSocket 或额外中间转发，握手次数与链路路径都可能不同。首次访问慢、连接建立后下载正常，通常更值得检查 DNS、TLS 和承载入口，而不是立刻判断加密算法拖慢吞吐。额外封装通常会增加一些字节与处理，但不必然在真实网络中形成最主要瓶颈。

VLESS 的协议层较精简，也不能据此保证更省电。若选用的服务器距离更远、无线网络重传更多，节省的协议处理可能完全被链路成本覆盖。比较两者时，应尽量使用相近服务器条件与相同应用任务，分别记录首次请求、连续访问和后台恢复。连接前后各测一次，无法代表全天使用情况。

导入后优先检查哪几项

在 Home 中打开对应条目的编辑页，依次核对 Type、Address、Port、UUID，再看传输方式、TLS、Host、Path 及服务端要求的其他项。每改一项就重新建立连接，避免旧会话掩盖结果。若同一订阅中的多个条目都出现认证失败，先确认订阅是否更新和设备时间是否准确；若仅某个入口失败，则优先检查该入口的独有路径与证书设置。

04 / 证书与身份

Trojan：把 TLS 条件核对完整

Trojan 的常见设计以 TLS 连接承载代理请求，再用密码识别用户。它借助成熟的 TLS 机制建立受保护的客户端到服务器链路，因此证书、名称与时间都是连接条件的一部分。配置看起来可能只有地址、端口与密码，但这不意味着 TLS 可以忽略；很多“密码正确仍连不上”的问题，实际上发生在密码被服务器处理之前。

理解 Address、Server Name 与证书

Address 用于定位服务器，Server Name 通常影响 TLS 的服务器名称指示与证书验证。服务器收到名称后，可能选择对应的证书和站点入口。客户端则需要确认获得的证书是否可信、是否在有效期内、是否覆盖目标名称。直接把 Address 改为 IP，却没有保留正确的 Server Name，可能导致连向正确机器却验证失败。

证书域名不匹配、证书链不完整、设备时间异常，都可能表现为 TLS 握手失败。排查时先读错误发生阶段：若尚未完成 TLS，就不要反复重设 Password。若 TLS 已通过而认证被拒绝，再检查密码、账户状态和服务端监听类型。错误信息不完整时，可以用同一条目在已知正常的网络下复测，判断是网络路径差异还是参数固定错误。

不要把跳过验证当成常规修复

证书验证用于确认服务器身份。跳过验证有时会使错误暂时消失，但也丢掉了这个判断条件，不能证明原配置已修好。若部署使用特定信任材料，应按服务端的可信说明设置；普通用户不应为了让连接按钮显示成功，就永久忽略名称或证书错误。记录具体报错、确认服务器证书配置，通常比绕过检查更有诊断价值。

连接复用和网络切换的影响

TLS 握手存在成本，但已经建立的会话与首次连接不能混为一谈。浏览器和应用会复用部分连接，系统也可能缓存域名解析结果，因此第二次打开页面往往比第一次快。这不自动说明某种协议做了特别加速。若需要比较，应分别记录冷启动与连续访问，避免拿一条新建会话对比另一条已经预热的会话。

iPhone 从 Wi-Fi 转到蜂窝网络时，源地址与原有连接状态会变化。对基于 TCP 的会话而言，已有连接通常需要重新建立，页面短暂停顿可能是正常恢复过程。On Demand 影响何时触发连接，不负责让所有旧 TCP 会话跨网络保持原样。持续出现无法恢复时，再检查系统网络权限、当前节点与应用是否正确发起重试。

适用条件与实际取舍

已有部署提供清楚的 TLS 名称、有效证书和密码时，Trojan 的核对路径比较明确，适合作为常见网页与应用流量的候选。它不因使用 TLS 就天然比其他方案更快，也不因握手存在就一定更耗电。弱信号下持续重连、服务器端拥塞和后台保活，都可能比一次握手造成更大的实际消耗。

如果只有少数应用失败，应继续按应用需求分解，而不是立即更换协议。某些应用需要 UDP，某些依赖不同 DNS 结果，还有些请求根本被 Rule 送往 DIRECT。先证明请求确实经过这个 Trojan 条目，再讨论服务器是否支持相应业务。对于连接超时的通用顺序，可参阅延迟测试、协议参数与系统时间排查。

05 / 通用代理接口

HTTP / SOCKS5：转发能力与加密边界

HTTP 代理起源于应用层转发需求，常见于浏览器和组织网络；SOCKS5 则提供较通用的代理协商与转发机制。两者的优势是接口明确、适用软件较多，而不是默认提供完整加密。选择时必须问清：客户端到代理入口是否另有 TLS 或可信网络保护，认证方式是什么，以及是否需要转发 UDP。仅有用户名和密码，并不能回答这些问题。

HTTP CONNECT 不等于代理链路加密

HTTP 代理可以接收普通 HTTP 请求，也可以通过 CONNECT 建立到指定目标的隧道。访问 HTTPS 网站时，网站 TLS 通常在该隧道内建立，但客户端与代理之间的协商是否加密，是另一个条件。目标网站使用 HTTPS，不代表代理认证信息在所有连接方式下都获得同样保护。应区分网站的 TLS 与连接代理入口时使用的 TLS。

若服务端明确提供受 TLS 保护的 HTTP 代理入口，需要按其地址、端口、证书名称及认证信息设置，而不是只因为网站地址以 HTTPS 开头就勾选相关选项。反过来，普通 HTTP 代理入口也不会因客户端随意启用 TLS 而自动升级；双方不一致时，常见结果是握手失败或连接被关闭。

SOCKS5 的认证、DNS 与 UDP

SOCKS5 可协商认证方式，并支持以域名或 IP 指定目标。域名究竟由本地解析还是交给代理端处理，会影响解析结果和故障位置，但实际路径还受到 Shadowrocket 的 DNS 设置与路由行为影响，不能只看协议名称。排查时应核对请求携带的是域名还是 IP，以及日志所显示的解析与转发顺序。

SOCKS5 标准包含 UDP ASSOCIATE，但不是每个服务器、账户或网络都提供可用的 UDP 转发。控制连接建立成功，不保证后续 UDP 端口在当前网络中可达。普通 HTTP CONNECT 通常用于 TCP 隧道，也不应被当作通用 UDP 能力。对语音和实时业务，需要按照实际服务端功能验证，而不是从“支持代理”四个字推导支持范围。

在移动设备上的使用判断

如果用户已有组织网络提供的 HTTP 或 SOCKS5 入口，优先依照管理说明配置，不应为了协议名称不同而自行替换。移动网络经常切换，组织入口也可能只允许特定来源网络；在办公室 Wi-Fi 可用而蜂窝网络不可用，不一定是客户端填错密码。需要核对入口开放范围、地址解析和认证条件，再比较协议处理开销。

这类接口本身的协商可能较简单，但真正速度仍取决于服务器与目标之间的连接。代理入口离设备很近，却需要绕行到较远出口，仍可能造成较长响应。电量方面也没有“协议不额外加密就一定更省”的结论，持续断线重试会带来额外唤醒，错误的保活策略可能抵消较少的计算工作。

若认证失败，依次检查服务端要求的认证方式、用户名格式、密码与账户权限。若只有域名目标失败而 IP 目标正常，则转向 DNS 路径排查；若只有 UDP 业务失败，检查转发能力与网络端口。将这三种分支分别记录，通常比频繁切换 Global Routing 更容易找到原因。

06 / 三层隧道

WireGuard：密钥、地址与路由一起看

WireGuard 的设计目标是建立结构较精简的三层加密隧道，围绕对等端公钥识别身份，并通过 UDP 承载 IP 数据。它与按请求转发的应用代理思路不同，因此需要额外理解隧道地址、对等端与路由范围。在 Shadowrocket 中使用时，还要区分 WireGuard 对等端配置和客户端自身的 Rule，两套判断作用于不同层次，不能把其中一套视为另一套的替代品。

Private Key 与 Public Key 的方向

Private Key 属于当前对等端，应保密保存；Public Key 可以提供给需要识别它的另一端。客户端配置里的对端 Public Key 应指向服务器，而服务器则需要认识客户端的 Public Key。把两边公钥填反，或者修改私钥后没有同步对应公钥，会使握手无法建立。密钥字符串不是普通密码，不能凭长度相近就互换。

若配置包含 Preshared Key，它是双方另外共享的认证材料，需要两端一致。Endpoint 表示远端可访问的地址和端口，不是隧道内部地址。接口 Address 表示设备在隧道中的地址，也不应直接照抄 Endpoint。服务器可能还会限制某个对等端允许使用的来源地址，因此“握手成功但数据不通”仍有必要检查地址分配。

Allowed IPs 与 Rule 各自负责什么

Allowed IPs 在 WireGuard 体系中参与对等端选择及接收来源约束，其含义与普通代理的域名规则不同。客户端集成方式还会决定哪些流量进入该隧道，所以不能看到全网段就认为 Shadowrocket 的所有请求必然走它。先看 Global Routing 与 Rule 选择了什么策略，再看被交给 WireGuard 的流量是否符合对等端配置。

如果隧道需要访问内部网段，应确认这些网段没有与当前 Wi-Fi 的本地地址冲突。相同的私有地址段可能同时存在于家庭网络和远端网络，路由判断就会产生歧义。调整时应依据实际拓扑，不要简单把所有本地网段都送往远端；否则局域网设备访问和本地 DNS 都可能发生变化。

Keepalive 与移动网络的电量取舍

Persistent Keepalive 用于帮助维持 NAT 映射，不是提高下载速度的开关。需要由外部主动访问、或者网络对空闲映射回收较快时，它可能有用；但更频繁发送保活，也会使无线模块有更多活动机会。对只在前台发起请求的使用方式，不应在没有证据时把保活设得非常频繁。应先确认是否真的存在空闲恢复问题。

WireGuard 支持根据有效认证数据更新对端地址，能适应一定的地址变化，但不意味着所有上层应用会话都能毫无停顿地跨网络延续。Wi-Fi 与蜂窝切换后，新的 UDP 路径是否可达、NAT 映射是否更新、应用是否重新尝试，都影响恢复。先观察握手与收发情况，再判断是隧道层还是应用层停住。

MTU 不是越大越好

隧道封装会占用额外字节，实际路径允许的报文大小又可能小于本地接口上限。MTU 不合适时，可能出现小请求正常、大响应卡住，或某些网站反复加载。先排除服务器负载和丢包，再按部署说明进行有记录的调整；一次只变一个值，并用同样任务复测。不要照抄不同网络的数值，也不要把所有大文件变慢都归为 MTU。

若已有完整 WireGuard 配置，且用途包含明确的隧道网段或长期连接，可以按原配置建立基线。若只有一条普通代理订阅，则不能凭空推导出密钥、接口地址和路由。选择依据是服务器实际能力与任务模型，而不是把“三层隧道”理解为一定比应用代理更高级。

07 / QUIC 与拥塞控制

Hysteria2：先确认 UDP 路径

Hysteria2 基于 QUIC 构建代理传输，关注有丢包、较长往返时间等条件下的连接表现。QUIC 运行在 UDP 之上，并集成基于 TLS 的安全握手与多路流传输。这种设计提供了不同于单条 TCP 字节流的处理方式，但收益取决于真实网络条件。若当前网络不允许相应 UDP 流量，再好的拥塞控制也无法替代基础可达性。

多路流减少哪类等待

在一条 TCP 连接里，前面丢失的数据需要补齐，后面的字节才会按序交付。QUIC 可以让不同流的数据交付相对独立，减少跨流的顺序等待；但同一条流仍需要满足其可靠传输要求，而且不同流依然共享底层网络容量。不能把“多路流”理解成不受丢包影响，更不能据此保证所有网页都会更快。

QUIC 还需要加密、拥塞控制和报文处理，移动设备上的计算与唤醒成本取决于实现和任务。弱信号下重传多，电量可能增加；某些高吞吐任务完成得更快，也可能缩短持续传输时间。因此应分别比较短请求、长下载与待机恢复，而不是只看一次下载峰值就得出全天省电结论。

认证、TLS 与混淆字段分别核对

Hysteria2 条目通常包含服务器地址、端口、认证信息以及 TLS 相关条件。Server Name 应与服务端证书及入口设置相符；密码或认证字符串需要原样保留。如果部署另外使用混淆设置，客户端与服务器的类型和密码也必须一致。混淆不是在任何服务端上都可自行开启的增强项，双方不一致会直接影响通信。

协议代际也必须匹配。名称接近的不同代际不代表认证格式与握手相同，不能仅通过修改显示名称完成转换。优先使用服务端提供的可导入信息，并检查导入后的 Type 是否确实对应 Hysteria2。若订阅解析后出现不认识的字段，不要删除它们来换取“看起来干净”的配置，应先确认字段用途与客户端支持情况。

带宽参数不是购买到的速度

如果配置暴露上行、下行或拥塞控制相关项，要先阅读该字段实际单位与作用。有些设置用于向算法表达带宽预期，并不增加物理容量。报得过高，可能让发送行为超过链路承受能力，导致排队、丢包或其他应用体验变差；报得过低，则可能限制吞吐。服务端的限制和当前网络瓶颈仍然存在。

移动网络可用带宽会随信号、位置与拥塞变化，适合固定宽带的参数不一定适合蜂窝环境。遇到下载快但网页响应变差，应观察是否在持续占满带宽，而不是继续调高数字。对重视实时响应的任务，稳定的排队延迟往往比峰值吞吐更重要；协议选型应围绕实际任务，而非测速界面的一项结果。

失败时先区分路径与认证

若同一设备在某个 Wi-Fi 下无法连接、换蜂窝后立即正常，优先检查 UDP 路径与网络策略；若两个网络都在相同握手阶段失败，再检查类型、认证、证书与系统时间。若连接后大传输异常，则继续观察丢包、服务器负载与报文大小。保留现象和每次变更，才能判断 Hysteria2 是否适合当前环境，而不是把偶发成功当作稳定可用。

08 / 实测与决策

用同一任务比较，再按层次排错

协议选型的最终依据，是同一设备在真实任务里的可重复表现。先确认候选条目参数正确、服务器状态正常，再分别测试网页首屏、连续访问、长传输与空闲后恢复。每轮只改变协议或节点中的一个主要条件，并记录网络、信号与测试任务。不同地域、不同负载的服务器不能直接用来证明某种协议天然更快。

Global Routing 与协议类型分开设置

Global Routing 的 Config、Proxy、Direct 决定请求如何选择路径，不改变服务器协议。Config 按当前配置规则分流；Proxy 用于将适用流量交给代理策略；Direct 用于直接连接。临时用 Proxy 对照可以帮助排除某些规则影响，但不能理解为所有系统流量、所有局域网例外和所有 DNS 行为都被统一改写，仍要结合实际设置与日志。

下面只是独立的 Rule 语法示例，不是可直接替换现有文件的完整配置。规则自上而下判断，FINAL 处理此前未命中的请求；这里的 PROXY 表示代理策略，DIRECT 表示直接连接。修改前应备份 Config，并确认所用策略在当前配置中有效。

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

规则匹配与 DNS 存在联系：IP 类规则需要相应目标地址信息，域名规则则依赖请求保留可匹配的域名。若日志显示某请求走了 DIRECT，先检查 Rule 顺序，不要据此评价代理协议性能。更多匹配对象与顺序说明见规则关键字入门。

建立四类测试记录

第一类记录连接能否建立及失败阶段；第二类记录相同小请求的响应稳定性；第三类记录持续传输是否出现明显波动；第四类记录锁屏、解锁和网络切换后的恢复。Connectivity Test 可作快速线索，但测试目标和方式不等于所有应用。偶尔的低延迟不能覆盖连续请求失败，单次超时也不足以证明服务器永久不可用。

电量比较需要相近亮度、信号、温度、应用和传输量，并观察足够长的使用区间。系统电池统计可能把部分开销归给前台应用或网络相关进程，因此不应只盯住 Shadowrocket 的百分比。设备发热时先排除大文件持续传输与弱信号；不要在没有稳定测试条件时给协议排出精确耗电名次。

按失败阶段缩小范围

完全超时，先检查地址、端口、网络可达性与 TCP / UDP 条件；出现 TLS 错误，检查名称、证书与系统时间；认证拒绝，检查密码、UUID 或密钥方向；连接建立后仅部分应用失败，再看 DNS、Rule、UDP 能力和目标服务。每轮只修改一项，重新连接并重复同一任务；无法改善时回到基线，避免错误叠加。

日常网页使用先考虑已有配置的完整性与稳定性；明确需要 UDP 的应用先核对端到端能力；内部网段任务核对隧道地址与路由；高吞吐任务再比较持续表现。仍无法定位时，带着经过隐藏敏感信息的现象记录查阅FAQ，需要重新建立操作主线则返回入门指南，不要以频繁切换协议替代分层检查。