Shadowrocket
协议技术参考与参数选型

选型首先受服务器约束

协议决定客户端与服务器如何建立连接、证明身份和传递数据。它不是一个可以单独替换的外观选项：服务器接受 Shadowsocks 时，客户端选成 Trojan，即使地址、端口和密码看起来相同，也无法完成正确交互。因此，选型的第一步不是比较名称，而是取得完整的服务器说明，确认协议类型、认证字段、传输方式以及是否启用 TLS。已有订阅通常携带这些信息，手动编辑前应保留一份原始记录。

本页所说的速度是一次完整访问的结果，涉及设备到服务器的路径、服务器负载、目标站点响应和客户端处理成本。协议能够改变握手次数、封装开销与丢包后的恢复方式，却不能替代可用的网络路径。不要把一次 Connectivity Test 的结果直接视作网页加载速度；测试目标和实际访问目标可能不同，短连接测试也难以反映持续传输时的拥塞与波动。

分清协议、传输和加密

协议负责约定数据格式和认证方式，传输负责承载字节或数据包，加密层负责保护传输内容。某些组合使用 TCP，某些使用 UDP；WebSocket 是可选的传输组织方式，TLS 则是安全层。一个服务器可以同时出现协议名、传输名和证书域名，这些字段描述的是不同层次。仅知道 VLESS 或 VMess 还不足以重建配置，必须继续核对对应的传输和安全参数。

规则处在另一条逻辑链上：先判断请求应当采用哪个策略，再通过选定服务器使用对应协议。DOMAIN-SUFFIX 不会改变服务器的认证方法，FINAL 也不会修复错误的 TLS 名称。遇到访问失败时，先分辨请求是否经过预期策略，再检查协议连接是否建立；把这两步混在一起，会出现不断改密码却实际命中 DIRECT，或反复改规则却始终认证失败的情况。

移动端看持续成本，不只看峰值

iPhone 与 iPad 上的电量消耗，不只来自加解密计算。无线网络反复唤醒、弱信号重传、短时间内重复握手，以及后台连接维持，都可能提高耗电。同一协议在稳定 Wi-Fi 与信号变化的蜂窝网络上，表现可能不同。比较时应固定设备、网络、目标任务和测试时长，同时记录发热、加载等待与重连次数，而不是根据协议名称给出固定的省电排名。

Shadowrocket 中可见的字段会随所选类型和相关选项变化。本文解释字段职责，不把所有协议的可选项视作必填项；实际配置应与应用当前界面以及服务器说明对应。某个扩展没有出现在编辑页面时，不应把它塞入名称或密码中。首次使用可按教程完成基本连接，再逐项增加确有需要的传输设置，每次只改变一个变量。

在阅读后续章节时，可以采用一个统一顺序：先判断服务器实际提供什么，再核对认证材料，然后检查传输与安全层，最后验证真实业务。若已有信息只包含地址与端口而缺少协议说明，应先补全资料。猜测协议或随意切换安全选项，通常只能得到新的失败现象，无法形成可复现的诊断结论。

设计取舍：集中处理代理数据

Shadowsocks 的设计重点是以相对简洁的方式传递代理流量，将目标地址与应用数据放入双方约定的加密结构。它不像一个完整的网络隧道那样，要求用户先理解虚拟网段和路由地址；常见手动配置主要围绕服务器地址、端口、加密方法和密码展开。这种简洁降低了基本配置的理解成本，但不意味着不同加密方法、协议代际或扩展可以相互兼容。

从早期的流式加密方案到带认证的加密方案，重要变化在于接收方能否检查数据的完整性，而不只是还原内容。AEAD 将加密与认证结合，客户端和服务器必须在具体方法与密钥材料上达成一致。看到相似名称时也要逐字核对，不能凭密钥长度或算法家族推断兼容。对于带有不同密钥格式要求的配置，更不能沿用其他类型的任意文本密码。

地址、方法与密码如何对应

服务器地址是建立外层连接的入口，可以是域名或 IP；端口用于定位该入口上的服务。加密方法决定数据处理格式，密码或指定格式的密钥用于生成认证与加密所需材料。这几个字段必须作为一组核对。端口正确但方法不符时，底层连接仍可能建立，随后数据无法被对端接受；因此“能连到端口”与“协议认证成功”是两项不同证据。

从 Subscribe 导入后，应先在服务器编辑页面确认类型确实为 Shadowsocks，再核对方法和密码是否完整。部分分享信息经过编码，复制时丢失尾部字符、混入换行或被额外解码，都可能改变实际内容。如果订阅重新导入后恢复正常，而手动编辑的记录仍失败，应比较字段差异，不要把手动修改覆盖回订阅中的其他服务器。

扩展参数需要服务器明确支持。某些配置会包含插件或额外封装说明，它们不是所有 Shadowsocks 连接都需要的默认项。基础协议可用，不代表任意附加传输也可用；反过来，服务器要求扩展时，仅填基础四项也不够。遇到未知扩展，应查清名称、对应选项与必要参数，不能通过启用 TLS 或更换常见端口来代替。

TCP 与 UDP 要分别验证

浏览网页主要验证的是相应的应用访问路径，不能据此推断 UDP 转发已经正常。客户端选项、服务器配置以及中间网络都可能影响 UDP。用户已有服务包含 UDP 能力时，应使用实际需要 UDP 的业务验证，并检查日志中该请求所走的策略。若网页正常而某类实时业务失败，先确认业务流量与转发支持，再判断是否需要调整协议。

在移动设备上，Shadowsocks 的实际处理成本与加密实现、数据量和网络条件相关。较少的封装通常有利于降低额外开销，但弱信号下重复传输造成的等待，可能远大于加密计算差异。比较两条配置时，应使用相同任务观察持续吞吐与响应稳定性。仅比较一次小数据包测试，既不能证明长时间更快，也不能证明后台使用更省电。

适合选择它的情况，是用户已有服务明确提供完整的 Shadowsocks 配置，并且目标业务与所支持的转发方式相符。需要证书身份校验、特定传输或网络层地址管理时，应根据服务器实际能力阅读其他章节，而不是向 Shadowsocks 记录里添加不对应的字段。配置成功后保留原始资料，后续故障优先比较网络环境与记录变化。

相近字段不代表相同协议

VMess 将用户身份认证与代理数据传递组织在自己的协议结构中，常见配置使用 UUID 标识用户，并涉及相应的安全参数。VLESS 的设计则减少协议自身的部分处理，将传输安全更多交给外层机制。两者可能使用相似的服务器地址、UUID 和传输字段，但消息格式与服务端处理方式不同。不能通过把编辑页面的类型从 VMess 改为 VLESS，完成一次有效转换。

理解这一区别有助于判断“参数都一样为什么不能连”。UUID 只是认证材料的一部分，并不是能够通用于所有协议的登录凭证。服务器必须在对应入口配置相同类型，还要接受相应的传输与安全层组合。已有订阅如果同时列出不同类型的记录，应把它们视为独立连接资料，不要从其中一条拼接密码、端口或传输字段到另一条。

将入口地址与服务名称分开

服务器地址决定先连接哪里，TLS 中的服务名称用于身份校验和握手，WebSocket 的 Host 与 Path 则参与相应的应用层请求。它们有时相同，有时因服务器部署结构而不同。特别是在地址使用 IP 时，证书仍可能签发给域名；此时应依照服务器说明填写所需名称，而不是把证书名称简单改成该 IP，也不能把 Path 当成域名的一部分。

WebSocket 的 Path 通常包含开头的斜杠，并且必须与服务器接受的路径一致。字符大小写、结尾斜杠或多余空格，都可能影响请求是否被接收。Host 也不是备注名称，填写容易辨认的中文标题不能代替它。手动录入时可先建立字段清单，把地址、端口、UUID、传输、TLS 名称、Host 与 Path 分行保存，再逐项对应应用中的可用选项。

VMess 配置还可能涉及安全方式等参数；旧资料中的某些字段不一定适用于当前服务。VLESS 的扩展与传输组合也需要客户端和服务器共同支持。不要将一篇旧说明里的默认值机械填入已有配置，更不要在看不到对应选项时自行推断替代项。优先保留订阅导入的完整记录，必要时向自己的服务提供方确认当前应使用的字段。

握手层数影响短任务感受

采用 TCP、TLS 和 WebSocket 的组合时，连接通常需要逐层建立。对于少量数据的短任务，建连等待可能比后续传输更显眼；稳定的已有连接则可能呈现不同体验。因此，某条组合在持续访问中表现平稳，并不能证明它在频繁重连的蜂窝网络中也同样合适。比较时应分别观察首次打开、连续访问和网络切换后的恢复。

VMess 的认证机制涉及时间因素，设备时间明显偏离时，可能导致认证异常。应先检查系统日期与时间设置，再复核协议字段；VLESS 记录失败则不应直接套用同一原因。网络切换后，原有连接是否仍能使用，也取决于底层传输。TCP 连接通常需要在路径变化后重新建立，不能因为协议名称相近，就期待所有组合都有相同的恢复行为。

选择这两类协议，应以现有服务的完整组合为单位，而不是只比较 VMess 与 VLESS 两个名称。若连接失败但没有清晰报错，可以依次确认入口可达、TLS 握手、传输请求与身份认证。每一步保留一条判断依据，避免同时修改多个字段后偶然恢复，却无法知道真正原因。

安全层是连接结构的一部分

Trojan 将代理请求与密码认证放在 TLS 连接之中，设计上利用成熟的 TLS 机制保护客户端到服务器之间的通信。因此，理解 Trojan 不能只看密码，还要理解服务器证书、服务名称与握手过程。外层安全连接未完成时，应用层认证通常还没有进入可用阶段；此时反复更换密码，并不能解决证书过期、名称不匹配或握手协商失败的问题。

这里的 TLS 连接保护的是到代理服务器这一段。目标网站如果使用 HTTPS，还会有应用到目标网站的独立安全连接，两者不是同一张证书，也不应混为一谈。服务器连接成功而某个网站报证书错误时，需要辨认报错来自哪个层次。仅凭错误文字包含 TLS，便修改 Trojan 服务器的名称，可能破坏原本正确的配置。

入口、SNI 与证书各有职责

地址告诉客户端向哪里建立连接，SNI 在握手过程中标识所需服务，证书则为服务身份提供验证依据。它们在简单部署中可能使用同一个域名，在不同入口安排下也可能不完全相同。正确做法是按服务器说明对应填写，并让证书覆盖预期服务名称。若入口给出的是 IP，也不能据此断定证书必须包含该 IP，应先核实指定的 TLS 名称。

密码需要与服务器记录完全一致，前后空格、换行和字符替换都可能导致认证失败。端口只标识服务入口，某个常用端口并不能证明其上运行的是 Trojan，也不能证明证书配置正确。若服务器允许额外的传输封装，则还需核对相应字段；普通 Trojan 记录不应被随意加入其他传输的 Path 或 Host，除非服务端明确要求。

部分高级字段用于协商应用协议或改变握手细节，例如 ALPN。它们的作用是让双方就后续处理达成一致，不是通用的加速开关。用户没有相应说明时，应保留导入记录中的设置。把别处看到的值复制进来，可能让外层连接成功却进入错误服务，或使服务器拒绝继续处理。诊断时先回到已知有效的组合，再逐项定位差异。

证书异常按原因处理

证书名称不匹配时，核对地址与 TLS 名称是否被混淆，并确认服务器实际提供了预期证书。提示有效期异常时，检查设备时间，再确认服务器证书是否需要更新。出现信任链问题时，应由服务器配置补齐相应链条，或确认其既定信任方式。关闭证书校验会失去身份检查依据，不应把它作为恢复连接的常规步骤。

在 iOS 上，TLS 的计算和握手成本通常只是整体体验的一部分。稳定连接承载较多请求时，建连开销可以被分摊；移动网络频繁断开时，重复握手会增加等待与无线活动。不能据此给 Trojan 固定标注“更耗电”或“更快”。应在相同网络中比较实际任务，并区分首次连接耗时和连接建立后的传输表现。

适用场景是用户已有服务明确提供 Trojan，且证书名称与认证资料完整。若同一服务给出多种入口，可优先验证证书信息清楚、当前网络可达的那组记录。出现单个目标失败时，先查规则与 DNS，不要立即重建 TLS 配置；出现所有目标均失败且日志指向握手时，再按本章的层次核对。有关解析问题可继续阅读DNS 设置与解析排查。

两类通用代理如何传递请求

HTTP 代理源于对网页请求的集中转发需求，能够以 HTTP 的方式接收代理请求；处理需要隧道的连接时，常见机制是 CONNECT。SOCKS5 则以更通用的目标地址和连接请求为中心，不依赖用户正在访问哪一种网页资源。两者的历史侧重点不同，但都需要服务器真实支持对应协议，不能因为只有地址和端口，就任意选其中一种尝试。

HTTP 代理、通过 TLS 连接的 HTTP 代理，以及经 HTTP 代理访问 HTTPS 网站，是三个不同概念。最后一种情况下，目标网站的 HTTPS 并不自动为客户端到代理入口的所有交互提供相同保护。SOCKS5 本身也不等于加密隧道。判断安全边界时，应明确外层连接是否有保护，以及业务内容自身是否使用端到端的安全协议。

账号认证与传输保护分开核对

这两类记录常见地址、端口、用户名和密码字段，但认证是否启用、支持什么方式，要以服务器设置为准。空用户名不一定表示匿名服务，填入任意字符也不会使服务器接受请求。如果已有资料只给出了带认证的代理地址，应按协议说明拆分字段，避免把用户名留在地址栏，或把端口误当成密码的一部分。

SOCKS5 的用户名与密码认证不负责提供完整的数据加密。使用环境需要保护外层连接时，必须确认服务实际提供了相应安全机制，而不是寻找一个名称相似的开关。HTTP 代理同样如此：应用访问目标站点的证书正常，只能证明该目标连接的相关校验通过，不能替代代理入口自身的身份与传输检查。

代理转发目标时，域名是在本地还是由代理侧处理，会影响解析结果和排错方向。客户端可能把域名交给代理，也可能因配置或请求形式先获得 IP。遇到按域名访问失败、按已知地址测试却正常的情况，应检查 DNS 路径和日志中的目标形式，不要立即把问题归因于账号认证。两种测试可能实际走了不同的解析链路。

UDP 支持不能从类型名称推断

SOCKS5 标准包含 UDP 相关机制，但实际使用还取决于客户端实现、服务器能力和网络可达性。HTTP CONNECT 的常见使用方式主要面向 TCP 隧道，不能直接推断所有 UDP 业务都能经过该入口。若用户的主要任务包含实时音视频或其他 UDP 请求，应明确验证该条记录的能力，不应把浏览器打开网页当作完整验收。

在 iPhone 或 iPad 上，这些协议的性能仍取决于连接路径。一个简单的入口可能在特定网络内表现直接，也可能因远端处理、连接数量限制或认证策略而产生等待。协议历史较长不代表必然更慢，字段较少也不代表必然更省电。若频繁失败重试，额外的无线活动反而会使简单配置产生明显电量成本。

适用情况通常是用户已有明确的 HTTP 或 SOCKS5 服务资料，或者需要接入既定网络中的代理入口。应先确认信任范围，再验证所需业务与解析方式。若目标是保护设备到远端入口之间的数据，仅选择这两个名称还不构成完整方案。无法确认入口安全层时，应补齐服务说明，而不是根据浏览器地址栏的安全标识推断整条链路。

从请求代理转向网络数据包

WireGuard 的设计关注点是以精简的协议结构建立网络层隧道，使用公钥识别对端，并通过 UDP 承载加密数据包。它与前面按目标连接组织代理请求的类型不同：配置不仅要知道连到哪里，还要描述本端使用的隧道地址、对端密钥以及允许进入相应路径的地址范围。将它理解为“另一个只填密码的服务器类型”，容易漏掉关键字段。

WireGuard 采用固定的现代密码学组合，减少用户在算法菜单中做选择的需要。这种取舍降低了算法组合的配置复杂度，却把正确性更多集中到密钥、地址和路由关系上。协议本身精简，并不意味着网络设置可以省略。密钥完全正确但隧道地址或允许范围不符时，仍可能出现握手成立而业务无法返回的现象。

本端私钥与对端公钥不能互换

私钥用于证明本端身份，应由用户妥善保管；公钥用于识别对端。客户端记录中需要的对端公钥，必须对应服务器实际使用的私钥，而服务器也需要识别该客户端对应的公钥。两端不是各自随机填一组值就能工作。若配置还使用预共享密钥，该值也须双方一致，并与公钥、私钥分别保存，不能互相替代。

Endpoint 描述外层服务器地址与端口，隧道 Address 描述进入隧道后的本端地址，两者属于不同网络层次。前者可以是公网可达的域名，后者可能来自指定的内部网段。将 Endpoint 的 IP 填入隧道地址，通常不能得到正确配置。导入用户已有资料时，应保留地址后的前缀长度，并区分 IPv4 与 IPv6 字段，不能只保留看起来像 IP 的部分。

AllowedIPs 将地址范围与对端关联，在完整配置语义中同时涉及选路和允许的来源范围。Shadowrocket 中还存在自身的规则策略，因此需要理解服务端隧道配置与客户端分流是两层不同约束。不要仅为“让所有请求进去”就扩大所有地址范围，尤其是在访问局域网或多个内部网段时，应按原始网络规划核对需要覆盖的目标。

保持活动与 MTU 都是边界参数

PersistentKeepalive 用于在需要时维持中间设备上的映射，有助于某些空闲后需要被对端联系的场景。它不是越频繁越可靠的通用开关：较短间隔意味着更多周期性数据包，在移动网络中可能增加无线活动。是否需要以及采用何种值，应由网络条件和既有配置决定。若只是在主动访问时偶尔重连，应先确认真正的空闲与映射行为。

MTU 描述一次承载的数据大小边界。隧道增加封装后，可用空间会变化；路径不能正确处理较大数据包时，可能出现小请求成功、大页面或大文件停顿。不能仅凭此症状就断定 MTU 错误，还应排除丢包与目标响应。确需调整时，保留原值，在同一网络、同一目标上逐次验证，不要同时改 DNS、规则和密钥。

在 iOS 上，WireGuard 的 UDP 承载与端点更新机制可以适应一些网络变化，但不能承诺所有切网过程都连续。当前网络若限制 UDP，或映射、路由与返回路径有问题，仍会影响使用。适合选择它的前提是已有完整且可用的隧道资料，尤其是需要访问指定内部网段的场景；不要只根据精简的协议设计，推导固定速度或电量优势。

面向波动路径的设计思路

Hysteria2 基于 QUIC 组织传输，利用 UDP 作为底层承载，并结合相应认证和拥塞控制机制处理代理流量。它的设计关注高时延、丢包和吞吐波动等路径条件，但这种设计方向不是对任意网络的性能承诺。首先必须确认当前网络允许所需的 UDP 通信；如果外层数据包不能正常到达服务器，再调整带宽或认证字段也无法补救。

QUIC 支持在一条连接中组织多个流，能够减少某些场景中不同流之间因丢包产生的交付阻塞。不过，所有流仍共享实际路径容量，拥塞和无线信号限制不会消失。Hysteria2 还需要将应用流量封装到自己的协议结构中，因此不能把某个 QUIC 特性直接等同于所有业务必然更快。观察结果应包含实际任务完成时间，而不只是瞬时传输峰值。

认证、TLS 与额外参数分别填写

基本配置需要服务器地址、端口、认证信息，以及服务要求的 TLS 设置。认证内容必须按已有资料原样对应，不能因为它表现为一段文本，就与其他协议的密码混用。证书名称的判断方法与前文相同：入口地址不一定等于 TLS 服务名称，应确认服务器证书覆盖预期身份，并保留校验。

部分服务还提供额外的混淆设置，其类型与密码需要双方一致。它与用户认证是不同字段，不能把两段密码合并，也不能仅在客户端启用而期待服务器自动识别。若订阅里没有该项，不应把它视作必需的性能设置。遇到无法识别的扩展，应先查明当前应用是否提供对应支持，再决定是否使用该条连接资料。

带宽参数容易被误解为限速解除按钮。它们在相关模式中可能参与发送策略或拥塞控制，填写的数值应当反映合理的路径能力，而不是期待的最高速度。估计过高时，发送可能超出实际承载能力，引起排队、丢包或其他任务响应变差。估计过低则可能限制吞吐。是否需要填写、单位是什么，应逐项依照应用界面和服务器说明确认。

速度和交互延迟需要一起看

在同一设备上，大文件传输速度较高时，其他页面的点击响应可能反而变慢，这通常涉及排队与带宽竞争。评估 Hysteria2 时，应同时观察持续下载和轻量请求，而不是只保留速度最好的一次结果。若调整参数后峰值提高但页面更容易停顿，应回退设置，再比较较温和的参数是否更适合当前网络。

移动网络信号变化会影响可用速率，固定的带宽估计很难一直准确。Wi-Fi 下得到的数值不宜直接照搬到蜂窝网络，也不能用一段空闲时的测试代表全天条件。频繁重试、长时间高吞吐和无线活动都可能带来发热与电量消耗。需要长时间后台连接时，应按真实使用周期观察，不应仅凭一次高速度结果决定长期配置。

适用前提是已有服务明确提供 Hysteria2，且当前网络能够稳定传递其 UDP 流量。若所处网络不满足这个条件，应在已有服务提供的其他可用记录中验证，不要不断放大带宽数值。选型结论应写成“在这一网络和任务下更合适”，而不是把一次体验推广为协议的固定排名。

从必要能力筛选，而不是给名称排名

实际选型应先列出任务约束：已有服务支持哪些类型，当前网络能否正常使用 TCP 与 UDP，是否需要访问内部网段，以及主要任务是短页面、持续传输还是实时交互。完整资料与稳定可达性优先于协议名气。只有一条有效配置时，先将它验证清楚；存在多条记录时，再用一致条件比较，不必为了追求某个名称重新拼凑参数。

日常网页访问可以先使用字段完整、握手稳定的已有记录，重点看首个页面和连续页面的响应。需要指定内部网络地址时，核对 WireGuard 等既有隧道资料中的地址与路由。需要 UDP 业务时，确认协议、服务器和路径共同支持。持续传输则应同时观察吞吐、其他请求的等待和设备发热，不把某一次峰值当成综合结论。

先确认 Global Routing，再改协议

Global Routing 的配置、代理、直连三种姿态，对应界面词 Config、Proxy、Direct。Config 按当前配置的规则选择策略；Proxy 用于将相关流量按代理姿态处理；Direct 用于直连。使用 Proxy 可以帮助比较部分规则影响，但不是完整诊断结论，具体请求仍需结合日志确认。测试结束后，应恢复日常使用的姿态，避免把临时排错设置当成长期规则。

下面的片段仅演示规则语法与先后关系，不是完整配置，也不含服务器信息。规则自上而下匹配，FINAL 放在末尾承接此前未命中的请求。示例中的 PROXY 仍需在实际配置中对应可用策略。关于配置段落见.conf 结构说明，关于命中顺序见自定义规则与 FINAL。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY

每次只验证一个失败层次

完全无法连接时，先核对当前网络能否使用，再确认服务器地址、端口和协议类型；随后看错误是否指向 TLS、认证或超时。连接成立但网页打不开时，检查 DNS 和目标请求的策略。仅部分业务异常时，检查其是否需要 UDP、是否使用不同目标，以及大数据包或并发是否触发问题。不要同时更换 DNS、关闭校验、修改规则和重建服务器。

建立一份简短测试记录，写明网络类型、选定记录、Global Routing 姿态、目标任务及错误阶段即可。更换 Wi-Fi 与蜂窝网络时，保持其他设置不变；比较协议时，也尽量固定目标和任务。电量观察应覆盖足够的正常使用时间，并留意屏幕亮度、后台任务和信号强弱。短时电量百分比变化不足以证明某个协议固有耗电更高。

整理日志或截图前，删除订阅地址、认证密码、私钥和能恢复配置的内容。只保留相关时间段、目标类型及错误描述，避免整份配置外传。订阅更新后出现差异时，先比较类型、地址、传输和认证字段，不要立即覆盖所有本地设置。应用购买恢复属于另一条流程，见已购恢复说明，不通过重建协议记录处理。

最后将结论落实为可重复操作：确认一条有效记录、保存原始资料、恢复日常规则，再验证真实业务。仍有异常可阅读已连接却无法上网的检查顺序或常见问题；需要重新走一遍导入步骤，则返回快速上手教程。协议选择到此形成闭环：资料正确、路径可达、策略符合预期、任务验证通过。