Shadowrocket
协议类型与参数参考

先确认服务器提供的协议，再选择 Type

协议类型必须与服务器端匹配，不能把同一组地址和密码任意切换成另一种类型。在 Home 的服务器编辑入口或 Add Server 中，Type 决定客户端怎样组织认证和数据；服务器必须理解相同格式，连接才有机会成立。用户已有的订阅通常已包含这些选择，导入后应先保留原值。只有掌握服务端实际配置时，才适合手动重建条目；仅凭名称里写着某种协议，并不足以确认全部参数。

一条连接应拆成多个层次理解。地址和 Port 决定先连接到哪里，协议认证决定对方是否接受请求，传输方式决定字节怎样承载，TLS 负责相应通道的身份验证与加密，Global Routing 则决定哪些请求进入这条路径。同样的 VLESS 可以搭配不同传输，同样使用 TLS 的两条连接也可能有不同认证机制。排查时如果把这些层次混在一起，容易出现改了密码却实际上是证书不匹配的情况。

七类协议不是速度排行榜

协议的历史背景反映的是设计目标，而不是在任何网络中的固定表现。Shadowsocks 偏向精简的代理转发，VMess 包含自身的认证和数据保护设计，VLESS 将更多保护责任交给外层机制，Trojan 使用 TLS 通道承载代理请求。HTTP 与 SOCKS5 是通用代理接口，WireGuard 处理 IP 层隧道，Hysteria2 则使用基于 QUIC 的传输。它们解决的问题并不完全相同，不能只按名称从旧到新排序。

速度通常先受服务器出口、往返时间、拥塞和无线信号制约，之后才轮到协议处理开销。一次网页打开可能包含 DNS 查询、握手和多个短请求，持续下载则更受吞吐量影响；两者结论可能相反。在 iPhone 上还要考虑蜂窝信号、低电量状态和前后台切换，不能把一次测速最高值当作日常体验。比较时应固定设备、网络、服务器条件与目标，只改变一个可控变量。

用工作负载解释电量与兼容性

电量消耗取决于实际传输量、连接维持方式和无线模块工作时间，不是某个协议永久拥有的属性。频繁建立 TLS 连接可能增加短时开销，持续发送保活包可能让网络更常被唤醒，丢包后的重传也会增加耗电。长时间视频、少量消息和待机三个场景应分别观察。设备温度升高时先检查 Data 中的流量变化和后台任务，不要直接认定协议实现存在问题。

TCP 与 UDP 能力也应分开核对。网页能够打开，只证明相关路径上的请求成功，并不能证明语音或其他 UDP 流量可以通过。部分协议支持 UDP，但服务端、当前传输方式或上游网络未必允许；反过来，使用 UDP 承载的协议也可能转发应用的 TCP 请求。这里的“应用流量类型”和“外层连接类型”是两个概念，看到一个 UDP 字样不能据此判断全部应用行为。

选型的第一轮只需要回答三个问题：服务器实际提供什么、当前网络允许什么、需要承载什么业务。随后再看认证资料是否完整、证书能否正确验证，以及连接失败后是否容易定位。若目前只有一种可用类型，应先把它配置正确，而不是寻找无法在服务端对应的设置。需要先认识分享格式时，可阅读分享链接与订阅链接的区别，再返回对应协议章节。

UUID 相似，不代表连接方式相同

VMess 的设计包含用户认证和自身的数据保护机制，VLESS 则采用更精简的身份识别结构，将通道保护更多交给 TLS 等外层方案。两者都可能使用 UUID，但服务端处理方式不同，不能把 Type 从 VMess 改成 VLESS 后保留其余字段就认为完成转换。已有分享资料指明哪一种，就应使用哪一种；只有服务端同时配置了对应入口，客户端才有条件分别建立条目进行比较。

UUID 是身份标识，不是服务器地址，也不是订阅链接中的任意查询参数。复制时应检查是否混入空格、换行或引号，并保留完整结构。VMess 还可能涉及安全选项或历史兼容字段，这些值应按服务端资料处理，不应从旧教程推断所有服务器必须填写同一个数字。VLESS 的认证精简也不表示可以忽略外层保护；需要 TLS 的入口如果关闭 TLS，通常无法按预期完成连接。

传输选项必须作为一组理解

TCP、WebSocket 等传输方式描述的是代理数据如何承载，并不替代 VMess 或 VLESS 本身的身份认证。同一地址可以有不同入口，其中一个要求 WebSocket，另一个只接受直接的 TCP 连接。选错传输时，网络层可能仍显示端口可达，但后续数据无法被正确处理。添加服务器时应把传输类型与相应的 Host、Path 等参数一起核对，避免只改顶部的一个选项。

WebSocket 的 Path 是服务端接收请求的路径，通常需要精确匹配，包括前导斜杠和大小写；它不是任意的网站目录。Host 是相关请求中的主机信息，SNI 则参与 TLS 握手，两者虽然有时相同，却承担不同职责。Address 可以指向实际连接入口，Host 与 SNI 可以指向配置要求的名称，不能看到三处不同就擅自统一。应根据已有资料分别确认，而不是用其中一个值覆盖另外两个。

TLS 的证书验证用于确认连接对象的身份，不能把“能够连上”作为关闭验证的理由。证书域名与预期名称不匹配、证书链不完整、设备时间明显错误，都可能导致握手失败。应先检查 SNI、证书和时间，而不是跳过验证。对于需要其他握手机制或特定参数组合的入口，也应完整保留导入结果；某个界面选项出现，不意味着所有服务器都支持该选项。

比较表现时把传输开销一起计算

额外的封装和握手会增加首个请求的工作量，但是否能感知取决于连接复用、往返时间和业务模式。连续请求复用已有连接时，初次建立的成本可能被摊薄；反复建立短连接时，握手时间更容易体现。在稳定网络下比较下载速度，也不能直接推断弱信号环境下的表现。iPhone 日常使用包含后台恢复和网络切换，应至少覆盖这些过程，再判断某个组合是否更适合当前环境。

遇到“服务器测试有结果，网页却打不开”，应把端口可达与完整请求成功区分开。先确定 Global Routing 让目标进入该条目，再检查 UUID 和 Type，随后核对 TLS 与传输字段。若浏览器出现证书相关错误，还要判断错误来自代理入口还是最终网站，两者不是同一张证书。保留具体错误和发生阶段，比只记录“无法连接”更容易找到需要修改的字段。

如果手头同时有多种协议入口，优先选择参数完整且能通过证书验证的一组，再比较业务体验；不要因为 VLESS 的结构更精简就断言一定更省电，也不要因为 VMess 有自身保护就忽略外层配置。需要快速识别协议名称时，可先读支持的协议一分钟速览，本章则用于处理字段之间的依赖与失败边界。

它传递 IP 数据包，而不是只描述代理目标

WireGuard 的设计重点是精简的 IP 层加密隧道，使用公钥识别对端，并通过 UDP 承载数据。它与提交目标地址的应用代理协议不同，客户端和服务端还需要知道隧道内部如何分配地址、怎样把目标流量交给正确对端。在 Shadowrocket 中使用时，外层依然受到应用整体接管与路由机制影响，不能把一份隧道参数的含义完全等同于 Global Routing 的模式。

密钥关系是排查的起点。客户端 Private Key 必须保密，对应的公钥需要在服务端被登记；客户端填写的 Peer Public Key 应是服务器对端的公钥。两者位置颠倒、复制不完整或仍使用旧公钥，都可能导致握手无法成立。若资料还包含预共享密钥，也必须两端一致。不要把服务器公钥填入客户端私钥字段，更不要为修复连接而把真实私钥写进反馈截图或公开记录。

Endpoint、Address 与 Allowed IPs 不应混用

Endpoint 是外部网络中连接服务器的位置，通常由域名或 IP 与 UDP 端口组成。Address 是隧道内部使用的地址，并不是设备当前 Wi-Fi 的局域网地址，也不是服务器公网地址。已有配置给出什么地址和前缀，应按要求保留；随意换成“看起来空闲”的私网地址，可能与服务端路由或地址分配冲突。握手成功只证明密钥与入口基本可用，并不证明内部地址正确。

Allowed IPs 表达对端关联的目标地址范围，也参与相应的路由判断；它不是应用层域名规则。范围缺失时，握手可能正常但业务数据不进入预期对端；范围过大时，也不能据此推断 Shadowrocket 的全部请求都会绕过 Config 的选择。应分别核对服务器条目的隧道设置与应用级策略，并用实际目标验证。涉及 IPv6 时还要确认隧道地址、目标范围和服务器转发能力均包含相应支持。

DNS 是另一项独立配置。隧道中能访问某个 IP，却无法访问域名时，问题可能在解析服务器的可达性，而非 WireGuard 的加密。已有配置里的 DNS 地址可能只能通过隧道访问，此时路径和规则必须允许相关请求。排查时可以先区分地址访问与域名访问，再检查 DNS 结果；不要用修改密钥的方式处理解析失败，也不要因为握手存在就排除路由问题。

MTU 与保活需要针对路径调整

封装会占用额外空间，MTU 用于限制相应数据包的大小。过大的设置可能在某些路径上造成大请求卡住、部分网页加载不完整或持续传输异常，而小请求仍然成功。过小的设置则可能降低有效传输效率。只有出现与包大小有关的证据时，才适合谨慎调整；每次保留原值并比较同一任务，不应从另一种网络照搬一个数值作为所有设备的固定答案。

Persistent Keepalive 用来在需要时维持网络映射，但不是增加吞吐量的加速开关。蜂窝网络或某些路由环境可能需要定期活动来维持返回路径，过于频繁的保活则会增加无线唤醒。应根据现有网络是否存在空闲后恢复失败的现象来判断，而不是默认把间隔设得很短。iPhone 在屏幕关闭和网络切换后的表现，也应与前台持续下载分开观察。

WireGuard 适合已经具备完整隧道资料、需要明确 IP 层访问范围的场景。它的结构精简并不取消服务器转发、防火墙和地址规划的要求。若只拿到 Endpoint 与一个公钥，通常还不足以重建全部配置，应向现有配置来源核对缺少的资料。分享问题时可以记录错误阶段、网络类型与目标范围，但密钥和内部访问资料应保留在受控环境中。

导入成功只代表内容被识别

订阅或分享链接被 Shadowrocket 接受，并不表示服务器当前可用，也不表示全部字段都符合现有入口。导入后应先检查 Type、Address、Port、身份字段和传输设置，再选择服务器进行验证。对于已有订阅，应从自己的配置来源获取更新信息，并注意更新可能覆盖手动修改。需要长期保留的本地调整，应先明确哪些内容由订阅管理，避免下次更新时误以为应用自行改变了设置。

分享链接和 Subscribe 订阅承担不同任务。前者通常描述单个条目，后者可能返回多个条目并持续更新；两者还可能使用不同编码或格式。二维码只是内容的另一种载体，不会让错误参数变得正确。Scan QR Code 导入后仍然需要核对结果，尤其是包含特殊字符的认证信息、路径和额外参数。订阅地址本身也可能包含访问凭据，应避免出现在公开截图、记录或可分享的故障描述中。

先用模式确认路径，再用规则决定细分

Global Routing 中的 Config、Proxy、Direct 对应配置、代理、直连三种姿态。Config 按当前启用的配置规则处理请求，Proxy 主要用于让请求按代理路径处理，Direct 用于直连。三者决定的是请求去向，不会改变服务器协议内部的认证方式。排查某条服务器时，可先在明确的代理姿态下验证，再返回 Config 检查分流；测试结束应恢复适合日常用途的模式。

规则通常按顺序匹配，前面的具体条件可能先于后面的广泛条件生效。DOMAIN-SUFFIX 处理域名后缀，IP-CIDR 处理 IPv4 地址范围，FINAL 表示前面没有命中时的最终策略。规则能够决定走 PROXY 或 DIRECT，却不能修复错误的 Password、UUID 或证书。若一个域名直连正常、按 Config 失败，应先确认命中策略，再判断失败发生在代理入口还是目标服务。

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

以上只是用于解释匹配顺序的 .conf 片段，不是一份完整的日常配置。example.com 是教学域名，私网范围仅展示地址规则，GEOIP 的结果依赖所用数据和实际目标地址。应把片段放在正确的 [Rule] 段落理解，不能将其粘贴到 Add Server 的认证字段。更完整的段落关系可查阅配置文件 General、Rule、Host 与 URL Rewrite 说明。

DNS 与 On Demand 不属于协议认证

DNS 决定域名如何解析，规则决定请求如何走，两者可能相互影响，但都不等于服务器的 Type。某个域名返回多个地址时，不同地址的可达性可能不同；仅修改代理协议名称不能解决错误解析。IPv6 也应单独考虑，设备获得 IPv6 地址并不代表现有服务器能转发所有 IPv6 目标。应观察实际地址类型和请求路径，再判断需要调整的是 DNS、路由还是服务器能力。

On Demand 控制符合条件时怎样触发连接，不负责把 VMess 转换成 VLESS，也不代替 Config 中的规则。若开启后在网络变化时出现自动连接，应先检查触发条件；若连接已建立但只有部分目标失败，应回到规则、DNS 和协议字段。将“何时连接”与“连接后怎样分流”分开记录，可以避免为了修复某个网站而反复更改自动连接设置。

手动修改前应保留可恢复的配置，并确认其中没有需要公开传播的敏感资料。应用的 Data 可帮助观察是否发生流量，连接记录若可用则可辅助判断策略和错误阶段，但流量增加不代表请求最终成功。最有效的检查顺序是字段完整、协议匹配、外层可达、认证通过、规则命中、目标响应；每一步得到明确结果后再进入下一步，不要同时改动多层配置。