在使用Xray的过程中，你一定无数次的听说了【回落】这个功能。本文就稍微说明一下这个功能的逻辑以及使用方式。
1. 回顾《小小白白话文》中的回落
如果你用了《小小白白话文》中的Xray配置，并完成了HTTP自动跳转HTTPS优化，那么你已经有了基于 VLESS 协议的简易回落：
"inbounds": [
{
"port": 443,
"protocol": "vless",
"settings": {
"clients": [
...
],
"decryption": "none",
"fallbacks": [
{
"dest": 8080 // 默认回落到防探测的代理
}
]
},
"streamSettings": {
...
}
}
]
这一段配置用人话要怎么解释呢？
Xray的入站端口[inbound port]是443即由Xray负责监听443端口的HTTPS流量Xray的入站协议[inbound protocol]是vless只有vless协议的流量才会流入Xray中做后续处理。注：
VLESS这个轻量协议开发的初衷就是给xray及v2fly等核心引入回落功能、并同时减少冗余校验/加密。（当然，到目前为止，xray中的trojan协议也已完整支持回落功能。）- 回落目标端口
[fallback dest]是8080Xray接受443端口的访问流量后，属于vless协议的流量、由Xray进行内部处理并转发至出站模块。而其他非vless协议的流量，则转发至8080端口。问：到底是单数还是复数？
答：一定有聪明的同学发现，配置文件中，明明是复数
inbounds,fallbacks，为什么我解释的时候都是单数：inbound,fallback呢？因为，配置文件中用复数，说明
xray支持 N 个同等及的元素（即N个入站，M个回落等等），上面的示例解析中仅仅是其中一个，所以我用了单数。 - 回落给
8080端口的流量，由后续程序处理小小白白话文中的示例，就是8080端口由Nginx处理，根据配置找到并展示小熊猫的网页。 - 总结，小小白白话文示例中的最简单回落，完整数据路线如下：
2. 重新认识回落 (WHAT, HOW v1)
基于上面的示例，你应该就可以明白什么是回落（What）和怎么回落（How）了，简单地说就是下面这几个要素：
- 回落的时间是流量进入
Xray监听端口后 - 回落的依据是
协议类型等流量特征 - 回落的目标是某个
端口 - 被回落的流量由监听
回落端口的后续程序接手
3. 为什么要回落 (WHY v1)
最初，是为了防御 【主动探测】 (Active Probing)
主动探测： 简单粗暴的理解，就是指外部通过发送特定的网络请求，并解读服务器的回应内容，来推测服务器端是否运行了 xray, v2fly, shadowsocks 等代理工具。一旦可以准确认定，则服务器可能受到干扰或阻断。
之所以可以根据服务器回应内容进行解读，就是因为一次完整的数据请求，其实有很多数据交换的步骤，每一个步骤，都会产生一些软件特征。用大白话说就是：
- 正常的网站的回应，一定【会有】类似
Nginx,Apache,MySQL的Web服务、数据库等工具的特征 - 正常的网站的回应，一定【不会有】类似
xray,v2fly,shadowsocks等代理工具的特征
于是，当我们给 Xray 提供了【回落】功能后（如上例，回落给 Nginx），面对任何用来探测的请求，产生的结果是：
- 探测流量无法掌握你的
VLESS要素，故都会被回落至Nginx - 探测流量全都回落进入
Nginx，故VPS服务器的回应一定【会有】Nginx的特征 - 因为
Xray本身不对探测流量做任何回应 ，所以VPS的回应一定【不会有】Xray的特征
至此，【回落】功能就从数据交互逻辑上解决了服务器被 【主动探测】 的安全隐患。
4. 重新认识【回落の完全体】 (WHAT, WHY, HOW v2)
为什么又要再次认识回落呢？ 因为，上面仅仅说清楚了基于“协议”的、抵抗【主动探测】的初版回落。
在 rprx 不断开发迭代 VLESS 协议及 fallback 功能的过程种，逐渐发现，回落完全可以更加灵活强大，只要在保证抵抗【主动探测】的前提下，充分利用数据首包中的信息，其实可以做到多元素、多层次的回落。（如 path, alpn 等）
基于这个开发理念，【回落】功能才逐渐成长为现在的完全体，即完成了 纯伪装 --> ws分流 --> 多协议多特征分流 的进化。最终版甚至完全替代了以前要用Web服务器、其他工具才能完成的分流的功能。且由于上述的【回落/分流】处理都在首包判断阶段以毫秒级的速度完成、不涉及任何数据操作，所以几乎没有任何过程损耗。
因此，现在 Xray 中【完整体的回落功能】，同时具备下述属性：
- 安全： 充分抵御主动探测攻击
- 高效： 几乎毫无性能损失
- 灵活： 数据灵活分流、常用端口复用（如443）
啰嗦君： 这样多轮介绍虽然略显繁琐，但只有这样层层深入展开，才能充分的说明【回落の完全体】独有的强大！
5. 多层回落示例及解读
理解了【回落の完全体】是什么，那就可以动手操作配置多层回落了。其实，项目已经提供了非常完整的示例，即官方模板中的 VLESS-TCP-XTLS-WHATEVER。
5.1 首先，我将服务器端配置的 443 监听段摘抄如下：
{
"port": 443,
"protocol": "vless",
"settings": {
"clients": [
{
"id": "", // 填写你的 UUID
"flow": "xtls-rprx-direct",
"level": 0,
"email": "love@example.com"
}
],
"decryption": "none",
"fallbacks": [
{
"dest": 1310, // 默认回落到 Xray 的 Trojan 协议
"xver": 1
},
{
"path": "/websocket", // 必须换成自定义的 PATH
"dest": 1234,
"xver": 1
},
{
"path": "/vmesstcp", // 必须换成自定义的 PATH
"dest": 2345,
"xver": 1
},
{
"path": "/vmessws", // 必须换成自定义的 PATH
"dest": 3456,
"xver": 1
}
]
},
"streamSettings": {
"network": "tcp",
"security": "xtls",
"xtlsSettings": {
"alpn": [
"http/1.1"
],
"certificates": [
{
"certificateFile": "/path/to/fullchain.crt", // 换成你的证书，绝对路径
"keyFile": "/path/to/private.key" // 换成你的私钥，绝对路径
}
]
}
}
},
这一段配置用人话要怎么解释呢？
Xray的入站端口 (inbound port) 是443即由Xray负责监听443端口的HTTPS流量，并使用certificates项下设定的TLS证书来进行验证Xray的入站协议 (inbound protocol) 是vlessvless协议流量直接流入Xray中做后续处理- 非
VLESS协议流量有4个不同的回落目标：path为websocket的流量，回落给端口1234后续处理path为vmesstcp的流量，回落给端口2345后续处理path为vmessws的流量，回落给端口3456后续处理- 其它所有流量，回落给端口
1310后续处理
xver为1表示开启proxy protocol功能，向后传递来源真实IP- 上述回落结构如下图所示：
- 网页回落不见了！没错，聪明的同学应该发现了，防御【主动探测】的
nginx回落不见了！！！这是为什么呢？会不会不安全？别急，我们继续分析：
5.2 后续监听处理的配置段摘抄如下：
- 后续处理回落至
1310端口的流量，按照下面的配置验证、处理：{ "port": 1310, "listen": "127.0.0.1", "protocol": "trojan", "settings": { "clients": [ { "password": "", // 填写你的密码 "level": 0, "email": "love@example.com" } ], "fallbacks": [ { "dest": 80 // 或者回落到其它也防探测的代理 } ] }, "streamSettings": { "network": "tcp", "security": "none", "tcpSettings": { "acceptProxyProtocol": true } } },看，神奇的事情发生了，
trojan协议这里又出现了一个新的fallbacks。前面已经说过，xray中的trojan协议也具有完整的回落能力，所以，此时trojan协议可以再次做判断和回落（这也就是传说中的套娃回落了）：- 所有
trojan协议的流量，流入Xray中做后续处理 - 所有非
trojan协议的流量，转发至80端口，【主动探测】的防御，完成！
- 所有
- 后续处理回落至
1234端口的流量，仔细看！它其实是vless+ws：{ "port": 1234, "listen": "127.0.0.1", "protocol": "vless", "settings": { "clients": [ { "id": "", // 填写你的 UUID "level": 0, "email": "love@example.com" } ], "decryption": "none" }, "streamSettings": { "network": "ws", "security": "none", "wsSettings": { "acceptProxyProtocol": true, // 提醒：若你用 Nginx/Caddy 等反代 WS，需要删掉这行 "path": "/websocket" // 必须换成自定义的 PATH，需要和分流的一致 } } }, - 后续处理回落至
2345端口的流量，仔细看！它其实是vmess直连：{ "port": 2345, "listen": "127.0.0.1", "protocol": "vmess", "settings": { "clients": [ { "id": "", // 填写你的 UUID "level": 0, "email": "love@example.com" } ] }, "streamSettings": { "network": "tcp", "security": "none", "tcpSettings": { "acceptProxyProtocol": true, "header": { "type": "http", "request": { "path": [ "/vmesstcp" // 必须换成自定义的 PATH，需要和分流的一致 ] } } } } }, - 后续处理回落至
3456端口的流量，再仔细看！它其实是是vmess+ws(+cdn)。说明： 你没看错，这就是 v2fly 曾经的推荐组合之一，并可完整支持
CDN。现已加入完美回落套餐哦！{ "port": 3456, "listen": "127.0.0.1", "protocol": "vmess", "settings": { "clients": [ { "id": "", // 填写你的 UUID "level": 0, "email": "love@example.com" } ] }, "streamSettings": { "network": "ws", "security": "none", "wsSettings": { "acceptProxyProtocol": true, // 提醒：若你用 Nginx/Caddy 等反代 WS，需要删掉这行 "path": "/vmessws" // 必须换成自定义的 PATH，需要和分流的一致 } } } - 至此，我们就能够完整的画出模板的回落路线了：
6. 结语
至此，Xray 的【回落】功能就介绍完了。希望本文能够对你理解 Xray 的强大有所帮助。
7. 附加题
我再无耻的留一个附加题：本文详解的 VLESS-TCP-XTLS-WHATEVER 模板？是否有可以优化的地方？
提示：HTTP自动跳转HTTPS
附：VLESS over TCP with XTLS + 回落 & 分流 to WHATEVER（终极配置）
这里是 进阶配置 的超集，利用 VLESS 强大的回落分流特性，实现了 443 端口尽可能多的协议、配置的完美共存，包括 XTLS Direct Mode
客户端可以同时通过下列方式连接到服务器，其中 WS 都可以通过 CDN
- VLESS over TCP with XTLS，数倍性能，首选方式
- VLESS over TCP with TLS
- VLESS over WS with TLS
- VMess over TCP with TLS，不推荐
- VMess over WS with TLS
- Trojan over TCP with TLS
这里设置默认回落到 Xray 的 Trojan 协议，再继续回落到 80 端口的 Web 服务器（也可以换成数据库、FTP 等）
你还可以配置回落到 Caddy 的 forwardproxy 等其它也防探测的代理，以及分流到任何支持 WebSocket 的代理，都没有问题