Shadowrocket 协议参考

01 / FOUNDATIONS

协议分层与 iOS 性能判断

把连接拆成可以分别核对的层

在 Add Server 里选择类型，只确定了一部分连接行为。一次代理请求还涉及服务器地址、端口、身份认证、底层传输、加密保护、目标地址解析与流量选择。可以把协议理解为客户端和服务端约定的消息格式，把传输理解为承载这些消息的通道。相同协议搭配不同通道，连接建立过程、额外开销和故障位置都可能不同；相同通道承载不同协议，也不意味着认证字段可以互换。

例如 VLESS 可以与 TLS、WebSocket 等条件组合，但并不是选择 VLESS 后这些条件就会自动成立。服务端若要求特定路径，客户端不能凭协议名称推断路径；服务端若只接受普通 TCP，客户端额外打开另一种传输也不会获得兼容性。填写前先将已有信息分成“到哪里连接”“用什么证明身份”“通过什么通道”“如何确认对端”四组，缺少任何必要项都应回到原始配置核对。

吞吐量、响应时间和稳定性是不同指标

速度通常至少包含三个维度：首次打开页面的等待、持续下载时的吞吐量，以及通话或交互中的抖动。握手较多的组合，可能首次建立连接较慢，但长连接传输仍然稳定；带宽较高的连接，也可能因排队导致交互迟缓。Connectivity Test 有助于发现明显不可达，但它的测试目标、连接是否复用、DNS 是否已缓存，都会影响结果，不能直接代替实际业务测试。

在 iOS 上，应用流量经过系统网络扩展处理，性能不仅取决于协议算法，还取决于无线信号、服务器距离、服务端负载和目标网站。Wi-Fi 信号较弱时，链路重传可能比加密运算更影响速度；移动网络频繁切换时，重新建连的等待又可能比持续吞吐更重要。因此，“某协议一定最快”没有可重复的技术前提，应把结论限定到同一设备、同一网络和同一测试任务。

电量消耗主要看连接怎样被使用

电量不能只按协议名称排序。蜂窝网络的无线模块唤醒、弱信号下持续重试、大量短连接、过于频繁的保活，以及后台持续传输，都可能增加耗电。一个握手较重但稳定复用的连接，未必比反复失败重连的轻量连接耗电。设备发热也需要结合屏幕亮度、应用负载和充电状态判断，不能仅凭开启客户端后的时间先后确定原因。

测试电量时，先固定一段有代表性的使用过程，例如相同长度的视频播放或相同文档浏览，再查看系统电池页面中的活动时长和后台行为。不要在一组测试里持续运行 Connectivity Test，另一组却保持待机。两次结果若来自不同信号条件，参考意义很小；出现异常时，优先检查后台是否有不断失败的连接、订阅是否在重试，以及 On Demand 是否反复触发连接。

协议能力必须与整条路径一起确认

支持 UDP 的协议类型，不等于当前服务器、传输组合和目标都能传递 UDP。客户端入口、服务端设置、网络对 UDP 的可达性，以及出口策略，都需要同时满足。反过来，某个网页能打开也不能证明 UDP 可用，因为网页可能只经过 TCP。记录问题时应写清业务使用的传输类型，而不是简单写“网络正常”或“协议失效”。

本页的 iOS 讨论用于说明移动设备上的行为取舍，不代表其他平台缺少这些协议能力。具体字段以当前 Shadowrocket 界面与服务端配置为准；安装与获取入口统一见全平台下载，本页不重复安装步骤，也不根据设备型号推测未经确认的兼容条件。

02 / SHADOWSOCKS

Shadowsocks：共享凭据与加密方法

设计背景与适用边界

Shadowsocks 的基础思路是让客户端与服务端通过预先约定的凭据和加密方法交换代理数据，核心结构相对直接。它不是一个可任意替换底层字段的通用容器：双方必须理解同一套协议格式，并对加密方法达成一致。对用户来说，最重要的不是记住名称，而是确认订阅中标出的类型、服务器、端口、密码及加密方法确实属于同一个服务条目。

较新的认证加密设计会同时处理数据保密性和完整性，避免仅加密而缺少可靠认证带来的问题。不同代际或扩展所需的密钥格式可能不同，不能把任意一段普通密码粘到所有方法里。客户端列表中出现某个方法，只说明客户端提供相应入口，不说明现有服务端已启用它。应优先沿用服务商给出的完整组合，不为追求名称更新而单独修改加密方法。

Server、Port、Password 与 Method 怎样对应

Server 是到代理服务端的地址，可以是域名或 IP；Port 是该服务监听的端口，不是目标网站的端口。Password 用于与所选加密方法共同确定认证或密钥材料，区分大小写，尾部空格也可能改变结果。Method 必须与服务端一致，错误方法常表现为能建立底层连接、却没有有效业务响应，而不是清晰显示“方法不匹配”。

若导入后条目存在但连接失败，先把这四项与原始信息逐项对照。特别注意复制过程中产生的全角符号、换行、截断，以及把管理页面端口当成代理端口的情况。对于要求特定编码密钥的配置，应保留原始编码形式，不自行重新计算或删减字符。订阅展示名只是备注，名称里写着地区或协议，并不能证明内部字段正确。

附加参数不是默认必需项

某些 Shadowsocks 条目还包含附加传输或其他扩展参数。这些参数不是看到开关就应该启用的增强功能，而是服务端要求的一部分。若原始订阅没有给出相应内容，不应根据另一条配置照抄。特别是路径、主机名和附加认证信息，往往与具体服务部署绑定，错误值可能使基础服务器与密码完全正确的条目仍然无法工作。

手动创建条目时，建议先填写服务端明确要求的最小字段，再确认连接；需要扩展时，按原始信息逐项补齐。已有订阅正常工作时，不必重新手填来“优化”。若订阅更新后字段被改回，说明订阅仍在管理该条目，应检查来源配置，而不是反复在同一个自动更新条目上修改。保留一份单独备注的测试条目，更便于对照和恢复。

在 iOS 上怎样判断是否合适

在信号稳定、服务端资源充足的条件下，Shadowsocks 较直接的数据处理路径有利于控制额外开销，但不能据此保证下载速度。选择时更应看现有服务是否稳定、是否需要 UDP、是否存在频繁短连接，以及实际网络的丢包情况。加密方法的计算成本可能有差异，不过对多数日常操作，网络等待与服务器负载通常更值得先检查。

如果待机耗电增加，先查是否出现持续重连、应用后台同步或 UDP 保活，而不是立即更换加密方法。若某项业务失败、其他业务正常，按目标与传输类型定位：可能是分流命中、目标解析或服务端出口限制，并不一定是 Shadowsocks 本身。对于能够稳定工作的已有配置，保留完整参数通常比自行拼接另一种传输组合更可靠。

03 / VMESS & VLESS

VMess 与 VLESS：认证和传输分开理解

相近字段不代表相同协议

VMess 将用户认证与代理消息封装结合起来，并有自己的数据保护机制；VLESS 更强调轻量的认证与转发结构，通常依赖外部安全层完成传输保护。二者可能都使用 UUID，也可能搭配相似的传输方式，但线上消息格式并不相同。把同一个 UUID 从 VMess 条目复制到 VLESS 条目，不会让服务端自动兼容，客户端的 Type 必须与服务端实际配置一致。

这种分工的演进说明了一个重要取舍：把认证、加密与通道拆开，可以减少某些重复工作，也会增加组合配置的责任。VLESS 自身的轻量设计不等于任意裸连接都具备机密性；VMess 带有内部保护，也不等于外层 TLS 可以不核对。判断安全边界时，应分别问“谁验证用户”“谁验证服务端”“哪一层保护数据”，不能把一个协议名称当作全部答案。

UUID、Security 与时间条件

UUID 是身份标识，必须完整匹配。外观类似并不能互用，复制时保留原有字符与分隔形式。VMess 的 Security 等字段应按服务端提供的信息选择，某些旧配置还会出现历史兼容字段，不应凭经验给所有条目填入统一值。VLESS 中与数据加密有关的选项，也不应套用 VMess 的含义；相同英文单词在不同协议页可能属于不同处理层。

VMess 的部分认证过程对客户端与服务端的时间差敏感。若参数看似正确但认证失败，检查设备是否开启自动日期与时间，并请服务商核对服务端时钟。调整时区的显示方式不等于校准实际时间，也不需要为了连接把设备改到另一个地区。时间正确后仍失败，应继续核对协议、凭据与传输，而不是反复调整时间设置。

WebSocket、gRPC 与 TCP 的区别

TCP 提供可靠字节流，协议消息可以直接通过它传递；WebSocket 增加一层基于 HTTP 握手建立的消息通道；gRPC 通常建立在 HTTP/2 机制之上，带有相应的服务和流处理语义。选择哪一种不是客户端单方面的性能偏好，而是服务端监听方式与中间转发条件共同决定。服务端只接受 WebSocket 时，把客户端改成 TCP 并不能省掉开销后继续使用。

WebSocket 的 Path 与 Host 应按已有信息填写。Path 是通道的路径，不是服务器地址，也不是订阅链接；大小写、斜杠和附加部分都可能影响匹配。gRPC 的服务名同样需要精确对应，不能以网站首页路径替代。若存在中间转发，服务器地址、HTTP Host 与 TLS Server Name 可能承担不同职责，应逐项理解，而不是强行把三个字段都改成同一个值。

TLS 与特殊流参数怎样处理

TLS 中的 Server Name 用于声明预期的服务端身份，并可能影响服务端选择证书；证书校验则确认对端是否符合该身份。它与 HTTP Host 并非同一个阶段的字段。若服务商给出独立的 Server Name，应保留该值，而不是因为 Server 填的是 IP 就清空它。ALPN 涉及应用层协议协商，只有在当前传输和服务端要求明确时才应调整。

某些 VLESS 组合还要求特定流参数或额外的握手材料，这些不是通用加速开关。应确认当前客户端界面支持对应组合，并且原始配置中的相关字段齐全；缺少必需材料时，不应拿另一个服务条目的值补上。导入成功只说明文本被识别，不证明整套组合已经通过服务端认证，也不证明业务流量一定采用了期望路径。

iOS 上的连接复用与电量

额外的 HTTP 通道和 TLS 握手会增加建立连接时的工作，但连接复用可能摊薄这部分成本。移动网络切换后，旧连接可能失效，需要重新建连；若频繁发生，表现会是打开页面偶尔等待较久，而不一定是持续下载慢。测试时应分别观察新连接和长连接，不把两种体验混为一个速度分数。

多路复用也不是始终有益：共享外层连接可以减少重复握手，但外层链路丢包、排队或重置时，多个业务可能一起受到影响。若没有明确的服务端建议，先保留导入值，用同一业务比较连接稳定性，再决定是否改变。涉及 UUID 或传输字段的基础疑问，可结合名词解释查阅，避免用界面名称相似来推断兼容性。

04 / TLS & GENERAL PROXIES

Trojan、HTTP 与 SOCKS5 的边界

Trojan：密码认证与 TLS 通道

Trojan 的典型设计把代理认证与转发放入 TLS 连接之中，利用成熟的 TLS 机制保护传输并确认服务端身份。对客户端使用者而言，关键字段通常包括服务器、端口、密码与 TLS 相关信息。这里的密码验证用户是否有权使用服务，证书验证客户端是否连接到了预期服务端；两者职责不同，密码正确不能抵消证书身份错误。

如果 Server 使用 IP，而证书签发给域名，通常需要按原始信息填写正确的 Server Name。不要把“地址可以连接”理解成“身份校验应该通过”。证书过期、证书链不完整、设备时间不正确，以及服务端返回了另一个站点的证书，都可能造成失败。应先查看错误属于认证、TLS 还是网络超时，再与服务商核对，而不是连续更换端口碰运气。

HTTP 代理与 HTTPS 目标不是一回事

HTTP 代理起初围绕 HTTP 请求转发形成，访问 HTTPS 目标时通常通过 CONNECT 建立到目标的隧道，再由业务应用与目标网站进行 TLS 通信。“目标网站是 HTTPS”和“客户端到代理的通道经过 TLS”是两件事。若代理入口本身是普通 HTTP，即使目标网站使用 HTTPS，也不能据此断言代理认证信息和全部元数据在入口链路上受到同等保护。

若当前界面与服务端提供 HTTPS 代理入口，应按对应类型配置外层 TLS，不能只把普通 HTTP 的端口改成常见 TLS 端口。用户名、密码、认证方式和服务器监听必须匹配；有些服务还限制 CONNECT 目标端口。遇到部分网站可用、某些端口不可用时，应核对服务端许可范围，不必先归因于 DNS 或规则。应用层返回的拒绝响应与底层连接超时，也应分别记录。

SOCKS5：通用代理协商，不自带加密

SOCKS5 提供一种通用的代理协商方法，可以表达目标地址，并可根据服务端设置使用用户名与密码认证。协议本身并不提供与 TLS 等同的传输加密。用户名与密码认证解决的是使用权限问题，不会自动形成保密通道。是否适合当前场景，必须结合所在网络、外部保护层与服务端部署判断，不能因为字段较少就认为安全边界更简单。

SOCKS5 协议定义了 UDP 关联机制，但实际使用还依赖客户端支持、服务端启用情况及网络路径。能够通过 SOCKS5 打开网页，主要证明某类 TCP 请求成功，不能推导游戏、语音或其他 UDP 业务也能成功。若服务端只提供 TCP 转发，应把这一边界视为服务条件，而不是在客户端不断切换 UDP 选项。客户端也不能用一个开关补出服务端没有实现的能力。

解析发生在哪里，需要单独判断

HTTP CONNECT 和 SOCKS5 都可能涉及以域名表达目标，但最终在哪里解析，还取决于客户端处理方式、规则需求与服务器实现。若客户端为了匹配 IP 规则先做了本地解析，即使之后把域名交给代理，也不能简单称为“所有解析都在远端”。应把服务端地址解析、目标地址解析和规则匹配触发的解析分别看待，避免用一个“远程 DNS”标签概括整个流程。

在 iOS 上，这几种协议的体感差异常来自是否新增 TLS 握手、连接是否被复用、服务器距离和实际负载。普通 HTTP 或 SOCKS5 字段较少，不代表必然更省电；Trojan 使用 TLS，也不代表必然耗电明显。若连接稳定，业务模式可能比协议差异影响更大。测试时同时关注身份校验是否正确，不能为了减少一次握手而改变所需的保护边界。

选型应服从已有服务的真实类型。服务商提供 Trojan，就保留相应认证和 TLS 条件；提供受控网络中的 HTTP 或 SOCKS5，就先确认该入口的信任范围和用途。不要将三者视为同一条服务器记录上的可互换菜单。基础操作疑问可在常见问题中查找，涉及证书与认证的具体失败则应携带去除凭据后的错误信息核对。

05 / WIREGUARD

WireGuard：密钥身份与 IP 隧道

与应用代理不同的工作模型

WireGuard 围绕加密 IP 隧道设计，身份以公钥体系表示，传输主要依靠 UDP。它处理的是隧道内的 IP 数据包，而不是像通用应用代理那样只协商某个目标连接。因此，地址、路由范围和对端密钥成为配置中的关键部分。把代理协议的“密码、服务器、端口”思路直接套用，容易遗漏本地隧道地址和允许经过对端的目标范围。

在 Shadowrocket 中使用 WireGuard 条目时，还需要区分客户端的流量选择与 WireGuard 对端自己的路由约束。前者决定哪些业务选择这个条目，后者决定被交给隧道的数据包是否属于对端允许的范围。两层都正确，业务才可能完成。选择了一个能握手的 WireGuard 条目，不意味着任意目标地址都必然可达，也不意味着已有分流规则会被自动替换。

Private Key、Public Key 与预共享材料

Private Key 属于本地身份秘密，Public Key 用来标识对端。客户端填写的对端 Public Key 应来自服务端，不能拿本地生成的 Public Key 替代；服务端也必须认识客户端的公钥。若配置另有预共享密钥，它是双方额外约定的材料，不能与 Private Key 混用。密钥外观可能相似，但字段职责不同，复制时应依据原始字段名而不是字符串长度判断。

不要把包含 Private Key 的完整配置贴到截图、日志或公开讨论中。排错时可以说明“密钥是否由同一份配置导入”“对端是否已登记客户端公钥”，但不需要展示真实值。重新生成本地密钥会改变客户端身份，若服务端没有同步登记，新密钥不会自动获得访问能力。因而，遇到失败时先核对对应关系，不应把反复生成密钥当成通用修复办法。

Endpoint、Address 与 Allowed IPs

Endpoint 是对端可到达的外部地址与端口，Address 是隧道内分配给本地的地址，两者不能互换。Allowed IPs 描述通过该对端处理的地址范围，在常见实现中还参与对端选择和接收地址约束。范围过窄，可能只有部分内部资源可访问；范围过宽，也不代表服务端具备转发所有目标的能力。应按提供的配置保留，不根据“全局连接”的直觉统一扩大。

若握手存在但业务不通，先核对隧道地址是否冲突、目标是否落入允许范围、服务端是否具备转发与回程路径。访问内部 IP 正常而域名失败，往往应继续检查 DNS；只有某个网段失败，则可能是路由或目标侧权限。客户端显示连接已建立，只能说明某一层状态，不应跳过地址与服务端出口检查。把这些层次分开，比单独观察开关是否打开更有效。

MTU、保活与移动网络切换

MTU 决定隧道中数据包的大小边界。封装会增加额外字节，若实际路径不能承载相应大小，又无法正确反馈路径信息，可能出现小请求成功、大页面或大传输停顿的现象。不要把任意较小数值当成统一最佳值；应依据服务端建议与测试现象调整，并记录原值。若减少 MTU 后仅某类问题改善，需要继续确认瓶颈，而不是由此推断所有连接都应采用同样设置。

Persistent Keepalive 一类保活用于帮助维持某些 NAT 映射，不是带宽加速选项。移动网络可能较快回收空闲映射，但更频繁的保活也会增加发送次数与无线模块活动。是否需要，应结合服务端访问方式、空闲后的恢复表现和原始配置判断。没有空闲断连问题时，不必为了“保持在线”主动缩短间隔，更不能把不间断握手测试作为省电配置。

WireGuard 对地址变化的处理有利于某些移动场景，但不能保证所有 Wi-Fi 与蜂窝切换都没有中断。切换后 UDP 路径、系统网络扩展状态和目标会话仍可能发生变化。测试时分别观察新请求能否恢复、旧业务是否需要重建；如果只有旧通话中断而新网页可用，应把它记录为会话连续性问题，不要笼统判定整个隧道无法使用。

06 / HYSTERIA2

Hysteria2：UDP 路径与拥塞控制

为什么选择基于 QUIC 的传输

Hysteria2 使用基于 QUIC 的传输设计，QUIC 通常运行在 UDP 之上，并整合可靠流、加密握手与连接管理等机制。它的设计关注点之一，是在不同质量的网络中管理传输，而不是简单把 TCP 数据包换成 UDP 就自动提速。UDP 提供的是承载条件，可靠性、拥塞控制和业务映射仍由上层实现负责，因此不能把“使用 UDP”理解为不需要重传或不受丢包影响。

与基于单一 TCP 连接的复用相比，QUIC 可以在传输层为不同流维护较独立的交付状态，减少某个流丢包对其他流交付的直接阻塞。不过共享链路的带宽、拥塞状态和设备资源仍然存在，一个连接上的大量传输仍可能影响其他业务。实际收益取决于网络条件、服务端配置和业务类型，并不是所有网页、下载与实时交互都会获得相同程度的改善。

Server、认证与 TLS 身份

Hysteria2 的服务器地址、端口、认证信息和 TLS 条件必须来自同一配置。认证字符串证明用户权限，TLS 身份校验确认对端，二者不可替代。如果 Server 是 IP、Server Name 是域名，按原始信息保留这种分工。遇到证书错误时应核对域名、有效期与设备时间，不应为了观察吞吐量先长期关闭校验，否则比较的已经不是同样的安全条件。

某些部署还要求额外的传输参数或混淆相关字段。这些字段必须双方一致，缺省与空字符串也未必等价。Hysteria2 与名称相近的其他代际不能按字段相似直接互用；导入时应确认类型被识别为服务端实际采用的协议。若手动输入后完全没有响应，除了检查密码，还应先确认当前网络能否到达所需的 UDP 端口。

带宽参数不等于承诺速度

部分配置提供上行与下行带宽参数，用于相应拥塞控制模式的估计或约束。它们不是填写得越大越好，也不是服务器会分配给用户的固定速率。把明显超过实际接入能力的数值写入，可能造成排队、丢包与竞争，下载表面上短时升高，交互体验却变差。应理解当前模式如何使用这些参数，并优先采用服务端建议，而不是照抄别人的高速网络数值。

单位也必须核对清楚。带宽与每秒传输字节不是同一概念，界面或配置要求的单位不能凭常见下载软件的显示方式猜测。上行拥塞同样会影响下行体验，因为请求、确认与控制信息都需要发送。若下载一开始快、随后延迟明显增加，除了服务器负载，还应检查本地链路是否被推到持续排队状态，不能只把下行参数继续提高。

iOS 上的速度和电量如何取舍

在存在一定丢包或时延变化的链路上，合适的拥塞控制可能改善持续传输；在质量良好的低时延网络中，额外收益未必明显。主动占用链路的传输方式也可能增加数据处理与无线模块活动，所以不能把高吞吐直接当成高能效。对电量敏感的用户，应比较完成相同任务所需的总时间、后台传输和设备温度，而不是比较某一瞬间的峰值速率。

如果目标是语音、交互或远程操作，优先看抖动、掉线和排队，而不是只看下载。测试时不要让大文件传输与交互测试互相干扰，除非本来就在评估这种并发场景。切换 Wi-Fi 与蜂窝后，也应重新确认 UDP 路径；一个网络表现良好，并不能证明另一个网络具有相同的包大小限制、NAT 行为或空闲连接保留时间。

适合已有条件，而不是替代所有类型

当服务端明确提供 Hysteria2、当前路径允许 UDP，且主要问题确实与链路质量或拥塞有关时，它值得作为对照选项。若现有 TCP 类连接已经稳定，切换并非必需。若业务失败来自规则把目标送往错误策略，或者 DNS 返回不可达地址，换成 Hysteria2 也不会自动修正规则。应先确定问题属于传输层，再评估协议带来的实际收益。

保存测试结论时，应写明网络、业务、带宽设置是否沿用原值，以及是否出现重连或后台活动。避免只保存“快”或“慢”的备注，因为这些词无法在条件变化后复现。原有条目应保留，测试条目单独命名；订阅更新时再核对差异，防止把自动更新后的参数变化误当成同一协议忽然改变表现。

07 / ROUTING & DNS

Global Routing、DNS 与协议的交界

先确认流量是否真的进入所选协议

Global Routing 控制流量的整体选择方式，不负责把一种协议变成另一种协议。配置姿态 Config 按当前配置处理规则；代理姿态 Proxy 用于让适用流量走代理路径；直连姿态 Direct 用于直接连接。界面词与规则策略要区分：Proxy 是界面姿态，PROXY 是规则中可使用的策略名称，二者有关联但并非同一个字段，不能仅凭字母相似推断当前请求的实际路径。

测试协议之前，应确认当前条目已被选择，并检查相关请求命中的规则与最终策略。某网站在 Config 下直连成功，并不能证明所选代理条目可用；在 Proxy 下失败，也不能立即证明协议参数错，因为仍可能是服务端出口或目标响应问题。Direct 可帮助判断目标是否能通过本地网络访问，但该结果只适用于当前网络条件，不是对所有连接的永久判断。

三类解析不要混在一起

第一类是代理服务器地址的解析：Server 如果填写域名，客户端必须先知道怎样找到它，这属于建立代理前的条件。第二类是目标域名的解析：目标可以由本地流程解析，也可能以域名形式交给远端处理，取决于协议和配置。第三类是规则匹配需要的解析：某些基于 IP 的规则可能需要先获取地址。三类解析发生的时机不同，也不一定使用完全相同的路径。

因此，所谓“DNS 正常”需要说明是哪一类正常。服务器域名能解析，不等于目标网站能解析；目标解析成功，也不等于返回地址可以从当前出口到达。若仅 IPv6 目标失败，应检查当前网络与出口的 IPv6 能力，而不是立即关闭所有 DNS 功能。若 IP 可访问、域名失败，则先关注解析和身份字段，但也要注意 HTTPS 目标可能依赖域名身份，不能用直接输入 IP 作为完全等价的业务测试。

规则顺序会改变观察结果

规则通常按从上到下的顺序处理，先命中者决定策略。DOMAIN-SUFFIX 匹配域名后缀，GEOIP 根据地址归属库判断，FINAL 为其他规则未命中的请求提供兜底。下面是用于解释顺序的局部片段，不是建议直接替换现有配置；其中的 PROXY 必须在实际配置中具有有效含义，示例域名也只是教学文本，不代表需要访问的服务。

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

这个片段先检查域名后缀，再检查地址归属，最后走兜底。将 FINAL 提前会使后面的规则失去预期机会；把本应走代理的目标先匹配到 DIRECT，则会让协议测试实际上绕开代理。DOMAIN 与 DOMAIN-SUFFIX 也不能随意互换，前者表达精确域名，后者覆盖后缀范围。需要更细的写法与顺序解释，可阅读自定义规则匹配顺序与 FINAL。

配置文件不等于订阅条目

订阅主要带来服务器条目及相关参数，配置文件则可以影响规则、DNS 与其他处理。导入新的条目后，如果仍使用旧配置，规则不会因为协议名称变化就自动重写。反过来，替换配置后即使没有修改服务器，也可能改变连接路径。记录故障前应确认这两部分是否分别更新过，避免把同一天发生的规则变化错误归因于某个协议。

编辑 .conf 后应确认保存、选择了预期配置，并按界面提示重新应用相关状态。测试时保留原配置，避免把生产使用与试验修改混在一起。结构说明可参阅General、Rule、Host 与 URL Rewrite 分段解析；订阅导入位置则见Subscribe 与其他导入入口。

On Demand 与协议连接状态分别观察

On Demand 依据系统条件决定何时尝试建立连接，不会修复认证、证书或服务端可达性。若网络切换时不断出现连接动作，应分别检查触发条件与协议重连结果。关闭触发条件后手动测试，可以帮助隔离“系统反复发起连接”与“某次连接本身失败”，但测试完成后应恢复原有设置，不要遗忘需要的连接条件。

最终记录应包含当前 Global Routing、配置名称、所选条目、目标与命中策略，以及是否触发 DNS 或 UDP。这样才能解释为什么同一条目在两个用户设备上表现不同。客户端开关显示开启，只说明网络扩展处于某种运行状态；请求走哪里、在哪里解析、采用什么协议，仍要结合当前配置和具体连接判断。

08 / SELECTION & DIAGNOSIS

按场景选型与逐层排错

选型顺序：兼容条件先于性能偏好

第一步是列出已有服务真正提供的协议和完整参数，而不是先挑一个听起来较快的名称。第二步确认当前网络是否允许所需传输，例如 UDP 路径是否可用。第三步再看业务：短时浏览关注首个响应，持续下载关注稳定吞吐，通话与交互关注抖动和中断，内部资源访问还需核对地址与路由范围。只有前两步成立，第三步的比较才有实际意义。

若服务商只提供一种协议，客户端不能凭空改成另一种；若提供多个条目，也可能对应不同服务器与负载，不能把测试差异全部归结为协议。较严谨的比较应尽量让服务端位置与网络条件接近，并记录无法保持一致的变量。对多数用户而言，完整、稳定且符合业务需求的现有配置，比增加一套不熟悉的传输组合更容易维护。

从不可达走到业务层，不跳步

完全无法建立连接时，先核对 Server 与 Port、当前网络及服务端监听情况。域名解析失败属于入口问题，底层超时更应关注路径与监听，立即重填 UUID 往往没有帮助。若网络连接已建立但出现明确认证错误，再检查密码、UUID、密钥对应关系与时间条件。若错误指向 TLS，则聚焦 Server Name、证书与设备时间，不要同时更改 DNS 和路由来掩盖问题。

认证通过但业务不通时，下一层是传输参数、目标地址与服务端转发。WebSocket Path、gRPC 服务名、特殊流参数或 WireGuard 路由范围，都可能在基础连接成立后阻止业务。若只有部分目标失败，检查规则命中、目标解析及服务端出口；若只有 UDP 业务失败，则沿客户端、服务端和网络逐段确认 UDP，而不是继续以网页测试证明“已经全部正常”。

短暂可用后断开，重点看状态变化

空闲一段时间后失效，可能涉及 NAT 映射、保活和服务器空闲策略；Wi-Fi 切换蜂窝后失效，则需要观察旧连接是否重建、UDP 路径是否变化，以及 On Demand 是否触发。大请求停顿而小请求正常，可以进一步考虑 MTU 和路径反馈；高负载时才失败，则应检查排队、带宽估计、设备资源与服务端负载。每种现象都比一句“总是断线”更有定位价值。

不要一次修改多项保活、MTU、复用与带宽参数。先写下原值，只改与当前现象最相关的一项，重复同一任务，再恢复或保留。若无改善就撤回，不要把试验值不断叠加。订阅管理的条目还应注意自动更新覆盖；可单独复制测试条目并明确备注用途，避免下次更新后无法判断参数是手工改变还是来源改变。

电量异常用任务对照，不用名称推断

如果主要目标是减少耗电，应先检查后台持续活动、失败重试、保活频率和无线信号，再比较协议。测试期间保持屏幕、业务时长与网络尽量相同，避免一组在充电、一组在低电量状态。系统电池统计可以作为线索，但短时间百分比变化容易受温度和估算影响，应结合多次任务结果。单次高速下载更快完成，也可能比长时间低速重试更节省总活动时间。

没有必要为了待机测试持续发送探测请求，这会改变本来要观察的状态。若发现客户端关联的后台活动增加，应确认是否有其他应用持续通过连接传输，以及规则是否让本可直接访问的高频任务进入了更长路径。此时修正业务路径可能比更换协议有效；但任何规则调整都应符合实际用途，不应仅为了电池统计减少需要的连接。

完成测试后保留可解释的配置

最终选择应能回答三个问题：为什么与服务端兼容、为什么符合当前业务、失败时怎样恢复。保留一份已验证的配置，记录必要参数的来源与适用网络，删除已经确认无效的试验修改。不要把测试中的关闭验证、临时放宽范围或极端带宽值留作日常设置；若某项参数必须偏离原始配置，应说明原因并与服务商核对其边界。

需要回到操作主线时，继续阅读Shadowrocket 快速上手；需要核对获取渠道时，进入全平台下载页。Mac 提供 Apple 芯片与 Intel 两种版本，其他桌面及安卓安装的系统提示也在下载页集中说明。本页的结论不是推荐某一种协议始终优先，而是让每次选择都有可核对的条件、每次失败都有明确的下一步。