Shadowrocket
协议选择与参数说明

01 / 先区分协议、传输与规则

类型必须与服务端一致

在 Add Server 选择类型，本质上是在选择客户端与服务器之间交谈的格式。Shadowsocks、VMess、VLESS、Trojan 等名称描述了不同的认证和数据组织方式，并不是可以随意替换的速度档位。如果已有信息写明 VLESS，就不能只因另一种协议看起来更简单而改选 Trojan。服务器必须理解相同的协议、凭据和传输组合，连接才有成立的前提。

理解配置时，可以把连接拆成四层：最底层是设备到服务器的网络可达性，其上是 TCP、UDP 或基于它们构造的传输，再上是协议认证与可选的 TLS，最后才是请求到达目标服务。Config 中的规则负责决定哪些请求走哪个策略，不负责修正服务器密码。把这几个层次分开，才能避免在认证错误时反复修改 DNS，或者在规则走错时不断更换协议。

地址、身份与传输分别核对

服务器地址用于找到连接入口，端口用于定位入口上的服务。地址可以是域名，也可以是 IP；填写域名时还多了一次解析过程。认证字段则证明连接者被允许使用这个入口，可能表现为 Password、UUID 或密钥。传输字段描述请求如何送达服务端，例如 WebSocket 的 Path、HTTP Host 或其他服务名称。即便地址和凭据正确，传输路径不符也可能导致握手中断。

订阅导入通常会把这些字段一起写入服务器条目，因此首次排查应保留导入后的原始值，并与用户已有信息逐项比对。不要先清空看不懂的选项，也不要把别的条目中的参数拼进当前条目。某个界面没有显示额外传输项，可能意味着该组合不需要它，也可能与当前类型有关；具体以当前应用界面和已有配置为准，而不是照抄不相关的示例。

速度与耗电需要放在同一条件下比较

在 iOS 上，协议处理会消耗处理器资源，但无线信号、重传、屏幕亮度和后台活动往往同样重要。握手较短的协议不保证大文件更快，能迅速跑满带宽的协议也未必适合长时间低流量待机。短连接更容易暴露握手与解析成本，持续下载则更容易暴露带宽、拥塞控制与服务器负载。评价之前应先说明自己测的是哪一种任务。

协议选择也不改变服务器所在网络的基本条件。相同协议在不同入口上可能呈现完全不同的延迟和吞吐；不同协议若使用相同拥塞出口，也可能一起变慢。比较时固定设备、网络、目标资源与测试时段，暂停其他大流量任务，记录连接是否成功、首个请求等待时间和持续传输稳定性。不要把一次测试得到的排序写成永久结论。

02 / Shadowsocks：加密方法与密码配对

围绕代理转发组织连接

Shadowsocks 的设计出发点是以相对简洁的方式承载代理流量，在客户端与服务器之间增加认证和加密处理。它通常不要求用户理解完整的虚拟网络拓扑，而是围绕服务器地址、端口、加密方法和密码建立配置。对使用者而言，字段数量较少意味着比较容易核对，但并不意味着任意组合都有效；加密方法本身就是协议兼容性的一部分。

传统配置中常见的加密方法会把算法、工作方式或密钥长度写在名称里。选择时必须与服务端完全一致，不能根据手机型号挑选一个看起来更快的名称。不同方法的密码处理方式与报文格式可能不同，客户端能够保存条目也不代表服务端会接受。对于具有不同凭据格式要求的协议变体，更应沿用已有配置，而不是把普通密码直接替换进去。

四个核心字段逐项检查

服务器地址应填写真实入口，不要把整条分享链接粘进地址栏。端口填写服务端给出的数字，避免复制时带入空格、冒号或说明文字。Password 需要保留大小写和符号，注意聊天工具可能在复制时加入换行。Method 对应加密方法，应逐字核对。若信息来源只给出分享链接，优先按教程导入，再查看解析结果，通常比手工拆解更不容易遗漏编码字符。

某些部署还会提供额外插件或传输相关设置。它们不是装饰性选项，而是连接路径的一部分；服务端要求额外封装时，客户端缺少对应参数就无法按同一种格式通信。反过来，普通入口也不应自行添加额外封装。无法确认时，应向自己的服务商核对字段用途，不要从网上寻找一个“通用值”覆盖原有信息，更不要用关闭检查代替兼容性确认。

TCP 正常不等于 UDP 正常

Shadowsocks 可以涉及 TCP 与 UDP 的转发，但两者是否可用还取决于服务器、网络路径和客户端条目设置。网页能打开，只能说明当时使用的请求路径成功，不能证明需要 UDP 的应用一定正常。出现网页可用而实时应用失败时，应先确认该应用实际使用的传输，再核对服务器是否提供相应能力，而不是立即更换加密方法。

UDP 报文具有大小限制，额外封装会压缩可用载荷空间。小报文正常、大报文或持续流量异常时，需要考虑路径 MTU、丢包和分片问题。此时反复修改 Password 通常没有意义，因为认证问题不会只在某一报文大小下稳定出现。应记录是所有目标异常还是特定任务异常，并用同一服务器上的简单请求建立对照，缩小问题范围。

在 iOS 上观察处理开销

在硬件与实现适配良好的条件下，现代认证加密方法可以有效处理较大流量，但实际表现仍受服务器处理能力和网络带宽限制。持续高吞吐时，设备可能因加密、收发和无线活动产生更多热量；待机时则需要区分是否真的有业务流量。不能仅凭协议字段少，就推导出它始终最省电，也不能把设备发热全部归因于某一种算法。

排查时先保留一份原始条目，逐项确认地址、端口、Method 和 Password，再用 Connectivity Test 和实际目标请求分别验证。如果所有请求都失败，优先查入口与凭据；如果只有特定应用异常，再检查 UDP、DNS 和规则路径。相关协议之间的整体定位可结合协议类型概览阅读，但实际填写仍以已有服务器参数为依据。

03 / VMess 与 VLESS：身份字段之外还有传输

相似的外观不代表相同的协议

VMess 与 VLESS 经常都使用 UUID 形式的身份字段，也都可能搭配不同传输，因此初看容易混淆。VMess 把用户认证与协议内的数据保护机制组织在一起；VLESS 则更强调精简协议自身的处理，把可靠的数据保护交给匹配的安全传输组合。两者在报文和认证流程上并不相同，不能因为 UUID 格式一致，就认为只改类型也能连接。

UUID 是标识用户身份的值，不是服务器域名，也不是显示名称。复制时应保留完整结构，尤其不要漏掉字符或夹入不可见空格。某些配置还包含与认证方式或兼容性相关的字段，不能只凭旧教程照填。VMess 的一些历史参数并非所有当前配置都需要；遇到已有信息与界面不一致，应先核对配置来源和当前支持的组合，而不是自行补出一个值。

传输决定服务器怎样接收连接

同一协议可以运行在不同的传输之上。直接基于 TCP 的组合通常没有 WebSocket 路径；使用 WebSocket 时，Path 和 Host 可能决定请求被转发到哪一个后端；使用其他传输时，又可能出现不同的服务标识。它们承担的是传输适配职责，不是用来替代 UUID 的另一组密码。只填写地址和 UUID、遗漏传输字段，是导入不完整时常见的失败原因。

Path 需要保留开头斜杠、大小写以及已有查询部分，不要把它当成给用户阅读的备注。Host 与服务器地址可以不同：前者可能参与应用层路由，后者用于建立网络连接。若同时启用 TLS，还可能存在用于安全握手的 Server Name 或 SNI。三者有时相同，但角色不同，应分别按配置填写，而不是为追求一致把它们全部改成服务器 IP。

VLESS 的精简不等于可以省略安全层

讨论 VLESS 时，需要明确区分“协议自身不承担某部分加密”与“整条连接没有保护”。实际安全性取决于它所搭配的安全传输和认证机制。不能把协议名称当成安全结论，也不能因为界面中某项写着不加密，就随意关闭 TLS。若服务端要求特定安全组合，应完整保留对应设置；若缺少说明，应先补齐信息再连接。

某些条目会出现 Flow 等附加选项，这些选项对应特定工作方式，并非可通用开启的性能按钮。填错可能使连接在认证后中断，也可能直接不被服务端接受。正确做法是以已有分享信息为基准，并确认 Shadowrocket 当前界面能够表达该组合。界面没有对应能力时，不能通过把字段塞进备注来实现；应核对服务端是否另有兼容入口。

握手、时钟与移动网络切换

涉及时间校验的认证流程可能受设备时钟偏差影响。发现入口可达而认证持续失败时，可以检查系统日期与时间是否正常，但不应把时钟当成所有失败的统一解释。对于使用 TLS 和额外传输的组合，首次请求还可能包含多阶段握手；持续传输建立后，这些固定成本被摊薄，所以网页首开体验与大文件速度可能给出不同排序。

在 iOS 的 Wi-Fi 与蜂窝网络之间切换时，原有连接可能需要重建。应观察恢复后新请求能否成功，而不是要求每个既有下载都持续不中断。比较 VMess 与 VLESS 时，要尽量固定传输和服务器条件，否则测到的差异可能主要来自 WebSocket、TLS 或入口负载。进一步查看 VLESS 时，建议先保存原条目，再一次只修改一个明确需要修正的字段。

04 / Trojan：把密码认证放在 TLS 内理解

TLS 负责安全通道，密码负责使用权限

Trojan 的设计思路是利用成熟的 TLS 通道承载代理协议，再在通道内部完成相应的身份认证与请求转发。理解它时应把两次判断分开：首先，客户端需要确认正在连接可信的 TLS 服务；其次，该服务需要确认客户端提交的密码有效。证书正确只能证明安全握手满足检查条件，不代表代理密码已被接受，两者不能相互替代。

这也解释了为什么某些错误看上去都发生在“连接服务器”阶段，实际原因却不同。服务器地址或端口错误可能连 TCP 都建立不了；Server Name 不匹配可能使证书验证失败；Password 错误则可能在 TLS 建立后被拒绝。诊断时应根据失败所处阶段检查对应字段，不要把所有连接中断都归为密码错误，也不要用关闭证书检查来掩盖域名配置问题。

连接地址与证书名称可以不同

Address 决定客户端把网络连接送到哪里，而 Server Name 或 SNI 用于 TLS 握手中的服务器名称表达。通过 IP 连接时，服务端证书仍可能为域名签发，因此已有配置可能要求另外填写名称。证书还涉及有效期、签发链和名称覆盖范围；即便浏览器能够打开某个网站，也不能直接证明代理入口使用了相同端口、证书和路由配置。

当服务器同时承载多个服务时，SNI 还可能影响其选择哪一份证书或哪个后端。把它随意改成常见网站域名，通常不能解决问题，反而可能使请求进入不相关的服务。正确值应来自用户已有配置。如果此前正常、后来突然出现证书错误，应检查设备时间、服务端证书状态和入口变更，保留错误信息再向自己的服务商核对。

额外传输仍需要完整匹配

Trojan 条目不一定都只有最简字段。某些服务端部署在 TLS 外观之下还要求匹配特定传输与路径，用户应按已有信息核对，而不是把其他 Trojan 条目的字段合并进来。若通过订阅导入，先确认应用识别出的类型与传输是否完整；手工输入时则需要分别记录地址、端口、密码、安全层名称以及所有明确要求的附加字段。

密码是区分大小写的凭据，复制时出现空格、换行或符号替换都可能导致认证失败。不要把用于订阅下载的令牌当成 Trojan 密码，也不要把条目备注当成用户名。订阅地址与服务器凭据属于不同对象：前者用于取回配置，后者用于实际连接。订阅更新成功只说明能够获取配置内容，不能证明其中每个服务器此刻都可连接。

iOS 上的速度与电量取决于使用方式

TLS 在移动系统中是成熟的基础能力，但成熟不代表没有成本。首次建立安全通道需要握手，频繁创建短连接时，这部分等待可能更明显；持续传输时，吞吐更多受到网络、加密处理和服务器转发能力影响。若同时叠加额外传输，还要计算封装与连接管理的开销。不能简单断言 Trojan 永远比另一协议更快或更慢。

电量观察应覆盖实际使用周期。短时下载可能产生较高瞬时功耗，但完成得快；反复失败重连则可能在低吞吐时仍持续唤醒网络。发现待机耗电异常时，先检查是否有应用在后台请求、是否持续重试、是否频繁切换网络，再观察 On Demand 的触发条件。单凭协议名称无法判断后台活动的来源，更不能通过修改密码解决重试行为。

一个有用的排查分支是：先用当前入口建立连接，再访问一个原本可达的普通目标，最后测试实际业务。如果连接阶段就失败，检查地址、TLS 与认证；如果只有某个目标失败，检查 DNS、规则和目标响应。若需要按操作顺序定位“开关已开但网页打不开”，可继续阅读连接开关打开后的四步排查，避免只围绕 TLS 重复尝试。

05 / HTTP 与 SOCKS5：代理接口不等于加密通道

从应用层代理的职责理解差异

HTTP 代理来自应用层请求转发需求，既可以处理普通 HTTP 请求，也可以通过 CONNECT 为目标连接建立字节通道。SOCKS5 则以较通用的方式表达目标地址和连接命令，不要求所有被承载的数据都是网页协议。它们描述的是代理接口，不能只凭名称推断客户端到代理服务器之间已经受到加密保护；安全层需要另外确认。

这一点与目标网站使用 HTTPS 是两个问题。目标网站的 HTTPS 可以保护设备与目标之间相应的应用数据，但代理入口可能仍能观察连接目标等信息，而连接到代理本身的认证与传输也有独立边界。若选择带 TLS 的 HTTP 代理组合，应核对证书与服务器名称；若已有信息明确为普通代理，就不能在客户端随意打开 TLS 并期待服务端自动适配。

用户名、密码和服务端允许范围

HTTP 与 SOCKS5 都可能涉及用户名和密码，也可能通过服务端访问控制决定是否允许使用。应严格按已有信息填写，不要认为字段留空一定可用。某个代理允许特定网络来源访问，并不代表换到蜂窝网络后仍会被接受。遇到网络切换后失败，需要把服务端访问范围与凭据一起核对，而不是立即判断 Shadowrocket 的条目损坏。

服务器地址中不要包含多余的协议前缀或路径，除非界面明确要求输入完整 URL。端口也不应该从目标网站地址中推断。若用户已有信息来自单位或个人维护的网络环境，还应确认该代理允许访问的目标范围与用途。某些入口仅服务于特定应用或网络区域，不能因为它接受一次认证，就假设所有互联网目标都可以经过它转发。

域名交给谁解析会改变结果

请求到达代理前，客户端可能已经把目标域名解析成 IP，也可能把域名交给代理处理。两种方式会影响解析位置、错误表现和基于域名的规则判断。不能看到 SOCKS5 支持域名地址，就认定所有请求都必然在服务器端解析；Shadowrocket 的 DNS 与路由设置、应用请求方式和实际实现都可能参与其中。排查时应分别观察域名请求与已知地址请求。

同样，网页可用不表示实时通信可用。普通 HTTP CONNECT 的经典使用方式主要围绕 TCP；SOCKS5 虽有 UDP ASSOCIATE，但服务端、客户端配置及中间网络都必须满足要求。若实际任务依赖 UDP，应先确认入口明确提供该能力。缺少支持时，不是修改一个目标端口就能补上，而是需要已有服务端提供兼容的连接方式。

适用场景与 iOS 表现

当用户已有的是单位网络提供的 HTTP 代理，或个人环境中的 SOCKS5 入口，选择对应类型通常比强行改成其他协议更合理。其价值在于与现有服务接口匹配，而不是协议名称听起来更通用。若入口只适用于可信局域网，应把这个网络边界视为配置的一部分；连接环境改变后，需要重新评估认证保护、网络可达性和允许访问的范围。

较少的协议内处理并不保证更低的总耗电。没有额外加密的连接可能减少某部分计算，但目标自身的 TLS、网络重传以及应用请求频率仍然存在。代理服务器若处理缓慢，设备可能花更长时间保持无线活动。比较时应同时记录成功率、请求等待和持续任务完成时间，不要仅看一次延迟测试，便把普通代理当作所有场景的性能答案。

出现只能访问部分目标的情况，应先确认代理的访问策略和目标端口限制，再检查本地规则。若身份认证被拒绝，则回到用户名、密码和来源网络范围；若握手成功后目标超时，则继续检查解析与服务器到目标的路径。这样的分层方法比不停更换协议类型更有效，也能给自己的服务商提供明确的问题描述，而不是只有“无法使用”四个字。

06 / WireGuard：密钥、Peer 与地址路由

它处理的是网络层隧道

WireGuard 的设计围绕网络层隧道、精简的密码学组合和以公钥识别对端展开。与填写单个代理密码的类型相比，它通常要求用户同时理解本地接口地址、对端身份、连接入口和允许进入隧道的地址范围。参数看起来更多，并不是每个字段都承担认证；其中一些描述身份，另一些描述如何把网络包送到正确位置，必须分别理解。

Private Key 属于当前客户端的私钥，Public Key 用于表达对应身份；Peer 的 Public Key 则指向远端对等端。把客户端自己的公钥填入远端公钥栏，会使双方身份关系不成立。Preshared Key 如果配置提供，是额外的共享密钥，并不替代公私钥配对。真实密钥不应放进公开截图、文章或日志分享中，向他人描述问题时也应先删除这些内容。

Endpoint 与接口 Address 各有用途

Endpoint 指连接到远端的网络入口，通常由地址与端口组成。接口 Address 则是隧道内部赋给本端的地址，可能带有前缀长度；它不是远端服务器的公网地址。导入时应保留服务端分配的值，不能为了与家庭局域网看起来一致而自行更改。地址冲突、前缀错误或本端地址未被服务端接受，都可能形成握手正常但业务不通的现象。

Allowed IPs 参与对等端与地址前缀之间的关联，并影响哪些目标可以交给该对端处理。它不是允许访问的网站清单，也不是简单的备注。填写全地址范围和只填写局部网段，含义差别很大；同时还要考虑 Shadowrocket 的上层策略如何把请求交给这个服务器。隧道内部可路由范围与应用中的规则分流是两层约束，不能用其中一层自动替代另一层。

握手成功之后还要验证业务路径

握手只说明双方完成了相应的密钥交互，并不能证明地址分配、转发和 DNS 都正确。若握手可见而网页失败，应检查隧道地址、Allowed IPs、远端转发和解析设置。若完全无法握手，则优先检查 Endpoint、公钥配对和 UDP 可达性。把这两个分支区分开，可以避免在路由出错时反复重建密钥，增加服务端与客户端不一致的机会。

MTU 影响隧道中单个包的大小。底层网络能承受的包大小要扣除隧道开销，设置过大时，可能出现小请求正常、大响应停住的情况。调整应以可复现的现象为依据，并一次只改变这一项；不应把任意较小数字当成通用优化。若问题只出现在某个网络环境，还要考虑底层路径差异，而不是认为整份 WireGuard 配置都已失效。

保活、漫游与电量边界

WireGuard 通过 UDP 工作，网络地址变化后具有相应的对端端点更新机制，但实际恢复仍受移动系统调度、NAT 状态和网络条件影响。某些配置会使用 Persistent Keepalive 帮助维持映射。保活不是越频繁越好：过密的周期可能增加待机无线活动，过疏又可能无法满足特定网络的映射需求。应保留已有配置的要求，再基于明确问题调整。

在 iOS 上，长时间连续流量和长时间待机是两种不同负载。前者重点观察吞吐、热量与丢包恢复，后者重点观察是否存在持续后台业务和保活唤醒。不能把网络层隧道的结构简洁直接等同于任何场景都更省电。实际填表时，可结合WireGuard 字段逐项解读核对；如果手上只有单个代理密码，而没有密钥和地址信息，则不能据此自行构造一个可用的 WireGuard 条目。

07 / Hysteria2：UDP 路径与拥塞控制

围绕 QUIC 组织传输

Hysteria2 基于 QUIC 构建代理传输，QUIC 运行在 UDP 之上，并结合 TLS 完成相应的安全握手。它的设计关注包括高时延、丢包等条件下的传输表现，但这不是对所有网络都更快的保证。若所在网络限制 UDP，或者 UDP 路径质量明显较差，协议的设计优势也无法凭空绕过底层可达性这一前提，甚至可能表现为完全无法建立连接。

理解 QUIC 时应区分传输内的多路流与底层链路资源。独立流可以减少某些跨流阻塞，但它们仍共享无线链路、路径容量和拥塞状态；发生丢包时，具体流的数据依然可能需要恢复。不能把“多路”理解为带宽自动翻倍，也不能把它等同于所有请求都不会互相影响。服务器处理、目标响应与网络排队依然决定最终体验。

认证与证书字段分别保留

Hysteria2 条目需要匹配服务端的地址、端口和认证信息；启用的安全层名称与证书检查也应按照已有配置填写。Password 或对应认证字段不是 TLS 证书的替代品。即使服务器使用域名入口，也应核对 Server Name 是否与配置要求一致。若使用 IP 连接而证书面向域名，名称字段尤其重要，不应为了让所有栏位一致而清空它。

某些部署还会给出额外的混淆相关设置。这些参数属于双方约定的一部分，只有在服务端明确要求时才应启用，并保持类型与凭据匹配。随机填写一个混淆密码不会增强兼容性，反而可能让报文在进入认证阶段之前就无法被正确解释。通过订阅导入后，应先检查这些附加字段是否完整，再判断问题是否来自网络质量。

带宽参数不是加速倍率

涉及上行和下行带宽的字段用于为相应传输策略提供依据，而不是把线路容量提高到所填数字。填写远高于实际能力的数值，可能让发送行为与链路承受能力不匹配，造成排队、丢包或影响同一网络中的其他任务；填写过低则可能主动限制可用吞吐。还应留意单位，避免把每秒字节与每秒比特混淆，产生数量级上的偏差。

并非所有服务器配置都以同一种方式使用客户端提供的带宽信息，具体拥塞控制行为需要结合双方支持的设置理解。最稳妥的起点是已有配置和服务端说明，而不是套用别人设备上的所谓最佳值。若要调整，应先在稳定网络中建立基线，分别观察单任务下载、上行发送和网页交互，不要只追求一次峰值而忽略其他请求的等待时间。

移动网络下怎样判断是否适合

蜂窝网络的可用容量与时延可能随信号和小区负载变化。某一时刻测得的带宽，不一定适合之后的整段使用；在电梯、交通工具或弱信号区域反复测试，还会把无线变化混进协议比较。建议先在位置固定、信号稳定时验证基本连接，再观察真实移动过程中的恢复情况，区分固定配置错误与网络波动导致的暂时失败。

高吞吐、加密处理、重传和无线收发都可能提高设备功耗。Hysteria2 在某些路径上缩短任务完成时间，也可能在另一些路径上因持续丢包增加开销，因此不能笼统给它贴上省电或耗电标签。若用户已有多个兼容入口，应把相同任务的完成时间、稳定性和实际电量变化一起记录；如果只有一个入口，则先把字段核对正确，不必为了协议名更换全部配置。

08 / 按场景选择，再用规则与实测验证

先看已有条件，再比较设计取舍

最优先的选择依据是服务端实际提供的入口。已有订阅只包含一种协议时，先保证导入完整、认证正确和目标可达，不必根据协议排名自行改写类型。若用户确实拥有多个可用入口，才按任务比较：频繁网页请求关注解析与首个响应，持续下载关注吞吐与稳定性，实时应用关注 UDP 能力和时延波动，访问个人内部网段则关注地址路由是否准确。

对需要显式 TLS 与传输配置的入口，应优先考虑信息是否完整、维护时能否清楚核对；对网络层隧道，则要确认密钥、地址和路由范围都已提供；对基于 UDP 的传输，还要确认当前网络允许并稳定承载 UDP。协议选型不应只看字段少或名称新，能够准确表达已有服务、出现故障时能够分层定位，同样属于实际可用性的重要部分。

Global Routing 不改变协议身份

Global Routing 的配置、代理、直连，对应界面词 Config、Proxy、Direct。Config 按当前配置中的规则决定策略，Proxy 用于将相应流量交给代理策略，Direct 则采用直连路径。切换这些姿态是在改变路由决策，不是在更换服务器协议。若当前请求根本没有进入所选服务器，对该请求比较协议速度就没有实际意义，应先确认路径。

下面的片段用于说明规则顺序，需放在 Shadowrocket 配置的对应规则区域，并确认代理策略指向有效服务器。它不是完整配置，也不包含服务器凭据。DOMAIN-SUFFIX 先匹配指定域名后缀，GEOIP 再处理符合地区地址库条件的目标，FINAL 为剩余请求指定策略。实际是否需要地区规则，应由用户自己的访问需求决定，不能机械复制。

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

规则通常按顺序匹配，较具体的条件应放在合适位置；FINAL 应承担剩余连接的处理职责。IP 规则与域名规则拥有不同的输入条件，DNS 解析结果也可能影响判断。某个目标走 DIRECT，不能证明所选代理协议失效；某个目标走 PROXY 后失败，也不能直接证明规则语法错误。更多配置操作见设置说明，首次连接步骤见快速上手教程。

建立一份可重复的验证记录

验证时先在 Home 选中目标服务器，再确认 Global Routing，打开连接并执行 Connectivity Test，然后访问实际业务目标。测试工具的结果只覆盖它执行的那种检查，不代表所有协议能力、所有目标或所有规则路径。记录网络类型、所选条目、目标和失败阶段即可，不要公开订阅链接、密码或密钥；向自己的服务商反馈时也应先删除敏感内容。

若完全无法连接，按地址解析、端口与传输、TLS 或协议认证的顺序检查；若连接成立而部分目标失败，再检查 DNS、规则命中、UDP 与目标服务。性能测试则一次只改一个变量，避免同时换服务器、改传输和改路由。电量比较还应固定观察时长和屏幕使用方式，等待设备温度与后台任务相对稳定后再开始，不能把两次不同负载直接相减。

最后，把协议选择与获取客户端分开处理。iPhone / iPad 在 App Store $2.99 一次性付费，Mac（Apple 芯片与 Intel）、Windows、安卓、Linux 版免费；获取与安装相关问题统一查阅下载指南及其常见问题。本站是 Shadowrocket 官网与官方手册，不提供、不销售、不推荐节点或订阅。已有条目需要理解界面含义时，可阅读英文界面词对照；需要检查连接顺序时，可阅读首次连接操作说明，再回到本页核对对应协议的技术边界。