深度剖析原理

fallback 为 Xray 提供了高强度的防主动探测性, 并且具有独创的首包回落机制.

#原理

Fallback 回落

Fallback 是 Xray 的最强大功能之一, 可有效防止主动探测, 自由配置常用端口多服务共享

fallback 为 Xray 提供了高强度的防主动探测性, 并且具有独创的首包回落机制.

fallback 也可以将不同类型的流量根据 path 进行分流, 从而实现一个端口, 多种服务共享.

目前您可以在使用 VLESS 或者 trojan 协议时, 通过配置 fallbacks 来使用回落这一特性, 并且创造出非常丰富的组合玩法.

fallbacks 配置

json
  "fallbacks": [
    {
      "dest": 80
    }
  ]

fallbacks: [ FallbackObject ]

一个数组，包含一系列强大的回落分流配置。

FallbackObject

json
{
  "name": "",
  "alpn": "",
  "path": "",
  "dest": 80,
  "xver": 0
}

fallbacks 是一个数组，这里是其中一个子元素的配置说明。

fallbacks 项是可选的，只能用于 TCP+TLS 传输组合

  • 该项有子元素时，Inbound TLS 需设置 "alpn":["http/1.1"]。**

通常，你需要先设置一组 alpn 和 path 均省略或为空的默认回落，然后再按需配置其它分流。

VLESS 会把 TLS 解密后首包长度 < 18 或协议版本无效、身份认证失败的流量转发到 dest 指定的地址。

其它传输组合必须删掉 fallbacks 项或所有子元素，此时也不会开启 Fallback，VLESS 会等待读够所需长度，协议版本无效或身份认证失败时，将直接断开连接。

name: string

尝试匹配 TLS SNI(Server Name Indication)，空为任意，默认为 ""

alpn: string

尝试匹配 TLS ALPN 协商结果，空为任意，默认为 ""

有需要时，VLESS 才会尝试读取 TLS ALPN 协商结果，若成功，输出 info realAlpn = 到日志。 用途：解决了 Nginx 的 h2c 服务不能同时兼容 http/1.1 的问题，Nginx 需要写两行 listen，分别用于 1.1 和 h2c。 注意：fallbacks alpn 存在 "h2" 时，Inbound TLS 需设置 "alpn":["h2","http/1.1"]，以支持 h2 访问。

提示

Fallback 内设置的 alpn 是匹配实际协商出的 ALPN，而 Inbound TLS 设置的 alpn 是握手时可选的 ALPN 列表，两者含义不同。

path: string

尝试匹配首包 HTTP PATH，空为任意，默认为空，非空则必须以 / 开头，不支持 h2c。

智能：有需要时，VLESS 才会尝试看一眼 PATH（不超过 55 个字节；最快算法，并不完整解析 HTTP），若成功，输出 INFO 日志 realPath =。 用途：分流其它 inbound 的 WebSocket 流量或 HTTP 伪装流量，没有多余处理、纯粹转发流量，理论性能比 Nginx 更强。

注意：fallbacks 所在入站本身必须是 TCP+TLS，这是分流至其它 WS 入站用的，被分流的入站则无需配置 TLS。

dest: string | number

决定 TLS 解密后 TCP 流量的去向，目前支持两类地址：（该项必填，否则无法启动）

  1. TCP，格式为 "addr:port"，其中 addr 支持 IPv4、域名、IPv6，若填写域名，也将直接发起 TCP 连接（而不走内置的 DNS）。
  2. Unix domain socket，格式为绝对路径，形如 "/dev/shm/domain.socket"，可在开头加 @ 代表 abstractopen in new tag，@@ 则代表带 padding 的 abstract。

若只填 port，数字或字符串均可，形如 80、"80"，通常指向一个明文 http 服务（addr 会被补为 "127.0.0.1"）。

xver: number

发送 PROXY protocolopen in new tag，专用于传递请求的真实来源 IP 和端口，填版本 1 或 2，默认为 0，即不发送。若有需要建议填 1。

目前填 1 或 2，功能完全相同，只是结构不同，且前者可打印，后者为二进制。Xray 的 TCP 和 WS 入站均已支持接收 PROXY protocol。

注意

若你正在 配置 Nginx 接收 PROXY protocolopen in new tag，除了设置 proxy_protocol 外，还需设置 set_real_ip_from，否则可能会出问题。

补充说明

  • 将匹配到最精确的子元素，与子元素的排列顺序无关。若配置了几个 alpn 和 path 均相同的子元素，则会以最后的为准。
  • 回落分流均是解密后 TCP 层的转发，而不是 HTTP 层，只在必要时检查首包 PATH。
  • 您可以查看更多的关于 Fallbacks 的使用技巧和心得

Browser Dialer

背景

通过 uTLS，Xray 可以模拟主流浏览器的 TLS 握手指纹（具体参见 TLS 中 fingerprint 选项）。但是仍然不能保证在任意时刻 uTLS 模拟浏览器行为完全一致。

对此 浏览器转发（browser dialer）open in new tag应运而生。用户在自己的浏览器中打开一个页面至 localhost:8080，这个页面利用原生 JS 充当 Xray 的网络栈，与代理服务端建立 TLS，HTTP 连接。

这个方法简洁的实现了真实的浏览器的 TLS 指纹、行为特征。最大程度抗检测与抗封锁。

不过目前的浏览器转发有以下缺点：

  • 用户需要手动开浏览器
  • 浏览器发出的连接必须直连 使用 tun 的用户需要特别注意容易形成死循环
  • 浏览器只能发出 HTTP 连接 所以目前仅支持 WebSocket 与 XHTTPopen in new tag 传输方式
  • 当浏览器从 localhost:8080 页面连接至代理服务端，需要考虑 CORSopen in new tag
  • 因为中间经过 JS 处理数据，会有一些性能损耗
  • 不能使用自定义 SNI 或者 Host，也就是说 SNI == host == address。自定义 HTTP 头以及其它 tlsSettings 项会被忽略

配置方法

  1. 准备一份 WebSocket 或 XHTTP 配置，注意 address 必须填域名，若需要指定 IP，请配置 DNS 或系统 hosts
  2. 使用环境变量启动 Xray XRAY_BROWSER_DIALER=127.0.0.1:8080。Windows 上命令为 set XRAY_BROWSER_DIALER=127.0.0.1:8080 Linux 上命令为 XRAY_BROWSER_DIALER=127.0.0.1:8080 ./xray -c config.json
  3. 确保浏览器直连（或者在路由中将服务端地址直接由 freedom 发出），打开页面 localhost:8080，还可以 F12 看 Console 和 Network
  4. 浏览器会限制发出的连接数，所以建议开启 Mux.Cool

内部通信机制

  • Xray 监听地址端口 http://127.0.0.1:8080，作为 HTTP 服务，浏览器访问地址，加载网页中的 JS。
  • JS 主动向 http://127.0.0.1:8080 建立 WebSocket 连接，成功后，Xray 将连接发给 channel。
  • 需要建立连接时，Xray 从 channel 接收一个可用的连接，并发送目标 URL 和可选的 early data。
  • JS 成功连接到目标后告知 Xray，并继续用这个 conn 全双工双向转发数据，连接关闭行为同步。
  • 连接使用后就会被关闭，但 JS 会确保始终有新空闲连接可用。

WebSocket

v1.4.1+

根据浏览器的需求，对 early data 机制进行了如下调整：

  • 服务端响应头会带有请求的 Sec-WebSocket-Protocol，这也初步混淆了 WSS 握手响应的长度特征。
  • 用于浏览器的 early data 编码是 base64.RawURLEncoding 而不是 StdEncoding，服务端做了兼容。
  • 此外，由于 Xray-core#375open in new tag 推荐 ?ed=2048，这个 PR 顺便将服务端一处 MaxHeaderBytes 扩至了 4096。 （虽然好像不改也没问题）

XHTTP

v1.8.19+

XHTTPopen in new tag 本身支持 QUIC，如果想使用浏览器自己的 QUIC 网络栈，Chrome 可以在 chrome://flags 中设定。其它浏览器也有相关选项。

原理上说 tlsSettings 项会被忽略，使用哪个 HTTP 版本将完全由浏览器决定。

传输方式（uTLS、REALITY）

传输方式（transport）是当前 Xray 节点和其它节点对接的方式。

传输方式指定了稳定的数据传输的方式。通常来说，一个网络连接的两端需要有对称的传输方式。比如一端用了 WebSocket，那么另一个端也必须使用 WebSocket，否则无法建立连接。

StreamSettingsObject

StreamSettingsObject 对应入站或出站中的 streamSettings 项。每一个入站或出站都可以分别配置不同的传输配置，都可以设置 streamSettings 来进行一些传输的配置。

json
{
  "network": "raw",
  "security": "none",
  "tlsSettings": {},
  "realitySettings": {},
  "rawSettings": {},
  "xhttpSettings": {},
  "kcpSettings": {},
  "grpcSettings": {},
  "wsSettings": {},
  "httpupgradeSettings": {},
  "sockopt": {
    "mark": 0,
    "tcpMaxSeg": 1440,
    "tcpFastOpen": false,
    "tproxy": "off",
    "domainStrategy": "AsIs",
    "dialerProxy": "",
    "acceptProxyProtocol": false,
    "tcpKeepAliveInterval": 0,
    "tcpKeepAliveIdle": 300,
    "tcpUserTimeout": 10000,
    "tcpCongestion": "bbr",
    "interface": "wg0",
    "v6only": false,
    "tcpWindowClamp": 600,
    "tcpMptcp": false,
    "tcpNoDelay": false
  }
}

network: “raw” | “xhttp” | “kcp” | “grpc” | “ws” | “httpupgrade”

连接的数据流所使用的传输方式类型，默认值为 "raw"。

提示

v24.9.30 版本后，为了更贴近实际行为，TCP 传输方式已更名为 RAW。为了兼容性，"network": "raw" 和 "network": "tcp"，rawSettings 和 tcpSettings 互为别名。

security: “none” | “tls” | “reality”

是否启用传输层加密，支持的选项有

  • "none" 表示不加密（默认值）
  • "tls" 表示使用 TLSopen in new tag。
  • "reality" 表示使用 REALITY。

tlsSettings: TLSObject

TLS 配置。TLS 由 Golang 提供，通常情况下 TLS 协商的结果为使用 TLS 1.3，不支持 DTLS。

realitySettings: RealityObject

Reality 配置。Reality 是 Xray 的原创黑科技。 Reality 比 TLS 的安全性更高, 配置方式也和 TLS 一致.

提示

Reality 是目前最安全的传输加密方案, 且外部看来流量类型和正常上网具有一致性。 启用 Reality 并且配置合适的 XTLS Vision 流控模式, 可以 达到数倍甚至十几倍的性能提升。

rawSettings: RawObject

当前连接的 RAW 配置，仅当此连接使用 RAW 时有效。

xhttpSettings: XHTTP: Beyond REALITYopen in new tag

当前连接的 XHTTP 配置，仅当此连接使用 XHTTP 时有效。

kcpSettings: KcpObject

当前连接的 mKCP 配置，仅当此连接使用 mKCP 时有效。

grpcSettings: GRPCObject

当前连接的 gRPC 配置，仅当此连接使用 gRPC 时有效。

wsSettings: WebSocketObject

当前连接的 WebSocket 配置，仅当此连接使用 WebSocket 时有效。

httpupgradeSettings: HttpUpgradeObject

当前连接的 HTTPUpgrade 配置，仅当此连接使用 HTTPUpgrade 时有效。

sockopt: SockoptObject

透明代理相关的具体配置。

评论

评论加载中……