Shadowrocket 协议手册

连接不是一个协议名称就能描述完整

一次代理连接通常包含目标地址、代理协议、承载传输、认证信息和安全设置。目标地址告诉客户端连接哪台服务器；代理协议定义怎样表达访问目标、怎样确认用户身份；传输负责把消息送过去；安全设置决定是否使用 TLS、验证什么证书。把这些层次合在一起看，才能解释“同样选择 VLESS，却只有其中一条连接能用”的情况：名称相同不代表端口、传输与认证也相同。

TCP 提供有序可靠的字节流，UDP 提供报文传输而不直接保证送达。WebSocket 是在既定连接上封装消息的方式，并不是与 Shadowsocks 平级的代理认证协议；TLS 负责建立受保护的通道，也不替代代理账户。看到订阅里同时出现协议名、WebSocket、TLS，应将它们理解成一组组合参数，而不是三个互相竞争的选项。客户端的实际可选字段以当前界面和连接资料为准。

地址、名称与端口分别核对

服务器地址可能是域名，也可能是 IP。端口是服务器具体监听的入口，不能因为某个协议经常使用某个端口就照搬常见数值。使用 TLS 时，连接地址与用于证书验证的名称可能不同：前者用于找到服务器，后者用于证明连接对象身份。如果资料单独给出 SNI 或 Server Name，应原样核对；仅将服务器地址换成 IP，不一定能保留原来的证书验证行为。

认证也有不同表达：密码、UUID、密钥对不能互换。UUID 即使外观像一串随机字符，也不等同于任意密码；公钥可以交给需要验证身份的一方，私钥则属于本机秘密。复制时要注意首尾空格、换行、大小写以及扫码内容是否完整。先判断字段属于哪一层，再决定查服务器管理员、检查系统时间，还是检查证书名称，可以避免在不相关的开关之间反复试错。

Global Routing 不会改变服务器协议

Global Routing 的配置、代理、直连分别对应 Config、Proxy、Direct。Config 按当前配置文件的规则选择策略；Proxy 将受客户端接管的请求按代理姿态处理；Direct 用于直连。这里描述的是路由决策，不是把服务器变成另一种协议。切到 Proxy 可以帮助排除“测试请求没有走到预期策略”的干扰，但无法修复错误密码、无效证书或服务器没有开启的 UDP 转发。

规则里的 PROXY、DIRECT、REJECT 是策略关键字，与界面姿态的大小写写法不同。规则从上向下匹配，命中即停止；FINAL 应放在末尾承担兜底。下面的 example.com 只是文档示例，不能用它验证你自己的服务器。实际验证应选择已知目标，查看连接记录所采用的策略；配置文件中的策略名称还必须与文件实际定义相符，不能把示例当成完整可运行配置。

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

此外，域名解析发生在哪一侧会影响诊断。客户端解析失败、服务器解析失败与代理认证失败可以表现成相似的加载超时，却属于不同环节。保留原始配置，先确认入口可达，再确认认证，再检查目标解析和规则。每次只改一项，才能把现象和原因对应起来。规则顺序的完整说明见自定义规则与 FINAL 兜底文章。

设计目标与演进方向

Shadowsocks 的设计重点是把代理请求封装到加密连接中，以相对简洁的交互完成目标地址传递和数据转发。它不是完整的网络层隧道，通常围绕 TCP 连接和 UDP 报文提供代理能力。理解这个边界很重要：应用是否被客户端接管、域名怎样解析、局域网地址是否直连，仍由系统接入方式和 Shadowrocket 配置共同决定，不能仅凭协议名判断所有流量的走向。

协议的加密方案经历过演进。现代资料中常见的 AEAD 方法将保密性与完整性校验结合起来，使接收端能够识别被修改的数据；不同代际的方案还可能改变密钥格式和报文结构。选择时应完全依据服务器给出的 Method，而不是只看名字相似。客户端列表中存在某个方法，不代表你的服务器已经启用它；把方法改成另一项，通常会直接造成认证或解密失败。

Method、Password 与附加参数

最基本的核对项是 Address、Port、Method、Password。Method 必须逐字一致，Password 要保留原始字符。部分较新的加密方案要求规定长度的编码密钥，不能用随意输入的短语替代；也不要将编码后的密钥自行解码再粘贴，除非连接资料明确要求。若导入链接包含附加选项，应先完整导入，再与手动添加时可见的字段逐项比对，避免遗漏服务器所依赖的设置。

有些连接资料还描述额外的封装或扩展。这些选项并不是 Shadowsocks 名称本身自动包含的能力，也不保证任意平台的任意客户端界面都采用相同呈现。正确做法是确认服务端实际组合以及 Shadowrocket 当前界面是否支持对应选项。如果资料只写“Shadowsocks”而缺少方法与认证信息，就还不足以建立连接，应向你已有服务器的管理方核对，而不是猜测一组常见值。

速度与 iOS 电量怎样理解

Shadowsocks 的交互结构相对紧凑，但这不意味着任何场景都最快。现代设备对部分加密算法具有硬件加速，另一些算法在不同芯片上有不同效率；报文长度、连接数量和无线信号也会影响实际开销。短网页主要受解析和连接建立时间影响，持续下载则更依赖链路容量与服务器负载。没有相同设备、相同目标和相近网络条件，就不能把两次测速差异全部归因于加密方法。

UDP 需要单独测试。服务器可能只开放 TCP，防火墙可能未允许 UDP，或者中间网络对 UDP 的处理不同。此时网页能加载而实时应用异常，并不矛盾。也不要因为 UDP 测试失败就立即更换密码：如果 TCP 已经稳定通过认证，先确认 UDP 转发能力、对应端口和服务器策略，通常比反复编辑已验证的认证字段更有效。协议支持报文不代表应用一定按预期走该入口。

在 iOS 上，影响电量的常见因素是网络扩展处理的数据量、连接重建、无线网络质量和后台唤醒。频繁短连接可能比少量稳定长连接更容易暴露握手成本；信号弱时的重传又可能掩盖加密差异。适合把 Shadowsocks 作为已有服务器提供的轻量代理选项来评估，而不是设定一个固定省电排名。保存可用配置，完成稳定性验证后再比较性能，能减少排错与测速互相干扰。

VMess 为什么包含更多协议内处理

VMess 在设计上把用户认证、请求信息和数据保护纳入自己的协议体系。客户端需要按约定构造请求，服务端才能识别用户并转发目标流量。它可以与不同承载方式组合，因此一条 VMess 资料除了服务器地址和 UUID，还可能涉及安全方式、传输类型和 TLS。历史配置中出现的兼容字段，不能据此随意增减；应以当前服务器实际使用的配置和可用导入资料为依据。

VMess 的认证过程对时间同步有要求。若入口可达，却在换设备后持续认证失败，应检查系统日期、时间和时区设置，优先使用系统自动时间。不要把“能连接到端口”理解为认证已经成功：网络层建立连接只是第一步，后续协议头和认证仍可能被服务器拒绝。重复点击测试不会修复时间偏差，反而容易把认证错误误判为不稳定的网络波动。

VLESS 简化了什么，又依赖什么

VLESS 的设计侧重轻量认证与请求转发，将数据保护更多交由外部安全机制承担。UUID 仍用于身份识别，但协议层不内置通用的数据加密，不能因此推断“整个连接一定没有保护”；当外层使用正确配置的 TLS 时，传输通道仍能受到保护。反过来，若外层没有相应安全机制，也不能因为选了 VLESS 就假定数据已经加密。安全属性需要看完整组合。

VMess 与 VLESS 不能仅通过保留 UUID、切换 Type 来相互转换。服务端必须监听相应协议，外层传输也必须匹配。某些连接资料可能包含额外的流控或安全选项，这些字段不是所有传输组合都适用。客户端没有显示某项时，应先核对当前选择的类型、服务器要求和支持范围；不要为了“让字段出现”随意切换到别的协议，导致原来正确的入口也失去对应关系。

WebSocket、Host 与 Path 的关系

采用 WebSocket 时，Path 是服务端用于接收对应请求的路径，通常需要保留开头斜杠及完整字符。Host 是 HTTP 层请求的主机信息，SNI 则用于 TLS 握手和证书选择；两者经常相同，但属于不同层，不能永远视为同一个字段。如果服务器前方存在反向代理，Path 或 Host 不匹配可能在代理协议开始认证之前就返回 HTTP 错误，因此改 UUID 并不能解决这类失败。

使用域名证书时，应保持证书验证开启，并核对 Server Name 是否与证书覆盖的名称一致。遇到证书错误，先检查系统时间、名称拼写、证书有效性及服务器证书链。跳过证书验证会削弱对连接对象身份的确认，不适合作为常规修复步骤。若管理员提供的是 IP 入口和单独的验证域名，应保留这种分工，不要把所有名称都统一替换成 IP。

在 iOS 上，VMess 与 VLESS 的耗电差异不能只由协议头大小推导。外层 TLS 握手、WebSocket 封装、连接复用和服务器距离都会影响结果；频繁重连时，建立连接的成本可能比稳定传输中的协议差异更明显。已有服务器只提供其中一种时，优先正确使用该组合；两种都提供时，固定目标与测试条件，比较首次打开、连续传输和网络切换后的恢复，而不是只看一次峰值速度。

Trojan 把安全通道放在前面

Trojan 的典型设计是在 TLS 连接内进行密码认证和代理请求传递，因此证书验证是理解其连接过程的关键。客户端先连接服务器并建立 TLS，再发送协议认证信息。若握手阶段已经失败，密码尚未进入有效验证流程；若 TLS 正常而认证失败，则需要核对密码及服务端协议配置。把两种错误分开，可以减少在证书问题上反复修改密码的无效操作。

Address、Port、Password 与用于 TLS 的名称应一起核对。SNI 帮助服务器选择相应证书和入口，但它不是任意可填的装饰字段。连接资料如果采用域名，先保持原值完成基础验证；只有在明确知道服务器结构时才调整地址与验证名称。Trojan 使用 TLS 不代表任何带 TLS 的服务器都能作为该协议入口，服务器仍需要实际提供相应代理服务和认证账户。

HTTP 代理不等于访问 HTTP 网站

HTTP 代理通过 HTTP 语义接收转发请求，访问 HTTPS 目标时常使用 CONNECT 建立字节通道。这里必须区分两段连接：客户端到代理服务器，以及代理服务器到目标网站。目标网站使用 HTTPS，并不自动使第一段成为加密的代理连接；只有代理入口自身采用受支持的 TLS 等保护时，第一段才具备相应属性。判断隐私边界时，不能仅看浏览器地址栏里的锁形标识。

HTTP 代理可能需要 Username 和 Password，也可能按服务器的其他访问控制方式授权。认证信息应来自已有服务器资料，不要将网站账号填进代理认证字段。若资料给的是受 TLS 保护的 HTTP 代理入口，应核对相应类型与证书名称；不要把它当作普通 HTTP 端口测试后，就断言服务器故障。HTTP 请求被接受，也不保证服务器允许所有 CONNECT 目标或所有端口。

SOCKS5 的通用性与明确边界

SOCKS5 通过协商表达认证方式与目标地址，是一种通用代理协议。它能够表示域名或 IP 目标，也定义了 UDP 相关机制，但基础协议本身不提供通用的传输加密。用户名和密码用于认证，并不等同于为后续数据自动建立加密通道。若使用场景要求客户端到服务器这一段受保护，就需要结合实际外层机制和可信网络环境判断，不能把“有密码”当成“全程加密”。

SOCKS5 的 UDP 是否可用，需要客户端、服务器和中间网络共同满足条件。服务端可能只实现 TCP 转发，UDP 关联返回的地址也可能受到网络可达性影响。域名解析究竟由哪一侧执行，同样要结合请求形式和客户端设置来看。使用 IP 成功而域名失败时，先检查解析路径；TCP 成功而实时应用失败时，再检查 UDP，不要把所有失败统一解释为账户错误。

这三种协议的选择应由现有入口决定。办公网络已有 HTTP 代理，就按其认证与访问范围配置；实验或本地网络已有 SOCKS5 服务，就明确其保护边界；已有 Trojan 资料，则保留完整 TLS 参数。不要因为名称听起来更复杂就替换类型。在 iOS 上，代理请求模式、握手频率和网络质量通常比一个孤立的协议标签更能解释加载速度与电量差异。

它与应用层代理的差别

WireGuard 面向 IP 数据包建立加密隧道，以较精简的协议结构和固定的现代密码套件减少配置复杂度。与主要转发连接请求的代理协议不同，它需要描述本端接口地址、对端身份以及哪些地址范围属于对端。因而一份 WireGuard 资料通常不只是服务器地址加密码，还包括本机私钥、对端公钥、隧道地址和路由相关内容。理解这些关系，比逐个记忆字段名称更有用。

WireGuard 以 UDP 作为外层承载，所以当前网络能否稳定传输 UDP 是基础条件。某些环境中网页直连正常，并不能证明 UDP 隧道入口也可达。端点域名解析、端口开放和服务器回程都需要成立。协议握手成功后，还要验证目标流量是否有正确路由，以及服务器是否允许相应转发；因此“显示有握手”与“所有目标都可以访问”仍然是两个不同结论。

PrivateKey、PublicKey 与地址归属

PrivateKey 属于本端秘密，PublicKey 用于让对端识别本端身份。服务器公钥不是客户端公钥，两边的字段不能对调。若资料还给出预共享密钥，它是另一项双方必须一致的参数，而不是替代公私钥的通用密码。不要在讨论截图或故障日志里公开私钥；导入资料中即使没有常见的 Password 字段，也可能包含能够直接建立连接的敏感身份信息。

Address 表示隧道接口中的本机地址，不是服务器公网地址，也不是任意可用的局域网地址。它通常由服务器管理方分配，并与对端配置相关。Endpoint 才指向外部可达的服务器端点。把 Address 改成服务器 IP，会混淆隧道内部与外部网络；自行复制另一台设备的接口地址和身份，也可能引起地址冲突或对端归属变化，应按已有服务器分配给当前设备的资料使用。

AllowedIPs、MTU 与保持连接

AllowedIPs 参与判断哪些目的地址交给该对端，也参与接收数据时的地址归属检查。它不是按域名排列的网站规则；是否与 Shadowrocket 的策略路由共同工作，需要结合当前导入方式和界面能力理解。资料只覆盖特定网段时，不应自行改成全部地址范围来“提高兼容性”，否则可能改变访问边界。若访问某个内网失败，要同时核对隧道地址、对端范围和服务器回程路由。

MTU 决定隧道接口承载的数据包尺寸边界。外层封装会占用空间，路径对分片或较大 UDP 报文的处理又可能不同，于是可能出现小请求正常、大响应停滞的现象。排查时先确认是否只有大传输异常，再按照服务器建议调整，不能把任意较小值当成通用答案。降低 MTU 会增加同等数据量所需报文数，过度调整也会带来额外开销，应记录每次修改后的具体变化。

PersistentKeepalive 可帮助某些网络维持地址转换映射，但持续发送报文也可能延长无线活动时间。在 iOS 上，应依据服务器要求与实际闲置断连现象决定是否使用，而不是把间隔一味缩短。WireGuard 的计算效率不能直接等同于整机省电：隧道承载流量、保持连接、信号强弱和网络切换都参与结果。适合需要明确网络层地址与网段访问的已有环境，前提是用户持有完整且匹配的对端配置。

设计取舍从承载方式开始

Hysteria2 基于 QUIC 构建代理传输，关注具有时延和丢包的网络条件下的数据传送。QUIC 在 UDP 上实现连接管理、可靠传输与拥塞控制等机制，所以“外层使用 UDP”不代表应用数据完全没有可靠性处理。与此同时，它仍需要可用的 UDP 路径：如果网络持续丢弃对应报文，协议内部机制无法凭空建立可达性。选型前先确认这一前提，比反复修改带宽参数更重要。

QUIC 的流机制可以减少某些跨流阻塞，但不能消除无线信号弱、共享出口拥塞或服务器容量不足带来的限制。单条连接中的实际效果还受客户端实现、目标响应和路径变化影响。Hysteria2 与其他代际协议的名称相近，也不意味着连接资料可以直接互用；Type、认证方式和附加参数都应匹配实际服务器。导入成功只说明资料能被解析，还要完成握手与访问验证。

认证、TLS 与可选封装

基础核对包括 Address、Port、认证信息与 TLS 名称。认证字符串由现有服务器提供，可能包含需要完整保留的分隔字符；不要只复制看起来像密码的一部分。TLS 的证书链、有效性和名称仍需正常验证。若客户端报告证书问题，应先检查系统时间及名称设置，再核对服务器证书；不能用持续关闭验证的方式掩盖配置错误，这会丢失对连接对象的可靠确认。

连接资料可能另外提供可选混淆相关设置。它与用户认证、TLS 证书是不同层次，双方必须采用相容配置；多填一个未经服务器要求的字段，也可能让服务器无法理解报文。没有给出的选项先保持默认，有明确提供的则逐项核对。遇到仅某个网络失败的情况，保留同一份资料切换网络测试，比在未知条件下同时修改认证、混淆与带宽更容易找到原因。

带宽值为什么不能随意填大

某些配置允许填写上传、下载带宽，用于相应拥塞控制模式的速率估计或上限协商。其效果取决于客户端和服务端配置，不是输入多大就能获得多大吞吐。填写远高于实际可用容量的数值，可能造成队列增长、丢包或与其他流量竞争；填写过低，则可能限制可用吞吐。应先核对单位，分清 bit 与 byte，并按当前接入链路和服务器建议给出合理值，而不是照搬别人的测速截图。

移动网络的容量会随信号、位置与基站负载变化，一份固定估计不一定适合所有时段。若从稳定 Wi-Fi 切到蜂窝后出现明显抖动，首先比较网络本身的可用容量，再判断带宽配置是否过于激进。使用默认或协商行为时，也需要实际观察短请求和持续传输，不能仅根据参数更少就认为必然更优。所有性能调整都应有明确现象、一次变更和可回退的记录。

在 iOS 上，较积极的数据发送、丢包恢复与持续大流量可能增加无线活动时间和发热。即便一次下载更快，也不代表全天使用一定更省电；反过来，更短时间完成同样任务也可能减少总活动时间，结果需要实测。应同时比较任务耗时、失败率和相近使用时长内的电量，不把任何单一现象当成结论。测试时关闭无关的大流量任务，避免把后台下载算到协议头上。

适用场景应描述为“现有服务器提供 Hysteria2，当前网络 UDP 可用，并有必要评估丢包条件下的表现”，而不是无条件替代所有 TCP 方案。若同一服务器的其他入口正常，只有这一入口在某个接入网络失败，先考虑路径对 UDP 的处理；若所有网络都失败，再回到服务器监听、认证与证书。按条件缩小问题范围，通常比不断尝试更高带宽更有价值。

把“快”拆成可以观察的过程

网页打开包含域名解析、连接建立、代理握手、目标握手以及内容传输。首次加载慢，可能是前面几步耗时；大文件下载慢，则可能是持续吞吐受限。Connectivity Test 的结果只代表所采用测试方式与目标的表现，不是所有应用的综合速度，也不一定等于底层网络的往返时延。比较协议时，先说明测试在回答什么问题，再决定记录哪些现象。

公平对照应尽量固定设备、接入网络、服务器地区、目标服务和测试时间范围。同名服务器也可能走不同出口，负载会随时间变化；连续测试时设备升温，又可能影响后面的结果。可以交替测试两种可用配置，并重复短请求与持续传输，而不是先把一种跑热，再测试另一种。结果差距较小时，应保留波动范围，不必强行归纳成某种协议永久领先。

电量不是只由加密计算决定

iOS 的代理工作通常涉及网络扩展、数据包处理以及系统无线连接管理。密码计算会消耗资源，但屏幕、蜂窝信号、重传、后台任务和保持连接也可能占据重要比例。系统电池页面给出的归属是综合结果，并不能直接分离某一协议的每次计算成本。若代理期间同时看视频、下载或长时间亮屏，不能把整段电量变化全部记为 Shadowrocket 的协议开销。

应把空闲与活跃使用分开观察。空闲测试关注是否频繁唤醒、重连或发送保持报文；活跃测试关注同样任务需要多久、是否发热和失败重试。On Demand 会依据条件触发连接，它不是降低协议成本的按钮。若配置导致网络切换时不断重建，实际体验可能比持续连接更差。先明确是否需要自动连接，再检查触发条件是否符合日常网络环境，避免为了省电反而制造更多切换。

TCP、UDP 与网络切换的实际影响

TCP 在丢包时需要恢复有序字节流，链路质量差可能拉长等待；UDP 承载的上层协议也需要自己的恢复与拥塞管理，并非天然没有等待。实时应用更关注持续抖动与报文送达，网页更关注短事务完成时间。一次大文件吞吐测试不能代表通话或交互体验，同样，某个实时应用异常也不能直接证明代理的 TCP 转发有问题。应选择与你实际用途相同的任务。

Wi-Fi 与蜂窝之间切换会改变外部地址、可用带宽及路径 MTU，已有连接可能中断。即使某种承载具备迁移能力，整体恢复仍依赖客户端实现、服务器和目标应用。测试时记录“切换后新请求能否成功”与“原来的请求能否继续”，这两个指标不能混写。对于必须持续交互的使用场景，恢复的可预测性通常比瞬间最高速更重要。

还应检查路由是否一致。一个配置把大部分请求直连，另一个把相同请求送到远端，测出的电量与速度差异就不只是协议差异。用 Config 测试时保持同一组规则与策略；必要时短暂采用 Proxy 进行受控验证，结束后恢复原来的姿态。Data 的服务器统计可辅助确认流量是否经过预期入口，但计数本身不是成功率，也不能单独证明所有域名规则均已生效。

详细读数说明见Data 流量统计文章。记录测试时应写下任务、网络、路由姿态和是否切换过连接，同时隐藏账户资料。一个可复查的结论应是“在这些条件下，该配置完成此任务更稳定”，而不是“这个协议永远更快”。当两种方案表现接近时，字段完整、容易维护和恢复步骤清楚，往往比继续追逐微小差异更实用。

选型顺序：支持范围先于性能偏好

如果你只有一份已有订阅，第一步是完整导入并核对类型，不需要先决定最喜欢哪种协议。服务器没有开放的类型无法由客户端凭空启用。需要手动填写时，先收齐入口、认证、传输、安全与附加字段，再到 Add Server 选择对应类型。订阅与手填入口的区别见Subscribe、扫码与手动导入说明；日常上手流程仍以使用教程为主。

如果同一现有环境提供多个完整入口，按任务筛选：普通网页先看短请求稳定性；持续下载看吞吐与发热；实时应用确认 UDP 能力及抖动；访问指定内网时，核对是否需要 WireGuard 的隧道地址与网段配置。协议名称只提供设计线索，不能替代端到端测试。维护方面也应考虑证书续期、密钥管理和配置更新，选择你能保持资料准确的组合，而不是字段最多的组合。

建立最小可用配置，再恢复分流

保留原始连接，复制一份用于测试。先确认系统联网正常，再验证入口地址和端口，接着检查认证与 TLS，最后访问已知目标。需要排除规则干扰时，可暂时采用 Global Routing 的 Proxy 姿态，但测试结束应恢复预期设置。连接稳定之后再启用 Config，核对当前文件、规则顺序和 FINAL。不要同时调整 DNS、协议、传输与策略，否则即使恢复也难以知道哪一步起了作用。

“只有某个网站失败”时，先检查该目标是否本来就能访问，再看它命中了哪条规则、采用哪个策略，以及域名解析是否正常。“所有目标都失败”时，优先返回入口与认证；“小请求正常、大响应停住”时，关注路径、MTU 与传输；“切网后失败”时，检查新网络可达性和连接重建。用现象分支缩小范围，比把所有故障统一归为协议不合适更有效。

订阅更新、敏感资料与获取边界

Subscribe 更新后可能改变地址、端口或条目集合，手动修改的项目也可能被新的订阅内容覆盖。出现“之前能用、更新后失败”时，应比较变更项，确认是否仍在使用预期条目，不要立即修改全部全局设置。向已有服务器管理方反馈时，可提供协议类型、错误阶段、接入网络和是否能复现；订阅链接、UUID、密码、私钥及带认证信息的二维码应遮盖，避免把完整访问权限随日志公开。

如果问题实际发生在客户端获取或首次打开阶段，先查看安装放行说明，不要把安装问题混入协议测试。Mac 需区分 Apple 芯片与 Intel；首次打开被拦截时核对来源后在系统隐私与安全性处理。Windows 的 SmartScreen、安卓的安装权限以及 Linux 的执行权限也应按下载页对应说明处理。其他平台安装包由本站 /dl 提供，不在协议资料中寻找替代安装地址。

iPhone / iPad 在 App Store 产品页核对开发者 Shadow Launch Technology Limited、官方图标与应用 ID 932747118，系统要求以 App Store 页面标注为准。价格分为两档：iPhone / iPad 版 App Store $2.99 一次性付费，Mac / Windows / 安卓 / Linux 版免费。购买客户端不包含服务器连接资料；取得客户端与导入已有订阅是两件独立的事，连接失败也不应通过重复购买客户端来处理。

最终保留一份已经验证的配置，并写下它适用的网络与用途。后续每次只调整一个变量，确认访问、规则和恢复行为后再继续。若问题仍未解决，回到本页相应协议章节核对字段，再参照下载与安装常见问题区分获取问题与连接问题。选对协议的标准不是名称新旧，而是服务器支持、参数匹配、验证结果明确，并能在日常网络里稳定重复。