mirrors/Exclave
0
0
Fork 0
mirror of https://github.com/dyhkwong/Exclave.git synced 2026-04-19 05:33:43 +00:00
Code Wiki Activity
Page: 配置
Pages
Configuration Group Home Route Settings _Experiments _实验 分组 设置 路由 配置
配置
dyhkwong edited this page 2026-04-16 20:27:27 +08:00
Unescape Escape
Table of Contents
This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

配置

Shadowsocks

Shadowsocks 协议。

AEAD 加密算法

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

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

流加密算法

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

“无加密”加密算法

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-plugin 的 mode=grpc、serviceName 不存在于官方实现，但确实存在于一个流行的作者为 teddysun 的 v2ray-plugin 分叉。
  • V2Ray 为了缓解 Go 程序未启用 CGO 编译时在 Android 中无法查询 DNS 的问题，为 Android 硬编码 DNS 为 8.8.8.8（即使是启用了 CGO 编译的情况下；本软件已删除此行为）。使用 teddysun 的 v2ray-plugin 分叉可能会受此硬编码 DNS 影响。Shadowsocks v2ray-plugin 因为过久未更新未受此问题影响。
  • Shadowsocks Android 在 2026 年 1 月引入了一个重大变化。对于插件发出的流量绕过 VPN 的方法，Shadowsocks Android 删除了插件的 protect 支持，转而使用把 Shadowsocks Android 应用本身绕过 VPN 的方法。但是，system 栈技术上无法把应用本身绕过 VPN。此后新出现的不支持 protect 的插件与更新后移除 protect 支持的插件可能会在本软件的 system 栈下停止工作。

ReducedIvHeadEntropy

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

Shadowsocks 2022

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

Trojan 协议。配合 TLS 使用。

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

VMess

单独使用（带加密时），或配合 TLS 和/或“传输层”使用。

Alter ID

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 协议的名称与版本号并未对此作出区分，造成了语义上的混乱。

AuthenticatedLength/NoTerminatedSignal

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

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

用户 ID

一个 v4 UUID。

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

VLESS

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

Flow（流控）

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 移除，本软件亦不支持。

用户 ID

一个 v4 UUID。

  • 如果填写 Xray 发明的“UUID v5 映射”字符串，本软件会将其转换为 v5 UUID。这仅被视为对非标准行为的兼容。sing-box 和 mihomo 也兼容此非标准行为且允许任意长度的字符串输入。
  • 新版 Xray 服务端不要求 UUID 的第七字节和第八字节匹配，并将其用作“路由用途”，修改 UUID 的第七字节和第八字节可能会遭遇区别对待。

加密

VLESS 加密。如果为 none，不使用加密。如果以 x25519mlkem768plus 开头，使用后量子 X25519MLKEM768 进行密钥协商，流量会被使用 AEAD 算法加密。该字段同时包含了外观、RTT、填充、X25519 公钥、MLKEM768 公钥等信息。

Hysteria 2

Hysteria 2 协议。更像是一个基于 QUIC 的网络加速工具而不是代理协议。使用 HTTP/3 进行认证，使用 QUIC Stream 转发 TCP、QUIC Datagram 转发 UDP。

  • 对于上传或下载，如果上传速度或下载速度被设置，将使用 Brutal“拥塞控制”以不遵守 QUIC 拥塞控制的方式抢占带宽（除非服务端不允许）。切勿设置上传速度和下载速度，以始终使用 New Reno 拥塞控制（quic-go 自带）或 BBR v1 拥塞控制（Hysteria 2 修改版），而不是抢占带宽的 Brutal“拥塞控制”。
  • 无论被配置为“保守（conservative）”、“标准（standard）”还是“激进（conservative）”（这些是 Hysteria 2 而不是 BBR 发明的词汇），BBR v1 在探测出特定的带宽后会完全忽视丢包机制，也会导致严重的公平性问题。这在 BBR v2 和 BBR v3 得到了有效解决，但是 Hysteria 2 使用的 BBR 版本是 BBR v1。
  • 如果使用 Hysteria2 官方服务端的“userpass”验证，“密码”格式为用户名:密码。包含冒号的用户名不能正常工作。由于历史原因，Hysteria2 官方旧版本服务端不支持包含 Unicode 大写字母的用户名，而 Hysteria2 官方新版本服务端实际上转换用户名为 Unicode 小写，但其他 Hysteria2 实现可能无此行为。
  • sing-box 在服务端启用 ignore_client_bandwidth 且上传速度和下载速度被设置时只允许使用 Brutal“拥塞控制”的客户端连接，不允许使用其他拥塞控制的客户端连接。您需要自行设置上传速度和下载速度。
  • 对于上传或下载，如果上传速度或下载速度被设置，设置拥塞控制为 reno 或 bbr 不代表 New Reno 或 BBR 会被使用。如果服务端允许，Brutal 将始终被使用；New Reno 或 BBR 只会在服务端不允许 Brutal 时被使用。

Salamander 混淆

若“混淆密码”被填写，将启用 Salamander 混淆，混淆成“没有特征的 UDP 包”。不兼容原始 Hysteria 2 协议。

端口跳跃

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

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

AnyTLS

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

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

NaïveProxy

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

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

  • 如果“服务器端口范围”不为空，“服务器端口”将被忽略。端口范围内的一个随机端口将被使用。
  • 端口范围格式： 
    1037-1137
1237-1337
  • 协议“TCP”使用 TCP 传输 TCP 和 UDP。协议“UDP”使用自定义的可靠 UDP 传输协议传输 TCP 和 UDP。
  • 流量特征：这个字段很不幸地是 Base64 编码的 protobuf 消息。关于如何生成这个值的指引，请参考 mieru 的文档。

TUIC

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

Juicity 协议。使用 QUIC Stream 转发 TCP 与 UDP。

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

SOCKS

SOCKS4 代理（CONNECT）、SOCKS4A 代理（CONNECT）、SOCKS5 代理（CONNECT 和 UDP ASSOCIATE）。

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

HTTP

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

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

HTTP/3

HTTP/3 CONNECT 隧道。

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

TrustTunnel

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

  • 对于 TCP，它基本上是一个标准的 HTTP/2 CONNECT 隧道或 HTTP/3 CONNECT 隧道。对于 UDP，它使用私有 UDP over TCP 魔法地址协议。
  • 本软件未实现其私有 ICMP echo over TCP 魔法地址协议和私有“健康检查 over TCP”魔法地址协议。
  • ServerNameToVerify：软件内的“SNI”实际上是指“ServerName”。如果“ServerNameToVerify”不为空，“ServerName”将在适用时用作 SNI；“ServerNameToVerify”将用于证书校验。这个选项是为了匹配 TrustTunnel 的 custom_sni。如果 custom_sni 不为空，custom_sni对应于“ServerName”，hostname 对应于“ServerNameToVerify”；否则 hostname 对应于“ServerName”。

SSH

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=
  • 已知问题：未区分“无认证”和“密码为空的密码认证”、未区分“无私钥密码句”和“私钥密码句为空”。如果您需要连接此类 SSH 服务端，请使用自定义出站。

WireGuard

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

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

ShadowTLS

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

  • 该协议不支持代理 UDP。
  • 不是一个完整的可独立运行的代理协议，通常用法是与 Shadowsocks 等协议组成链式代理。
  • 该协议在服务端能够被与正常 TLS 区分。
  • ShadowTLS v2 不支持 X25519MLKEM768 TLS 密钥协商。

ShadowsocksR

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

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

Mux

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

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

PacketEncoding

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

    • 其他正确设计的协议（如 Shadowsocks、Trojan、SOCKS 等）没有此协议设计缺陷，不需要“packetEncoding”。

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

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

  • XUDP：见于 Xray。

  • Packet (PacketAddr)：见于 V2Ray。

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

传输层（Transport）

又称为“传输协议”、“传输方式”、“传输层协议”、“底层传输”、“底层传输协议”、“底层传输方式”、“V2Ray 传输层“等（配置项对应的一般是“transport”或“network”）。实际上是 V2Ray 与 Xray 发明的一堆承载其他代理协议的额外的私有协议，而不是原始协议（如 Trojan 和 Shadowsocks）的一部分，并污染了其他协议的名称和规范。

  • 这些“传输层”只支持代理 TCP。UDP 不会应用这些“传输层”。
  • 并非所有协议与“传输层”的排列组合都可以使用。
  • 如果不是走投无路的话，不要使用滥用 CDN 的协议。
  • 雪上加霜的是，除了“传输层”，Xray 还发明了应用于 TCP 和 UDP 且可以无限嵌套的“finalmask”以进一步污染协议的名称和规范。本软件不支持“finalmask”。

TCP（无传输层）

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

HTTP 混淆

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

  • Host 与 path 的格式：每行一个。
  • 如果 Host 未指定，将使用 www.baidu.com 和 www.bing.com（确实如此），非 V2Ray/Xray 可能无此行为，您可能需要显式设置 Host 为服务器地址以连接部分服务器。
  • 在 Clash/mihomo 被称为“HTTP 传输层”，在 sing-box 中是不带 TLS 的“HTTP 传输层”。
  • HTTP 混淆与正常的 HTTP(S) 服务可以被简单区分。

KCP

又称“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 传输层不兼容，本软件不支持。

WS

又称“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，或者将它们导入为路由资源。

HTTP

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

  • host 的格式：每行一个。如果未指定，将使用 www.example.com。
  • 在 Clash/mihomo 被称为“H2 传输层”，在 sing-box 中是带 TLS 的“HTTP 传输层”。
  • Xray 曾经存在过使用 HTTP/3 的“HTTP 传输层”，后来又被移除。本软件不支持。

QUIC

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

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

GRPC

又称“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 制造的破坏性变更不被支持。

HTTPUpgrade

来源于 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，您需要自行解决此兼容性问题。

Meek

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

XHTTP

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

  • 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 文档）。

Mekya

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

Hysteria2

又称“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。

TLS

  • 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 编码）。该字段的值可通过 openssl x509 -in fullchain.cer -noout -fingerprint -sha256 获取（删掉所有的冒号）。
    • 固定证书公钥 SHA-256：较为通用的“证书公钥 SHA-256 指纹”格式（Base64 编码）。该字段的值可通过 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 时，即使用户没有禁用证书验证，一些代理软件实际上也会为他们禁用证书验证，一些用户会误以为不需要禁用证书验证也能使用无效证书。
    • 固定证书 SHA-256、固定证书公钥 SHA-256 通常指的是固定叶子（leaf）证书，但是一些流行代理软件改变了其语义，允许将其用作固定中间证书或固定根证书。本软件不兼容此类行为。
    • 支持这些目的相似的自定义验证逻辑是糟糕的，仅仅是因为它们无法互相转换，服务器不愿进行良好配置，缺少它们将只能以不安全的方式连接服务器。
  • mTLS：双向 TLS。填入 PEM 格式的证书文本、PEM 格式的证书私钥文本。一些流行代理软件可以被配置为服务端需要客户端提供证书进行双向校验，但这实际上导致了与原有协议不兼容，破坏了各个实现之间的互操作性。
  • uTLS 指纹：使用 uTLS 库模仿一些流行浏览器的 TLS Client Hello。
    • 有助于规避针对 TLS Client Hello 指纹识别的审查，但也会因为鹦鹉学舌而暴露一些额外的特征（鹦鹉已死）。如果 Go 指纹未被屏蔽，切勿使用；如果不得不使用，也不要依赖它作为长期解决方案。
    • 不可用于基于 QUIC 的协议。
  • ECH 配置：填入 Base64 格式的 ECH 配置以启用 Encrypted Client Hello。如果启用 ECH 但 ECH 配置未填写，将使用直连 DNS 查询 HTTPS 记录以获取 ECH 配置。如果获取 ECH 配置失败，连接将被终止。

REALITY

又一个类 TLS 协议，表现为与合法网站进行 TLS 握手。一些目标网站会认为这是对它们的骚扰。

  • 该协议（大约在 2023 年）出现前已经出现了该协议的同类思路与实际代码（例如 Cloak，大约在 2019 年）。
  • 由于 Xray 将其版本号硬编码到协议字段，并且其服务端允许被配置为对一些不符合版本号要求的客户端拒绝提供服务，本软件硬编码了一个 Xray 版本号到协议字段，该硬编码的版本号可能会被一些 Xray 服务端拒绝提供服务。
  • 该协议依赖于特定的 TLS 密钥协商，已经进行并且将来也会不得不持续进行破坏性变更以适应新的 TLS 密钥协商。启用“禁用 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。不兼容链式代理。

自定义配置

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

自定义完整配置

本软件的修改版 V2Ray 的 JSONv4 完整配置。不支持半成品的 V2Ray JSONv5 配置。

  • 部分参数会被强制修改以符合在 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"
      }
    ]
  }
}

自定义出站配置

本软件的修改版 V2Ray 的 JSONv4 OutboundObject。

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

存在但不受支持的协议

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

sing-uot (v2)

这是 sing-box 发明的使用魔法地址的 UDP over TCP（或称 UoT）私有协议，而不是原始协议（Shadowsocks、Shadowsocks 2022、TUIC、SOCKS5、SOCKS4A、NaïveProxy）的一部分。

UDP over stream：这是 sing-box 的私有 UDP over TCP 协议 v2 在 QUIC 上的变体，使用 QUIC Stream 转发 UDP。

sing-mux

这是来自 sing-box 的使用魔法地址的多路复用私有协议，而不是原始协议（Shadowsocks、Shadowsocks 2022、Trojan、VMess、VLESS）的一部分。

sing-mux 以 UDP over TCP 的形式作用于 UDP，因此与 sing-uot 冲突。如果非要同时开启，则 TCP 使用 sing-mux，UDP 使用 sing-uot。

  • h2mux：使用 Go HTTP/2 库的多路复用机制。
  • smux：使用 Smux。
  • yamux：使用 Yamux。
  • 填充（padding）：填充 TLS 握手以缓解所谓的“TLS in TLS”问题。您只应对基于 TLS（或 REALITY）的协议启用“填充”。该“填充”很大程度上受 NaïveProxy 填充机制的启发。
  • Brutal：Hysteria 的抢占带宽的 Brutal“拥塞控制”在 TCP 上的移植。本软件有意不支持。

ShadowQUIC

一个类 QUIC 协议。

JLS 被使用以表现为与合法网站进行 QUIC 握手。一些目标网站会认为这是对它们的骚扰。

需要安装独立的插件。

SunnyQUIC

这是 ShadowQUIC 的“双胞胎协议”，不使用 JLS 进行认证而是在 QUIC 层提供一个认证机制。

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

Home

主页

Exclave wiki by dyhkwong is marked CC0 1.0 Universal. To view a copy of this mark, visit https://creativecommons.org/publicdomain/zero/1.0/.