Shadowrocket协议手册

一、协议选型：先分清四层参数

协议类型必须与服务器一致

在 Shadowrocket 中选择协议，并不是从一组名称中挑选“最快”的选项。服务器监听什么协议，客户端就必须使用与之匹配的类型；同一个地址和端口，通常不能只改协议名称就继续连接。订阅已经提供类型时，应先保留原有设置。手动通过 Add Server 添加时，则先整理服务器地址、端口、认证信息，以及对方明确要求的传输与加密参数。资料不全时，返回已有服务的配置说明核对，比连续试换选项更有效。

理解配置时，可把它拆成四层：第一层是地址与端口，决定连接去哪里；第二层是协议与认证，决定双方用什么格式确认身份和交换请求；第三层是传输方式，决定这些请求如何承载；第四层是 TLS 等安全设置，决定连接如何验证身份并保护传输。部分协议将其中几层合并实现，因此并非每个添加页面都会出现全部字段。某一字段不存在，不等于功能缺失，也不应把其他类型的字段机械复制过来。

速度、电量与安全不是同一指标

速度至少包含建立连接、首个响应和持续传输三个环节。握手少，可能缩短首次打开网页的等待；拥塞控制合适，可能改善长时间传输；服务器负载较低，也可能让原本普通的协议表现更稳定。电量则还受无线信号、重传、后台唤醒和保持连接频率影响。单凭协议名无法推导固定的耗电顺序。在信号较弱的蜂窝网络中，反复重连造成的额外开销，有时比不同加密算法之间的差异更明显。

认证与加密也要分开看。密码或 UUID 用来识别使用者，并不自动意味着每一段传输都已加密；TLS 加密了客户端到服务端的通道，也不意味着服务端到目标网站的所有连接都由该协议负责保护。访问网站时仍应关注网站自身的安全连接。选型的实用起点，是确认完整链路的配置边界，而不是寻找一个能概括所有安全属性的名称。

协议与分流各自解决什么问题

Global Routing 决定流量是否交由规则选择处理路径，协议则决定被交给服务器的连接如何传输。配置模式 Config 按当前配置处理；代理模式 Proxy 将适用流量交由所选代理处理；直连模式 Direct 直接访问。切换这三种模式，不会修复错误的密码或端口；更换协议，也不会自动修正误写的 DIRECT 或 REJECT 规则。诊断时要把“是否经过服务器”与“经过服务器后能否通信”分别验证。

建议先保存能够复现问题的原始配置，再逐项调整。服务器名称可用于辨认，但不能证明其实际协议；同样，地区标签不等于物理距离或实际路由。导入前后如果同名条目出现差异，应比较字段而非仅比较名称。涉及协议选项的具体呈现，以当前应用内可见项目为准；本页解释字段含义，不把某种服务器组合视为所有用户都应启用的默认值。

二、Shadowsocks：紧凑转发与加密方法

设计重点是较轻的代理封装

Shadowsocks 的设计围绕加密代理转发展开，将目标地址与应用数据封装后交给服务端处理。它不是完整的设备组网协议，也不要求为设备分配一套隧道内网地址。对客户端使用者而言，核心信息通常比较集中：服务器地址、端口、密码和加密方法。字段数量较少能降低人工输入的复杂度，但并不代表可以忽略其中任何一个；尤其是加密方法，必须使用服务器实际配置的值。

早期的流加密方法与后来的 AEAD 方法，在完整性保护和消息处理上存在区别。AEAD 同时处理数据机密性与完整性校验，不能因为名称相近就与旧方法互换。不同协议代际也可能对密钥长度、编码和认证结构有不同要求。如果资料给出的是指定格式的密钥，不应自行改成普通短密码；若客户端不能识别该组合，应先确认双方支持情况，而不是仅挑一个看起来相似的名称。

Password 与加密方法要成组核对

Password 是敏感认证信息，复制时应留意首尾空格、换行以及全角字符。加密方法决定如何使用相应密钥材料，两者需要共同匹配服务端。输入后能够保存条目，只表示表单被接受，不表示远端认证成功。若延迟测试有结果但网页仍无法访问，也不能据此认定密码一定正确：不同测试路径可能只检查部分连接过程，应结合实际请求与应用内记录判断。

部分已有配置还包含额外的传输扩展参数。这些参数属于服务端组合的一部分，不是让普通条目自动变快的开关。不要把其他条目中的 Host、路径或扩展选项复制到当前条目，也不要在缺少说明时任意开启。来自已有订阅的条目如果更新后恢复了原值，通常说明订阅仍在管理这些字段；需要比较时，可另存测试条目，避免一边手动修改、一边被更新覆盖而失去诊断依据。

TCP、UDP 与实际体验

Shadowsocks 可涉及 TCP 与 UDP 转发，但两种流量能否正常通过，还取决于服务端能力和中间网络条件。网页文字能够加载，不代表依赖 UDP 的应用请求也一定正常；反过来，某个应用没有声音或长时间等待，也不能立即归因于协议本身。先确认已有服务明确支持哪些流量，再检查客户端相关设置。需要验证时，应选择实际使用场景中的少量请求，而不是持续运行大流量测试。

在 iPhone 上，紧凑封装可能使常见短连接的处理路径较直接，但加密算法、设备硬件、服务器带宽和网络丢包仍共同决定结果。不能把“结构简单”写成固定的低耗电保证。长时间下载时，屏幕状态与无线链路常会显著影响电量；待机时，连接保持和后台网络活动又可能更重要。比较两个已有条目，应尽量使用同一网络、同一内容和相近时间，避免把条件差异误记成协议差异。

常见排错顺序是先核对地址和端口，再逐字检查加密方法与密码，然后确认额外传输参数及 UDP 条件。若只有部分网站失败，转到规则、DNS 和目标可达性检查，不要马上重建条目。若所有请求都失败，而直连网络正常，则保留失败时间和错误类别，检查远端监听与认证状态。需要区分节点测试与实际网页表现时，可参阅延迟测试与实际体验说明。

三、VMess 与 VLESS：认证、传输与 TLS

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

VMess 将用户认证与数据传输封装结合起来，使用 UUID 等信息识别使用者，并在协议层处理相应的安全与数据格式。VLESS 则采用更精简的协议设计，将安全通道的职责更多交给 TLS 等外层机制。两者可能都出现 UUID、传输方式和 TLS 字段，因此界面观感接近，但它们不是同一种协议的两个显示名称。服务器配置为其中一种时，客户端不能仅替换类型并沿用所有参数。

精简并不等于所有情况下都更快，也不意味着可以省去安全设置。VLESS 本身不提供与 VMess 相同的数据加密职责，实际保护取决于整个传输组合。阅读已有服务的说明时，要把协议名与传输、安全配置作为一个整体。例如“使用 VLESS”只是配置的一部分，仍需知道连接入口、认证标识、外层安全方式，以及是否存在指定的传输参数。不能从协议名称推断这些字段的默认答案。

UUID、时间与历史参数

UUID 是认证标识，应完整保留其格式和字符，不要把它当作可随意起名的备注。订阅导入后，应先检查协议类型和标识是否正确解析，再看附加选项。VMess 的认证过程对时间条件有要求，因此设备时间明显偏离可能造成握手失败；可先确认系统日期与时间正常。不要因为看到网上的旧字段说明，就向当前条目补入历史参数，或把旧组合视为所有服务器都兼容的设置。

若条目中出现 Encryption 等字段，其意义需结合所选协议理解，不能把一个协议中的取值照搬到另一个协议。客户端允许填写某项，也不意味着远端接受全部取值。手动添加前最好列出“明确给出的字段”和“资料中未提到的字段”，对未提到的项目保留应用适用的默认状态，必要时向已有服务核对。随意试填会同时引入多个变量，使后续错误无法定位到原始原因。

WebSocket、gRPC 与证书名称

WebSocket 是一种传输承载方式，常涉及路径与请求 Host；gRPC 组合可能涉及服务名称等参数。路径通常区分大小写，开头斜杠、尾部字符与转义也可能影响匹配。服务器地址负责找到入口，Host 用于相应请求的目标处理，SNI 则用于 TLS 握手中的名称指示。这几个值有时相同，有时不同，应按已有配置填写，不能因为某个域名能解析，就将其同时填进所有名称字段。

TLS 验证需要证书与所使用的服务器名称相符，同时证书链能够正常验证。证书报错不应通过直接忽略验证来当作常规解决办法。先核对设备时间、SNI、地址输入和证书有效性，再检查服务端配置。ALPN 用于协商应用层协议，其取值也必须符合实际传输组合；随意增加名称不会增强兼容性，反而可能让握手结果与服务端要求不一致。

在移动网络中，多一层承载会增加一定封装与握手工作，但其实际影响取决于连接复用、服务器处理和网络质量。频繁打开短请求与持续传输大文件，可能呈现不同结果。排错时先让单个正确条目稳定连接，再比较已有可用组合；若发生“连接成功但页面不完整”，还需检查 DNS、规则与目标连接，不应仅围绕 UUID 反复修改。

四、Trojan：以 TLS 通道承载代理请求

把安全通道交给 TLS

Trojan 的设计重点，是在 TLS 连接内传递认证与代理请求，利用成熟的 TLS 机制保护客户端到服务端的通信。它与同样使用 TLS 的其他协议并不通用：TLS 只是外层安全通道，通道内部仍需遵守 Trojan 的认证与请求格式。服务器开放了一个安全网页端口，不代表该端口就能作为 Trojan 入口；客户端能够完成 TLS 握手，也不等于后续代理认证已经通过。

常见配置需要地址、端口、Password，以及匹配服务器的 TLS 名称信息。Password 是协议认证凭据，证书则用于确认所连接服务器的身份，两者解决不同的问题。密码正确而证书验证失败，连接仍可能被终止；证书正确而密码错误，同样无法正常转发。理解这一点后，便可将报错分成“安全通道未建立”和“通道建立后认证或请求失败”两类，不必每次都从头改动所有字段。

地址、SNI 与证书链的关系

地址可能是域名，也可能是明确提供的 IP 地址；SNI 是 TLS 握手中的名称指示，通常应采用服务器配置要求的名称。如果连接地址使用 IP，而证书签发给域名，就更需要核对名称验证条件。不能将“能连接到这个 IP”理解为“任意 SNI 都能使用”。若同一入口承载多个服务，名称还可能参与选择服务端处理路径，填错后得到的证书或响应也可能完全不同。

证书链验证涉及可信签发链、有效期和名称匹配。遇到错误时，先看系统时间，再确认地址及 SNI 没有多余字符，随后检查远端证书状态。不要将长期关闭验证作为普通使用建议，因为这样会削弱对服务端身份的确认。如果已有服务采用特殊的证书安排，应先明确其信任设置与风险边界，再按对应说明处理；不应从不相关的条目中复制一套验证开关。

握手开销与移动设备表现

TLS 握手会在建立连接时引入协商工作和往返等待，但这不是 Trojan 独有的成本，其他使用 TLS 的组合也存在类似过程。连接复用、会话恢复和网络往返时间会影响实际体验。短时间内打开多个网页，与长时间保持同一连接，表现可能不同。因此，“用了 TLS 就一定更慢”或者“某端口一定更省电”都不是可靠结论，仍应在相同网络条件下观察具体任务。

在 iPhone 从无线局域网切换到蜂窝网络后，原有传输连接可能需要重新建立。此时如果只出现短暂等待，应先观察能否恢复，不要立即认定密码失效；如果每次切网后都持续失败，则分别检查当前网络可达性、域名解析结果和服务器入口状态。重连次数过多会增加无线通信与处理开销，稳定的服务端设置和合理的连接行为，通常比反复切换高级字段更值得优先确认。

Trojan 能否转发 UDP，还取决于服务端实现、客户端相关能力及实际配置，不能仅根据类型名称推断所有应用都能正常运行。网页可用而某项实时通信失败时，应记录该应用涉及的网络条件，再检查 UDP 和规则路径。若只有单个目标失败，可对照开关已打开却无法上网的排查顺序，避免将所有问题都归入证书或协议类型。

适合保留 Trojan 的情形，是用户已经拥有字段完整、证书配置正常且实际测试稳定的对应入口。若现有资料只提供密码而未说明所需名称或传输组合，应先补齐信息；不要为了追求某种协议印象，主动把其他可用条目改为 Trojan。选型最终应服从服务端能力、使用任务和维护成本，而不是只看某一次连接测试的数字。

五、HTTP 与 SOCKS5：通用代理的边界

连接代理与访问网页不是同一层

HTTP 代理源于常见的应用层请求转发需求。访问安全网站时，客户端可通过 CONNECT 请求建立到目标的隧道，再由目标网站自身的 TLS 保护相应网页通信。这里有两条不同的关系：设备到代理服务器之间是否加密，以及设备到目标网站的内容是否由网站自身的安全连接保护。目标网址采用安全连接，并不能反向证明设备到代理的所有请求和认证元数据都已得到同样保护。

当已有入口明确使用 TLS 保护代理连接时，应使用应用内与之匹配的类型和安全设置，而不是仅因为目标网站是安全网站就自行开启。普通 HTTP 代理端口与安全代理端口可能不同，认证条件也可能不同。服务器地址、端口、用户名与密码必须成组核对。出现认证失败时，检查凭据及服务端权限；出现握手失败时，则先确认是否误将普通入口当作 TLS 入口。

SOCKS5 更关注目标连接的转交

SOCKS5 提供通用的代理协商与目标地址表达方式，不以理解网页内容为前提。它可使用不同的认证方式，也定义了 UDP 相关转发机制，但协议本身不自动给全部通信增加加密保护。用户名与密码用于认证，不应被误解为已经建立安全通道。已有服务若要求额外保护，应按实际部署核对；仅看到一个 Password 输入框，不能判断连接具备何种机密性。

SOCKS5 的 UDP 转发需要服务端支持，也需要中间网络能够承载相应数据。TCP 连接正常而 UDP 请求失败，是可能出现的边界情况。如果某项任务依赖实时数据或特殊应用流量，先查看已有服务对 UDP 的明确说明，再观察实际请求。不应通过反复改变端口来猜测能力，更不应把某次网页测试成功写成“所有流量已经验证通过”。

域名解析位置影响结果

代理请求可以携带目标域名，也可能在某一阶段已经转为目标 IP；实际 DNS 路径还受应用、Shadowrocket 配置和服务端处理方式共同影响。因此不能简单宣称某种通用代理永远只在本地解析，或者永远只在远端解析。若直接使用 IP 能访问、使用域名却失败，应检查 DNS 返回结果、规则匹配和代理请求中的地址形式，而不是只重输认证密码。

企业或自有网络中的代理还可能限制目标端口、目标地址或请求方法。认证成功只是获得相应访问权限的一个步骤，不代表能够访问任意目标。HTTP CONNECT 被拒绝时，可能是目标端口不在允许范围；SOCKS5 请求被拒绝时，也可能是远端策略或目标不可达。应以错误发生阶段来划分责任：入口不可达、认证失败、目标被拒绝、目标建立连接失败，各有不同检查方向。

在 iPhone 上，这两类入口适合已有环境本来就提供相应代理的情况。它们字段较熟悉，却不必然比其他协议快或省电。若远端限制较多，应用可能不断重试，反而增加等待与通信开销。验证时先用权限范围内的一个实际目标，再检查需要使用的应用类型。不要为了统一条目外观，将已有加密协议转换为 HTTP 或 SOCKS5；协议类型不同，服务器端必须有对应入口才能工作。

六、WireGuard：密钥、隧道地址与路由范围

从代理连接转向网络层隧道

WireGuard 面向网络层隧道设计，使用固定的现代密码学组合和基于公钥的对等端身份机制。与围绕单个代理请求工作的协议相比，它更强调对等端、隧道地址以及允许承载的网络范围。因此，配置中除了入口地址，还可能出现本端私钥、对端公钥、隧道内地址和路由相关信息。字段看起来更多，并不表示每项都需要用户自行决定；通常应按已有服务器提供的完整配置逐项核对。

WireGuard 主要基于 UDP 传输。网络允许普通网页访问，不等于它也允许到指定入口的 UDP 通信；同样，一个端口的 TCP 探测结果不能证明相同编号的 UDP 入口可用。若隧道始终没有有效握手，应先确认地址、端口、网络条件和对端密钥，而不是把问题归入网站规则。服务器入口能否收到请求，与隧道内某个目标能否访问，是前后两个阶段。

Private Key、Public Key 与地址各有用途

Private Key 属于本端敏感身份材料，不应发送到公开讨论区，也不应拿对端公钥代替。Public Key 用于识别对等端，服务端也需要知道允许接入的客户端公钥。若配置包含预共享密钥，应按双方约定一致填写，而不是临时生成一个只在本端使用的值。密钥格式符合表单要求，仅代表编码可能有效，并不表示服务器已经为这个身份配置访问权限。

隧道内地址与连接入口地址不同。入口地址负责让设备通过当前网络找到服务器；隧道内地址则用于隧道建立后的网络通信。把服务器公网地址填进本端隧道地址字段，通常不能得到正确结果。DNS 地址也应区分是否仅在隧道内可达：如果配置要求使用内部解析器，而隧道本身尚未建立，域名访问失败就可能是后续症状，不应先把所有 DNS 项目改成其他值。

Allowed IPs、MTU 与保持连接

Allowed IPs 参与定义对等端关联的地址范围与路由选择，不是一般意义上的网站白名单。范围过小可能使预期流量没有进入对应路径；范围过大又可能影响原本应走其他路径的连接。在 Shadowrocket 中还需结合当前 Global Routing 和配置的实际处理方式理解结果，不要把服务器端的地址范围说明等同于应用内每一条分流规则。修改之前，先明确所需访问的是内部资源还是普通互联网目标。

MTU 关系到单个网络包可承载的大小。封装后可用空间变小，某些路径上的分片或路径发现异常，可能表现为小请求可用、大页面或长传输停住。较低 MTU 有时能辅助定位，但设置过低也会增加包数量和处理开销，不能统一套用某个“最佳数字”。应以已有配置为基准，小幅、单项测试，并记录是否真正改善了同一个可复现请求。

保持连接机制可帮助维持某些网络设备中的映射，但定期发送数据也会带来通信与唤醒成本。蜂窝网络中不应为了“稳定”就把间隔一味缩短；如果当前连接已经稳定，没有理由盲目增加后台通信。比较电量时，还要排除 On Demand 条件造成的重复建立行为。WireGuard 的简洁协议设计有利于控制实现复杂度，但实际设备耗电仍取决于网络、传输量和连接维护频率。

这类方案适合用户已有明确的对等端和网络范围配置，尤其是访问自有网络资源时。排错先确认握手，再测试隧道内地址，最后检查域名和应用请求；如果顺序颠倒，可能把路由或解析问题误当成密钥错误。恢复时保留原配置副本，不要为了修复一个目标而直接扩大全部地址范围，也不要公开包含私钥的截图或完整配置。

七、Hysteria2：QUIC、带宽与弱网取舍

面向不稳定链路的传输设计

Hysteria2 基于 QUIC 构建代理传输，设计上关注较高延迟、丢包等条件下的数据传递。QUIC 通常运行在 UDP 之上，并整合安全连接与多路数据流机制。这里应区分两个结论：协议针对某些网络问题作了设计，并不意味着在所有网络中都更快；客户端提供该类型，也不意味着当前网络一定允许访问相应 UDP 入口。选型前必须先确认已有服务器提供的确实是 Hysteria2，而不是其他名称相近的入口。

基于 QUIC 的承载避免了某些将多个逻辑流简单叠在同一可靠字节流上的问题，但数据仍共享底层路径和可用带宽。严重丢包、服务器负载过高或网络对 UDP 处理不佳时，体验仍可能下降。不能把多路机制理解为“丢包不影响速度”，也不能把一次大文件测试的结果直接推广到小请求、实时通信和后台同步等不同任务。

认证与 TLS 仍需逐项匹配

常见配置包含入口地址、端口、认证信息和 TLS 名称相关设置。认证字段用于确认使用者，TLS 则负责安全通道与身份验证，其分工与其他协议一样需要分别理解。出现认证错误时，先核对已有服务提供的认证内容；出现证书或名称错误时，检查 SNI、系统时间和远端证书。不要因为协议使用 QUIC，就认为可以跳过证书验证或随意选择名称。

有些已有配置会要求特定的混淆参数或端口相关设置，这些都是双方协作的条件。只有客户端开启、服务端未采用相同设置时，可能无法正常通信。导入后应首先保留订阅解析出的组合；手动添加则依据明确说明填写。若资料没有提到某项扩展，就不要为了追求更复杂的配置而补上。界面中出现某个高级选项，是提供配置能力，不是要求所有用户启用。

带宽字段不是测得的实际速度

某些配置模式会使用上行、下行带宽信息参与发送行为控制。填写的数值应依据该字段说明、网络实际条件及已有服务要求理解，而不是照抄蜂窝网络图标所暗示的理论速率。数值填得更大不会凭空增加链路容量；估计过高，可能让链路更容易积压或丢包，影响网页响应和其他应用。估计过低，则可能限制本来可利用的吞吐，应在可复现任务中逐步观察。

还要留意单位。比特速率与字节速率并不相同，宽带标称值与应用下载显示值也不能直接逐字比较。若已有配置使用自动适应方式，不应仅为了“优化”改成手填带宽。若确实需要手动设置，应同时考虑上行能力：下载任务仍会产生确认和控制信息，上行被其他应用占满时，下行表现也可能恶化。测试期间尽量暂停无关的大流量任务，避免错误归因。

在 iPhone 上，弱信号下的高吞吐可能伴随更多无线活动、处理与重传，设备发热或电量变化不能只归因于协议名称。短时测试还可能受屏幕亮度、充电状态和后台任务影响。若主要需求是日常网页与消息，应优先比较稳定响应和切网恢复，而不是只追求单次峰值；若主要是持续传输，则还要观察长时间速率、目标服务器限制和电量成本。

遇到连接超时，先检查当前网络是否能到达该 UDP 入口，再看地址、端口与认证；若连接后只有部分内容卡住，再检查带宽估计、路径包大小、DNS 和规则。网络切换可能改变实际路径条件，即使底层机制具备相关能力，也不能保证所有现存请求都不中断。应记录失败发生在建立连接、切网还是长传输阶段，用具体症状决定下一步，而不是持续提高带宽数值。

八、按场景选择，并用分层方法验证

先用已有条件缩小候选范围

若用户只有一个完整可用的入口，实际任务是正确导入与验证，而不是在全部协议之间重新选型。若已有服务提供多个组合，可先排除当前网络无法承载的类型，再比较实际任务。经常切换无线局域网与蜂窝网络时，重点观察恢复时间及失败次数；访问自有网络资源时，重点检查地址范围、DNS 与权限；大量短请求场景关注建立连接和首个响应，持续传输场景则关注稳定吞吐。

测试时尽量保持同一设备、同一网络和同一目标内容，分别观察首次连接、重复访问与一段时间后的表现。一次只换一个条目或一个参数，不同时改变协议、DNS 和 Global Routing。Connectivity Test 可用于初步辨认入口状态，但测试数字不等同于完整网页加载时间，也不能代表所有目标。详细解释见延迟、地区与协议类型的取舍。

用最小规则确认流量走向

当前 Global Routing 为 Config 时，规则顺序会影响请求最终走向。下面是语法说明，不是可直接替代现有配置的完整方案；其中 example.com 仅用于示例，PROXY 所指向的实际策略应与当前配置一致。规则通常按顺序匹配，FINAL 承担前序规则未命中时的最终处理。即使服务器参数完全正确，如果目标提前命中 DIRECT 或 REJECT，观察到的行为也可能与预期不同。

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

DOMAIN-SUFFIX 依域名后缀匹配，IP-CIDR 使用地址范围，GEOIP 依据相应地址地理数据库判断，而不是按网站使用的语言判断。DNS 结果、目标是否以域名形式出现，以及前序规则都可能影响最终命中。不要把示例中的地域规则当成每个人都应使用的选择。需要测试协议时，先明确测试目标应走哪个路径，再观察记录中的实际处理，避免测到直连后误以为是在比较两个协议。

从入口到目标逐层排查

第一层检查设备当前网络是否正常，再确认入口域名、地址和端口；第二层确认协议、认证和传输字段；第三层检查 TLS 名称、证书与时间条件；第四层确认 Global Routing、规则与 DNS；最后检查目标本身及远端访问权限。若只在某个网络失败，优先比较该网络的可达性与传输条件；若所有网络都失败，则更应关注入口状态和共同配置，而不是分别修改每一处设备设置。

订阅更新后条目消失或字段变化时，先判断问题发生在导入解析阶段，还是已存在条目的连接阶段。列表为空并不是加密方法选择错误的典型证据，也不该通过修改 TLS 选项解决。可参照订阅导入失败或列表为空自查，核对链接完整性、已有服务状态和更新时机。订阅地址可能包含敏感凭据，分享问题时不要原样公开。

保留可恢复的配置与有效记录

每次测试记录网络类型、协议组合、改动字段和结果即可，不必公开完整认证数据。不要将私钥、密码、UUID 或完整订阅地址放入截图；错误信息也应检查是否夹带敏感内容。无效改动要及时恢复，避免留下多项叠加配置。需要回到操作流程时阅读快速上手教程，需要按问题查找时阅读常见问题，界面词与关键字可在术语表继续查阅。

最终选择标准是：与已有服务器匹配、当前网络可以稳定承载、所需应用流量能够正确处理，并且参数维护清楚。不要为了某一次测试领先而牺牲证书验证，也不要把更复杂的组合当成必然升级。先建立一个可复现、可恢复的正确基线，再对具体瓶颈作调整，才能分清协议设计的取舍与网络环境带来的差异。