Shadowrocket 协议技术参考

01 · 协议选型：先区分连接的不同层

已有服务决定可选范围

在 Shadowrocket 的 Add Server 中选择类型，是声明客户端应当使用哪一种通信格式，并不是让远端自动变成这种协议。同一个 Address 与 Port 不一定能接收多种协议；只有服务器明确提供了对应入口，切换类型才有意义。开始前应整理服务说明中的协议名、地址、端口、认证材料和传输设置。若通过 Subscribe 导入，先保留导入结果，不要因某个名称看起来更熟悉，就把已经识别的类型改成另一种。

协议主要规定客户端与服务器如何交换认证和代理请求；传输方式决定这些消息经由什么通道传递；TLS 则可以为通道提供加密与服务器身份验证。三者常在同一份连接资料中出现，但作用不同。例如 VLESS 与 WebSocket 并不是两个互斥的协议选择，前者描述代理层，后者可能承担外层传输。把这些层次拆开，才能理解为什么 UUID 正确，连接仍可能因路径或证书问题失败。

把一条连接拆成可核对的项目

这些项目存在先后依赖。地址解析失败时，修改认证字段通常没有帮助；服务器已经完成 TLS 握手后才拒绝认证，继续调整 DNS 也不会解决密码错误。日志里最先出现的、与失败直接相关的信息，比最后一个笼统的超时提示更有价值。记录错误发生在解析、建立通道、身份验证还是访问目标阶段，可以显著缩小检查范围。

速度与电量没有统一排序

在 iOS 上，实际体验同时受到无线信号、往返时延、丢包、服务器负载和目标站点影响。协议额外开销只是其中一项。一个握手步骤较少的设计，可能在短连接较多时更容易体现差异；持续传输大文件时，链路容量和拥塞控制通常更重要。不要把一次 Connectivity Test 的结果当作整条访问路径的吞吐结论，更不要据此推断所有目标的访问表现。

电量同样不能仅按协议名判断。加密计算会消耗资源，但频繁重连、无线模块持续活跃、过密的保活和反复重传也可能成为主要来源。比较时应保持设备、网络、屏幕亮度和任务一致，分别观察首次打开、持续传输和待机阶段。没有完成这些条件控制，就不适合给出某种协议必然省电或必然更快的结论。

还要把“支持某协议”和“支持该协议的所有组合”分开。某个外层传输、认证扩展或特殊字段是否可用，应以当前 Shadowrocket 的实际界面与已有服务说明为准。资料中若出现客户端没有对应位置的选项，不应随意塞入备注或其他输入框。先确认它是否属于另一层设置，再决定是否需要向原服务提供方补充询问。

02 · Shadowsocks：共享密钥与加密方法

设计目标与连接模型

Shadowsocks 围绕加密代理连接设计，常用共享密钥完成通信保护。客户端接收应用请求，将目标信息和数据按约定格式交给远端，再由远端连接目标。它与完整的 IP 层隧道不是同一个概念：协议主要处理代理转发，不会仅凭一个服务器地址就自动表达全部系统路由、内部地址分配或对等端关系。这种边界使参数相对集中，但仍需要客户端的路由策略决定哪些请求进入代理。

理解 Shadowsocks 时，最重要的是把加密方法当作协议兼容性的一部分，而不是可以任意调整的强度滑块。客户端和服务器必须使用一致的方法、密钥规则与消息格式。资料中看起来只差几个字符的方法名称，可能对应不同设计，不能按名称相近就互换。对于较新的方法族，密钥材料还可能具有特定编码或长度要求，不能默认任何普通文本密码都符合要求。

Address、Port、Password 与方法的对应关系

Address 填写已有服务给出的主机名或 IP 地址，不应把整条分享链接放进地址字段；Port 是服务端监听该协议的端口，不是网页地址中的任意数字。Password 必须完整保留原值，尤其注意复制过程中多出的首尾空格、换行和全角标点。加密方法应逐字符核对，不能因为界面提供多个选项，就选择一个看起来较新的名称替代服务端配置。

常见 AEAD 方法把数据保密与完整性验证结合起来，接收端可以拒绝无法通过验证的消息。密钥或方法不匹配时，表现可能只是连接关闭、目标无响应或认证相关错误，不一定出现明确的“密码错误”文字。因此，远端端口能建立连接并不能证明参数完整正确；必须进一步验证客户端能否通过该连接访问实际目标。分享链接导入后也应检查类型与字段，而不是只看列表里出现了一个名称。

TCP、UDP 与附加传输不是同一开关

网页访问中常见的 TCP 流量，与依赖 UDP 的应用流量可能具有不同结果。服务端、客户端设置和中间网络都要允许相应转发，才能形成完整路径。仅开启一个 UDP 相关选项，不会让不支持该能力的远端自动获得支持；反过来，某个网页正常打开，也不足以证明 UDP 路径可用。应按实际应用需求分别验证，而不是把所有失败归为服务器整体不可达。

部分连接资料还包含额外的传输或封装设置。这些内容不应与 Shadowsocks 的密码和加密方法混淆。只有已有服务明确给出并且当前界面提供对应配置时，才按原值填写。若导入链接遗漏附加参数，手工补齐时应先记录原配置，再一次修改一项；连续更换方法、端口和附加传输，会让后续无法确定究竟是哪一项导致变化。

在移动设备上怎样判断取舍

Shadowsocks 的参数层次较集中，适合作为理解“入口、密钥、方法”对应关系的起点，但这不代表它在任何网络里都占优势。持续传输时的表现仍受服务器出口和链路丢包影响；短时任务则还会受到名称解析与连接建立影响。iPhone 从 Wi-Fi 切换到蜂窝网络后，既有连接可能需要重新建立，恢复速度取决于整个链路，不能只从协议名推断。

排错时可按四步缩小范围：先确认 Address 能解析，再确认端口属于当前入口，然后核对方法与密钥，最后区分 TCP 与 UDP 的任务差异。若连接可以建立但仅部分域名失败，应转到本页的验证与分流章节检查规则和 DNS。不要为解决单个目标问题，反复修改已经能够成功认证的协议参数。

03 · VMess 与 VLESS：认证、传输及安全层

相似字段不代表两者可以互换

VMess 和 VLESS 都经常使用 UUID 作为用户标识，因此导入后可能呈现相似的地址、端口和身份字段。但它们不是同一种通信格式，不能只替换类型而保留其他项目不变。VMess 包含自身的认证与数据保护机制；VLESS 的基础设计更精简，本身不提供等同于 VMess 的载荷加密，通常需要配合经过正确配置的安全传输。二者的选择首先由已有服务器入口决定。

这种设计差异并不能直接换算为性能高低。VLESS 减少某些代理层职责后，外层 TLS 或其他安全机制仍有自己的成本；VMess 的实际表现也受到传输、复用和链路状态影响。如果一条资料只写“VLESS”，却没有说明外层安全设置，信息仍然不完整。不要看到认证字段存在，就误以为通道已经同时具备服务器身份验证与数据加密。

UUID、时间与认证失败

UUID 是结构化的标识值，应完整保留字符及分隔符，不能把显示名称、订阅地址或其他密码填进去。VMess 的认证设计与时间有关，设备时钟明显偏差时可能影响连接，因此认证失败时要检查系统日期与时间是否正确。对导入资料中出现的兼容性字段，应以服务端说明及当前客户端选项为准；不要从旧教程抄取一个数字，覆盖已经正常导入的值。

UUID 正确并不说明所有认证条件都满足。服务端可能已经停用某个用户、限制某个入口，或者更新了连接资料。遇到更新订阅后仍失败的情况，应比较新旧记录的协议类型、端口与传输项目，而不是只比较名称。名称相同的两条连接可能指向不同配置；名称不同也可能只是在同一入口上更换了备注。判断依据应始终是实际字段。

WebSocket、Host、路径与 SNI

WebSocket 为代理数据提供一种外层传输方式，其路径必须与服务端路由约定一致。路径通常包含开头的斜杠，大小写与其他字符也可能影响匹配。Host 可以参与 HTTP 请求的虚拟主机选择，而 SNI 在 TLS 握手中用于声明服务器名称。二者处于不同层次，即使在某份资料中取值相同，也不能据此认定它们永远应该相同。

使用 IP 作为 Address 时，服务说明可能仍要求填写域名形式的 SNI，因为连接地址与证书身份并不是一回事。正确做法是使用已提供且能够通过验证的名称，而不是关闭验证来绕过错误。若外层传输尚未成功，代理层的 UUID 甚至可能没有机会被服务端检查，这就是为什么需要先区分 TLS 错误、路径错误与认证错误。

按任务检查，而不是按名称排名

在移动网络中，额外封装会增加握手和报文开销，也可能改变连接恢复行为，但实际影响需要结合任务长度观察。短连接较多的页面、长期保持的会话和持续下载，关注点并不相同。若某组合在 Wi-Fi 下正常、蜂窝网络下失败，应先确认相同入口的地址解析、外层传输和端口可达情况，再分析协议本身。有关 Config 的总体用法可继续查阅功能说明，避免把路由选择问题误判为协议兼容性问题。

04 · Trojan：TLS 身份验证与密码认证

通道安全和用户认证分别负责什么

Trojan 采用基于 TLS 的连接设计，在受保护的通道中完成代理请求与用户认证。理解它时，应当把服务器身份和用户身份分开：TLS 证书用于帮助客户端确认正在连接哪一个服务器；Password 用于让服务器识别用户是否具有访问资格。密码正确但证书验证失败，连接仍然不应被视为正常；证书正常但密码不匹配，也不能完成代理访问。

这种分工说明 TLS 不是一个用于“尝试提速”的可选装饰。对普通 Trojan 连接，不能为了排错随意关闭 TLS，同时期待远端继续识别原有协议。已有资料若还包含特殊传输设置，应完整核对对应组合，而不是套用所有 Trojan 连接都只有三个字段的假设。基础协议与附加承载方式需要共同匹配，任何一层错误都可能阻止最终请求。

Address、Port、Password 与 SNI 的填写边界

Address 决定网络连接发往哪里，可以是服务提供的域名，也可以是在说明中明确指定的 IP。Port 必须是该 Trojan 入口的端口；看到 TLS 并不能推断端口必然为某个固定值。Password 按原始资料完整填写，注意复制工具是否带入不可见换行。SNI 则应使用服务说明指定的服务器名称，它可能与 Address 相同，也可能在 Address 为 IP 时使用另外给出的域名。

证书校验会涉及名称匹配、有效期、信任链及设备时间等条件。SNI 的作用不是把任意域名写进去就能获得有效证书，而是向远端声明期望的名称，并让后续验证与之对应。若证书名称不符，应先检查输入错误、服务资料是否过期以及服务器证书配置；若设备日期异常，则先修正系统时间。关闭校验会改变连接的安全属性，不应成为长期解决方案。

如何读懂连接失败的先后顺序

如果 Address 无法解析，问题发生在到达服务器之前；如果远端拒绝连接，先查端口与监听状态；如果出现 TLS 名称或信任错误，重点检查身份验证层。只有 TLS 通道建立后，服务端才有机会继续处理 Trojan 认证和目标转发。按这个顺序检查，可以避免在证书尚未通过时反复更改 Password，也能减少没有方向的参数组合测试。

还有一种情况是通道与认证都已完成，但目标网站仍打不开。此时应检查目标域名解析、远端到目标的连通性，以及本地请求是否确实选择了这条连接。若只有一个网站失败，不能立即归为整个 Trojan 入口故障。应使用另一个允许访问的目标作对照，并结合请求记录确认错误位于哪个阶段，而不是只看 Home 中的连接开关状态。

移动网络表现与使用建议

TLS 建立连接需要握手，其成本在高往返时延或频繁重建连接时更容易显现。持续会话建立后，实际传输则更多取决于链路容量、拥塞和目标响应。不能因为采用 TLS 就认定必然更慢，也不能因为某次测试耗时较短就认定后续任务始终稳定。iOS 的无线网络切换、休眠与重新唤醒都可能改变既有连接状态，需要单独观察恢复过程。

对于已有完整 Trojan 参数的用户，选择重点是证书验证能否通过、地址和 SNI 是否明确、网络切换后是否能恢复，而不是额外堆叠未知设置。若需要逐字段复核，可阅读Trojan 参数填写说明。保留一份确认可用的配置，再在副本中进行测试；订阅更新后也要确认正在检查的是当前生效记录，而不是旧的手工副本。

05 · HTTP 与 SOCKS5：通用代理的能力边界

HTTP 代理与 HTTPS 网站是两个概念

HTTP 代理来自通用代理访问模型，可以处理符合其约定的请求，并通过 CONNECT 等机制建立到目标的通道。一个常见误解是：目标网址使用 HTTPS，客户端到代理服务器之间就一定使用 TLS。实际需要分别观察两段关系。网站的 HTTPS 主要保护客户端与目标站点的应用数据；代理入口本身是否以 TLS 保护，则取决于代理类型和入口配置，不能从目标网址反推。

即使 CONNECT 后的目标内容受到 HTTPS 保护，代理仍需要知道连接哪个目标，并参与转发。因此，目标内容的加密不等于代理认证信息和全部连接元数据都获得相同保护。若已有服务提供加密的 HTTP 代理入口，应按其明确说明选择对应类型与安全选项；不要把普通 HTTP 入口随意改成另一种类型，再将握手失败理解为用户名错误。

SOCKS5 的协商、认证与 UDP

SOCKS5 是面向通用连接转发的协议，通过协商确定认证方式及请求操作。它可以表达目标地址和端口，也定义了 UDP 关联机制，但基础协议本身不提供 TLS 那样的通道加密。用户名和密码用于访问控制，不能与加密能力画等号。填入凭据之后，仍需理解客户端到代理这一段采用了怎样的保护方式，以及服务端具体启用了哪些能力。

SOCKS5 规范包含 UDP 相关功能，不代表每个服务入口和每条网络路径都支持它。服务端实现、访问策略、中间网络以及客户端当前设置都会影响结果。TCP 网页访问成功而某个 UDP 应用失败时，先检查实际服务是否允许 UDP，再核对转发路径。不能只因协议名里写着 SOCKS5，就将失败完全排除在协议或入口能力之外。

字段较少，也需要精确核对

这两类连接常见字段包括 Address、Port，以及服务要求时的用户名和密码。是否需要认证必须遵照已有资料，不能把空用户名与随意填写的用户名视为等价。若凭据中包含特殊字符，优先使用可靠的导入方式或在独立字段中填写，避免手动拼接分享链接时引入编码问题。备注名称仅用于本地辨认，不能代替任何认证字段。

名称解析与实际使用场景

请求可以携带域名，也可能在本地解析后携带 IP，这会影响名称解析发生的位置和后续规则判断。不能仅按“HTTP”或“SOCKS5”标签推断所有域名都一定在远端解析。排查时应同时检查 Shadowrocket 的 DNS 设置、目标请求形式和生效规则。如果同一目标用域名失败而用已知地址可以连接，才进一步核查名称解析路径，而不是立即更换用户名或端口。

在已配置的办公代理、测试环境或明确提供通用代理入口的场景中，这些类型便于与现有基础设施对接，但它们不是其他协议的通用替代项。在 iPhone 与 iPad 上，实际表现仍由认证、通道保护、目标连通性和系统网络共同决定。使用期间若需要恢复原始策略，应记录修改前的 Global Routing 姿态与 Config，避免一次测试影响后续所有应用。常见操作问题可转到疑难解答按现象继续查阅。

06 · WireGuard：对等端、密钥与隧道地址

从代理请求转向 IP 层隧道

WireGuard 面向 IP 层隧道设计，使用公钥标识对等端，并把网络数据包封装在 UDP 中传输。与只填写地址和密码的代理入口相比，它还需要表达隧道内部地址、对等端身份以及允许处理的地址范围。理解这些项目，才能判断一份资料是否完整。仅知道远端 IP 与端口并不足以建立正确关系，因为服务器还必须认识客户端的公钥，并为其配置相应的地址和转发行为。

把 WireGuard 用在 Shadowrocket 中时，还应分清应用自身的流量接管与某个远端协议的封装。iOS 显示 VPN 相关状态，是客户端获得系统网络处理能力的表现，不意味着当前所有出站连接都使用 WireGuard。最终仍需观察选中的服务器类型、Global Routing 和 Config；也不能仅凭系统 VPN 图标，推断隧道内部地址与远端对等端已经正常通信。

私钥、公钥与可选共享材料

客户端私钥用于本端身份与密钥协商，应妥善保存在自己的设备和备份中；服务器公钥用于识别远端对等端。这两个字段不能颠倒，也不能用同一个值填满所有密钥位置。客户端公钥由其私钥对应产生，远端需要按该公钥识别客户端。如果更换客户端私钥却没有同步远端配置，即使 Endpoint 不变，原有授权关系也可能失效。

部分服务还提供额外的预共享密钥，用于在既有公钥机制上加入共享材料。它既不是客户端私钥，也不是服务器公钥，必须按资料分别填写。不要将真实密钥贴入公开截图、错误报告或文章评论；排错时可以描述字段是否存在、格式是否符合要求，但不应公开原值。迁移设备时也要注意备份文件可能包含这些敏感内容，不能只把它当作普通规则文件。

Endpoint、地址范围与 DNS

Endpoint 指向远端实际可达的地址和 UDP 端口；隧道内部地址则属于隧道中的网络身份，两者处于不同网络层。把内部地址误填为公网入口，或者把 Endpoint 填入内部地址字段，都会破坏连接。地址范围相关配置用于表达哪些目的地址或对等端地址关系被允许处理，其实际作用还要结合客户端的路由集成方式理解，不能把它简单等同于 Shadowrocket 的域名规则列表。

IPv4 与 IPv6 也需要分别考虑。只配置某一地址族的路径，并不能证明另一个地址族具有相同连通性。如果域名优先返回 IPv6，而隧道或远端转发缺少相应支持，就可能出现部分目标失败。DNS 服务器是否可达同样重要：指定了某个内部 DNS 地址后，应确认它确实能通过已有隧道访问。不能仅因资料中写有 DNS，就认定解析路径已经自动正常。

保活、MTU 与移动网络切换

保活用于在需要时维持网络映射，尤其是在中间设备会回收空闲 UDP 状态的环境中。但更频繁的保活可能增加无线唤醒，因此不应为了追求“保持在线”随意缩短间隔。是否需要以及采用什么值，应依据已有服务说明和实际网络。移动网络切换会改变客户端可见的外部地址，WireGuard 的设计允许对等端在认证通信后适应地址变化，但恢复仍依赖新路径能够传送数据。

MTU 影响单个数据包可承载的大小。过大可能在某些路径上导致分片或丢包，过小则增加封装比例和报文数量。若表现为小请求正常、大页面或持续传输停滞，可以将路径 MTU 作为检查分支，但不能把它当成所有超时的万能原因。先核对密钥与握手，再验证内部地址、DNS 和目标转发，最后在明确证据下调整 MTU。配置备份与换机事项可参阅配置迁移说明。

07 · Hysteria2：QUIC、UDP 路径与拥塞取舍

设计出发点与兼容性边界

Hysteria2 使用基于 QUIC 的传输，依赖 UDP 路径，并结合认证与 TLS 相关机制建立代理通信。它的设计关注复杂链路下的数据传输与拥塞处理，但这种关注不等于任何网络环境都能得到更高速度。协议必须先有可用的 UDP 通路；如果当前网络不允许到达远端对应端口，调整带宽参数或密码不会绕过这个基础限制。

Hysteria2 的数字是协议名称的一部分，不是本页给出的 Shadowrocket 应用版本。导入时应确认服务说明确实提供 Hysteria2，而不是仅凭一个近似名称选择类型。协议代际、传输格式及可选设置可能存在兼容性边界，不能假设同一地址与认证材料在不同类型之间自动通用。当前应用是否提供某个附加选项，应以实际界面和已有服务说明为准。

入口、认证与证书需要分别验证

首先核对远端 Address 和 UDP 端口，然后核对认证材料与 TLS 服务器名称。地址指向实际通信入口，SNI 参与服务器名称声明与证书验证，二者可以根据服务配置采用不同表达，但不能任意猜测。若使用 IP 连接却需要域名验证，应使用服务明确给出的域名；不能把关闭证书验证当作补足资料缺失的办法。

某些连接资料还包含混淆或其他附加参数。它们不是认证密码的替代品，也不是默认必须开启的通用开关。只有服务器配置了对应能力，客户端才应填写一致的材料。遗漏、拼写错误或多余启用，都可能使报文在到达认证阶段之前就无法被正确处理。排错时应按照资料逐项比对，不要同时改变认证、安全和附加设置来碰运气。

带宽填写不是给连接设定实际能力

如果当前配置提供上行、下行带宽或拥塞相关选项，应先理解它们属于传输控制信息，而不是对服务端容量的承诺。某些控制模式会参考带宽估计，其他模式可能由实现自动判断；具体生效条件以对应设置说明为准。把数字填写得很大不会增加无线信号、服务器出口或目标站点的能力，反而可能带来更高丢包、排队或对同一网络其他任务的干扰。

填写时还要区分比特与字节，留意界面要求的单位。家庭宽带的标称速率也不等于 iPhone 当前无线连接的稳定可用速率，更不等于蜂窝上行能力。若缺少可靠测量，优先保留已有资料的建议值或明确支持的自动方式，而不是根据一次短时峰值填写。比较前后效果时要观察完成时间、失败率和其他应用是否被明显影响，不能只盯住瞬时峰值。

丢包、网络切换与电量观察

QUIC 在 UDP 上处理连接与可靠传输，为不同数据流提供自己的管理机制，但它无法让物理链路中的丢包消失。网络质量变差时，重传和拥塞控制仍然发挥作用；无线信号反复变化也可能使此前估计失效。某些环境对 UDP 的处理与 TCP 不同，因此同一台设备上，TCP 类型的入口可用并不能证明 Hysteria2 的 UDP 路径一定可用。

在 iOS 上，持续发送、重传和保持网络活跃都可能影响电量。需要分别观察持续传输与空闲阶段，且尽量排除屏幕、后台同步和设备温度的干扰。Wi-Fi 与蜂窝网络切换后，也不能仅凭 QUIC 的一般能力认定会话一定连续；服务器、客户端实现和新路径条件都参与结果。若主要任务是短时查阅且现有其他连接已经稳定，没有必要仅为协议名称更换全部配置。

建议先在相同网络、相同目标和相近时段中验证基础连通，再比较多次任务完成情况。如果只有 UDP 入口失败，优先收集端口可达与路径信息；如果所有入口都失败，则检查设备网络与目标。将“传输不能建立”和“已经建立但任务较慢”分成两个问题处理，才能避免使用不相关的参数调整掩盖真正原因。

08 · 从协议到实际请求：验证、规则与排错

先建立一条可重复的验证主线

完成协议参数核对后，回到 Home 选择待验证的连接，再检查 Global Routing。配置姿态对应 Config，按当前配置中的规则决定策略；代理姿态对应 Proxy，用于让相关流量按所选代理路径处理；直连姿态对应 Direct，主要用于直接访问。三者是路由姿态，不是不同的远端协议。Direct 下某个网站正常，并不能证明刚才填写的 Trojan 或 Shadowsocks 已经能够连接。

测试时先记录原姿态与当前 Config，选取一个明确的任务，例如打开同一网页并确认内容完成加载。Connectivity Test 可以作为连通性线索，但其结果受测试方法、目标和当时网络影响，不应替代真实任务。系统连接开关开启只说明客户端处于接管状态，也不等于每个请求都成功经过远端。验证应覆盖“选中正确记录、请求采用预期策略、目标完成访问”这三个环节。

规则先后顺序会改变观察结果

Config 中的规则按从上到下逐条判断，第一条命中后就决定策略。PROXY 表示交给代理策略处理，DIRECT 表示直接连接，REJECT 表示拒绝请求。即使协议参数完全正确，目标若命中 DIRECT，就不会按预期经过代理；目标若先命中 REJECT，也不会因为后面存在 PROXY 而继续尝试。排错时先确认实际命中项，不要直接更改已经通过认证的连接资料。

以下是用于说明顺序的 Shadowrocket .conf 规则片段，不包含服务器信息。例外域名放在范围规则之前，私有地址段采用 DIRECT，最后以 FINAL 接住前面没有命中的请求。示例中的域名只用于讲解，不代表实际服务；不能把这几行当作适合所有环境的完整配置。

[Rule]
DOMAIN,ads.example.com,REJECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,10.0.0.0/8,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT
FINAL,PROXY

如果把 DOMAIN-SUFFIX 放到前面，ads.example.com 会先满足范围规则，后面的精确拒绝规则便没有机会生效。IP 规则是否参与判断，还与请求中可用的地址信息和解析行为有关；不要仅凭规则文字推断每个域名一定会命中某个地址段。更完整的排列方法可阅读规则顺序与 FINAL 说明，首次操作仍以快速上手教程为主线。

按故障层次选择下一步

每次只改一项，并记录修改前后的具体结果。若更新 Subscribe 后记录发生变化，先确认当前选中的是否仍为预期入口；手工副本不一定跟随订阅更新。报告问题时可提供协议名、错误阶段、网络类型和脱敏后的字段结构，但应移除完整订阅地址、Password、UUID 与私钥等敏感材料。日志也可能包含访问目标，分享前需要检查。

用任务条件形成最终选型

需要与现有通用代理环境对接时，先核对 HTTP 或 SOCKS5 的认证、保护方式及所需能力；已有 Shadowsocks、VMess、VLESS 或 Trojan 入口时，重点是方法、传输和 TLS 的一致性；已有 WireGuard 资料时，检查对等端、内部地址和允许范围；已有 Hysteria2 入口时，优先验证 UDP 路径与控制参数。这些是检查重点，不是性能排行榜。

最终保留的连接应满足资料完整、身份验证符合预期、常用任务能重复完成，并且在实际网络切换和待机条件下表现可接受。不要为了单次测试数字更小，牺牲正确的证书验证或持续修改已经稳定的配置。应用购买、系统兼容性及恢复获取请返回App Store 正版下载指南；连接现象与界面操作可继续查看疑难解答。本页负责解释判断依据，教程负责把这些判断串成可执行的首次配置步骤。