Shadowrocket 协议技术参考

选型前提：协议、传输与路由分层

在 Shadowrocket 中选择协议，首先是选择与服务器相同的通信约定，而不是为同一条连接添加一个速度标签。服务器只接受某种协议时，客户端必须使用对应类型；仅把 Add Server 中的类型改成另一项，并不能让服务器获得新能力。订阅导入的条目通常已经包含这些条件，手动编辑前应先保留原条目，避免把一个可以核对的问题变成多处参数同时变化的问题。

一条连接包含不同职责

可以把连接资料分成四层阅读：地址和端口决定接入哪里，协议及认证决定对方如何识别连接，传输及加密决定数据怎样送达，路由规则决定哪些请求交给这个条目。这些层彼此有关，但不能互相替代。密码正确不代表证书正确；证书有效不代表服务器接受该账号；规则指向 PROXY，也不代表当前选择的服务器一定可用。分层核对能解释“已连接但网页打不开”为什么仍有多种原因。

协议名称也不总能完整描述外层传输。VMess、VLESS 可以配合不同传输配置；Trojan 常见于 TLS 连接；Hysteria2 使用基于 QUIC 的传输；WireGuard 则建立网络层隧道。某个协议字段出现 WebSocket、Host、Path 或 SNI，说明还需要阅读外层条件。不能从名称推断这些值，更不能把其他条目中看起来相似的内容直接复制过来。

先限定条件，再比较表现

真正可选的范围是已有服务器同时提供、且当前客户端支持的配置集合。若只有一个有效条目，重点是正确填写与验证，而不是追求名称上的更新。若有多个可用条目，应先固定本地网络、目标网站和测试方式，再观察连接成功率、首个内容出现的时间、持续传输及后台行为。服务器位置、负载、带宽和中间网络均可能盖过协议本身的差异，跨服务器测试不能直接归因于协议。

数据安全同样需要分层判断。协议连接受到加密保护，并不意味着所有目标应用都会忽略自身的安全要求；目标网站的 HTTPS 仍承担端到端的身份验证。反过来，使用普通 HTTP 或 SOCKS5 接入时，也不能假定代理接入这一段自动具备加密。阅读资料时要区分代理链路、目标网站和域名解析三个环节，确认每一段由什么机制保护，而非只看一个锁形图案或名称。

Global Routing 不负责改变协议

Global Routing 中的 Config、Proxy、Direct 属于流量策略。Config 按配置规则处理请求；Proxy 让流量按代理模式处理；Direct 用于直接连接。改变这些选项不会把 Shadowsocks 转成 Trojan，也不会修复缺失的认证字段。排查时可用适当模式隔离规则因素，完成测试后再恢复日常配置，避免临时设置长期留存。具体操作顺序见教程中的规则说明。

本页讨论的是兼容性与设计取舍，不为任何协议作统一排名。协议可以改善某类网络条件下的传输方式，却不能增加服务器实际带宽，也不能消除无线信号差或账号失效。把“能否建立正确连接”和“建立后是否满足当前任务”分成两个问题，后续每章的参数解释才有明确用途。

Shadowsocks：加密代理的参数边界

Shadowsocks 的设计重点是以相对精简的代理协议承载连接，通过共享的认证与加密资料在客户端和服务器之间处理数据。它不是远程网络接口，也不要求把服务器所在网络的所有路由都交给客户端。对于用户而言，最重要的资料通常是服务器地址、端口、加密方法与密码；这些看似不多的字段必须逐项一致，尤其不能因为地址与密码相同，就认为加密方法可以自行更换。

加密方法不是可随意调整的偏好

不同方法对应不同的数据格式和密钥处理方式。常见的认证加密设计会同时检查数据是否被篡改，而不只是隐藏正文。客户端应使用服务器明确指定的方法；某些较新的方法还要求特定形式的密钥，不能按普通短密码理解。若原始资料给出一整段编码内容，应完整保留大小写、符号和末尾字符，不要为了方便记忆而改写，也不要自行增加空格或引号。

从链接导入能减少手工输入错误，但编码的外观不能代替核对。导入后应查看协议类型、地址、端口以及方法是否符合已有资料；遇到无法识别的链接，应先确认链接是否完整，以及是否包含需要另外支持的扩展。不要只复制浏览器中显示的一部分，也不要把显示名称当成认证字段。条目名称只是便于辨认的备注，对服务器验证通常没有作用。

TCP 与 UDP 需要分别成立

网页连接通常依赖可靠传输，但实时通信或部分应用还可能使用 UDP。Shadowsocks 是否能处理相应流量，取决于客户端设置、服务器支持和中间网络共同成立。网页可用而某项实时功能失败时，不能立即判定密码错误；应该先确认失败功能使用的传输，再核对服务器是否启用相应转发，以及本地网络是否允许该流量。一次网页访问成功只能证明该次访问的路径可用。

有些资料会附带额外的传输或插件参数。这些属于服务器部署的一部分，不是所有 Shadowsocks 条目的通用要求。只有地址、端口和密码，并不一定足以复现带扩展的连接。当前界面没有对应输入项时，应回到配置来源确认兼容性，而不是寻找名字相近的字段强行填入。协议支持与某项扩展支持是两回事，导入成功也不保证每项扩展都被实际使用。

在 iPhone 上怎样理解效率

精简的协议结构有利于减少额外处理，但不等于任何环境下都更快或更省电。加密算法能否高效执行、服务器处理能力、连接数量与无线网络重传都会影响结果。阅读页面与持续传输文件是不同负载：前者更关注连接建立和小请求响应，后者更关注稳定吞吐。若只比较一次大文件传输，就可能忽略日常应用反复连接时的实际体验。

在电量方面，保持少量稳定连接与不断失败重连的差异，常常大于两种正确配置之间的加密开销差异。出现后台用量明显变化时，先检查条目是否反复超时、是否由 On Demand 持续触发，以及网络切换后连接能否恢复。不能仅根据“Shadowsocks 参数少”就认定后台应当没有成本，也不能把系统记录的全部网络活动都算作协议本身的消耗。

排错顺序可保持简单：先确认原条目未过期，再核对方法和密码，随后检查服务器入口与本地网络，最后处理规则和解析差异。不要在一次失败后同时更换方法、端口与 DNS；那样即使恢复，也无法知道真正原因。保留一份已确认的参考记录，下一次订阅更新后才能辨认是服务端资料变化，还是本地编辑造成偏差。

VMess 与 VLESS：认证和外层传输分开看

VMess 与 VLESS 都经常出现在采用多种传输组合的服务器配置中，但二者不是同一个类型的不同名称。VMess 定义自己的认证及数据处理方式；VLESS 更侧重精简的身份和请求描述，把连接保护交给部署中配套的安全层。两者都可能涉及 UUID，却不能仅凭相同的 UUID 就互换。服务器监听的协议类型、传输方式和安全配置，需要与客户端完整对应。

为什么要区分协议与传输

这些协议的使用背景包含对传输组合和部署方式的需求，因此一个条目不仅描述“谁在连接”，还可能描述“通过什么外层抵达”。同样写着 VLESS 的两个条目，可能在外层传输上完全不同。看到 WebSocket 时，还要核对 Host 和 Path；看到 TLS 时，还要核对证书身份相关参数。任何一层不匹配，都可能让连接在到达真正的认证步骤之前就结束。

UUID 是身份标识，不是网站地址，也不是可以随意填写的设备名称。应逐字复制已有资料，不修改分隔符或把它换成另一条目的值。VMess 的认证还对时间有要求，因此系统时间明显不正确时，应先恢复自动设置并重新验证。时间问题也可能影响 TLS 证书的有效期判断，所以它不是 VMess 专有的排错项目，但在此类条目中尤其值得提前检查。

VMess 的兼容性资料怎样处理

旧资料可能带有额外的认证兼容字段，新资料则可能使用不同的认证约定。不要把历史教程中的固定数值当作所有服务器的默认答案，也不要为追求“现代配置”而自行修改已有有效条目。优先使用当前服务器提供的完整资料；若订阅与手填结果不同，应比较实际字段，而不是比较显示名称。无法确认的选项，应让资料提供方说明其在该服务器上的含义。

VMess 的数据保护不应与外层 TLS 混为一谈。外层是否存在、证书验证如何完成、是否经过中间转发，都是独立的部署条件。有的错误表现为认证失败，有的则停在握手或路径匹配阶段。诊断记录若能指出失败阶段，就先检查该阶段对应字段；没有明确记录时，也应按地址、传输、证书、认证逐层缩小范围，而不是反复随机更换加密选项。

VLESS 的精简意味着什么

VLESS 本身不应被理解为天然提供完整的链路加密。它减少了协议层承担的部分职责，因此外层安全配置尤其重要。资料中指定 TLS 或其他受支持的安全方式时，客户端必须按该组合配置；不能只保留 UUID 和端口就认为已经还原整个连接。若出现 Flow 等附加字段，也必须确认当前客户端与服务器确实支持相同组合，名称相似并不构成兼容证明。

Host、SNI 和服务器地址虽然可能填写同一个域名，职责却不同。服务器地址决定网络连接的目标；SNI 参与 TLS 中的服务名称选择；Host 可能参与外层请求的路由。Path 则可能决定 WebSocket 请求到达哪个处理入口。多层转发部署里，这些值不一致未必是错误，因此不能用“全部改成服务器域名”的方式统一它们。应以原始配置中每个字段的用途为依据。

速度取舍落在具体组合上

直接传输、WebSocket 和额外的安全握手可能具有不同的连接建立成本，但稳定连接会摊薄一次性成本。小请求多的任务与长时间传输因此可能得出不同结果。VLESS 的精简不保证端到端一定快于 VMess；服务器负载、外层转发和目标网站仍可能成为主要限制。在 iOS 上，应比较自己实际使用的完整条目，而不是用协议结构推算一个固定速度结论。

如果已有资料明确要求某个传输组合，就先验证这个组合，不先做性能优化。连接成立后，再分别观察首次访问、连续访问与切换网络后的表现。对安全参数进行调整前应保留原条目，尤其不能把关闭证书检查当作提速步骤。相关名词可交叉查阅术语手册，但字段最终仍以你已有服务器的说明和当前应用可用选项为准。

Trojan、HTTP 与 SOCKS5：代理入口的安全差异

这几类协议都可以作为代理接入方式，但它们对安全层和认证的安排不同。Trojan 的设计围绕 TLS 连接承载代理请求，并使用对应密码完成认证；HTTP 代理使用 HTTP 语义建立或转发连接；SOCKS5 提供更通用的代理请求协商。选择时首先看服务器实际提供哪一类入口，然后确认接入段是否受到加密保护，不能因为它们都能转发网页就当作完全等价。

Trojan：证书验证属于连接条件

填写 Trojan 时，地址、端口和密码只是基础，TLS 的服务名称同样重要。服务器地址可能是域名或 IP，但证书通常针对特定名称签发。SNI 用于在 TLS 握手中提示服务名称；证书验证则进一步检查对端身份是否符合预期。二者相关却不相同，填了 SNI 并不自动说明证书可信，也不能把任意域名作为通用值。应使用服务器资料明确指定的名称。

证书过期、设备时间错误、名称不匹配或中间证书链不完整，都可能阻止连接。遇到这些情况，应核对系统时间与原始资料，必要时由服务器管理者修复证书。允许不安全之类的选项会改变身份验证边界，不是通常意义上的兼容加速功能。即使某次关闭验证后能够连通，也只是帮助定位到验证环节，不代表原问题已经得到正确处理，更不应把该状态作为日常配置。

密码应按原始资料完整复制，注意尾部换行和空格。若服务器还使用额外的传输封装，相关路径与请求参数也要一起匹配；不能假定所有 Trojan 服务器都只有一种连接形态。需要逐字段说明时，可阅读Trojan 密码、SNI 与 TLS 参数说明。该文章解释填写逻辑，不提供服务器信息，也不替代你已有资料中的具体数值。

HTTP：区分代理接入与目标 HTTPS

HTTP 代理常见于明确管理的网络环境。对于 HTTPS 目标，代理通常通过 CONNECT 建立到目标地址的通道，目标应用仍应完成自身的 TLS 验证。但是目标网站使用 HTTPS，并不自动意味着客户端到代理的控制信息也通过独立 TLS 保护。若服务器提供的是带 TLS 的代理入口，应确认当前条目的类型或安全设置确实对应这种入口，而不是仅把端口改成一个常见数字。

代理账号和密码不同于网站登录资料。认证失败时，先检查是否需要用户名、密码是否准确，以及账号是否允许当前来源连接。不要把浏览器登录页面中的凭据直接当作代理认证，除非管理者明确这样说明。普通 HTTP 代理的能力也与部署有关，不能仅凭能访问一个网页，就推断它能满足所有应用流量；需要 UDP 的任务尤其要另行确认其适用性。

SOCKS5：通用转发不等于默认加密

SOCKS5 通过协商描述目标地址与请求类型，可支持域名形式的目标，并定义了相关认证与 UDP 转发机制。不过，协议本身不应被当作加密通道。实际部署可能限制认证方式、可连接目标或 UDP 能力；客户端与服务器共同支持时，相应功能才成立。仅看到 SOCKS5 这个名称，无法判断服务器是否允许某种流量，也无法判断接入链路具有什么保护。

域名由哪里解析也是重要区别。即使协议能够传递域名，实际请求仍可能先由应用或本地解析环节转换成地址。排查时要结合 Shadowrocket 的 DNS 与规则设置，不宜仅根据协议说明断言所有解析都会在远端完成。出现网站名称访问失败、直接地址却有响应时，应检查解析结果和策略命中，而不是立即更换代理账号或把所有问题归为认证失败。

对日常任务的选择应从已有环境出发：服务器明确提供 Trojan，就优先把证书与密码核对完整；受管理网络提供 HTTP 或 SOCKS5，就先确认管理要求及安全边界。不要为了看起来更简洁而舍弃必要的 TLS，也不要为了尝试更多名称而把已有条目批量改写。在 iPhone、iPad 上，正确且稳定的接入方式通常比反复重试一个不匹配的类型更有利于速度和电量。

WireGuard：网络层隧道与密钥配置

WireGuard 与前面几类面向代理请求的协议有一个重要区别：它描述的是通过加密隧道承载网络层数据的方式。其设计采用相对精简的协议和固定的密码学组合，减少大量可协商选项。使用者因此不必在许多加密方法之间选择，却需要准确处理本地接口、对端身份和路由范围。看起来字段较少，不表示可以缺失网络规划；地址、密钥和允许范围共同决定隧道能做什么。

Private Key 与 Public Key 的职责

本地 Private Key 用于标识并保护本端身份，Public Key 则用于识别相应对端。它们是一组有关系但不能互换的资料。复制配置时，不要把自己的 Public Key 填到对端身份位置，也不要把对端 Public Key 当作本地 Private Key。若原始资料包含额外的预共享密钥，双方也必须保持一致；它不是备注字段，更不是在连接不稳定时可以随意删除的项目。

本地私钥属于敏感信息。排查时可记录“已与原配置核对一致”，但不应将完整内容发到公开讨论中，也不要出现在公开截图里。更换本地私钥通常意味着服务器端也要更新对应身份关系，不能只在客户端重新生成后期待原服务器继续接受。若设备丢失或配置需要撤销，应由已有服务器管理者处理对端授权，而不是简单修改显示名称。

Endpoint、Address 与 Allowed IPs

Endpoint 指向对端接入地址及端口，本地 Address 则是隧道内使用的地址，两者用途不同。把公网接入地址填到隧道地址栏，或把隧道内部地址当作外部服务器入口，都会破坏预期连接。地址族也要匹配实际配置：资料只提供某一类地址时，不应自行补出另一类。DNS 字段通常描述解析安排，也不能拿来替代本地接口地址或服务器端点。

Allowed IPs 关联对端可承载的地址范围，也参与 WireGuard 的路由和来源校验逻辑。在 Shadowrocket 的整体处理链中，还需要结合应用的流量策略理解实际去向，不能把它简单等同于网站域名规则。范围过窄可能导致某些目标无法通过隧道，范围过宽则可能偏离原有网络规划。应按管理员提供的配置保留，不为“让全部可用”而任意扩大。

移动网络下的保活与恢复

WireGuard 使用 UDP，移动设备切换 Wi-Fi 与蜂窝网络后，网络映射可能变化。协议具有适应对端地址变化的设计，但实际恢复仍依赖新的通信能否到达、服务器是否接受以及本地网络是否允许。Persistent Keepalive 可用于在需要时维持某些网络映射，不过它会增加周期性通信。没有固定数值适合所有网络，应遵从已有部署要求，再观察后台和切网表现。

不应为了追求更稳定而无限缩短保活间隔。无线网络中，少量周期性数据也可能影响设备的休眠机会；若网络本身稳定且没有映射维持需求，增加保活未必带来收益。反过来，完全取消已有配置要求的保活，也可能使长时间空闲后首次请求失败。正确方法是在明确出现的问题上验证设置，记录空闲恢复是否改善，并结合系统电池用量观察代价。

MTU 与局部失败的关系

隧道封装会占用额外空间，因此路径的可承载包大小值得关注。MTU 不合适时，可能出现小请求成功而较大传输卡住、部分网站能开而另一些持续等待的现象。但这些症状也可能由其他原因导致，不能一见卡顿就修改 MTU。应先核对原值和服务器建议，排除规则、解析及信号问题后，再一次只调整这一项，并保留恢复依据。

验证不能只停留在握手是否发生。握手代表双方完成了某一阶段的通信，还要检查目标网段、DNS 与实际业务请求。若握手存在但业务不通，应优先核对隧道地址、允许范围和服务端转发条件，而非反复重建密钥。这样可以把身份问题与网络规划问题分开，避免在已正确的部分继续制造变化。

Hysteria2：QUIC 传输与带宽参数

Hysteria2 面向的一个设计问题，是在存在丢包、时延或波动的网络路径上保持可用的传输表现。它采用基于 QUIC 的传输，底层依赖 UDP，并结合相应的认证与安全机制。这里的“应对波动”是一种设计方向，不是对任何网络都有效的保证；如果本地网络不允许所需 UDP 通信，或服务器入口无法到达，改变协议名称不会绕过这些基本可达条件。

为什么不能把 UDP 理解为天然更快

UDP 本身不提供可靠有序传输，但上层协议可以在其上实现可靠数据流、重传和拥塞控制。Hysteria2 的表现来自完整传输设计，而不是省略所有可靠性工作。丢包仍然需要处理，服务器仍然有带宽和处理能力限制。较好的吞吐表现也可能伴随更高的实际发送量，所以比较时既要看完成任务所需时间，也要看是否对同一网络上的其他任务造成明显影响。

QUIC 可以提供多个流，减少某些跨流阻塞问题，但无线信号很差、上行拥塞或路径持续变化时，各流仍共享有限网络资源。不要把“支持多流”解释为单个请求完全不受其他请求影响。日常浏览与持续下载关注的指标也不同：前者可能更依赖解析和握手，后者更受稳定带宽支配。只展示一段持续下载速度，不能代表所有任务都适合相同配置。

认证、SNI 与证书仍要逐项正确

地址、端口和认证信息决定基础连接能否成立，TLS 相关设置决定对端身份验证是否符合预期。资料指定 SNI 时应保持原值，证书异常则按名称、有效期和信任链逐步处理。不要因为底层使用 QUIC，就认为可以跳过证书核对。若其他协议在同一服务器地址可用，也只能说明另一个入口可达，不能证明当前 UDP 入口以及对应认证已经正确。

某些服务器还会要求额外的混淆参数。这类参数必须与服务器一致，并不是启用越多越好。仅凭“连接失败”无法判断是否缺少它；应先阅读已有资料，确认是否有明确要求。若当前客户端界面没有某项扩展选项，需要确认支持范围或改用已有资料中明确兼容的配置，而不是把扩展密码放进普通认证栏，或者自行尝试相似的开关组合。

带宽字段表达的是条件，不是目标愿望

上传和下载带宽参数可能参与传输速率与拥塞控制行为，具体效果还取决于双方配置及实际协商。填写时要注意单位和方向：上传通常指客户端向网络发送，下载则相反；比特与字节不是同一单位。应按服务器说明和真实接入能力设置，而不是把数值填得尽可能大。过高的假定可能加剧队列积压与丢包，反而拖慢其他交互请求。

蜂窝网络的可用带宽会随信号、位置和网络负载变化，Wi-Fi 的外部接入能力也不等于路由器标注的无线连接速率。因此，单次峰值不宜直接作为长期参数依据。若已有资料没有要求手动设定，应保留合理的原始设置，先确认当前协商方式。调整后应测试连续任务与交互任务，而不是只看瞬间速度；改善必须能够在相近条件下重复出现才有参考价值。

iOS 上的电量与适用场景

当任务更快完成时，设备可能更早回到较低活动状态；但持续高流量、重传和连接维持也会增加处理与无线通信成本。这两种影响同时存在，所以不能把 Hysteria2 固定归为省电或耗电。对长时间传输，可关注总完成时间与温度变化；对后台空闲，则观察是否持续通信或重连。两种场景分别测试，结论才不会互相混淆。

如果已有服务器提供这一协议，并且当前网络允许相应 UDP 通信，可以把它纳入真实任务比较。若失败集中出现在特定网络，优先核对该网络条件；若所有网络都失败，则回到认证、证书和服务器入口检查。更多速度定位方法见网速慢的分层排查，不要在尚未建立正确连接时进行带宽参数优化。

速度与电量：建立可重复的比较方法

协议结构可以解释潜在开销，却不能直接给出某台 iPhone 上的体验排名。一次访问至少经过本地无线网络、域名解析、代理入口、服务器转发和目标服务。短板可能在任一环节，连接测试显示的数值也只覆盖特定测量过程。因此，应把速度问题拆成连接建立、首个响应、持续吞吐及失败恢复，再根据当前任务选择观察对象，避免用一个结果替代整条路径的评价。

固定变量，才有比较意义

选择相同设备、相同网络和相同目标，在相近条件下比较已确认可用的条目。开始前暂停与测试无关的大量传输，避免照片同步、系统更新或其他应用占用带宽。若两个条目对应不同服务器，就明确记录这个差异，结论只能是两套连接方案的比较，不能写成纯粹的协议比较。若目标内容被缓存，也要说明，否则后一次访问可能只是读取了不同位置的缓存。

不要为了追求整齐的数据而连续高频运行所有诊断。测量本身会消耗流量、增加服务器负载，并改变设备活动状态。先复现用户任务，再用少量针对性测试补足原因，通常比不断刷新测试列表更有效。第一次结果异常时可以在相同条件下复核，但不应只保留最好的一次。记录成功、失败以及网络切换条件，往往比记录一个峰值更能帮助定位问题。

Connectivity Test 能说明多少

Connectivity Test 的含义取决于测试方式与目标。结果正常可以说明对应测试路径在当时完成了预定步骤，但不能保证所有网站都可用，也不能证明持续带宽充足。结果超时同样不一定代表服务器完全停止服务：测试目标、解析、认证或本地网络都可能影响它。应把测试记录与实际网页或业务请求配合阅读，而不是只按列表排序决定协议优劣。

若页面等待很久才开始出现内容，优先检查解析与握手；若开始很快但持续传输缓慢，再考虑带宽、拥塞和服务器负载；若只有某个目标失败，则检查规则命中、目标自身状态与解析差异。需要完整的逐项排除顺序时，可阅读节点超时与连接失败核对清单。同一个症状可能对应不同层，测试应服务于缩小范围。

电池用量必须结合活动解释

iOS 电池用量页记录的是一段时间内的应用相关活动，百分比还受其他应用用量影响。它不是协议的独立功耗仪。若一段时间进行了大量下载、连接测试或后台传输，客户端相关用量升高并不意外。比较时应尽量保持任务、时长、屏幕状态和网络条件接近，同时观察设备是否发热、是否出现重复失败，以及耗电发生在前台操作还是后台空闲。

无线信号较弱时，通信成本可能明显变化；稳定 Wi-Fi 与不稳定蜂窝环境的结果不宜直接对比。加密计算当然有成本，但在许多移动任务中，无线通信、持续传输和反复唤醒也非常重要。减少无意义的失败重连，往往比修改某个已经匹配的算法字段更有实际价值。不能仅凭协议参数多少，推断它对电池的影响大小，更不能承诺固定的续航改善幅度。

On Demand 与保活不是同一件事

On Demand 决定在相应条件下如何触发连接，协议保活则通常用于维持现有通信关系或网络映射。前者不能修复服务器认证错误，后者也不能代替正确的按需规则。如果一个失效条目被条件持续触发，可能产生反复连接；如果保活过于频繁，则可能在空闲期间仍有通信。排查时应分别观察触发条件和连接后的行为，不同时改动两组设置。

后台问题可进一步对照On Demand 与后台耗电排查。最终选择应满足自己的常用任务：稳定打开、切网能恢复、空闲行为合理，再考虑持续速度。对很少执行的大文件任务表现出色，并不必然是日常浏览的最佳配置；保留不同场景下已验证的条目，比强求一个统一排名更实用。

填写与验证：从原始资料到日常 Config

把前面的原理用于实际操作，可以固定为“保存原资料、确认类型、核对字段、验证连接、恢复规则”五个阶段。这里不重复首次打开的全部界面步骤，具体点击顺序见快速上手教程。本章用于处理那些已经能够添加条目，却不确定导入是否完整、某个字段能否留空，或为什么代理连接正常而日常规则仍然失败的问题。

导入后先核对，不立即批量修改

使用自己已有的 Subscribe 信息时，应保留原始来源，并检查更新后条目是否属于预期分组。显示名称只是备注，不能据此确定协议和服务器相同。手工修改订阅生成的条目，还可能在后续更新时被覆盖，因此需要了解其管理方式。对需要试验的字段，优先保留原条目并建立可辨认的测试记录，不要在整个订阅组中同时替换地址、端口或安全选项。

订阅地址可能携带访问凭据，即使外观只是普通链接，也应按敏感信息处理。不要把完整地址贴进公开截图或错误报告；需要说明结构时，只使用明显的示例值。本页不需要用户提交任何真实配置。核对资料时，可逐项确认类型、认证、外层传输和安全字段是否齐全，再检查有没有复制时带入的换行、空格或被截断的内容。

按失败阶段选择检查分支

如果连服务器入口都无法到达，先检查地址、端口和当前网络；如果出现 TLS 或证书错误，检查时间、名称及信任链；如果进入认证阶段后失败，再检查密码、UUID 或密钥。已经能够建立连接却打不开目标时，则应转向 DNS、规则、服务器转发及目标自身状态。这个顺序不是保证所有记录都会显示明确阶段，而是防止在明显的证书错误面前反复修改密码。

只有某个网络失败时，保留同一条目分别验证两种网络；只有某个目标失败时，保留同一网络检查不同目标。这样一次只改变一个条件，结论才能被复核。若系统提示与应用记录互相矛盾，先确认测试时间和当前实际选中的条目。多次编辑之后，显示名称相近的副本容易混淆，应通过字段与分组确认对象，而不是凭列表位置判断。

用短规则验证策略，而不是堆叠配置

协议连接正常后，再把 Global Routing 恢复到日常需要的 Config。以下是 Shadowrocket 配置中可查阅的简短规则片段，仅用于解释顺序与策略，并非完整配置。示例中的域名不是服务推荐；PROXY、DIRECT 的效果还需结合实际选择的条目和当前配置验证。不要把片段追加到未知位置后就认为已经生效，应在 Config 中确认使用的是预期文件。

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

第一条按域名后缀匹配，第二条按地理 IP 条件匹配，最后一条为未匹配请求提供最终策略。规则通常按顺序处理，因此更具体的条件应放在能够正确覆盖它的位置。这里选择 FINAL,PROXY 只是展示语法，不代表所有用户都应让其余流量走代理。若目标是只处理指定网站，应重新明确最终策略，可参考指定网站的 DOMAIN-SUFFIX 配置说明。

确认结束条件与恢复路径

一次完整验证至少应覆盖实际任务、规则命中、空闲恢复以及你经常发生的网络切换。无需为了证明配置正确而访问大量无关目标，也不必长期运行连续测试。能够稳定完成自己的任务后，停止试验性改动，恢复必要的日常策略，并记录保留下来的设置。若测试失败，则还原刚修改的一项，再沿下一个分支检查，避免不断叠加临时调整。

向已有服务商或服务器管理者反馈时，提供协议类型、失败阶段、网络条件及经过删减的错误描述即可；真实密码、私钥、完整订阅地址和个人访问内容应当移除。若问题来自购买、已购恢复或商店兼容性，则转到已购恢复说明及该页常见问答，不把账号购买问题与协议认证混在一起。系统要求与是否通用购买，以 App Store 页面标注为准。

协议参考的作用是把问题定位到正确的层，而不是鼓励反复更换名称。地址与认证解决接入，安全层验证对端，传输影响数据抵达方式，Config 决定请求去向。始终按这条链路逐层确认，就能把“看起来都一样的连接失败”分成可以检查的小问题，也能在订阅更新或更换设备后保留清晰、可恢复的使用路径。