Shadowsocks 协议。

AEAD 加密算法。支持 aes-128-gcm、aes-256-gcm、chacha20-ietf-poly1305,以及非标准但事实上通行的 aes-192-gcm、xchacha20-ietf-poly1305。

• 在 V2Ray 和 Xray 中,chacha20-poly1305 是 chacha20-ietf-poly1305 的别名。实际上,由于历史原因,这是不同的加密算法而 chacha20-poly1305 不被 V2Ray 支持。

支持一些标准的或非标准但事实上通行的 流加密算法。不支持一次性认证(OTA)。

• 流加密算法被发现主动探测漏洞,开发者试图以 OTA 缓解该问题,但又引入了新的主动探测漏洞。最终流加密算法由于缺乏完整性保护被废弃且被 AEAD 加密算法取代。后来流加密算法更被发现攻击者可以在不知道密码情况下解密通信内容。

Shadowsocks"无加密"加密算法,通常被称为 none、plain 或 dummy。

• 无密码,因此密码实际上可以是任意字符串。数据被明文传输,因此仅适用于局域网或测试用途,否则需要配合具有安全信道的 SIP003 插件使用,或在其他安全信道内使用。

SIP003 插件。

• v2ray-plugin(或称 v2ray)和 simple-obfs(或称 Simple obfuscation,客户端称 obfs-local、服务端称 obfs-server)无需安装独立的插件也可使用。您可以安装并使用适用于 Shadowsocks Android 的插件。simple-obfs 已被废弃并被 v2ray-plugin 取代。simple-obfs 可以与正常的 HTTP/TLS 服务被区分。
• 不支持代理 UDP,插件不会作用于 UDP。
• 与官方实现保持一致的是,如果未指定,v2ray-plugin 使用 cloudfront.com 作为 host(确实如此),其他软件可能无此行为或有不一样的默认值,您可能需要显式设置 host 为服务器地址以连接部分服务器。
• 与官方实现保持一致的是,如果未指定,obfs-local 使用 cloudfront.net 作为 obfs-host(确实如此),其他软件可能无此行为或有不一样的默认值,您可能需要显式设置 host 为服务器地址以连接部分服务器。
• obfs-local 尽管在源码中存在 obfs-uri、http-method 参数,但从未正式发布。几乎没有软件支持这些参数,本软件亦是如此。
• V2Ray 为了缓解 Go 程序未启用 CGO 编译时在 Android 中无法查询 DNS 的问题,为 Android 硬编码 DNS 为 8.8.8.8(即使是启用了 CGO 编译的情况下;本软件已删除此行为)。如果您要使用独立的 v2ray-plugin 而不是内置的 v2ray-plugin,请使用修复了此问题的版本而不要使用 Shadowsocks 官方的版本。
• Shadowsocks Android 在 2026 年 1 月引入了一个重大变化。对于插件发出的流量绕过 VPN 的方法,Shadowsocks Android 删除了插件的 protect 支持,转而使用把 Shadowsocks Android 应用本身绕过 VPN 的方法。但是,system 栈技术上无法把应用本身绕过 VPN。此后新出现的不支持 protect 的插件与更新后移除 protect 支持的插件可能会在本软件的 system 栈下停止工作。

将 IV 的前 6 个字节重新映射为可打印字符。在 2022 年或 2023 年左右,该机制据报告被一些地区的防火墙豁免,但也会造成极其明显的特征。如果不是走投无路的话,不要滥用豁免机制。这不是 Shadowsocks 协议的一部分。

2022-blake3-aes-128-gcm、2022-blake3-aes-256-gcm、2022-blake3-chacha20-poly1305 加密算法。

• 尽管后来被 Shadowsocks 名义上认可为 SIP022 与 SIP023,Shadowsocks 2022 是一个事实上的独立设计的新协议,而不是 Shadowsocks 的升级或修改版本,更不是 Shadowsocks 的新加密算法。
• 如果使用可扩展身份标头(EIH),"密码"格式为 iPSK0:iPSK1:...:iPSKn:uPSK。

Trojan 协议。配合 TLS 使用。

• V2Ray 与 Xray 发明的 Trojan 混合各种其他私有协议(但又未更改原始协议名称)的用法不是 Trojan 的一部分。
• 已知问题:ALPN 未指定或为空数组时会使用 ALPN h2 和 http/1.1,而不是无 ALPN,这与非 V2Ray/Xray 实现的 Trojan 可能不一致。在使用 uTLS 时,uTLS 指纹的 ALPN 会被使用。

单独使用(带加密时),或配合 TLS 和/或"传输层"使用。

alter ID 为 0 时将使用 VMess AEAD 头部认证。不为 0 时将使用旧式 VMess MD5 头部认证。在旧式 VMess MD5 头部认证中,作者声称 alter ID 的作用为"为了进一步防止被探测,一个用户可以在主 ID 的基础上,再额外生成多个 ID"(后来被指出这适得其反)。

• 不兼容 alter ID 为 0 的 VMess MD5 头部认证。不支持已废弃的 aes-128-cfb 加密算法。
• AEAD 头部认证是为了解决 MD5 头部认证的一些被发现的安全问题。VMess 协议的名称与版本号并未对此作出区分,造成了语义上的混乱。

这些"实验性"选项意在解决现有 VMess AEAD 头部认证的一些缺陷,但是自从被发明出来之后从未被真正推进。

• AuthenticatedLength 是一个不兼容现有协议的破坏性变更。

一个 UUID。

• 如果填写 Xray 发明的"UUID v5 映射"字符串,本软件会将其转换为一个 v5 的 UUID。这仅被视为对非标准行为的兼容。sing-box 和 mihomo 也兼容此非标准行为且允许任意长度的字符串输入。

VLESS 协议。配合"TLS 或 REALITY"和/或 VLESS 加密和/或"传输层"使用。

XTLS 与 Vision,声称可以"填充 TLS 握手并避免嵌套加密"。

• flow 为 xtls-rprx-vision 时,目标端口是 UDP 443 端口的流量将被阻断,为 xtls-rprx-vision-udp443 时将不被阻断。sing-box 和 mihomo 里的 xtls-rprx-vision 对应于 Xray 里的 xtls-rprx-vision-udp443。
• Xray 服务端在 flow 启用时拒绝对未启用 XUDP 的客户端提供服务,因此 flow 启用时 XUDP 被强制启用。
• 无加密时,尽管 Xray 的 XTLS(Vision)不可搭配"传输层"使用,但是 sing-box 意外地、mihomo 有意地支持了 XTLS(Vision)与 WS 或 HTTPUpgrade 一起使用。本软件曾经支持这样的组合,但支持已被移除。
• 该"XTLS"与 xtls-rprx-origin/direct/splice 的"XTLS"是两个不同的协议,但名称并未被更改,造成了语义上的混乱。xtls-rprx-origin/direct/splice 的"XTLS"早已被 Xray 移除,本软件亦不支持。

一个 UUID。

• 如果填写 Xray 发明的"UUID v5 映射"字符串,本软件会将其转换为一个 v5 的 UUID。这仅被视为对非标准行为的兼容。sing-box 和 mihomo 也兼容此非标准行为且允许任意长度的字符串输入。
• 新版 Xray 服务端不要求 UUID 的第七字节和第八字节匹配,并将其用作"路由用途"。第三方服务端实现很可能没有这样的行为。

VLESS 加密。如果为 none,不使用加密。如果以 x25519mlkem768plus 开头,将使用 X25519MLKEM768 作为密钥交换机制,流量将使用 AEAD 算法加密。该字段同时包含了外观、RTT、填充、X25519 公钥、MLKEM768 公钥等信息。

Hysteria 2 协议。使用 HTTP/3 进行认证,使用 QUIC stream 代理 TCP、QUIC datagram 代理 UDP。

• 对于上传或下载,如果上传带宽或下载带宽被设置,将使用 Brutal"拥塞控制"以不遵守 QUIC 拥塞控制的方式抢占带宽(除非服务端不允许)。切勿设置上传带宽和下载带宽,以始终使用 New Reno 拥塞控制(quic-go 自带)或 BBR v1 拥塞控制(Hysteria 2 修改版),而不是抢占带宽的 Brutal"拥塞控制"。
• 无论被配置为"保守(conservative)"、"标准(standard)"还是"激进(aggressive)"(这些是 Hysteria 2 而不是 BBR 发明的词汇),BBR v1 在探测出特定的带宽后会完全忽视丢包机制,也会导致严重的公平性问题。这在 BBR v2 和 BBR v3 得到了有效解决,但是 Hysteria 2 使用的 BBR 版本是 BBR v1。
• 如果使用 Hysteria2 官方服务端的"userpass"验证,"密码"格式为用户名:密码。包含冒号的用户名不能正常工作。由于历史原因,Hysteria2 官方旧版本服务端不支持包含 Unicode 大写字母的用户名,而 Hysteria2 官方新版本服务端实际上转换用户名为 Unicode 小写。第三方服务端实现很可能没有这样的行为。
• sing-box 在服务端启用 ignore_client_bandwidth 且设置了下载带宽时,强制客户端必须设置下载带宽以使用 Brutal。您需要自行为客户端设置下载带宽。
• OmitMaxDatagramFrameSize:不在 QUIC Client Hello 中添加 max_datagram_frame_size 参数。Hysteria 2 将自身伪装成 HTTP/3,但是 Hysteria 2 使用 QUIC datagram 代理 UDP,这会在 QUIC Client Hello 中添加一个明文的 max_datagram_frame_size 参数。此参数的存在或其特殊值可能让其与普通 quic-go 的 QUIC Client Hello 有区别。官方 Hysteria 2 实现的新版魔改了 QUIC,使其不发送 max_datagram_frame_size 且仍能使用 QUIC datagram。这是一个破坏性变更且不遵守 QUIC datagram 规范。如果 Hysteria 2 服务端不支持此变更,UDP 将无法使用。
• Chrome parrot:模仿 Chrome 的 QUIC Client Hello。Chrome 总是声明 max_datagram_frame_size,因此 OmitMaxDatagramFrameSize 始终被禁用以匹配 Chrome 的行为。有助于规避针对 QUIC Client Hello 指纹识别的审查,但也会因为鹦鹉学舌而暴露一些额外的特征(鹦鹉已死)。如果 quic-go 指纹未被屏蔽,切勿使用;如果不得不使用,也不要依赖它作为长期解决方案。

拥塞控制和带宽的协商流程:

对于客户端上传(即服务端下载):
- 服务端启用 ignoreClientBandwidth:使用客户端设置的 BBR 或 Reno。
- 服务端未启用 ignoreClientBandwidth:
 - 客户端未设置上传带宽:使用客户端设置的 BBR 或 Reno。
 - 客户端设置了上传带宽,服务端未设置下载带宽:使用 Brutal,以客户端上传带宽为准。
 - 客户端设置了上传带宽,服务端设置了下载带宽:使用 Brutal,取客户端上传带宽和服务端下载带宽的较小值。
对于服务端上传(即客户端下载):
- 服务端启用 ignoreClientBandwidth:使用服务端设置的 BBR 或 Reno。
- 服务端未启用 ignoreClientBandwidth:
 - 客户端未设置下载带宽:使用服务端设置的 BBR 或 Reno。
 - 客户端设置了下载带宽,服务端未设置上传带宽:使用 Brutal,以客户端下载带宽为准。
 - 客户端设置了下载带宽,服务端设置了上传带宽:使用 Brutal,取客户端下载带宽和服务端上传带宽的较小值。

这是 Hysteria 2 和 Brutal 官方实现和大部分第三方实现的协商流程,但不代表一些其他的 Hysteria 2 和/或 Brutal 实现一定遵守此流程。

混淆仅用于改变流量模式,而不是用于安全用途。如果启用混淆,将不兼容原始 Hysteria 2 协议。

• "Salamander":将每个包混淆成随机字节。
• "Gecko":在 Salamander 的基础上,再对 QUIC 握手进行拆分和填充。

定时更换源端口与目的端口,得益于 QUIC 的连接 ID,不会导致数据丢失/连接断开。

• 端口跳跃可能对缓解互联网服务提供商对 UDP 的 QoS 有用,如果您非要如此使用的话。会为审查者创造更多的特征。
• "服务器端口"格式:
  • 多个独立端口:1234,5678,9012
  • 一段端口范围:20000-50000
  • 两者的组合:1234,5000-6000,7044,8000-9000

AnyTLS 协议 v2。一个"试图缓解嵌套的 TLS 握手指纹(TLS in TLS)问题"的代理协议,有"灵活的分包和填充策略"与"降低代理延迟的连接复用"。

• AnyTLS 被设计为配合 TLS 使用。一些网红宣传的配合 REALITY 使用的方式虽然被 sing-box 意外地支持,但不是 AnyTLS 的一部分。
• 已知问题:在 ALPN 未指定或为空数组时会使用 ALPN h2 和 http/1.1,而不是无 ALPN,这与其他实现的 AnyTLS 可能不一致。在使用 uTLS 时,uTLS 指纹的 ALPN 会被使用。

NaïveProxy。一个复用 Chromium 网络栈、通过 HTTP/2 或 HTTP/3 达成多路复用、通过协商启用长度填充的 HTTP/2 CONNECT 隧道或 HTTP/3 CONNECT 隧道。

• 需要安装独立的插件。请到 NaïveProxy 项目下载其发行的适用于 SagerNet 衍生品的 NaïveProxy 插件。
• 附加头格式:

  Key1: value1
  Key2: value2
  

  软件会自动替换 LF(\n)为 CRLF(\r\n)。
• 不支持代理 UDP。

mieru v3。一个流量特征为随机(或自定义)、带多路复用、随机填充与重放保护的代理协议。"mieru"是其客户端的名称;服务端称为"mita"。

• 如果"服务器端口范围"不为空,"服务器端口"将被忽略。端口范围内的一个随机端口将被使用。
• 端口范围格式:

  1037-1137
  1237-1337
  

• 协议"TCP"使用 TCP 传输 TCP 和 UDP。协议"UDP"使用自定义的可靠 UDP 传输协议传输 TCP 和 UDP。
• 流量特征:这个字段很不幸地是 Base64 编码的 protobuf 消息。关于如何生成这个值的指引,请参考 mieru 的文档。

TUIC 协议 v5。使用 QUIC stream 代理 TCP、QUIC stream(UDP 转发模式 quic,但是每个包使用独立的 QUIC stream)或 QUIC datagram(UDP 转发模式 native)代理 UDP。

• 如果未指定,TUIC 原官方实现及其衍生品的客户端与服务端无 ALPN,但是 mihomo 的客户端与服务端使用 ALPN h3。您需要显式设置 ALPN 为 h3 以连接 mihomo 服务端。
• "强烈建议"禁用"0-RTT 握手",因为其易受重放攻击的影响。这不太影响性能。
• 由于有缺陷的鉴权流程,该协议存在多个主动探测问题,在服务端能够被精准地与正常的 QUIC 区分。
• 禁用 SNI:软件内的"SNI"实际上是"ServerName"。如果"禁用 SNI"被启用,将不发送 SNI,但仍然将 ServerName 用于证书校验。不同 TUIC 实现的"禁用 SNI"行为可能不尽相同。

Juicity 协议。使用 QUIC stream 代理 TCP 与 UDP。

• 该协议存在与 TUIC 一致的主动探测问题,在服务端能够被精准地与正常的 QUIC 区分。

SOCKS4 代理(CONNECT)、SOCKS4A 代理(CONNECT)、SOCKS5 代理(CONNECT 和 UDP ASSOCIATE)。

• SOCKS5 仅支持无认证和用户名/密码认证而不支持所谓的 GSSAPI 认证(尽管它名义上是"必须"的)。SOCKS4、SOCKS4A 支持无认证和用户名认证。不支持 BIND。
• SOCKS5 用户名/密码认证的用户名长度和密码长度需为 1-255,但许多用户名/密码认证实现允许空用户名和/或空密码。如果您需要连接使用了用户名/密码认证且用户名和密码均为空值的 SOCKS5 服务端,请使用自定义出站。

HTTP/1.1 CONNECT 隧道、带 TLS 的 HTTP/1.1 CONNECT 隧道。若启用 TLS 且 ALPN 协商出 h2,则使用 HTTP/2 CONNECT 隧道。

• 支持 Basic 认证。不支持代理 UDP。
• 一个典型的 HTTP/2 CONNECT 隧道服务端是带 forwardproxy 插件的 Caddy。
• V2Ray 和 Xray 作为 HTTP CONNECT 隧道服务端时不支持 HTTP/2,但是在协商中却包含 ALPN h2,导致客户端在协商出 ALPN h2 时无法连接。将客户端的 ALPN 设置为 http/1.1 以避免此问题。
• 已知问题:未区分"未启用基本认证"和"启用基本认证但用户名和密码均为空"。如果您需要连接使用了基本认证且用户名和密码均为空的 HTTP 服务端,请使用自定义出站。

HTTP/3 CONNECT 隧道。

• 支持 Basic 认证。不支持代理 UDP。
• 一个典型的 HTTP/3 CONNECT 隧道服务端是带 forwardproxy 插件的 Caddy。
• 已知问题:未区分"未启用基本认证"和"启用基本认证但用户名和密码均为空"。如果您需要连接使用了基本认证且用户名和密码均为空的 HTTP/3 服务端,请使用自定义出站。

TrustTunnel 协议。它实际上是代理协议,而不是其开发者声称的所谓的"VPN 协议"。

• 对于 TCP,它基本上是一个标准的 HTTP/2 CONNECT 隧道或 HTTP/3 CONNECT 隧道。对于 UDP,它使用私有 UDP over TCP 魔法地址协议。
• 本软件未实现其私有 ICMP echo over TCP 魔法地址协议和私有"健康检查 over TCP"魔法地址协议。

SSH-2 动态端口转发。支持密码认证、公钥认证。

• 该协议不支持代理 UDP。那些支持私有 UDP 协议又未更改名称的 SSH 分叉不是 SSH 的一部分。
• 公钥认证类型的私钥为 PEM 格式或 OpenSSH 格式。
• 公钥格式:每行一个。示例:

  ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIOMqqnkVzrm0SdG6UOoqKLsabgH5C9okWi0dh2l9GKJl
  ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCj7ndNxQowgcQnjshcLrqPEiiphnt+VTTvDP6mHBL9j1aNUkY4Ue1gvwnGLVlOhGeYrnZaMgRK6+PKCUXaDbC7qtbW8gIkhL7aGCsOr/C56SJMy/BCZfxd1nWzAOxSDPgVsmerOBYfNqltV9/hWCqBywINIR+5dIg6JTJ72pcEpEjcYgXkE2YEFXV1JHnsKgbLWNlhScqb2UmyRkQyytRLtL+38TGxkxCflmO+5Z8CSSNY7GidjMIZ7Q4zMjA2n1nGrlTDkzwDCsw+wqFPGQA179cnfGWOWRVruj16z6XyvxvjJwbz0wQZ75XK5tKSb7FNyeIEs4TT4jk+S4dhPeAUC5y+bDYirYgM4GC7uEnztnZyaVWQ7B381AK4Qdrwt51ZqExKbQpTUNn+EjqoTwvqNj4kqx5QUCI0ThS/YkOxJCXmPUWZbhjpCg56i+2aB6CmK2JGhn57K5mj0MNdBXA4/WnwH6XoPWJzK5Nyu2zB3nAZp+S5hpQs+p1vN1/wsjk=
  ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBEmKSENjQEezOmxkZMy7opKgwFB9nkt5YRrYMjNuG5N87uRgg6CLrbo5wAdT/y6v0mKV0U2w0WZ2YB/++Tpockg=
  

• 连接保活间隔:keepalive 是 OpenSSH 发明的私有扩展(keepalive@openssh.com),但被广泛采用。不支持此扩展的 SSH 服务端可能会报错。
• 已知问题:未区分"无认证"和"密码为空的密码认证"、未区分"无私钥密码句"和"私钥密码句为空"。如果您需要连接此类 SSH 服务端,请使用自定义出站。

被用作代理(TCP 与 UDP)而不是 VPN 的用户态 WireGuard。

• 该协议是 VPN 协议而不是代理协议,不是被设计用于绕过防火墙,也不是本软件的主要功能。由于需要进行网络层到传输层再到网络层的用户态转换,该协议在本软件中仅仅是将将可用,请不要抱怨其糟糕的性能。
• "本地地址"格式:每行一个。
• "保留字段"格式:0,0,0(或 Base64 编码格式:AAAA)。"保留字段"被用于 Cloudflare WARP(通常是通过滥用方式取得)。
• Xray 支持其他软件不支持的留空本地地址与使用非标准的 WireGuard 密钥对。这些不被本软件支持,您需要自行解决此兼容性问题。

本软件已移除对该协议的支持。

(削除) ShadowTLS v2 及 v3。又一个类 TLS 协议,表现为与合法网站进行 TLS 握手。一些目标网站会认为这是对它们的骚扰。 (削除ここまで)

• (削除) 该协议不支持代理 UDP。 (削除ここまで)
• (削除) 不是一个完整的可独立运行的代理协议,通常用法是与 Shadowsocks 等协议组成链式代理。 (削除ここまで)
• (削除) 该协议在服务端能够被与正常 TLS 区分。 (削除ここまで)
• (削除) ShadowTLS v2 不支持 X25519MLKEM768 TLS key share。 (削除ここまで)

一个类 QUIC 协议,表现为与合法网站进行 QUIC 握手。俗称的"偷证书"在 QUIC 上的变体。

• JLS 被使用以表现为与合法网站进行 QUIC 握手。一些目标网站会认为此行为是 DDoS。
• 没有计划实现 ShadowQUIC 的"双胞胎协议"SunnyQUIC。它是又一个存在与 TUIC 一致的主动探测问题的协议。

Snell 协议 ^{[1] [2]} v4 和 v6。

• 该协议闭源且不公开协议规范,是第三方通过逆向工程重新实现的。因此,如果本软件对该协议的支持有 bug,也不要指望可以及时修复。
• Snell v4 客户端可以连接 Snell v5 服务端,但是没有实现 Snell v5 的 QUIC Proxy Mode。

早年一个加入各种伪装头的 Shadowsocks 分叉。

• 本软件支持的"协议"和"混淆"^{[1] [2]} 与 Clash 支持的一致。仅仅是因为 SagerNet 支持该协议,所以本软件也顺带有对该协议的支持。
• 该协议已过时且毫无抗审查性可言。
• 在 Clash 中,tls1.2_ticket_auth 是 tls1.2_ticket_fastauth 的别名。

TCP 多路复用。实际上是一个 V2Ray 发明的名为 Mux.Cool 的承载其他代理协议的私有协议,而不是 Shadowsocks、Trojan 等的一部分。

• 与其他流行的多路复用协议(如 sing-mux、Smux)没有关系且不兼容。
• Mux.Cool 以 UDP over TCP 的形式作用于 UDP。
• 该协议使用域名 v1.mux.cool 作为魔法地址。mux.cool 是一个真实存在的域名而不是一个保留域名,虽然似乎由 V2Fly 成员控制且未被使用,但并不会总是如此,将来有可能被实际使用而造成问题。
• 雪上加霜的是,该协议被 Xray 分叉并成为了 XUDP 的一部分,并在 XTLS 中被强制启用,然而该魔法地址未被更换。

• 由于协议设计缺陷,VMess、VLESS、Mux.Cool 同一个 UDP 套接字只有第一个包可以携带目标地址,需要一些使用魔法地址的不向前兼容的子协议(即"XUDP"或"Packet")以正确在每一个包携带目标地址。这些子协议不是原始协议的一部分。

  • 其他正确设计的协议(如 Shadowsocks、Trojan、SOCKS 等)没有此协议设计缺陷,不需要"packetEncoding"。

• 由于架构设计缺陷,即使是正确设计的协议在 V2Ray 和 Xray 里也会受上述问题牵连。

  • V2Ray 内部可选地将"packetEncoding"应用于这些协议以"解决"此架构设计缺陷,且会使基于域名或 IP 或端口的路由规则对使用了"packetEncoding"的流量失效。
  • 本软件"解决"此架构设计缺陷使用的是类似 Xray 的方法而不是 V2Ray 的方法,因此"packetEncoding"设置不存在于这些协议。

• XUDP:见于 Xray。

  • 不支持"Global ID"和"UoT Migration"。
  • Xray 在许多方面强制推行 XUDP,因此一些软件即使没有显式设置也会为 VLESS 相关协议使用 XUDP。

• Packet (PacketAddr):见于 V2Ray。

  • 目标地址只支持 IPv4 与 IPv6,无法在不扩展现有子协议的情况下将域名作为目标地址。本软件在 UDP 的目标地址为域名时,不会应用该子协议。

又称为"传输协议"、"传输方式"、"传输层协议"、"底层传输"、"底层传输协议"、"底层传输方式"、"V2Ray 传输层"等(配置项对应的一般是"transport"或"network")。实际上是 V2Ray 与 Xray 发明的一堆满是未记录行为的用于承载其他代理协议的额外的协议,而不是原始协议(如 Trojan 和 Shadowsocks)的一部分,并污染了其他协议的名称和规范。

• 这些"传输层"只有 TCP 转发语义而没有代理语义,因此需要配合其他代理协议使用。代理协议的 UDP(如 Shadowsocks UDP 和 SOCKS5 UDP)不会应用这些"传输层"。
• 并非所有代理协议与"传输层"的排列组合都可以使用。
• 如果不是走投无路的话,不要使用滥用 CDN 的协议。
• 雪上加霜的是,除了"传输层",Xray 还发明了应用于 TCP 和 UDP 且可以无限嵌套的"finalmask"以进一步污染协议的名称和规范。本软件不支持"finalmask"。

"TCP"这个令人迷惑的名称实际上是指不附加额外的"传输层"。在 Xray 中也称"RAW"。

"TCP 传输层"另有"数据包头部伪装"设置,可以附加一些 HTTP 头伪装成 HTTP,但与原始的"TCP 传输层"不兼容。

• host 与 path 的格式:每行一个。在 V2ray 中,如果 host 未指定,将使用 www.baidu.com 和 www.bing.com(确实如此)。如果指定多个 host,将随机选择一个。非 V2Ray/Xray 可能无此行为或可能有不同的默认值。
• 在 Clash/mihomo 被称为"HTTP 传输层",在 sing-box 中是不带 TLS 的"HTTP 传输层"。
• HTTP 混淆与正常的 HTTP(S) 服务可以被简单区分。

又称"mKCP"。实际上是魔改自 KCP 且不兼容 KCP 的私有协议。以暴力发包的方式抢占带宽。

• 如果 seed 未填写,将使用已被证明可被精准识别的 XOR 混淆流量数据,如果 seed 被填写,使用 AES-128-GCM 算法混淆流量数据。seed 不能用于保证通信内容的安全。
• "伪装头类型"基本上是一些毫无抗审查性而言的劣质伪装。
• Xray 制造破坏性变更,将 XOR 混淆和 AES-128-GCM 混淆分离出 KCP,导致出现了既不使用 XOR 混淆也不使用 AES-128-GCM 混淆的 KCP 传输层、使用 AES-128-GCM 混淆但 seed 为空的 KCP 传输层。它们与原 KCP 传输层不兼容,本软件不支持。

又称"WebSocket"。实际上是基于 WebSocket 的私有协议。通常被用于滥用 Cloudflare CDN。

• 该协议另有额外的"前置数据"设置以达到"减少 RTT"的目的。
• 若"前置数据头名称"为空,前置数据将被附加到 path(由 V2Ray 发明,Xray 不支持)。
• 若"前置数据头名称"不为空,前置数据将被用作 header(由 Xray 发明,Xray 的前置数据头名称为 Sec-WebSocket-Protocol;V2Ray 支持自定义前置数据头名称)。
• Xray 把最大前置数据作为 path 的一部分(?ed=[数字])而不是使用一个新的字段。您需要自行删除 path 中的 ?ed=[数字] 部分,并正确填写"最大前置数据"和"前置数据头名称"。
• 若未指定 host 但指定 SNI,Xray 会将 SNI 用作 host,您需要自行解决此兼容性问题。
• Xray 忽略用户设置的 ALPN 而始终使用 http/1.1 作为 ALPN,您需要自行解决此兼容性问题。该协议不支持所谓的"WebSocket over HTTP/2"或"WebSocket over HTTP/3"。
• 浏览器转发:通过 Android System WebView 转发 WebSocket 以达成"使用浏览器 TLS 指纹"的目的。
  • 若是使用自定义配置,您需要自行使用浏览器连接,并把浏览器从分应用 VPN 中排除。
  • 请从 v2ray-core 下载 v2ray-extra.zip 并将 index.html 和 index.js 放置到 Android/data/包名/files,或者将它们导入为路由资源。
  • 本软件仅视该功能为概念验证。该功能不能在 system 栈下正常使用,且使用体验或许会十分糟糕。

又称"H2"。这个令人迷惑的名称实际上是指 HTTP/2。

• host 的格式:每行一个。在 V2Ray 中,如果客户端未指定 host,将使用 www.example.com;如果客户端指定多个 host,将随机选择一个;如果服务端未指定 host,将接受任意客户端 host,否则客户端 host 必须是服务端 host 的其中一个。
• 在 V2Ray 中,路径校验实际上不是精确匹配。客户端实际上可以为路径附加任意后缀,而服务端仍然接受。
• 在 Clash/mihomo 被称为"H2 传输层",在 sing-box 中是带 TLS 的"HTTP 传输层"。
• Xray 曾经存在过使用 HTTP/3 的"HTTP 传输层",后来又被移除。本软件不支持。

实际上是基于 QUIC 的私有协议。

• 如果 ALPN 未指定,将会使用 h2、http/1.1 作为 ALPN(确实如此)。您需要显式设置 ALPN 为 h3 以连接 sing-box 服务端。改动此行为会导致与原版 V2Ray 协商 ALPN 失败。
• 如果 TLS 未启用,将自行签发一个证书并启用 TLS,并以 quic.internal.v2fly.org 作为 SNI,而不是报错退出。其他实现很可能没有这样的怪异行为。
• "QUIC 加密方式"基本上是毫无意义的重复加密。
• "伪装头类型"基本上是一些毫无抗审查性而言的劣质伪装。

又称"GUN",来源于一个同名的通过 gRPC 滥用 CDN 的概念验证。实际上是基于 gRPC 的私有协议。通常被用于滥用 Cloudflare CDN。

• "service name"不建议使用除 A-Z、a-z、0-9、_、. 以外的字符。
• Xray 制造破坏性变更,使用 URL 转义过的 service name,以及使用以"/"开头的 service name 以表示自定义 path。启用"gRPC service name 兼容性"将使此类 service name 与 Xray 兼容并破坏与非 Xray 的兼容性。
• Xray 制造破坏性变更,发明了与原协议不兼容的"multi 模式"。启用"multi 模式"以连接到此类 Xray 服务端。启用"multi 模式"时 service name 总是与 Xray 兼容。
• 其他 Xray 制造的破坏性变更不被支持。

来源于 Tor 的 WebTunnel 可插拔传输(也可能恰好相反),被设计用于使 Cloudflare 误认为其是 WebSocket 以滥用 Cloudflare CDN。

• Xray 使用 ?ed=[数字] 作为 path 的一部分(而不是使用一个新的字段)指示应该使用"0-RTT"。这不被本软件支持,您需要自行删除 path 中的 ?ed=[数字] 部分。
• V2Ray 另外支持设置"前置数据"以达到"减少 RTT"的目的。前置数据将被用作 header。
• 若未指定 Host 但指定 SNI,Xray 会将 SNI 用作 Host,您需要自行解决此兼容性问题。
• Xray 忽略用户设置的 ALPN 而始终使用 http/1.1 作为 ALPN,您需要自行解决此兼容性问题。

来源于 Tor 的 meek 可插拔传输。速度有限,被设计为封装流量为 HTTP/1.1 GET/POST 通信以滥用几乎所有 CDN。

原名"SplitHTTP"。被设计为把上行流量封装为 HTTP POST 请求、下行流量封装为流式 HTTP GET 请求。使用包式上行(packet-up)以滥用几乎所有 CDN,流式上行(stream-up 与 stream-one)以滥用 Cloudflare CDN。

• 使用 HTTP/1.1 或 HTTP/2 或 HTTP/3 是由 ALPN(用户输入的而不是协商的)、是否启用 TLS、是否启用 REALITY 等一系列因素决定。
• stream-up 与 stream-one 会添加 gRPC 标头以使 Cloudflare CDN 误认为其是 gRPC 以方便滥用 Cloudflare CDN。stream-one 是一个"HTTP 传输协议"的不兼容分叉。
• 由于 Xray 经常对该协议作出破坏性变更,若本软件未更新(或您使用本软件的旧版),可能会无法连接新版 Xray 服务端。
• Xray XHTTP 服务端不接受对启用 Mux 的客户端,使用该协议时不要在客户端启用 Mux。
• 为了避免 Xray 服务端对非 Xray 客户端进行差异化对待甚至拒绝提供服务,本软件部分支持用于服务器限制客户端行为的 extra 参数。上下行分离等不影响能否连接上服务器的特性不被本软件支持。(自定义配置可以使用除 sockopt 外的上下行分离,但您不能原封不动地把 Xray 的 extra 照搬过来。)
• 浏览器转发(浏览器拨号):通过 Android System WebView 转发 HTTP 以达成"使用浏览器 TLS 指纹"的目的。
  • 若是使用自定义配置,您需要自行使用浏览器连接,并把浏览器从分应用 VPN 中排除。
  • 大部分 TLS 选项会被忽略(详见 Xray 文档)。
  • 本软件仅视该功能为概念验证。该功能不能在 system 栈下正常使用,且使用体验或许会十分糟糕。

可能是 Meyka 的笔误也可能相反。meek 与 KCP 的混合物。被设计用于滥用几乎所有 CDN 以及以暴力发包的方式抢占带宽。

又称"hy2"。将 Hysteria 2 协议的一部分及其 QUIC 库用作"传输层"。Xray 中称为"Hysteria"。

• 对于上传或下载,如果上传速度或下载速度被设置,将使用 Brutal"拥塞控制"以不遵守 QUIC 拥塞控制的方式抢占带宽(除非服务端不允许)。切勿设置上传速度和下载速度,以始终使用 Reno 拥塞控制(quic-go 自带)或 BBR v1 拥塞控制(Hysteria 2 修改版),而不是抢占带宽的 Brutal"拥塞控制"。
• BBR v1 在探测出特定的带宽后会完全忽视丢包机制,也会导致严重的公平性问题。这在 BBR v2 和 BBR v3 得到了有效解决,但是 Hysteria 2 使用的 BBR 版本是 BBR v1。
• Chrome parrot:模仿 Chrome 的 QUIC Client Hello。有助于规避针对 QUIC Client Hello 指纹识别的审查,但也会因为鹦鹉学舌而暴露一些额外的特征(鹦鹉已死)。如果 quic-go 指纹未被屏蔽,切勿使用;如果不得不使用,也不要依赖它作为长期解决方案。

• SNI:服务器名称指示。若留空,服务器地址将被使用。
  • 该字段实际上是指 Go 标准 TLS 库(或者 uTLS 库)中的 "ServerName",而不是 SNI。如果"ServerName"是域名,将用于证书校验以及用作 SNI;如果"ServerName"是 IP 地址,将用于证书校验,不发送 SNI。
• ALPN:应用层协议协商。格式:每行一个。
  • V2Ray 有着混乱的 ALPN 默认值行为(如果 ALPN 未指定或者是空数组),您可能需要显式设置合适的 ALPN。
• 跳过证书验证:在 V2Ray 中称为"允许不安全(allow insecure)"。启用此项且未部署其他安全措施会导致中间人攻击得逞。切勿启用除非您知道自己在做什么。
• 证书(链):填入 PEM 格式的 fullchain 证书文本。不使用系统根证书列表并只信任给定的证书。
• 固定证书/证书公钥/证书链 SHA256:
  • 如果不与"跳过证书验证"一起使用,除了进行常规的证书验证,还会额外校验证书散列值是否一致。
  • 如果与"跳过证书验证"一起使用,将跳过常规的证书验证,直接校验证书散列值是否一致。
  • 固定证书 SHA-256:较为通用的"证书 SHA-256 指纹"格式(hex 编码),类似于 certificate pinning。该字段的值可通过 openssl x509 -in <cert.pem> -noout -fingerprint -sha256 获取(删掉所有的冒号)。
  • 固定证书公钥 SHA-256:较为通用的"证书公钥 SHA-256 指纹"格式(Base64 编码),类似于 SPKI pinning。该字段的值可通过 openssl x509 -in <cert.pem> -pubkey -noout | openssl dgst -sha256 -binary | openssl enc -base64 获取。
  • 固定证书链 SHA-256:一种由 V2Ray 发明的证书链指纹私有格式(Base64 编码)。该字段的值可通过 v2ray tls certChainHash --cert <cert.pem> 获取。
  • 若证书本身不受信任或无效需要配合"跳过证书验证"使用。在使用固定证书/证书公钥/证书链 SHA-256 时,即使用户没有启用"跳过证书验证",一些代理软件实际上也会为他们禁用(常规的)证书验证 ^{[1] [2] [3]} ,一些用户会误以为不需要禁用常规的证书验证也能使用无效证书。在本软件中,使用固定证书/证书公钥/证书链 SHA-256 且"跳过证书验证"仅意味着跳过常规的证书验证并直接对比散列值,不意味着没有证书校验措施。
  • 固定证书 SHA-256、固定证书公钥 SHA-256 通常指的是固定叶子(leaf)证书,但是一些流行代理软件改变了其语义,允许将其用作固定中间证书或固定根证书。(削除) 本软件不兼容此类行为。 (削除ここまで) 0.17.47-beta.1 起兼容,但如此做法仅仅是为了互操作性,请不要依赖它。
  • 这些选项仅仅是为了兼容其他代理软件。支持这些目的相似的自定义验证逻辑是糟糕的,仅仅是因为它们无法互相转换,服务器不愿进行良好配置,缺少它们将只能以不安全的方式连接服务器。
• mTLS:双向 TLS。填入 PEM 格式的证书文本、PEM 格式的证书私钥文本。一些流行代理软件可以被配置为服务端需要客户端提供证书进行双向校验,但这实际上导致了与原有协议不兼容,破坏了各个实现之间的互操作性。支持 mTLS 仅仅是为了兼容其他代理软件。
• uTLS 指纹:使用 uTLS 库模仿一些流行浏览器的 TLS Client Hello。
  • 有助于规避针对 TLS Client Hello 指纹识别的审查,但也会因为鹦鹉学舌而暴露一些额外的特征(鹦鹉已死)。如果 Go 指纹未被屏蔽,切勿使用;如果不得不使用,也不要依赖它作为长期解决方案。截至 2026 年,uTLS 经常被发现模仿浏览器穿帮的问题。在 2026 年,由于缺乏维护,几乎所有 uTLS 指纹都是过时的浏览器版本。
  • 不可用于基于 QUIC 的协议。
• ECHConfigList:填入 Base64 格式的 ECHConfigList 以启用 Encrypted Client Hello。如果启用 ECH 但 ECHConfigList 未填写,将查询 ECHQueryName 或 SNI(ECHConfigList 为空时)或服务器地址中的域名(ECHConfigList 与 SNI 都为空时)的 DNS HTTPS 记录以获取 ECHConfigList。如果获取 ECHConfigList 失败,连接将被终止。
• ServerNameToVerify:如果填写 ServerNameToVerify,"ServerName"将在适用时用作 SNI,"ServerNameToVerify"将用于证书校验。由于 ServerName 不匹配,常规的证书验证将总是失败,因此总是跳过常规的证书验证转而执行自定义的证书验证。该选项仅仅是为了对应其他软件中类似 name-cert-verify 或 verifyPeerCertByName 的选项。

又一个类 TLS 协议,表现为与合法网站进行 TLS 握手(俗称的"偷证书")。一些目标网站会认为此行为是 DDoS。

• 该协议(大约在 2023 年)出现前已经出现了该协议的同类思路与实际代码(例如 Cloak,大约在 2019 年)。
• 由于 Xray 将其版本号硬编码到协议字段,并且其服务端允许被配置为对一些不符合版本号要求的客户端拒绝提供服务,本软件硬编码了一个 Xray 版本号到协议字段,该硬编码的版本号可能会被一些 Xray 服务端拒绝提供服务。
• 新版 Xray REALITY 服务端已经默认拒绝本软件发送的硬编码 Xray 版本号,导致本软件无法连接。其声称目的是屏蔽有特征缺陷的客户端,但使用版本号来判断客户端是否有特征缺陷是荒谬的,且本软件的 REALITY 客户端实现不存在其声称的所谓的"特征缺陷",除非用户主动启用"禁用 REALITY X25519MLKEM768"。修改硬编码的版本号并不能解决本软件的所有历史版本被恶意屏蔽的问题,也不能避免本软件将来再次被恶意屏蔽。因此,作为客户端用户,您应该要求此问题的始作俑者 Xray 解决问题,而不是要求本软件为了迁就这一问题而作出妥协;作为服务端用户,您应该抵制 Xray,换用其他服务端实现。Xray 声称的特征缺陷实际上是第三方软件在被迫变通解决 Xray 由于 REALITY 设计局限性所制造的 X25519MLKEM768 破坏性变更所导致的不兼容问题,然而 Xray 却反过来指责第三方软件。
• 该协议依赖于特定的 TLS key share,已经进行并且将来也会不得不持续进行破坏性变更以适应新的 TLS key share。启用"禁用 REALITY X25519MLKEM768"如果目标网站支持 X25519MLKEM768 且您在使用支持 X25519MLKEM768 的 uTLS 指纹且服务端不支持 REALITY X25519MLKEM768 破坏性变更。
• Short ID:通常被用于服务端对不同的客户端进行差异化对待甚至拒绝服务。
• uTLS 指纹:使用 uTLS 库模仿一些流行浏览器的 TLS Client Hello。Xray 强制该协议使用 uTLS。
• Xray 有意不允许 REALITY 与 WS 或 HTTPUpgrade 一起使用,但 sing-box 无此限制。本软件曾经支持这样的组合,但支持已被移除。

排列顺序:前置代理(入口节点)在最上方,落地代理(出口节点)在最下方。不兼容负载均衡。

• 带 SIP003 插件的 Shadowsocks 仅可作为前置代理。
• 启用 WebSocket 浏览器转发或 XHTTP 浏览器转发的配置仅可作为前置代理。

策略:随机、leastPing、leastLoad。不兼容链式代理。

负载均衡不是本软件的主要功能,仅仅是能用,很可能没有良好的使用体验。该功能仅仅是自 SagerNet 就存在并被保留至今,不会被投入精力去支持与完善。

本软件导出的配置可供参考。你可能需要为此阅读源码。欢迎贡献文档。自定义配置没有兼容性保证。

一个完整的 Exclave-core 配置。

• 部分参数会被强制修改以符合在 Android 上的运行要求。

0.17.30 及之前:参考SagerNet 文档 * Custom config (V2Ray)。

自从 0.17.31:

• 可以没有 inbound。来自 TUN 的流量不经过 inbound。

• inbound tag "socks"、 "tun"、"dns-in"被保留,请勿在 inbound 中使用。

• 配置需要存在一个 DNS 出站,且需要将来自 TUN 的 DNS 流量(具有 tag"dns-in")路由到此 DNS 出站。

示例配置:

{
 "dns": {
 "servers": [
 {
 "address": "localhost"
 }
 ]
 },
 "log": {
 "loglevel": "debug"
 },
 "outbounds": [
 {
 "protocol": "freedom"
 },
 {
 "protocol": "dns",
 "tag": "dns-out"
 }
 ],
 "routing": {
 "domainStrategy": "AsIs",
 "rules": [
 {
 "inboundTag": [
 "dns-in"
 ],
 "outboundTag": "dns-out",
 "type": "field"
 }
 ]
 }
}

Exclave-core 配置的单个 OutboundObject。

• 不支持的字段不会生效。软件里的全局设置将被应用。

这些协议确实存在于本软件但并未默认向用户显示,且随时可能会被改动或删除(错误报告仍然接受)。如果您确实要使用,您需要通过实验性标志启用它们。