Shadowrocket 协议参考

协议、传输与路由的分工

先辨认配置描述的是哪一层

选择协议前，先把一条连接拆成几个相互独立的部分：服务器地址决定连接发往哪里，端口决定访问哪个监听入口，协议决定双方怎样识别请求及校验身份，传输方式决定这些数据如何承载，路由则决定哪些请求使用这条连接。把这几层混在一起，容易出现“地址和密码都正确，却仍然无法使用”的情况。正确的核对单位是整套参数，而不是节点名称中的某个协议缩写。

例如，同样选择 VLESS，服务器可能要求不同的传输方式、TLS 条件和附加参数。类型名称一致，只说明双方尝试使用同一类请求格式，不代表连接细节已经一致。订阅导入通常能够保留更多字段，但也应检查导入结果。遇到客户端无法识别的参数，先确认当前应用实际提供的选项，再向已有服务器的管理方核对，不要自行把字段替换成看起来相近的名称。

速度与电量没有脱离环境的排名

协议设计会影响握手次数、数据封装和重传行为，但最终速度还受服务器负载、往返时间、丢包、无线信号和目标网站影响。短网页更容易暴露握手与解析开销，长文件传输更容易受到拥塞控制和可用带宽限制。一次延迟结果只能反映某种测试条件下的响应，不能替代完整访问测试，更不能推导出全天候吞吐量。比较时应保持设备、网络、目标和测试时段尽量一致。

在 iPhone 和 iPad 上，电量变化也不只是加密算法的结果。蜂窝网络信号较弱、连接频繁重建、持续后台传输、过密的保活，以及长时间开启详细日志，都可能增加消耗。若某个配置在稳定网络上表现正常，切换网络后却不断重新连接，应先查连接状态和保活条件，而不是立即认定协议本身耗电。电池设置中的统计还会受到观察区间内其他应用活动的影响。

协议参考不替代服务器说明

本文说明字段的作用，不能从字段作用反向猜出有效值。地址应来自用户已有信息，认证内容必须与服务器一致，传输扩展也需要两端同时支持。修改前建议记录原始设置，并为试验保留一个可辨认的副本。一次只改变一个变量，才能判断改动与结果是否相关；同时更换协议、DNS 和规则，即使恢复连接，也很难知道真正原因。

系统添加 VPN 配置的授权用于允许客户端建立本地网络处理通道，并不替用户填写远端服务器信息。系统显示已连接，也不等于远端认证、DNS 和目标访问全部成功。若停在授权阶段，先阅读VPN 配置提示说明；若已经连接但无法访问，应按后文顺序拆分问题，避免把系统授权问题误判为协议选型问题。

Shadowsocks：精简结构与加密参数

设计重点是加密转发

Shadowsocks 的设计出发点是用相对精简的协议结构转发应用流量，在客户端与服务器之间对数据进行加密和认证。它不是把整张远端网络直接搬到设备上的完整网络层隧道；用户在 Shadowrocket 中看到的系统 VPN 通道，与远端采用 Shadowsocks 是两个层次。前者负责接入设备流量，后者负责客户端和服务器之间的数据交换，理解这点有助于区分本地路由与远端协议。

“结构精简”不等于所有配置都相同。不同加密方法对应不同的数据格式和密钥要求，附加的传输扩展也会改变实际连接方式。普通配置与使用插件或其他扩展的配置，不能只复制服务器地址和密码就互换。手动添加时，应逐项确认当前应用是否支持服务器要求的组合；若原始信息来自订阅，应先保留导入的完整设置，不要为了让页面更简洁而删除未知字段。

密码与加密方法必须成对核对

基本字段包括服务器地址、端口、密码与加密方法。加密方法不是“越长越安全”的自由选择项，而是两端必须一致的协议约定。服务器采用一种方法，客户端改成另一种，即使密码完全相同也不能正常解密。某些较新的方法要求特定长度和编码形式的密钥，此时不能把日常使用的任意字符串当成等价密码。应保留原始大小写、符号与编码，不手工补空格或删除结尾字符。

如果订阅更新后突然失败，先查看类型和加密方法是否发生变化，再核对原有配置是否被更新覆盖。复制密码时，聊天工具的换行、富文本空格或选区遗漏都可能造成差异。地址与端口可达只能说明网络入口存在，不能证明密码正确；部分错误表现为连接后立即断开，另一些表现为持续等待。因此，错误发生的阶段比界面上的单个超时提示更有分析价值。

分别验证 TCP 与 UDP

常见网页访问通常能覆盖一部分 TCP 使用情况，但不能证明 UDP 已经可用。实时音视频、某些 DNS 查询及其他应用可能依赖 UDP，是否能够转发还取决于服务器能力、客户端配置和路径条件。若网页正常而实时应用失败，应单独检查这条路径，不要只重复网页测速。反过来，某个使用 UDP 的应用正常，也不足以证明所有域名解析和 TCP 请求都符合预期。

在设备上比较 Shadowsocks 配置时，优先看持续连接是否稳定、短请求是否频繁等待，以及网络切换后是否能够恢复，而不是只看一次大文件速度。硬件对算法的加速能力、实际吞吐量和数据量会共同影响处理开销。稳定、参数明确且已经得到验证的已有配置，通常比未经核实地追求某个算法名称更适合作为基线；性能问题应通过重复测试确认。

遇到“测试有响应但网页失败”，按地址解析、认证、UDP、规则命中和目标站点逐层检查。若只有部分域名异常，可进一步阅读DNS 排查说明。不要通过反复切换加密方法处理解析问题，也不要把跳过某项检查当作长期修复。只有当字段来源、两端支持情况与错误阶段都明确后，修改才具有可解释性。

VMess 与 VLESS：认证和传输分别核对

相近的字段不代表相同协议

VMess 在协议中包含用户身份识别、请求组织与数据保护相关机制；VLESS 则采用更精简的请求与认证结构，基础协议本身不提供同样的数据加密功能，通常需要配合合适的安全传输。二者可能都出现 UUID，也可能都搭配 TLS 或 WebSocket，但这些共同点并不意味着可以直接互换类型。服务器提供 VMess 时，客户端选择 VLESS 并保留 UUID，仍然会产生协议不匹配。

理解二者背景时，重点应放在职责分配：有的协议把更多机制放在自身内部，有的把数据保护交给外层安全通道。字段较少并不自动意味着更快，字段较多也不自动意味着更可靠。实际连接还受传输层数、握手路径、服务器实现和网络条件影响。选型时，应先确认用户已有服务器支持什么，再比较可用组合，而不是先选一个名称，再尝试让所有字段迁就它。

UUID 之外还有一组传输约定

手动添加时，先核对类型、地址、端口和 UUID，再检查传输方式与安全设置。UUID 是身份标识，不是服务器地址，也不能替代密码型协议的认证字段。某些 VMess 配置还涉及额外认证或加密相关选项，应以原始配置要求为准，不为迎合旧教程随意补值。设备时间明显不准确时，认证或证书验证也可能受影响，可先检查系统日期与时间是否正常。

若采用 WebSocket，路径和请求头中的 Host 是独立参数。路径通常需要保留前导斜杠及大小写，不能把域名填进路径栏，也不能把整条网页地址当作 Host。使用 TLS 时，SNI 参与服务器名称协商与证书验证；连接地址、Host 和 SNI 可以因部署方式而不同，但这种差异必须由现有配置明确给出。三者不是为了“看起来统一”就应被改成相同值。

把失败定位到具体阶段

入口超时首先指向地址、端口或路径可达性；TLS 错误应先看名称、证书链和设备时间；握手后立即结束则需要继续检查身份与协议字段。如果服务器前还有转发入口，错误也可能发生在入口与后端之间。此时客户端反复修改 UUID 并不能解决入口路径不匹配。记录测试时间、网络类型和错误摘要，通常比连续改动多个字段更便于定位。

在 iOS 上，多层传输可能增加首个请求的等待，也可能因复用连接减少后续握手，两种影响需要结合实际负载判断。不能把“开启复用”当作通用提速开关：多请求共享同一底层连接时，丢包或连接故障可能同时影响多个请求。若当前配置提供相关选项，应先确认服务端支持，再用同一组网页和持续传输分别验证，不凭单个测速结果决定。

已有订阅能够正常导入时，建议先以导入结果建立基线，再逐项阅读字段含义。遇到未知的流参数、安全扩展或传输类型，不要省略后继续连接，也不要默认客户端已经支持。保留原始信息，核对应用内实际选项，再决定是否需要向服务器管理方确认。完成协议核对后，仍需按入门指南验证 Global Routing 与实际请求，认证成功并不等于分流正确。

Trojan：TLS 身份与密码认证

安全通道与代理请求各有职责

Trojan 的基础设计把代理请求承载在 TLS 连接中，利用成熟的安全通道处理传输保护，再通过协议内的认证内容识别用户。理解时可分两步：先与服务器建立可信的 TLS 连接，再由服务器识别代理请求及用户身份。第一步成功不代表第二步必然成功，因此“证书正常”和“密码正确”是两项独立检查。把它们合并成一个开关，会让排错失去方向。

服务器地址可以是域名，也可以根据现有部署使用其他明确入口，但 TLS 校验所依据的名称仍需正确。SNI 用于告诉服务器客户端请求哪个名称，证书则需要能够证明该名称的身份。若连接地址与证书名称不同，应按已有配置填写相应字段，而不是删除 SNI 试图绕过问题。地址负责找到入口，名称负责验证身份，两者用途不同，不能互相替代。

核对证书时不要只看是否过期

证书问题还可能来自名称不匹配、证书链不完整、设备时间异常或服务器部署错误。只观察有效期不足以判断整个验证过程。遇到相关报错，应先查看设备时间，再确认填写的服务器名称与配置要求一致，最后由服务器管理方核对证书部署。关闭证书验证会改变信任边界，不能证明服务器身份，也不应当被当成修复密码、路由或解析错误的办法。

密码应完整保留原始字符，尤其注意复制时带入的换行与空格。显示名称可以自行修改，但密码、端口和协议类型不能因为名称变化而跟着猜测调整。若 TLS 已建立但认证失败，应先核对密码及服务器提供的实际协议类型。基础 Trojan 与带额外传输扩展的配置并不是只差一个备注，使用扩展时仍需两端同时支持，并填写对应的路径或其他约定。

握手成本要结合连接复用观察

首次连接通常需要完成网络连接和 TLS 握手，远距离、高丢包或网络切换会放大等待时间。后续请求是否复用底层连接，取决于实际实现与配置，不能仅凭协议名称推断。比较时可分别观察首次打开网页、连续访问和持续传输。如果只有第一次较慢而后续正常，优先分析解析与握手；若持续传输也反复停顿，则继续检查路径质量和服务器负载。

对 iPhone 电量而言，TLS 加密不是唯一变量。若应用不断发起短连接，或连接失败后持续重试，无线模块和系统网络处理都可能增加活动时间。应在相同网络和相近数据量下比较，并区分屏幕点亮、后台等待与实际传输。不要把一次长时间视频播放后的电量变化，直接拿来与几分钟静态网页浏览对照；不同使用负载无法形成有效结论。

当网页出现证书警告时，还需辨认警告来自哪一层：是客户端连接服务器时报告 TLS 失败，还是浏览器访问目标网站时出现证书问题。前者应检查当前连接参数，后者还可能涉及目标站点、设备时间或其他网络设置。不要看到“证书”两个字就修改 Trojan 密码。记录报错位置与发生时间，往往能快速把两类问题分开。

适合保留 Trojan 的情况，是现有服务器提供完整、可验证的 TLS 配置，认证字段明确，且实际访问表现稳定。它并不会因为使用 TLS 就自动优于其他方案，也不能保证每条网络路径都能正常工作。如果已有配置此前正常、最近才出现名称或证书错误，应优先检查部署变化，而不是立刻更换协议；购买与应用更新问题则应另查疑难解答。

HTTP 与 SOCKS5：通用代理的边界

两类通用接口解决不同问题

HTTP 代理最初围绕 HTTP 请求转发形成，常见的 CONNECT 方法则允许建立面向指定目标的字节通道。SOCKS5 是更通用的代理协商协议，定义目标地址、连接命令和可选认证流程，不要求上层内容必须是网页。二者都常作为现有网络环境中的标准接口，但“通用”描述的是接口用途，并不意味着所有实现支持全部命令、所有认证方式或所有应用流量。

HTTP 代理中的目标网站 HTTPS，与客户端到代理服务器之间是否加密，是两个不同问题。通过 CONNECT 访问 HTTPS 网站时，网站会话可以保持自身的 TLS 保护，但代理连接本身仍需按其实际类型判断。SOCKS5 基础协议同样不自动提供数据加密，用户名与密码认证也不等同于加密通道。因此，不能仅因网页地址显示安全标识，就认为代理这一段的所有元数据都已得到相同保护。

认证方式与目标解析要分开确认

添加已有 HTTP 或 SOCKS5 信息时，先核对服务器地址、端口、是否要求认证，以及当前应用支持的对应方式。部分入口不使用账号密码，部分则必须同时填写用户名与密码，二者不能靠留空试探来长期使用。若已有说明指定的是受 TLS 保护的代理入口，还应确认客户端所选类型与安全选项相符，不能把一个普通 HTTP 字段直接当作所有安全代理形式的代称。

域名由哪一端解析，会影响访问结果和错误定位。SOCKS5 可以表达域名目标，但实际请求是否把域名交给远端，仍与客户端解析和路由处理有关。HTTP CONNECT 的目标也可能以主机名或地址表示。若远端能够解析、设备本地却解析失败，切换解析位置可能改变表现，但应先理解当前配置，再进行验证。不要仅凭协议支持域名，就断言所有请求必然由远端解析。

网页可用不等于完整业务可用

普通 HTTP CONNECT 通常面向 TCP，不能据此推导出 UDP 应用可用。SOCKS5 定义了 UDP 相关机制，但不少部署只开放 TCP，或者 UDP 返回路径受到网络条件限制。若聊天文字正常而通话失败，应按业务使用的传输继续检查。反复更换网页目标只能验证网页访问，不会补齐缺失的 UDP 能力，也不能证明应用的所有请求都经过同一条路径。

这两类协议的处理结构可能较直接，但是否省电、是否更快，仍取决于加密层、连接寿命、网络质量和服务器实现。较少的协议字段不会自动减少蜂窝网络活动；如果认证不断失败、入口频繁断开，实际体验反而可能较差。在 iOS 上应观察连接重试、目标访问和后台行为，而不是仅以“标准协议”作为性能判断依据。

当用户已有的办公或测试环境明确提供这类入口时，可按其能力边界使用；若需要传输敏感数据，应同时确认目标应用自身的加密与代理链路保护。出现认证拒绝时先查账号字段，连接建立后目标不可达则继续查解析和远端访问权限。不要通过任意变换协议类型解决权限问题，也不要在求助记录中公开账号密码。相关操作入口见首次添加与连接步骤。

WireGuard：网络层隧道与密钥关系

从请求转发转向地址与对端

WireGuard 面向加密网络层隧道，使用固定的现代密码套件与公钥身份模型，设计上尽量减少协议选项和握手复杂度。与主要描述某个目标连接的代理协议相比，它更强调本地隧道地址、对端身份、端点和可达网段之间的关系。在 Shadowrocket 中使用时，仍需由客户端组织设备流量与该连接的关系，不能把其他环境中的完整路由行为直接假定为这里的实际行为。

它的配置看起来字段不多，但每个字段都承担明确职责。端点地址用于在现实网络中找到对端，隧道地址用于描述隧道内部的本地身份，公钥用于识别对端，私钥用于证明本端身份。端点地址与隧道地址往往不是同一类地址，不能互换填写。若把服务器公网地址填进本地隧道地址栏，即使端口正确，也会造成地址与路由关系错误。

密钥应按所属端辨认

本端私钥必须保密，对端公钥用于确认连接对象，二者不是一对可以任意交换的位置参数。若配置包含预共享密钥，它是额外的密钥材料，需要双方保持一致，不能用对端公钥代替。导入后遇到握手失败，应先核对密钥归属和端点，再查网络可达性。重新生成本端密钥会改变身份，若服务器仍只接受旧公钥，客户端单方面更换就无法恢复原有连接。

Allowed IPs 在 WireGuard 的语境中参与对端地址范围与加密路由关系，既不只是备注，也不能简单理解为设备上最终生效的全部分流规则。Shadowrocket 的 Global Routing 与 Config 还会影响流量如何进入所选连接。若隧道握手正常但某些地址不可达，应同时核对隧道地址范围、远端转发条件和客户端路由，不能只看最后一条规则就断言远端一定可达。

握手、MTU 与保活各查一层

WireGuard 使用 UDP，网络能访问普通网页，不代表端点所需的 UDP 路径畅通。若一直无法完成握手，应先查端点域名、端口、密钥与路径条件。若握手已经发生、少量数据正常、大页面或上传却卡住，则可继续排查 MTU。隧道封装会占用额外空间，路径上的报文大小限制若不能被正确处理，就可能表现为部分请求成功、较大传输停顿。

MTU 不宜从其他人的设备上照搬一个固定数值。应先记录现有值，再在可控条件下逐步验证，并观察网页、上传和持续传输是否同时改善。降低 MTU 可能避开分片问题，但也会增加相同数据量所需的报文数量，不是越小越好。只有当症状与报文大小有关、调整后能够重复改善时，才有理由保留修改；身份错误不可能靠 MTU 修复。

Persistent Keepalive 一类保活设置用于维持某些网络设备上的映射关系，但发送间隔会影响后台网络活动。只有在已有环境确有需要时才设置，不应为“更稳定”而一律采用很短间隔。蜂窝与 Wi-Fi 切换后，对端能否及时学习新的网络位置，也需要实际验证。在 iPhone 上，持续保活、弱信号与频繁切换可能比协议运算本身更明显地影响电量。

适合使用的前提是用户已有完整且相互匹配的对端配置，并清楚需要访问的地址范围。验证顺序应从握手到隧道内地址，再到域名和实际业务，不把一次握手成功当作全部完成。若域名失败但地址访问正常，转向 DNS；若仅特定网段失败，检查路由和远端转发；若休眠后恢复异常，再观察映射与保活。这种分层顺序比同时更换密钥和路由更容易得出结论。

Hysteria2：QUIC、带宽提示与路径条件

基于 UDP 的传输取舍

Hysteria2 基于 QUIC 组织传输，利用其安全握手与多流能力，并围绕高延迟、丢包等网络条件提供相应的传输设计。它的目标不是让所有网络都达到相同速度，而是在特定路径上采用不同于传统 TCP 承载的控制方式。QUIC 使用 UDP，因此网络入口和中间路径对 UDP 的处理，会直接影响是否能够连接。普通网页可用，不能作为此类路径已经畅通的证据。

理解多流时，需要区分流之间的传输独立性与共享资源。某个流的数据等待，不必像单一有序字节流那样阻塞所有其他流的交付，但这些流仍共享底层路径、拥塞控制和可用带宽。无线信号恶化或入口受限时，多流不会创造额外容量。若许多请求一起变慢，应先观察整条路径，而不是认为每个目标网站都同时发生故障。

认证、TLS 与附加参数分别核对

基本核对顺序是协议类型、服务器地址、端口、认证内容与 TLS 名称。Hysteria2 与名称相近的其他协议形式不能直接互换，客户端类型必须与现有服务器一致。认证字段应完整保留原始格式，SNI 与证书要求也要分别确认。若已有配置包含额外处理选项，只有在当前应用确实提供对应能力、服务器也使用相同设置时才填写，不能按字段名称猜测值。

带宽相关字段尤其容易被当成测速结果。它们在适用的拥塞控制方式下可以作为发送行为的参考或限制条件，并不意味着客户端承诺达到填写的数值。上传与下载还可能采用不同单位或填写约定，应以当前字段说明和已有配置为准。把数值填写得很高，不能突破接入带宽和路径容量，反而可能带来排队、丢包或对其他业务的干扰。

性能测试需要同时看交互与吞吐

持续下载速度较高，并不等于浏览网页、语音通话和后台同步都会更好。应在传输进行时观察其他请求的响应，判断是否出现明显排队。测试时不要只挑选一次最好的结果，也不要用不同目标和不同网络下的数据比较协议。先建立一个保守、可重复的基线，再检查调整带宽相关参数后，吞吐与交互是否同时改善，或只是其中一项发生变化。

在 iOS 设备上，QUIC 的处理、较高数据吞吐和持续无线活动都可能增加功耗，但不能仅凭使用 UDP 就给出固定耗电结论。同一时间内下载更多数据，往往会让设备更热；若比较的目标数据量不同，这种结果不能证明协议效率更低。应分别比较相同数据量完成所需时间，以及相同使用时长下的后台活动，结合信号和屏幕状态解释。

如果 Wi-Fi 正常而蜂窝网络始终连接失败，优先验证两种网络对 UDP 的实际支持，不要先改认证内容。若只有网络切换后短暂异常，观察重连是否恢复；若持续失败，再检查日志中的阶段。某些错误可能来自路径报文大小、服务器资源或入口限制，需要与现有服务器管理方核对。客户端界面的单个超时无法独立说明是哪一层拒绝了请求。

适合继续使用的条件，是已有服务器明确支持 Hysteria2，当前应用能够表达完整参数，且目标网络中的重复测试显示稳定收益。它不是必须替换所有现有配置的选项。若已有 TCP 承载方案已经满足业务，而当前网络的 UDP 表现不稳定，保留经过验证的配置更便于使用。选型结论应随使用场景变化，而不是随某个协议名称的新旧变化。

按场景选型与分层验证

先满足配置约束，再比较体验

实际选型从用户已有信息开始：确认服务器支持的协议、必填参数和目标业务，再看当前网络是否具备所需的 TCP 或 UDP 条件。普通网页、长时间传输、实时应用与远端网段访问，对握手、吞吐、抖动和路由的关注点不同。没有一项指标能够覆盖所有业务。先筛去字段不完整或路径条件不满足的组合，再比较剩余配置，比逐个尝试所有类型更有效。

日常网页使用可优先保留稳定、参数明确、首次打开响应可接受的已有配置；实时业务还应单独验证 UDP、抖动和连续性；访问远端网段则要确认地址范围与返回路径。若多种配置都可用，使用同一设备、网络和目标重复观察，不同时修改 DNS、规则和传输。测试结果只代表相应场景，不宜扩展成某协议在所有设备上的普遍结论。

Global Routing 决定请求怎么走

协议正确仍可能因为规则而走错路径。Config 按当前规则决定处理方式，Proxy 可用于临时缩小规则因素的影响，Direct 则用于观察原始网络。切换姿态只是诊断手段，不是自动修复。若 Proxy 下正常、Config 下失败，应优先检查规则、策略名称与 DNS，而不是重新填写密码。完成对照后恢复原先需要的姿态，避免临时测试设置长期影响其他业务。

下面是 Shadowrocket 配置中的简短规则片段，展示域名、地址与最终规则的顺序，不是完整配置。规则通常自上而下匹配，FINAL 应放在前面规则之后。这里的 PROXY 与 DIRECT 是策略含义，不能把服务器密码填在策略位置；使用命名策略时，还需要确认当前配置确实定义了对应名称。

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

DOMAIN-SUFFIX 匹配域名后缀，IP-CIDR 匹配地址范围，GEOIP 根据地址所属数据判断，FINAL 接住前面未命中的请求。它们不是协议参数，也不会改变远端认证。域名规则还需要请求处理过程保留相应域名信息；只看到目标地址时，判断条件可能不同。规则位置、解析结果与请求类型应结合查看，详细解释见规则写法与匹配逻辑。

用固定顺序缩小错误范围

第一步确认应用已获系统授权，并选中预期连接；第二步核对入口地址能否解析及访问；第三步看协议认证和 TLS 是否完成；第四步验证 DNS；第五步查看规则和策略；最后检查目标应用自身。若失败发生在前一层，先处理这一层，不继续批量改动后续字段。Connectivity Test 的结果应与实际网页、上传和所需业务共同判断，单个测试成功不能覆盖全部路径。

记录时保留网络类型、Global Routing、所选连接、失败阶段及是否可重复，不记录公开认证值。长传输卡住要补查 MTU、丢包和服务器状态；延迟正常而域名失败可转向DNS 排查；系统连接开关异常则查看疑难解答。每次只改一项，失败就恢复基线，避免多个未经证实的调整叠加。

最终应留下的是一份能够解释的配置，而不只是一个偶然连通的状态。将有效参数与适用场景分开记录，更新已有订阅后核对关键字段，网络条件变化时按同一顺序复查。日常操作可返回入门指南，App Store 购买、已购恢复及设备兼容性另见下载与正版核验页，不必在协议排错过程中同时处理购买问题。