Shadowrocket 协议参数
与连接类型选择

Shadowsocks：精简代理与加密方法

设计背景与边界

Shadowsocks 的设计重心是提供较精简的加密代理通道。客户端把目标地址与业务数据按约定封装，服务器验证并转发请求。它不是完整的虚拟局域网方案，也不会因为被选为 Type 就自动设置应用路由。对用户而言，最关键的不是记住协议历史，而是识别同名协议下仍存在不同加密方法与格式：服务器接受哪种方法，客户端就必须选择相同的方法，不能把名称相近视为兼容。

较早的流加密方式与后来的 AEAD 方式在数据格式和认证能力上不同。AEAD 把加密与完整性验证结合起来，能够检测被修改的数据；这并不意味着所有含 AEAD 名称的条目彼此通用。部分较新的方法还会对密钥长度与编码提出特定要求。实际填写应以已有服务器配置为准，客户端列表未出现的方法不能通过选另一个相似名称来替代。

Address、Port、Method 与 Password

在 Add Server 中选择 Shadowsocks 后，先检查 Address 与 Port。Address 是提供代理服务的主机名或 IP，不是订阅链接，也不是要访问的网站；Port 是该服务监听的端口。主机名不能混入整段网页路径，IPv6 地址也应按字段要求填写。若资料来自二维码或订阅，优先保留自动解析结果，再逐项和原资料对照，避免手工拆分时把端口或附加参数漏掉。

Method 决定双方如何处理密钥与密文，Password 则必须逐字符一致。某些方法使用普通口令派生密钥，另一些方法要求规定格式的密钥材料，所以不能简单地认为“密码越长越兼容”。复制时注意尾部换行、全角符号和不可见空格；不要把服务器面板展示的编码串再次自行编码。发生认证失败时，先核对方法与密码这组配对关系，而不是立即修改 DNS。

UDP、附加传输与 iOS 表现

Shadowsocks 的 TCP 和 UDP 路径需要分别验证。网页可以打开，不代表游戏或通话的数据报也能到达。客户端设置、服务端转发能力以及沿途网络都可能限制 UDP；目标应用本身还可能使用不同端口。若服务器资料包含附加传输参数，应确认当前客户端确实提供对应选项，并完整照填。基础协议名称相同，并不能说明附加传输具有相同兼容性。

在 iPhone 上，较精简的数据封装有机会减少部分处理开销，但实际速度仍会受到加密方法、设备能力和网络路径影响。大流量持续下载时，计算开销比较容易显现；偶尔打开消息时，连接建立和无线唤醒反而可能更重要。不能仅凭协议结构简洁就断言它必定更省电，也不应把一次测速中较高的峰值当作长期吞吐量。

排错可分三支：入口始终超时，先确认主机、端口和当前网络；连接建立后立即失败，检查 Method 与 Password；网页正常但部分应用失败，检查 UDP、规则命中和名称解析。若修改的是从 Subscribe 获得的条目，先复制保留原值，以免后续更新覆盖修正。按这条顺序逐项核对，每次只调整一个设置并验证结果。

WireGuard：密钥、地址与路由前缀

为什么字段与普通代理不同

WireGuard 面向 IP 数据包隧道，设计上采用固定的现代密码组件与相对精简的握手机制。它不依靠用户名密码表单识别对端，而是用密钥建立身份关系，并把允许通过对端的地址范围与路由联系起来。因此在 Shadowrocket 中查看 WireGuard 条目时，应把密钥、隧道地址、Endpoint 和 AllowedIPs 分开理解，不能套用普通代理“地址加密码”的填写习惯。

PrivateKey 是本端的私钥，PublicKey 通常指对端公钥。两者虽然都表现为编码字符串，却属于不同身份和方向。私钥不能放进对端公钥字段，也不能因为字符串长度相近就互换。PresharedKey 是可选的额外共享材料，只有双方约定使用时才应填写；自行添加一段值不会提高可用性，反而会使双方握手条件不一致。

Endpoint 与隧道地址

Endpoint 是对端实际接收 UDP 通信的主机和端口，隧道 Address 则是本端在隧道内使用的地址。二者处于不同层次：入口公网地址可达，并不证明内部地址分配正确；内部地址正确，也无法弥补入口端口不可达。把已有配置拆进界面时，应保留地址的前缀长度，并检查 IPv4 与 IPv6 是否分别按资料配置，不要凭本地局域网地址自行替换。

AllowedIPs 同时关系到哪些目标地址交给某个对端，以及收到的数据应具备怎样的源地址归属。较宽的前缀覆盖更多目标，较窄的前缀只覆盖指定网段，但它不是普通的访问网站白名单。客户端的 Global Routing、Config 规则与系统网络扩展还会影响业务流量是否进入这一条目，所以不能只看到一个全范围前缀就判断所有应用已经使用隧道。

MTU、保活与移动网络

MTU 决定隧道数据包大小上限。底层路径承载不了较大的封装包时，可能表现为小请求可用、大页面或上传卡住。调整 MTU 应在排除认证和路由错误之后进行，并保留原值逐步验证；不要把某个网络下有效的数值当作所有设备的固定答案。若 IPv6 与 IPv4 路径不同，也应分别测试，而不是只观察一次网页加载。

PersistentKeepalive 用于按约定间隔维持某些网络地址转换映射，并非越频繁越稳定。较短间隔可能增加后台数据与无线唤醒，较长间隔又可能不适应某些映射寿命。应先确认实际存在空闲后无法恢复的问题，再按服务器建议调整。移动网络切换时，入口可达性、地址变化和应用重试行为也都会影响恢复过程。

WireGuard 的握手成功只说明密钥关系及部分通信条件成立；要访问内部服务，还需要对端转发、返回路由、地址分配和 DNS 正常。若握手正常但没有业务流量，先核对 AllowedIPs、隧道地址和服务端返回路径，再查规则命中。字段逐项解释可继续阅读WireGuard 参数说明，分享问题时应隐藏私钥与真实内部网络信息。

按场景选型：规则验证与故障闭环

从需求倒推，而不是从名称倒推

需要普通网页与日常应用时，先选择已有资料中参数完整、能稳定连接的条目，不必为了协议名称更换服务器。已有内部网络和地址路由需求时，检查 WireGuard 对端与允许网段；已有 HTTP 或 SOCKS5 组织入口时，核对其认证和访问权限；需要使用 UDP 的应用，则单独验证相应能力。某项需求不满足时，再判断是配置问题、服务端能力还是网络限制。

VMess、VLESS 和 Trojan 的选择应保留各自所需的传输与 TLS 组合，Shadowsocks 应确认加密方法与数据报支持，Hysteria2 应确认 UDP 路径及速率参数。没有一种协议能够仅靠切换 Type 自动兼容另一种服务。若已有订阅包含多种类型，可以保留原条目逐一测试；不要通过混用 UUID、密码和传输路径创造未经服务端配置的组合。

先确认规则真的调用了该协议

协议验证和规则验证应分两步。先用明确的测试请求确认服务器可用，再在 Config 下核对目标是否进入预期策略。下面是用于说明匹配顺序的 Shadowrocket .conf 规则片段，不是完整配置；使用前必须确保当前配置已经定义可用的 PROXY 策略。示例域名只是教学文本，不代表应当访问的服务。

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

规则通常按顺序匹配，命中后采用相应策略。DOMAIN-SUFFIX 覆盖指定域名及其子域，IP-CIDR 表示地址段，no-resolve 用于避免该条规则为匹配而主动解析域名；已有目标地址仍可能参与地址匹配。GEOIP 根据地址归属数据库判断，不等同于网站所属地区。FINAL 是兜底，必须放在需要先行判断的规则之后，否则后面的意图可能无法实现。

如果目标命中 REJECT，连接在策略层就会被阻止，更换协议无法修复；若命中 DIRECT，应先确认是否符合预期。关于拒绝策略的作用与同域内容边界，可查REJECT 规则说明。规则调整也应复制配置后进行，避免为了验证一个目标而让其他应用的原有路径全部改变。

按失败阶段收敛检查范围

若只有域名访问失败而直接目标测试正常，应检查名称解析位置、返回地址类型及 DNS 请求的路由；不要把所有问题都处理为修改证书验证。若只在 IPv6 网络异常，应分别确认服务器入口、目标地址与隧道地址支持情况。恢复一个可用配置后，再逐项加回所需规则，能够找到具体引入故障的变更，而不是留下难以解释的一组开关。

保留能复现的结论

完成排查后，记录实际使用的协议、外层传输、成功的测试任务与仍存在的边界，并删除不再需要的实验条目。Subscribe 更新可能改变服务器参数，系统网络变化也可能让旧结论失效；出现新故障时应重新核对当前资料，而不是机械重复旧调整。配置、二维码和日志都可能包含敏感信息，分享前应逐项检查，不直接公开原始导出文件。

需要重新走操作主线时，返回使用说明；需要按现象查找短答案时，进入问答。本手册的目标是让每一次类型选择都有服务器资料作为依据、每一次参数修改都有可验证的原因，而不是用协议名称代替对连接条件的判断。