From b6e1d6c2c1eaeb9751c84df4ea632aef933150bc Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E9=A3=8E=E6=89=87=E6=BB=91=E7=BF=94=E7=BF=BC?= Date: Sat, 27 Jul 2024 15:04:42 +0000 Subject: [PATCH] Update VLESS flow description --- docs/config/inbounds/vless.md | 2 +- docs/config/outbounds/vless.md | 7 +++---- 2 files changed, 4 insertions(+), 5 deletions(-) diff --git a/docs/config/inbounds/vless.md b/docs/config/inbounds/vless.md index 721caba17..77f4697af 100644 --- a/docs/config/inbounds/vless.md +++ b/docs/config/inbounds/vless.md @@ -92,4 +92,4 @@ level 的值, 对应 [policy](../policy.md#policyobject) 中 `level` 的值。 - 无 `flow` 或者 空字符： 使用普通 TLS 代理 - `xtls-rprx-vision`：使用新 XTLS 模式 包含内层握手随机填充 -此外，目前 XTLS 仅支持 TCP、mKCP、DomainSocket 这三种传输方式。 +此外，目前 XTLS 仅支持 TCP+TLS/Reality diff --git a/docs/config/outbounds/vless.md b/docs/config/outbounds/vless.md index e8cbeea53..3c256c3bc 100644 --- a/docs/config/outbounds/vless.md +++ b/docs/config/outbounds/vless.md @@ -101,14 +101,14 @@ VLESS 的用户 ID，可以是任意小于 30 字节的字符串, 也可以是 - 无 `flow` 或者 空字符： 使用普通 TLS 代理 - `xtls-rprx-vision`：使用新 XTLS 模式 包含内层握手随机填充 支持 uTLS 模拟客户端指纹 -- `xtls-rprx-vision-udp443`：同 `xtls-rprx-vision`, 但是放行了目标为 443 端口的 UDP 流量 +- `xtls-rprx-vision-udp443`：同 `xtls-rprx-vision`, 但是不会拦截目标为 443 端口的 UDP 流量 -此外，目前 XTLS 仅支持 TCP、mKCP、DomainSocket 这三种传输方式。 +此外，目前 XTLS 仅支持 TCP+TLS/Reality。 ::: tip 关于 xtls-rprx-*-udp443 流控模式 -启用了 Xray-core 的 XTLS 时，通往 UDP 443 端口的流量默认会被拦截（一般情况下为 QUIC），这样应用就不会使用 QUIC 而会使用 TLS，XTLS 才会真正生效。实际上，QUIC 本身也不适合被代理，因为 QUIC 自带了 TCP 的功能，它作为 UDP 流量在通过 VLESS 协议传输时，底层协议为 TCP，就相当于两层 TCP 了。 +启用了 Xray-core 的 XTLS 时，通往 UDP 443 端口的流量默认会被拦截（一般情况下为 QUIC），这样应用就不会使用 QUIC 而会使用 TLS，XTLS 才会真正生效。实际上，QUIC 本身也不适合被代理，因为 QUIC 自带了 TCP 的功能，它作为 UDP 流量在通过 VLESS 协议传输时，底层协议为 TCP，就相当于两层阻塞控制了。 若不需要拦截，请在客户端填写 `xtls-rprx-*-udp443`，服务端不变。 ::: @@ -121,7 +121,6 @@ Splice 模式的的使用限制： - Linux 环境 - 入站协议为 `Dokodemo door`、`Socks`、`HTTP` 等纯净的 TCP 连接, 或其它使用了 XTLS 的入站协议 - 出站协议为 VLESS + XTLS -- 需要注意的是，使用 mKCP 协议时不会使用 Splice（是的，虽然没有报错，但实际上根本没用到） 此外，使用 Splice 时网速显示会滞后，这是特性，不是 bug。