Shadowrocket
协议类型与参数参考

设计背景与边界

Shadowsocks 的设计重心是以相对精简的协议完成加密代理转发：客户端向服务器描述目标，再由服务器建立到目标的连接。它主要依赖双方约定的密码和加密方法，不以网站证书作为基本认证条件。理解这一点有助于区分字段：普通 Shadowsocks 配置中的 Password 与 Method 是一组必要条件，不能把另一个协议的密码原样套入，也不能仅因端口相同就判断两种服务可以互换。

不同加密方法的报文格式和密钥要求可能不同。较新的方法与较早的方法并非只存在“强弱”差异，还可能有不同的密钥编码、长度及实现兼容要求。服务端给出哪种方法，客户端就应选择哪种方法；若列表没有对应选项，应确认信息是否适用于当前客户端，而不是寻找名字相近的选项替代。导入后仍应检查方法名称，尤其注意订阅转换过程是否遗漏了它。

地址、端口、密码与方法逐项核对

Server 填写服务器域名或 IP 地址，Port 填写实际监听端口。地址通常不包含网页路径，端口也不应混入地址输入框。Password 必须按提供的信息完整保存，注意复制时的空格、换行以及全角字符。Method 表示具体加密方式，不是任意偏好。若地址可以解析而连接持续失败，应同时核对端口与方法，不要把“域名能打开网页”当作代理端口正常的证据。

有些配置还附带额外传输参数，这些参数不属于所有 Shadowsocks 服务的共同要求。只有在已有信息明确提供时才启用，并保持对应的名称和参数一致。不能看到其他配置里有某个选项，就给当前连接照样添加；额外封装会改变服务端预期的数据格式。若导入条目与手动填写的结果不同，可以逐字段比较，但先保留导入条目作为参照，避免修复过程中丢失原始信息。

TCP 成功不代表 UDP 已经可用

网页浏览大多可以通过 TCP 完成，但实时通信、部分域名解析和使用 QUIC 的应用可能涉及 UDP。Shadowsocks 的 TCP 与 UDP 转发需要分别满足条件：服务端支持相应能力、网络允许对应数据通过、客户端配置没有关闭它。网页正常而实时业务失败时，应检查这条分支。不要仅凭一次网页加载，就断言当前连接适合所有应用，也不要只凭一个应用失败就认定整条连接失效。

在 iPhone 和 iPad 上，精简转发通常意味着需要关注的封装层次较少，但这不等于始终更快或更省电。设备芯片对算法的处理效率、长连接数量以及网络重传都可能改变实际结果。若同一配置在 Wi-Fi 正常、蜂窝网络超时，应先比较入口端口与网络可达性；若只有高负载时明显变慢，则要结合服务器负载和持续吞吐观察，不能从协议名称直接得出结论。

排错可以按“信息是否完整、入口是否可达、认证是否一致、具体业务是否支持”四步进行。先查看订阅更新是否成功，再核对当前选中的条目，避免修改了一个条目却在测试另一个。认证相关错误应回查密码和方法；超时优先查地址、端口和当前网络；只有部分请求异常时再看规则与 UDP。这样能够保留明确的因果关系，而不是在多个设置之间反复试探。

当已有服务器只提供 Shadowsocks 时，优先使用完整匹配的配置即可，不必为了协议名称更换类型。若用户同时持有多种可用配置，再以相同目标和相近时间比较网页首次加载、持续传输与后台待机表现。记录改善出现在哪个环节，比给协议贴上“轻量”或“高速”的结论更有用，也更便于之后在网络条件变化时重新判断。

把证书身份与用户密码分开理解

Trojan 将代理会话放在 TLS 连接之内，先依靠 TLS 建立受保护的通道，再在通道中提交协议认证与目标信息。这里存在两个不同身份：证书用于验证所连接的服务器，Password 用于证明客户端具有访问权限。密码正确不能弥补证书名称错误，证书有效也不能证明密码被服务器接受。排错时应按握手顺序观察，而不是把所有失败统一解释为密码错误。

这种组合把较多安全职责交给 TLS，因此服务器名称、证书有效期与设备信任条件尤为重要。它并不意味着用户需要手工填写每一种 TLS 选项；已有订阅通常已经给出必要设置。先维持导入结果，再根据错误定位缺失项。若在没有完整参数的情况下随意尝试不同名称，可能让连接到达另一个服务入口，导致现象更加难以解释。

Server、Server Name 与证书链

Server 是网络连接实际要访问的地址，Server Name 是 TLS 握手和名称验证使用的重要信息。使用域名连接时，两者经常一致；使用 IP 连接时，则可能仍需保留原有域名作为 Server Name。证书验证还涉及有效期与信任链，因此名称正确只是必要条件之一。若证书已经过期或中间证书配置有误，应该修正服务端，而不是反复更换客户端密码。

设备时间偏差、网络认证页面和错误的域名解析，都可能制造看似相近的 TLS 故障。公共 Wi-Fi 尚未完成网页登录时，访问可能被引导到认证入口；若解析得到错误地址，也可能连到不属于该服务的证书。遇到这类问题，应先确认网络本身可以正常使用，再检查域名解析结果与 Server Name。不要在尚未确认连接对象时提交更多凭据或扩大信任范围。

认证、传输与业务支持的边界

Trojan 的 Password 应完整保留大小写和符号，不要把订阅链接中的整段文本直接填入。若已有信息额外指定传输方式，也必须与服务端一致；不能因为普通 Trojan 常见于某种承载方式，就删除配置里明确要求的附加字段。导入后可以检查类型、地址、端口、密码和 TLS 名称五项，再查看其他传输参数。这个顺序能够先排除最常见的结构错误。

UDP 能否正常使用仍取决于服务端支持、客户端设置和实际网络条件。即便协议能够转发某类数据，也不代表所有应用都具有相同表现。实时业务对延迟与抖动更敏感，长时间下载则更容易受服务器出口带宽影响。若普通网页正常而某个实时应用异常，应单独验证相应业务，不要以网页成功替代业务测试，也不要盲目增大各种超时参数来掩盖问题。

iOS 上观察连接复用与重连

TLS 握手需要交换数据并进行计算，首次连接的成本与后续稳定传输并不相同。在频繁创建短连接的场景中，握手数量可能影响响应和电量；在长连接持续工作时，这部分成本被分摊，链路质量往往更加重要。服务端与客户端是否使用相关复用机制，也会改变观察结果。因此，测试时应分别记录首次打开和连续访问，不要把已经建立会话后的速度当作冷启动表现。

从 Wi-Fi 切换到蜂窝网络可能改变设备地址和可达路径，已有 TCP 连接通常需要重新建立。若切换后长时间没有恢复，应先停止当前任务，确认新网络正常，再测试重新连接的时间；不要立即清空配置。后台连接反复失败会增加重试与无线电活跃时间，表现为耗电上升。此时应查失败原因，而不是先把加密运算认定为耗电来源。

如果用户已有稳定可用的 Trojan 配置，日常使用中更重要的是保留正确的证书验证与认证参数，并在订阅更新后确认它们没有被意外覆盖。若需要与其他协议比较，应选择相近网络路径、相同目标与相同测试时段，明确记录比较的是整套服务表现。协议层的说明能够帮助定位问题，但不能替代对服务端运行状态和业务目标可达性的核实。

先理解它处理的是网络层数据

WireGuard 以网络层隧道为设计基础，与“为某个目标建立代理连接”的思路不同。配置除了远端地址，还需要本端地址、密钥身份和允许进入隧道的地址范围。把它放进客户端的统一连接管理中，并不会消除这些网络层条件。用户应取得完整配置，而不是仅凭一个域名和密码尝试手动拼接；缺少隧道地址或对端公钥时，通常无法建立符合预期的通信关系。

WireGuard 使用公钥标识通信对端，本端私钥用于证明本端身份，对端公钥用于指定接受的远端身份。它们不是可互换的两个字符串。客户端私钥应当保密，对端服务器也必须配置与该客户端对应的公钥；只在手机里填入一组新密钥，服务器不会自动认识它。若配置由管理方提供，应保留双方已经约定的密钥配对，不随意重新生成后覆盖。

Endpoint、Address 与 Allowed IPs

Endpoint 表示隧道对端的网络入口，通常由主机和 UDP 端口构成；Address 表示本端在隧道中的地址，不是服务器公网地址。Allowed IPs 在 WireGuard 的基础语义中同时关联目标路由范围与对端允许的地址范围，客户端集成后的具体处理还要结合应用设置。理解这些职责有助于排查“握手成功但访问失败”：身份握手只证明双方建立了会话，不证明每个目标都具有正确路由。

若需要访问组织内网，目标网段必须与已提供的配置范围相符，服务端也需要具备转发与返回路径。若本地 Wi-Fi 网段恰好与远端内网重叠，还可能出现路由选择歧义。此时反复更换密钥通常没有帮助，应先确认目标地址实际走向何处。对于 IPv6，也要检查是否有相应地址和路由条件，不能只因 IPv4 可用就假设另一套地址空间同时可用。

Keepalive 与移动网络的取舍

WireGuard 使用 UDP，移动设备经由地址转换设备访问远端时，空闲映射可能过期。Persistent Keepalive 的目的之一是通过周期性报文维持相关映射，不是提高带宽。较频繁的保活意味着更多无线电活动，较少的保活则可能使某些网络上的空闲后恢复变慢。应遵循已有配置，并在确有空闲恢复问题时针对性验证，不套用对所有手机都相同的固定间隔。

网络切换后，底层出口地址可能改变，WireGuard 的机制允许在满足条件时适应对端地址变化，但实际体验仍受新网络的 UDP 可达性、地址转换和服务端策略影响。Wi-Fi 正常、蜂窝网络不通时，先比较 UDP 是否可达，再看运营网络和对端限制。不能把具备地址更新机制理解为所有切换都不会中断，也不应以一次恢复较快就推断任何网络都能维持会话。

MTU 与 DNS 要分别验证

隧道封装会占用报文空间，路径可承载的有效大小与 MTU 设置不匹配时，可能出现小请求正常而大响应停滞的现象。但这种现象也可能来自丢包或服务器问题，所以调整前先保存原值，每次只改一个参数并重复相同请求。不要将网上某个 MTU 数字当作通用答案，也不要因为网页打不开就立即把它调到很小，造成不必要的吞吐损失。

DNS 决定域名如何得到地址，路由决定数据发向哪里，两者在隧道场景中经常同时出现，却不具有相同职责。直接访问已知内网地址成功、使用名称失败时，应优先核对内网 DNS 及其可达路径。对需要内网互通的用户，完整的地址规划比协议测速更重要；对普通网页场景，则仍需结合 Shadowrocket 的实际策略验证请求是否进入预期连接。

用同一套任务建立基线

协议比较应服务于实际任务。日常网页访问先看首次响应和连续加载；长文件传输看稳定吞吐与中途断连；实时通信看时延、抖动和 UDP 业务；内网访问则优先看地址规划、DNS 与返回路径。用户已有多个配置时，先选择一个能完成任务的基线，再比较其他配置。若所有配置都失败，应先检查当前网络和目标本身，避免在不具备测试条件时得出协议结论。

一次有效对比要尽量固定设备、网络、目标、规则模式与测试时间，暂停后台大流量任务，并记录是否为首次连接。每组重复几次，以常见表现而不是最好的一次作为参考。Connectivity Test 可以帮助筛查明显不可达的条目，但结果不等于完整网页体验，更不能证明 UDP、内网或长连接一定正常。将连接测试、实际访问和持续传输拆开，才能看到差异来自哪个环节。

Global Routing 三种模式用于隔离变量

Config 按当前配置规则决定连接策略，Proxy 用于把适用流量交给代理路径，Direct 用于直接连接。若 Config 异常而 Proxy 正常，通常应该回查规则与策略指向，而不是立即改密码；若两种需要代理的模式都失败，再回查入口、认证和传输。Direct 的测试只能提供本地网络基线，目标在直连条件下不可达时，也不能单独证明代理协议有问题。

下面片段展示按域名后缀选择策略、按地址段直接连接，并用最终规则处理其余请求的基本结构。示例属于 Shadowrocket 的 .conf 规则内容，不是可连接的服务器配置，也不包含认证信息。PROXY 需要在实际配置中对应有效策略；导入或修改前先备份，并确认当前 Config 确实选中了所编辑的文件。规则通常按顺序匹配，前面的宽泛条件可能使后面的具体条件无法生效。

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

域名规则依赖客户端在适当环节掌握域名信息，IP 规则则匹配地址；两者不能简单互相替代。网站可能涉及多个资源域名，应用也可能直接使用 IP，因此“主页面走了预期策略”不等于所有关联请求相同。GEOIP 结果还受到地址数据库与目标地址变化影响。只让指定网站使用代理的场景，可继续阅读指定网站走 PROXY 的规则说明，再根据自己的目标补充条件。

从错误现象回到相应层次

完全超时先核对网络、地址和端口；明确认证错误回查密码、UUID 或密钥配对；TLS 错误检查系统时间、Server Name 和证书；握手成功但业务失败，则进一步检查目标可达性、DNS、UDP 与路由。若只有一个域名失败，先测试其他已知目标；若所有域名失败而已知 IP 可达，再集中检查 DNS。每次只修改一组设置，验证后记录结果，不把多个猜测同时写入配置。

保留可复现记录，再决定是否换协议

排错记录应包含设备网络、目标类型、Global Routing 模式、错误阶段和发生条件，不需要暴露完整订阅地址、密码或私钥。分享截图或文字前，应删除认证内容和个人标识；只保留有助于复现的协议类型与非敏感字段。已有订阅发生更新后，可以对比类型、传输与名称字段，但保留原条目，避免在尚未确认新配置可用时失去工作基线。

最终选择应以兼容性与可复现结果为准：能完成任务、切换后可恢复、持续运行没有异常重试，比一次测试的最高数值更有参考价值。常见导入与连接问题可回到快速上手的故障排查，界面词可查概念速查，功能行为可查功能说明。若问题落在服务端认证、证书或路由范围，应向已有信息的提供方核对对应配置，而不是在客户端不断更换无关选项。