Shadowrocket
协议类型与参数核对

01 · 选型前先区分四层信息

协议名称只回答其中一个问题

在 Shadowrocket 中，服务器条目包含的并不只有协议。地址和端口决定连接到哪里；Shadowsocks、VMess、VLESS 等类型决定双方使用什么方式交换代理请求；TCP、WebSocket 等传输决定数据如何承载；TLS 则涉及加密与证书验证。规则和策略属于另一层，决定某次请求是否交给这个条目。四层可以同时影响结果，但不能互相替代。

因此，同一个地址不意味着可以任意切换类型。把 VLESS 改成 Trojan，即使端口和密码看似相近，也不会自动让服务器理解新的请求。服务器必须实际提供对应入口，身份字段、传输方式与安全设置也要一致。本文所说的“选择协议”，是从用户已有、明确支持的条目中选择，不是把一个条目的类型名称改成另一个名称。

从已有信息建立核对顺序

导入已有订阅后，先在 Home 查看条目，再进入编辑页核对类型与服务器地址。需要手动添加时，从 Add Server 选择与服务器说明一致的类型。不同类型会显示不同字段，字段是否出现、可选值和具体位置以当前应用界面为准。不要因为某篇说明提到一个字段，就把它填进名称相近但用途不同的输入框。

核对顺序建议固定为地址与端口、身份凭据、传输、安全设置，最后才是规则。这个顺序对应故障发生的层次：地址错误时连接尚未抵达目标；凭据错误时无法通过身份核验；传输不一致时请求不能被正确解析；证书验证失败时安全连接无法成立。提前改规则通常不能解决这些问题，反而可能使测试对象变得不明确。

客户端、服务与商店信息分别确认

Shadowrocket 是闭源商业应用。本页重点说明 iPhone 和 iPad；Mac、Windows、安卓与 Linux 版免费。客户端一次性买断 ≠ 线路套餐：购买的是客户端使用权，连接需要用户已有自己的订阅或服务器信息。本站不提供、不销售、不推荐节点或订阅。已有订阅是否有效、服务器允许哪些协议，应从该订阅对应的说明中确认，不能根据客户端能显示哪些类型来反推。

iPhone 与 iPad 在 App Store 购买，其余平台免费。需要安装包时，前往下载页，确认开发者 Shadow Launch Technology Limited、官方图标及应用 ID 932747118。系统要求与购买适用范围以 App Store 页面标注为准。连接失败与购买状态是两类问题，应用已经能正常打开，并不代表服务器信息一定有效。

02 · Shadowsocks：加密方法与凭据配套

从轻量代理的设计目标理解参数

Shadowsocks 的设计出发点是用相对简洁的协议承载代理流量，并让客户端和服务器通过共同约定的加密方法与密码交换数据。它不是把整台设备直接放进远端局域网，也不天然规定网站请求必须经过代理。Shadowrocket 仍然依据当前 Global Routing 状态和配置规则决定请求的去向，协议负责的是被交给它的那一部分流量。

这种分工让核心字段比较集中：服务器地址、端口、加密方法和密码是首先需要核对的内容。简洁不等于字段可以猜测，尤其不能仅凭密码正确就认定身份设置完整。加密方法是协议双方解释数据的约定，选择错误时，服务器可能收到连接却无法解析内容，表现可以与密码错误相似，通常不能靠重复连接自行恢复。

Method 与 Password 为什么要一起看

现代部署常使用带认证的加密方法，同时检查内容是否遭到修改。不同方法对密钥长度、派生方式与数据格式有各自要求。填写时保留服务器给出的完整方法名，不要把名称中相似的部分当成同一种方法，也不要把一个条目的密码复制到另一个条目后假定两者可以互换。协议变体之间的凭据格式还可能不同。

较新的 Shadowsocks 变体可能使用特定编码和长度的密钥，而不是任意一句口令。此时密码框里的字符串虽然看起来像普通文本，含义却是规定格式的密钥材料。不要自行缩短、补齐或重新编码。若导入成功但手动重建失败，先检查复制过程中有没有丢失末尾字符、混入换行，或者把链接转义后的文本当成了原始凭据。

UDP 与额外传输不能靠名称推断

部分应用流量会使用 UDP。TCP 网页可以加载，只能说明该条目的相关路径可用，并不能证明 UDP 同样可用。还要确认服务器端是否允许相应转发、当前网络能否传递数据，以及客户端条目的相关设置是否符合已有说明。把一个 UDP 失败问题判断为“整个协议不稳定”，会遗漏服务端限制或网络路径差异。

有些已有条目还附带额外传输设置。需要逐项确认这些设置的具体用途，而不是看见 Shadowsocks 就默认它们不存在。附加层与核心协议是不同的核对对象：核心密码正确，附加层参数错误仍会失败；删除不认识的参数也可能破坏原本完整的入口。先使用订阅导入的原始条目，是比手工精简更容易复现的基线。

在 iPhone 上怎样判断是否合适

在条件相同的情况下，较少的封装层可能减少部分处理开销，但这不构成速度或电量保证。实际体验还取决于加密实现、设备处理能力、服务器负载、丢包与往返时延。一次短网页测试主要感受到连接建立和小数据传输；持续文件传输观察的是吞吐。两种测试可能得出不同的主观结论，应该分别记录。

已有 Shadowsocks 条目能够稳定完成日常请求时，没有必要仅因为另一种协议名称更新就替换它。若出现可连接但特定应用失败，先区分域名解析、TCP 与 UDP 路径，再检查规则是否让该应用走了不同策略。遇到所有请求均失败，则优先回到地址、端口、加密方法和密码这四项，不要先调整电量相关设置。

03 · VMess 与 VLESS：身份、传输和 TLS

相近的字段不代表相同的协议

VMess 将身份认证与协议自身的数据保护机制结合，常见身份字段是 UUID。VLESS 则采用更精简的身份与请求描述，把链路安全更多交给外部安全层完成。二者都可能搭配不同传输，所以编辑页看起来会有相近字段，但它们不是可以通过更换类型互转的格式。使用哪一种，必须与服务器实际入口一致。

理解这种设计取舍，有助于避免把“字段少”直接理解为“更安全”或“更快”。VLESS 本身不提供与 VMess 相同的内容加密机制，部署时要明确外层如何保护连接；VMess 有自己的安全机制，也不意味着其外层传输参数可以忽略。评价一个条目时，应把协议、传输和安全设置作为完整组合，而不是只评价名称。

UUID 是身份信息，不是显示名称

UUID 应逐字符保留原值。条目名称可以用于区分地区或用途，改名通常不改变认证；UUID 则直接参与身份核验，随意改动会让服务器无法识别。复制时注意连字符、前后空格和自动换行。多个条目共用同一 UUID 也不能证明它们的地址、端口及其他设置相同，仍需要完整核对每个条目。

VMess 的认证还涉及时间信息。设备时间明显偏差时，可能出现参数看似正确却无法认证的情况。先在系统设置中确认日期与时间合理，再排查服务器凭据；不要以频繁改动 UUID 作为测试方式。若既有信息包含其他兼容字段，按服务器说明填写，不要从年代不同的示例中混合摘取数值。

WebSocket 的 Host、Path 与 TLS 的 SNI

WebSocket 把代理数据放在相应的连接之上，常见核对项包括 Host 与 Path。Path 必须与服务器路由匹配，开头的斜杠、大小写和尾部路径都可能有意义。Host 用于相关请求的主机信息，服务器可能根据它把请求交给不同入口。这两项错误时，即使目标端口可以建立连接，后续协议交换也可能失败。

SNI 是 TLS 握手中使用的服务器名称信息，证书验证则需要确认预期名称与证书匹配。服务器连接地址、WebSocket Host、SNI 在某些部署中相同，在另一些部署中不同；不能把三个输入框自动填成同一个值。通过 IP 地址建立底层连接时，也仍可能需要服务器说明给出的域名来完成正确的安全连接。

选型时以整套入口为单位

部分 VLESS 组合还要求 Flow 或特定安全参数。只有服务器明确要求、当前客户端也提供对应选项时才填写。不要因为另一个可用条目设置了某个值，就把它照抄到所有 VLESS 条目。不同组合的限制不同，空白也可能是正确状态；判断依据始终是当前服务器入口的配置信息。

在 iOS 上比较二者，先控制传输与安全层差异。一个使用直接 TCP 的条目与另一个使用多层封装的条目，测试结果不能只归因于 VMess 或 VLESS。若原始订阅条目可用而手动条目失败，先逐项对照 UUID、传输、Host、Path、TLS 和 SNI。只有对应组合全部一致，比较处理开销才有实际意义。

04 · Trojan、HTTP 与 SOCKS5：安全边界

Trojan 把 TLS 放在关键位置

Trojan 的常见设计是在 TLS 连接内承载代理请求，再通过密码等信息识别用户。它利用成熟的安全传输机制，但客户端仍需要正确的服务器地址、端口、密码与验证名称。能够连到端口，只能说明底层路径存在；密码正确也不能绕过证书名称不匹配。排错时应把握手失败与身份认证失败作为两种问题处理。

域名、SNI 和证书之间的关系尤其重要。证书应覆盖预期的服务名称，并处于有效、受信任的状态。若使用地址与验证名称不同的入口，按服务器信息分别填写。出现证书错误时先核对设备时间、名称和服务端证书链，不要把关闭验证作为常规修复方法，因为那会削弱识别连接对象的能力。

HTTP 代理不等于所有流量都受到保护

HTTP 代理源于应用层代理需求，可以转发请求，也常通过 CONNECT 为目标建立字节通道。条目中常见地址、端口、用户名与密码。这里需要区分两段连接：设备到代理服务器，以及应用到目标站点。目标站点使用 HTTPS，并不自动意味着设备到代理的身份信息也受到相同方式的保护，外层是否使用 TLS 必须另行确认。

因此，已有说明写 HTTP 时，不要自行假定它等同于带 TLS 的代理入口；说明要求安全传输时，也不要只填写普通代理字段。两端支持的方式不同，握手就可能不匹配。用户名和密码的正确性、代理是否允许 CONNECT、是否限制目标端口，都可能影响“部分网站可用、部分失败”的表现。

SOCKS5 提供通用协商，但不自带加密

SOCKS5 通过协商描述目标地址与连接需求，可以使用用户名和密码认证，也定义了 UDP 相关机制。它本身不为所有承载内容提供加密。身份认证与内容保密是不同能力，不能因为条目要求密码就认定链路已加密。实际安全边界还取决于网络环境、外部安全层和应用自身的连接保护。

SOCKS5 条目可以连接，不代表 UDP 一定可用。服务器可能仅允许 TCP，网络也可能无法传递 UDP 关联所需的数据。另一个需要区分的问题是域名在哪里解析：应用、客户端配置和代理请求形态共同影响实际路径。遇到域名失败但直接地址测试不同的情况，应检查 DNS 与规则，不要只重复修改代理密码。

按既有环境选，不按名称做安全排名

如果已有环境只提供某种代理入口，首先确认其传输保护与访问权限，再决定是否符合用途。不能用客户端的类型选项为服务器增加 TLS，也不能把 HTTP 改成 SOCKS5 来解决认证失败。对于组织管理的既有入口，还要遵循其访问范围和设备使用规则，避免把一个有限用途的代理误当成通用通道。

在 iPhone 上，这几种类型的速度差异常被网络路径掩盖。握手次数、连接复用、服务器响应和无线网络状态都可能比协议解析开销更明显。正确比较应使用同样的任务与相近环境，并先确认各条目安全设置完整。若某个条目只在绕过证书验证后可用，应修正服务信息，而不是把这个结果当成性能优势。

05 · WireGuard：密钥、地址与隧道范围

从网络层隧道理解它的不同

WireGuard 的设计目标是以相对精简的协议与固定的现代密码组合建立网络层隧道。与按代理请求描述目标的协议不同，它处理的是隧道中的 IP 数据包。这个差别会反映在配置字段上：除了远端地址，还要理解本地隧道地址、双方密钥及允许通过对端的地址范围。不能把普通代理的密码填法直接套用过来。

在 Shadowrocket 中使用 WireGuard，仍需把条目自身的隧道参数与客户端的规则决策分开。条目定义如何与对端通信，Global Routing 和配置决定哪些请求交给它。看到隧道内地址，不代表设备上的每个请求都已按预期通过隧道；看到客户端连接开关开启，也不能证明远端已经允许访问所需目标。

Private Key、Public Key 与 Endpoint

Private Key 属于本地身份材料，应保密保存；对端的 Public Key 用于识别远端。两者不是同一字符串的两个显示名称，也不能对调。若已有配置还包含 Preshared Key，它是额外的共同密钥，双方需要一致。排查时只记录字段是否存在与是否匹配，不要把完整密钥复制进公开截图、日志说明或问题留言。

Endpoint 指向远端可达地址与端口，不等于隧道内部的地址。配置中的本地地址则用于隧道内通信，也不是任意挑选一个私有地址即可。服务端需要认识相应客户端与地址关系，重复使用不适合的地址或身份可能导致冲突。新设备是否可以沿用同一组信息，应按用户已有服务器的配置规则确认。

Allowed IPs 与路由并非同一张表

Allowed IPs 涉及对端可承载的地址范围，并参与隧道内部的选路与来源约束理解。它与 Shadowrocket 的 DOMAIN-SUFFIX 等规则处于不同层次。外层规则即使把某个请求交给了 WireGuard，隧道或远端未允许相关地址范围，流量仍可能失败。反过来，隧道允许一个范围，也不代表客户端必然把所有相关请求交给它。

需要访问已有内部资源时，还要检查远端转发、目标返回路径与名称解析。隧道握手可以成功，但目标设备不知道如何返回数据，仍会表现为请求超时。若只有域名失败而对应内部地址可达，优先检查内部 DNS 的可达性及解析配置；若所有内部地址都不可达，再检查地址范围、远端权限与路由。

MTU 与 Persistent Keepalive 的取舍

MTU 限制单个隧道包可承载的大小。封装增加额外字节，路径又可能有自己的限制，设置不合适时会出现小请求成功、大传输停滞。不要看到卡顿就不断调低数值，应先确认故障是否与包大小有关，并保留原值。调整后用同样的目标和传输任务复测，避免把短时网络波动误认为 MTU 修复效果。

Persistent Keepalive 用于在某些网络地址转换环境下维持映射，但定期发包也会增加无线活动。它不是数值越短越稳定，更不是所有网络都需要。只有出现空闲后返回路径失效、且已有配置允许调整时，才有理由评估这一项。iPhone 在蜂窝网络下的唤醒成本需要纳入观察，不能只看一次重新连接是否更快。

06 · Hysteria2：UDP 路径与带宽估计

设计重点是有损路径上的传输行为

Hysteria2 基于 QUIC 构建代理传输，QUIC 通常运行在 UDP 之上。其关注点包括在存在丢包和较长往返时延的路径上维持传输效率。这里的“有损”描述网络条件，不代表所有蜂窝网络都符合相同特征。是否适合当前环境，需要先确认 UDP 路径可用，再观察实际任务，而不是根据协议名称预先判断速度。

QUIC 把安全握手与传输机制结合，并允许多路流在一个连接中承载。不同流之间可以减少部分因单一有序字节流造成的相互等待，但共享链路拥塞、无线丢包和服务器资源限制仍然存在。它不能把实际带宽变大，也不能让远端响应变快。某个网站加载慢，仍可能是 DNS、规则或目标本身的问题。

先核对认证与证书，再看性能参数

基本字段通常包括服务器地址、端口、认证信息和 TLS 相关设置。认证值应完全使用已有信息，不能把其他协议的 UUID 或密码按外观相似直接替换。SNI 与证书验证仍需要成立；QUIC 使用 UDP，并不意味着可以忽略服务端身份。证书错误与 UDP 不通可能表现不同，排查时应分别记录。

已有服务器若要求额外的 Obfuscation 方式或密码，需要客户端与服务器一致。它属于匹配入口的一部分，不是随意启用就会改善性能的按钮。没有明确配置时不要添加，已有配置包含时也不要随手删除。端口范围或端口切换同样需要远端明确支持，修改单端数值不会自动建立新的可达入口。

带宽字段表达估计，不是速度承诺

某些传输模式会使用用户填写的上行、下行带宽信息来参与发送控制。这些值应根据客户端视角理解方向，并严格核对单位。数字填得更大，不会增加物理链路容量，反而可能让发送速率与实际路径不匹配，造成排队、丢包和波动。数字过小则可能限制有效利用率，需要结合当前模式判断。

不同网络的可用带宽会变化，家中 Wi-Fi 的结果不能直接代表蜂窝网络。测试前先使用已有配置给出的基准，不要同时改上行、下行和其他传输参数。若当前界面或服务器采用自动估计方式，应按该方式的说明处理，不要把另一种模式的必填要求照搬过来。参数含义比追求一个大数字更重要。

识别 UDP 路径受限的情况

如果普通网页在不经过该条目时可用，而 Hysteria2 一直无法完成连接，可能需要检查当前网络对 UDP 的支持、服务器端口及远端运行状态。但单凭超时不能立即断定是 UDP 限制，也可能是地址解析、认证或安全设置错误。可以在另一种可信网络下用同一原始条目复测，以缩小路径因素的范围。

若连接能建立但持续传输波动明显，先观察是否存在无线信号变化、上行占满或设备发热。较积极的发送行为在特定路径上可能改善吞吐，也可能增加重传、无线活动与电量消耗。对于移动设备，应把单位任务完成时间和耗电一起记录；只看到短时间峰值，无法判断它是否适合长期使用。

07 · 在 iOS 上分开观察速度与电量

把“快”拆成三个可观察结果

首次打开页面的等待、持续传输的吞吐和长连接的稳定性，是三个不同指标。等待时间包含 DNS、建立底层连接、协议握手、安全握手以及目标响应。持续吞吐更多受瓶颈带宽、拥塞控制和服务器负载影响。长连接则会受到网络切换、空闲超时和后台状态影响。不能用一个延迟数字概括三者。

Connectivity Test 的结果取决于所用测试方法与目标，适合判断某种可达性或相对变化，不等于实际应用的完整路径。测试成功后页面仍失败时，需要继续检查 DNS、规则及目标请求。关于测试结果如何使用，可参阅延迟测试与实际加载体验说明，避免只按最低数字判断可用性。

比较协议时控制哪些变量

尽可能使用同一设备、同一网络、相近时间和相同目标进行比较。若两个条目位于不同远端位置、使用不同线路或负载差别明显，结果首先代表两条完整路径，而不是纯协议差异。已有条件无法控制时，可以记录真实体验，但结论应写成“这个条目在当前网络下的表现”，不要推广成某协议始终更快。

每轮只改变一个因素，并分别观察短请求和持续任务。首轮可能受缓存、握手和无线状态影响，重复测试应保留间隔。连续跑满带宽会改变设备温度和网络拥塞，反过来污染结果。若测试过程中切换 Wi-Fi、进入弱信号区域或发生其他大流量任务，应把该轮视作不同条件，不能直接合并比较。

耗电来自数据量，也来自无线活动

加密与封装需要处理时间，但移动设备的电量还会受到信号强度、无线唤醒、重传、屏幕和后台任务影响。某种协议处理开销较低，不代表实际总耗电一定较低。如果连接频繁失败并重试，或维持连接的报文让无线模块持续活动，额外成本可能超过协议算法本身的差别。需要看任务完成后的整体结果。

观察耗电时，先区分持续视频、主动传输和空闲保持。持续任务可以比较完成相同工作所需的时间及电量变化；空闲场景则关注是否存在不必要的定时测试、保活和重连。系统电池统计提供的是一段时间内的活动线索，不是严格的协议能耗实验。短时间百分比不变，也不能证明没有额外开销。

On Demand 与连接复用的边界

On Demand 控制按网络条件触发连接，不会让服务器协议自动适应错误参数。先在手动连接下建立稳定基线，再添加触发条件，才能区分是协议连接失败还是自动触发没有发生。具体条件设置可结合On Demand 网络条件说明查阅，测试时同时记录网络变化和连接状态。

连接复用可以减少反复握手，但也可能使多个请求共享同一连接的拥塞或故障状态。是否启用应服从已有服务器的支持范围与当前界面说明。遇到少数请求卡住时，不能只凭“复用通常更快”而排除它的影响；应保留原始条目，在相同任务中做单变量对照，并确认变化可重复出现。

08 · 按场景选型，再按层次排错

从用途筛选已有条目

日常浏览首先要求短请求稳定、名称解析正常和安全设置完整，已有可用条目就是合理起点。持续传输需要观察稳定吞吐与温度，而不是只看首次测试。访问已有内部网络时，WireGuard 的地址范围和返回路径可能是核心；在存在丢包的路径上，可以评估已有 Hysteria2 条目，但前提是 UDP 可用。以上都是检查方向，不是协议优劣排名。

如果已有信息只提供一种协议，先正确配置这一种，不必为了比较而寻找其他入口。若同时提供多种完整条目，先保存各自原始配置，按实际用途分别测试。不要把一个条目的 TLS、另一个条目的 Path 和第三个条目的凭据拼在一起；混合配置产生的失败不能用于判断任何一种协议是否适合。

先确认 Global Routing 的测试姿态

配置姿态 Config 按配置文件规则选择策略；代理姿态 Proxy 用于把相应流量交给代理路径；直连姿态 Direct 用于按直连路径处理。改变姿态会改变测试的去向，因此每轮必须记录当前选择。Proxy 仍受条目和请求能力的边界约束，不能修复错误凭据；Direct 可作为路径对照，也不等于所有请求都一定成功。

协议条目已验证后，再回到 Config 检查规则顺序。下面是用于解释匹配逻辑的 .conf 片段，不是通用配置；PROXY 策略需要在实际配置中可正确解析。规则通常按顺序匹配，FINAL 用于前面未匹配的请求。域名规则与 IP 规则依赖不同信息，DNS 解析也可能影响最终匹配。

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

这个示例将 example.com 及其子域名交给 PROXY，将指定私有地址范围与 GEOIP 命中的地址交给 DIRECT。它不意味着所有环境都应该采用相同策略，GEOIP 判断也依赖地址与所用数据。需要理解段名和配置边界时，继续阅读.conf 各段作用说明，不要用改协议代替修改误匹配规则。

按失败发生的位置缩小范围

完全无法连接时，先核对当前网络、地址解析、端口和服务器状态，再检查身份字段。出现明确证书问题时，检查时间、SNI、名称和证书链；连接建立后才失败，则继续看传输入口、目标访问权限和转发能力。只有部分域名异常时，优先核对 DNS、规则命中与目标状态，而不是立刻重建所有条目。

若网页正常而某类实时应用失败，分别确认 TCP 与 UDP；若小请求正常而大传输停滞，观察 MTU、重传和拥塞；若空闲后失效，检查映射超时与保活需求；若仅切换网络后出现，记录切换前后地址和连接恢复情况。每个分支只修改相关设置，复测同一个任务，成功后再恢复其他自动化条件。

记录结论，但不要暴露凭据

一份有用的排错记录包括协议类型、传输方式、网络条件、失败阶段、当前 Global Routing 姿态和可重复的目标现象。Password、UUID、Private Key 及完整订阅地址不应进入公开记录。应用日志或截图可能包含这些信息，分享前需要逐项检查，而不是仅遮住条目名称。名称通常不是最敏感的字段。

最终保留的是“哪个完整条目适合什么任务、在哪种网络下测试成立”的结论，而不是抽象的速度名次。首次操作回到教程主线，常见现象可查常见问题，应用购买与恢复则查App Store 核验说明。把购买、导入、协议连接和规则命中分开处理，下一次排错才能从已确认的层次继续，而不是从头猜测。