mirror of
https://github.com/XTLS/Xray-docs-next.git
synced 2025-04-04 22:03:35 +03:00
Update fallbacks-lv1.md
This commit is contained in:
Morrigan-Ship
GitHub
parent
ede029d336
commit
7524a5b131
1 changed files with 128 additions and 127 deletions
|
|
@ -1,10 +1,10 @@
|
|||
# 回落 (fallbacks) 功能简析
|
||||
# Fallbacks
|
||||
|
||||
在使用 Xray 的过程中，你一定无数次的听说了【回落】这个功能。本文就稍微说明一下这个功能的逻辑以及使用方式。
|
||||
When using Xray, you must have heard of the "Fallback" function countless times. This article will briefly explain the logic and usage of this function.
|
||||
|
||||
## 1. 回顾《小小白白话文》中的回落
|
||||
## 1. Review the fallback in "Little White Vernacular"
|
||||
|
||||
如果你用了《小小白白话文》中的[Xray 配置](../level-0/ch07-xray-server.md#_7-4-配置xray)，并完成了[HTTP 自动跳转 HTTPS 优化](../level-0/ch07-xray-server.md#_7-8-服务器优化之二-开启http自动跳转https)，那么你已经有了基于 `VLESS` 协议的简易回落：
|
||||
If you used the [Xray configuration](../level-0/ch07-xray-server.md#_7-4-Configure xray) in "Little White Vernacular" and completed the [HTTP automatic redirection to HTTPS optimization](../level-0/ch07-xray-server.md#_7-8-Server optimization 2-Enable http automatic redirection to https), then you already have a simple fallback based on the `VLESS` protocol:
|
||||
|
||||
```json
|
||||
{
|
||||
|
|
@ -19,7 +19,7 @@
|
|||
"decryption": "none",
|
||||
"fallbacks": [
|
||||
{
|
||||
"dest": 8080 // 默认回落到防探测的代理
|
||||
"dest": 8080 // Fallback to anti-detection proxy by default
|
||||
}
|
||||
]
|
||||
},
|
||||
|
|
@ -31,51 +31,51 @@
|
|||
}
|
||||
```
|
||||
|
||||
这一段配置用人话要怎么解释呢？
|
||||
How do you explain this configuration in human terms?
|
||||
|
||||
1. **`Xray` 的入站端口 `[inbound port]` 是 `443`**
|
||||
1. **The inbound port of `Xray` is `443`**
|
||||
|
||||
即由 `Xray` 负责监听 `443` 端口的 `HTTPS` 流量
|
||||
This means `Xray` listens for `HTTPS` traffic on port `443`.
|
||||
|
||||
2. **`Xray` 的入站协议 `[inbound protocol]` 是 `vless`**
|
||||
2. **The inbound protocol of `Xray` is `vless`**
|
||||
|
||||
只有 `vless` 协议的流量才会流入 `Xray` 中做后续处理。
|
||||
Only traffic using the `vless` protocol will flow into `Xray` for further processing.
|
||||
|
||||
::: warning
|
||||
**注：** `VLESS` 这个轻量协议开发的初衷就是给 `xray` 及 `v2fly` 等核心引入回落功能、并同时减少冗余校验/加密。（当然，到目前为止，`xray` 中的 `trojan` 协议也已完整支持回落功能。）
|
||||
::: warning
|
||||
**Note:** The lightweight `VLESS` protocol was originally developed to introduce fallback functionality for cores like `xray` and `v2fly`, while reducing redundant validation/encryption. (As of now, the `trojan` protocol in `xray` also fully supports fallback functionality.)
|
||||
:::
|
||||
|
||||
4. **The fallback destination port is `8080`**
|
||||
|
||||
3. **回落目标端口 `[fallback dest]` 是 `8080`**
|
||||
After `Xray` receives traffic on port `443`, traffic using the `vless` protocol is processed internally by `Xray` and forwarded to the outbound module. Other non-`vless` traffic is forwarded to port `8080`.
|
||||
|
||||
`Xray` 接受 `443` 端口的访问流量后，属于 `vless` 协议的流量、由 `Xray` 进行内部处理并转发至出站模块。而其他非 `vless` 协议的流量，则转发至 `8080` 端口。
|
||||
::: warning
|
||||
**Question: Singular or plural?**
|
||||
|
||||
::: warning
|
||||
**问：到底是单数还是复数？**
|
||||
**Answer:** Some sharp-eyed readers may notice that the config file uses plural forms like `inbounds` and `fallbacks`, but my explanations use singular forms like `inbound` and `fallback`. Why?
|
||||
|
||||
答：一定有聪明的同学发现，配置文件中，明明是复数 `inbounds`, `fallbacks`，为什么我解释的时候都是单数：`inbound`, `fallback` 呢？
|
||||
|
||||
因为，配置文件中用复数，说明 `xray` 支持 N 个同等级的元素（即 N 个入站，M 个回落等等），上面的示例解析中仅仅是其中一个，所以我用了单数。
|
||||
The plural forms in the config file indicate that `xray` supports multiple elements of the same type (e.g., N inbound rules, M fallback rules, etc.). The examples above only describe one of these elements, so I used singular forms.
|
||||
:::
|
||||
|
||||
6. **Traffic forwarded to port `8080` is handled by subsequent programs**
|
||||
|
||||
4. **回落给 `8080` 端口的流量，由后续程序处理**
|
||||
|
||||
小小白白话文中的示例，就是 `8080` 端口由 `Nginx` 处理，根据配置找到并展示小熊猫的网页。
|
||||
|
||||
5. **总结，小小白白话文示例中的最简单回落，完整数据路线如下：**
|
||||
In the example from the guide, traffic on port `8080` is handled by `Nginx`, which locates and displays the little panda's webpage based on its configuration.
|
||||
|
||||
7. **In summary, the complete data flow for the simplest fallback in the example is as follows:**
|
||||
```mermaid
|
||||
graph LR;
|
||||
|
||||
W(外部 HTTP:80 请求) --> N80(HTTP:80)
|
||||
W(External HTTP:80 Request) --> N80 (HTTP:80)
|
||||
|
||||
|
||||
subgraph Nginx 外部监听
|
||||
N80 -.- N301(301转写) -.- N443(HTTPS:443)
|
||||
subgraph Nginx External monitoring
|
||||
N80 -.- N301(301 Redirect) -.- N443(HTTPS:443)
|
||||
end
|
||||
|
||||
N443 --> X(Xray 监听 443) .- X1{入站判断}
|
||||
X1 --> |接收 VLESS 流量| X2(Xray内部规则)
|
||||
X2 --> O(Xray Outbounds 出站)
|
||||
X1 ==> |回落 非VLESS 流量| N8080(Nginx:8080)
|
||||
N443 --> X(Xray monitor 443) .- X1{Inbound judgment}
|
||||
X1 --> |Receiving VLESS traffic| X2(Xray Internal Rules)
|
||||
X2 --> O(Xray Outbounds output)
|
||||
X1 ==> |Falling back non-VLESS traffic| N8080(Nginx:8080)
|
||||
N8080:::nginxclass ==> H(index.html)
|
||||
|
||||
H:::nginxclass
|
||||
|
|
@ -83,57 +83,60 @@
|
|||
|
||||
```
|
||||
|
||||
## 2. 重新认识回落 (WHAT, HOW `v1`)
|
||||
## 2. Re-understanding of fallback (WHAT, HOW `v1`)
|
||||
|
||||
基于上面的示例，你应该就可以明白什么是回落（What）和怎么回落（How）了，简单地说就是下面这几个要素：
|
||||
Based on the above examples, you should be able to understand what fallback is (What) and how to fallback (How). In short, it is the following elements:
|
||||
|
||||
1. 回落的时间是流量进入 `Xray监听端口` 后
|
||||
2. 回落的依据是 `协议类型` 等流量特征
|
||||
3. 回落的目标是某个 `端口`
|
||||
4. 被回落的流量由监听 `回落端口` 的后续程序接手
|
||||
1. The fallback time is when the traffic enters the `Xray listening port`
|
||||
2. The fallback is based on traffic characteristics such as `protocol type`
|
||||
3. The fallback target is a certain `port`
|
||||
4. The fallen traffic is taken over by the subsequent program that listens to the `fallback port`
|
||||
|
||||
## 3. 为什么要回落 (WHY `v1`)
|
||||
|
||||
最初，是为了防御 **【主动探测】** (Active Probing)
|
||||
## 3. Why do we need to fall back (WHY `v1`)
|
||||
|
||||
**主动探测：** 简单粗暴的理解，就是指外部通过发送特定的网络请求，并解读服务器的回应内容，来推测服务器端是否运行了 `xray`, `v2fly`, `shadowsocks` 等代理工具。一旦可以准确认定，则服务器可能受到干扰或阻断。
|
||||
Initially, it was to defend **【Active Probing】**
|
||||
|
||||
之所以可以根据服务器回应内容进行解读，就是因为一次完整的数据请求，其实有很多数据交换的步骤，每一个步骤，都会产生一些软件特征。用大白话说就是：
|
||||
**Active detection:** In simple terms, it means that the outside world sends specific network requests and interprets the server's response content to infer whether the server is running proxy tools such as `xray`, `v2fly`, `shadowsocks`. Once it can be accurately identified, the server may be interfered with or blocked.
|
||||
|
||||
- 正常的网站的回应，一定【会有】类似 `Nginx`, `Apache`, `MySQL` 的 Web 服务、数据库等工具的特征
|
||||
- 正常的网站的回应，一定【不会有】类似 `xray`, `v2fly`, `shadowsocks` 等代理工具的特征
|
||||
The reason why it can be interpreted based on the server's response content is that a complete data request actually has many data exchange steps, and each step will produce some software features. In plain words:
|
||||
|
||||
于是，当我们给 `Xray` 提供了【回落】功能后（如上例，回落给 `Nginx`），面对任何用来探测的请求，产生的结果是：
|
||||
- A normal website response will definitely have features similar to `Nginx`, `Apache`, `MySQL` Web services, databases and other tools
|
||||
- A normal website response will definitely not have features similar to `xray`, `v2fly`, `shadowsocks` and other proxy tools
|
||||
|
||||
- 探测流量无法掌握你的 `VLESS` 要素，故都会被回落至 `Nginx`
|
||||
- 探测流量全都回落进入 `Nginx` ，故 VPS 服务器的回应一定【会有】 `Nginx` 的特征
|
||||
- 因为 `Xray` 本身不对探测流量做任何回应 ，所以 VPS 的回应一定【不会有】 `Xray` 的特征
|
||||
Therefore, when we provide the [fallback] function to `Xray` (as in the above example, fallback to `Nginx`), the result for any request used for detection is:
|
||||
|
||||
至此，【回落】功能就从数据交互逻辑上解决了服务器被 **【主动探测】** 的安全隐患。
|
||||
- The detection traffic cannot grasp your `VLESS` elements, so it will be fallen back to `Nginx`
|
||||
- All detection traffic falls back to `Nginx`, so the response of the VPS server will definitely [have] the characteristics of `Nginx`
|
||||
- Because `Xray` itself does not respond to any detection traffic, the response of the VPS will definitely [not have] the characteristics of `Xray`
|
||||
|
||||
## 4. 重新认识【回落の完全体】 (WHAT, WHY, HOW `v2`)
|
||||
So far, the [fallback] function has solved the security risks of the server being **[actively detected]** from the data interaction logic.
|
||||
|
||||
为什么又要再次认识回落呢？ 因为，上面仅仅说清楚了基于“协议”的、抵抗【主动探测】的初版回落。
|
||||
## 4. Re-understanding the [full version of fallback] (WHAT, WHY, HOW `v2`)
|
||||
|
||||
在 [RPRX](https://github.com/rprx) 不断开发迭代 `VLESS` 协议及 `fallback` 功能的过程中，逐渐发现，回落完全可以更加灵活强大，只要在保证抵抗【主动探测】的前提下，充分利用数据首包中的信息，其实可以做到多元素、多层次的回落。（如 `path`, `alpn` 等）
|
||||
Why do we need to understand fallback again? Because the above only explains the first version of fallback based on the "protocol" and resisting [active detection].
|
||||
|
||||
基于这个开发理念，【回落】功能才逐渐成长为现在的完全体，即完成了 `纯伪装 --> ws分流 --> 多协议多特征分流` 的进化。最终版甚至完全替代了以前要用 Web 服务器、其他工具才能完成的分流的功能。且由于上述的【回落/分流】处理都在首包判断阶段以毫秒级的速度完成、不涉及任何数据操作，所以几乎没有任何过程损耗。
|
||||
In the process of [RPRX](https://github.com/rprx) continuously developing and iterating the `VLESS` protocol and the `fallback` function, we gradually discovered that fallback can be more flexible and powerful. As long as we ensure resistance to [active detection] and make full use of the information in the first packet of the data, we can actually achieve multi-element and multi-level fallback. (Such as `path`, `alpn`, etc.)
|
||||
|
||||
**因此，现在 `Xray` 中【完整体的回落功能】，同时具备下述属性：**
|
||||
Based on this development concept, the [fallback] function has gradually grown into its current complete form, that is, it has completed the evolution of `pure camouflage --> ws diversion --> multi-protocol multi-feature diversion`. The final version even completely replaced the diversion function that was previously completed by Web servers and other tools. And because the above-mentioned [fallback/diversion] processing is completed at a millisecond speed in the first packet judgment stage and does not involve any data operation, there is almost no process loss.
|
||||
|
||||
- **安全：** 充分抵御主动探测攻击
|
||||
- **高效：** 几乎毫无性能损失
|
||||
- **灵活：** 数据灵活分流、常用端口复用（如 443）
|
||||
**Therefore, the [full fallback function] in `Xray` now has the following properties:**
|
||||
|
||||
::: tip 啰嗦君
|
||||
这样多轮介绍虽然略显繁琐，但只有这样层层深入展开，才能充分的说明【回落の完全体】独有的强大！
|
||||
- **Security:** Fully resist active detection attacks
|
||||
|
||||
- **Efficiency:** Almost no performance loss
|
||||
|
||||
- **Flexibility:** Flexible data diversion and reuse of common ports (such as 443)
|
||||
|
||||
::: tip 话声君
|
||||
Although such multiple rounds of introductions are a bit cumbersome, only by deepening them layer by layer can we fully illustrate the unique power of [full fallback]!
|
||||
:::
|
||||
|
||||
## 5. 多层回落示例及解读
|
||||
## 5. Multi-layer fallback example and interpretation
|
||||
|
||||
理解了【回落の完全体】是什么，那就可以动手操作配置多层回落了。其实，项目已经提供了非常完整的示例，即官方模板中的 [VLESS-TCP-XTLS-WHATEVER](https://github.com/XTLS/Xray-examples/blob/main/VLESS-TCP-XTLS-WHATEVER/)。
|
||||
After understanding what [full fallback] is, you can start to configure multi-layer fallback. In fact, the project has provided a very complete example, namely [VLESS-TCP-XTLS-WHATEVER](https://github.com/XTLS/Xray-examples/blob/main/VLESS-TCP-XTLS-WHATEVER/) in the official template.
|
||||
|
||||
### 5.1 首先，我将服务器端配置的 443 监听段摘抄如下：
|
||||
### 5.1 First, I will excerpt the 443 listening section configured on the server as follows:
|
||||
|
||||
```json
|
||||
{
|
||||
|
|
@ -142,7 +145,7 @@
|
|||
"settings": {
|
||||
"clients": [
|
||||
{
|
||||
"id": "", // 填写你的 UUID
|
||||
"id": "", // Fill with your UUID
|
||||
"flow": "xtls-rprx-vision",
|
||||
"level": 0,
|
||||
"email": "love@example.com"
|
||||
|
|
@ -151,21 +154,21 @@
|
|||
"decryption": "none",
|
||||
"fallbacks": [
|
||||
{
|
||||
"dest": 1310, // 默认回落到 Xray 的 Trojan 协议
|
||||
"dest": 1310, // Falling back to Xray's Trojan protocol by default
|
||||
"xver": 1
|
||||
},
|
||||
{
|
||||
"path": "/websocket", // 必须换成自定义的 PATH
|
||||
"path": "/websocket", // Must be replaced with a custom PATH
|
||||
"dest": 1234,
|
||||
"xver": 1
|
||||
},
|
||||
{
|
||||
"path": "/vmesstcp", // 必须换成自定义的 PATH
|
||||
"path": "/vmesstcp", // Must be replaced with a custom PATH
|
||||
"dest": 2345,
|
||||
"xver": 1
|
||||
},
|
||||
{
|
||||
"path": "/vmessws", // 必须换成自定义的 PATH
|
||||
"path": "/vmessws", // Must be replaced with a custom PATH
|
||||
"dest": 3456,
|
||||
"xver": 1
|
||||
}
|
||||
|
|
@ -178,8 +181,8 @@
|
|||
"alpn": ["http/1.1"],
|
||||
"certificates": [
|
||||
{
|
||||
"certificateFile": "/path/to/fullchain.crt", // 换成你的证书，绝对路径
|
||||
"keyFile": "/path/to/private.key" // 换成你的私钥，绝对路径
|
||||
"certificateFile": "/path/to/fullchain.crt", // Replace with your certificate, absolute path
|
||||
"keyFile": "/path/to/private.key" // Replace with your certificate, absolute path
|
||||
}
|
||||
]
|
||||
}
|
||||
|
|
@ -187,48 +190,46 @@
|
|||
}
|
||||
```
|
||||
|
||||
这一段配置用人话要怎么解释呢？
|
||||
1. **`Xray` listens on port `443`**
|
||||
Monitors HTTPS traffic using TLS certificates configured in the `certificates` section.
|
||||
|
||||
1. **`Xray` 的入站端口 (`inbound port`) 是 `443`**
|
||||
2. **`Xray` uses `vless` as its inbound protocol**
|
||||
Directly processes VLESS protocol traffic through its core routing system.
|
||||
|
||||
即由 `Xray` 负责监听 `443` 端口的 `HTTPS` 流量，并使用 `certificates` 项下设定的 `TLS` 证书来进行验证
|
||||
3. **Non-VLESS traffic follows 4 fallback paths:**
|
||||
- Path `websocket` → Port `1234`
|
||||
- Path `vmesstcp` → Port `2345`
|
||||
- Path `vmessws` → Port `3456`
|
||||
- All others → Port `1310`
|
||||
*Paths refer to HTTP request headers for routing*
|
||||
|
||||
2. **`Xray` 的入站协议 (`inbound protocol`) 是 `vless`**
|
||||
4. **`xver: 1` enables Proxy Protocol**
|
||||
Preserves original client IP addresses when working with reverse proxies.
|
||||
|
||||
`vless` 协议流量直接流入 `Xray` 中做后续处理
|
||||
|
||||
3. **非 `VLESS` 协议流量有 4 个不同的回落目标：**
|
||||
|
||||
1. `path` 为 `websocket` 的流量，回落给端口 `1234` 后续处理
|
||||
2. `path` 为 `vmesstcp` 的流量，回落给端口 `2345` 后续处理
|
||||
3. `path` 为 `vmessws` 的流量，回落给端口 `3456` 后续处理
|
||||
4. 其它所有流量，回落给端口 `1310` 后续处理
|
||||
|
||||
4. **`xver` 为 `1` 表示开启 `proxy protocol` 功能，向后传递来源真实 IP**
|
||||
|
||||
5. **上述回落结构如下图所示：**
|
||||
5. **Fallback structure visualization:**
|
||||
[Diagram/Figure Would Appear Here]
|
||||
|
||||
```mermaid
|
||||
graph LR;
|
||||
|
||||
W443(外部 HTTP:443 请求) --> X443(Xray-inbound: 443) .- X1{入站判断}
|
||||
X1 --> |协议 = VLESS 的流量| X2(Xray内部规则)
|
||||
X2 --> O(Xray Outbounds 出站)
|
||||
W443(External HTTP:443 requests) --> X443(Xray-inbound: 443) .- X1{Inbound judgment}
|
||||
X1 --> |Protocol = VLESS traffic| X2(Xray Internal Rules)
|
||||
X2 --> O(Xray Outbounds output)
|
||||
|
||||
X1 --> |path = /websocket 的流量| X1234(Xray-inbound:1234)
|
||||
X1 --> |path = /vmesstcp 的流量| X2345(Xray-inbound:2345)
|
||||
X1 --> |path = /vmessws 的流量| X3456(Xray-inbound:3456)
|
||||
X1 --> |其它所有流量| X1310(Xray-inbound:1310)
|
||||
X1 --> |path = /websocket Traffic| X1234(Xray-inbound:1234)
|
||||
X1 --> |path = /vmesstcp Traffic| X2345(Xray-inbound:2345)
|
||||
X1 --> |path = /vmessws Traffic| X3456(Xray-inbound:3456)
|
||||
X1 --> |All other traffic| X1310(Xray-inbound:1310)
|
||||
|
||||
```
|
||||
|
||||
6. **网页回落不见了！**
|
||||
6. **Web page fallback is gone! **
|
||||
|
||||
没错，聪明的同学应该发现了，防御【主动探测】的 `nginx回落` 不见了！！！这是为什么呢？会不会不安全？别急，我们继续分析：
|
||||
That's right, smart students should have discovered that the `nginx fallback` of the defense [active detection] is gone! ! ! Why is this? Is it unsafe? Don't worry, let's continue to analyze:
|
||||
|
||||
### 5.2 后续监听处理的配置段摘抄如下：
|
||||
### 5.2 The configuration section for subsequent monitoring processing is excerpted as follows:
|
||||
|
||||
1. 后续处理回落至 `1310` 端口的流量，按照下面的配置验证、处理：
|
||||
1. For the subsequent processing of the traffic falling back to port 1310, verify and process it according to the following configuration:
|
||||
|
||||
```json
|
||||
{
|
||||
|
|
@ -238,14 +239,14 @@
|
|||
"settings": {
|
||||
"clients": [
|
||||
{
|
||||
"password": "", // 填写你的密码
|
||||
"password": "", // Fill in your password
|
||||
"level": 0,
|
||||
"email": "love@example.com"
|
||||
}
|
||||
],
|
||||
"fallbacks": [
|
||||
{
|
||||
"dest": 80 // 或者回落到其它也防探测的代理
|
||||
"dest": 80 // Or fallback to other detection-resistant proxies
|
||||
}
|
||||
]
|
||||
},
|
||||
|
|
@ -259,12 +260,12 @@
|
|||
}
|
||||
```
|
||||
|
||||
看，神奇的事情发生了， `trojan` 协议这里又出现了一个新的 `fallbacks`。前面已经说过，`xray` 中的 `trojan` 协议也具有完整的回落能力，所以，此时 `trojan` 协议可以再次做判断和回落（这也就是传说中的套娃回落了）：
|
||||
Look, something magical happened, a new `fallbacks` appeared in the `trojan` protocol. As mentioned before, the `trojan` protocol in `xray` also has complete fallback capabilities, so at this time the `trojan` protocol can make judgments and fallbacks again (this is the legendary nesting doll fallback):
|
||||
|
||||
- 所有 `trojan` 协议的流量，流入 `Xray` 中做后续处理
|
||||
- 所有非 `trojan` 协议的流量，转发至 `80` 端口，【主动探测】的防御，完成！
|
||||
- All traffic of the `trojan` protocol flows into `Xray` for subsequent processing
|
||||
- All non-trojan protocol traffic is forwarded to port 80, and the [active detection] defense is complete!
|
||||
|
||||
2. 后续处理回落至 `1234` 端口的流量，仔细看！它其实是 `vless+ws`：
|
||||
2. The subsequent processing falls back to the traffic of port `1234`. Look carefully! It is actually `vless+ws`:
|
||||
|
||||
```json
|
||||
{
|
||||
|
|
@ -274,7 +275,7 @@
|
|||
"settings": {
|
||||
"clients": [
|
||||
{
|
||||
"id": "", // 填写你的 UUID
|
||||
"id": "", // Fill in UUID
|
||||
"level": 0,
|
||||
"email": "love@example.com"
|
||||
}
|
||||
|
|
@ -285,14 +286,14 @@
|
|||
"network": "ws",
|
||||
"security": "none",
|
||||
"wsSettings": {
|
||||
"acceptProxyProtocol": true, // 提醒：若你用 Nginx/Caddy 等反代 WS，需要删掉这行
|
||||
"path": "/websocket" // 必须换成自定义的 PATH，需要和分流的一致
|
||||
"acceptProxyProtocol": true, // Reminder: If you use Nginx/Caddy or other reverse generation WS, you need to delete this line.
|
||||
"path": "/websocket" // Must change to a custom PATH, which must be consistent with the diversion
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
3. 后续处理回落至 `2345` 端口的流量，仔细看！它其实是 `vmess直连`：
|
||||
3. The subsequent processing falls back to the traffic of port `2345`. Look carefully! It is actually `vmess direct connection`:
|
||||
|
||||
```json
|
||||
{
|
||||
|
|
@ -302,7 +303,7 @@
|
|||
"settings": {
|
||||
"clients": [
|
||||
{
|
||||
"id": "", // 填写你的 UUID
|
||||
"id": "", // Fill in UUID
|
||||
"level": 0,
|
||||
"email": "love@example.com"
|
||||
}
|
||||
|
|
@ -317,7 +318,7 @@
|
|||
"type": "http",
|
||||
"request": {
|
||||
"path": [
|
||||
"/vmesstcp" // 必须换成自定义的 PATH，需要和分流的一致
|
||||
"/vmesstcp" // You must change to a custom PATH, which must be consistent with the diversion
|
||||
]
|
||||
}
|
||||
}
|
||||
|
|
@ -326,10 +327,10 @@
|
|||
}
|
||||
```
|
||||
|
||||
4. 后续处理回落至 `3456` 端口的流量，再仔细看！它其实是是 `vmess+ws(+cdn)`。
|
||||
4. Then process the traffic that falls back to port 3456 and take a closer look! It is actually vmess+ws(+cdn) .
|
||||
|
||||
::: warning 说明
|
||||
你没看错，这就是 v2fly 曾经推荐的组合之一，并可完整支持 `CDN`。现已加入完美回落套餐哦！
|
||||
::: warning
|
||||
You read it right, this is one of the combinations v2fly has recommended, and it fully supports `CDN`. Now it has been added to the perfect fallback package!
|
||||
:::
|
||||
|
||||
```json
|
||||
|
|
@ -340,7 +341,7 @@
|
|||
"settings": {
|
||||
"clients": [
|
||||
{
|
||||
"id": "", // 填写你的 UUID
|
||||
"id": "", // Fill in UUID
|
||||
"level": 0,
|
||||
"email": "love@example.com"
|
||||
}
|
||||
|
|
@ -350,33 +351,33 @@
|
|||
"network": "ws",
|
||||
"security": "none",
|
||||
"wsSettings": {
|
||||
"acceptProxyProtocol": true, // 提醒：若你用 Nginx/Caddy 等反代 WS，需要删掉这行
|
||||
"path": "/vmessws" // 必须换成自定义的 PATH，需要和分流的一致
|
||||
"acceptProxyProtocol": true, // Reminder: If you use Nginx/Caddy to reverse WS, you need to delete this line
|
||||
"path": "/vmessws" // You must change to a custom PATH, which must be consistent with the diversion
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
5. 至此，我们就能够完整的画出模板的回落路线了：
|
||||
5. At this point, we can completely draw the template's fallback route:
|
||||
|
||||
```mermaid
|
||||
graph LR;
|
||||
|
||||
W443(外部 HTTP:443 请求) --> X443(Xray-inbound: 443) .- X1{入站判断}
|
||||
X1 --> |协议 = VLESS 的流量| X2(Xray内部规则)
|
||||
W443(External HTTP:443 requests) --> X443(Xray-inbound: 443) .- X1{Inbound judgment}
|
||||
X1 --> |Protocol = VLESS traffic| X2(Xray Internal Rules)
|
||||
X2 --> XO(Xray Outbounds 出站)
|
||||
|
||||
X1 --> |path = /websocket 的流量| X1234(Xray-inbound:1234)
|
||||
X1 --> |path = /vmesstcp 的流量| X2345(Xray-inbound:2345)
|
||||
X1 --> |path = /vmessws 的流量| X3456(Xray-inbound:3456)
|
||||
X1 --> |其它所有流量| X1310(Xray-inbound:1310)
|
||||
X1 --> |path = /websocket Traffic| X1234(Xray-inbound:1234)
|
||||
X1 --> |path = /vmesstcp Traffic| X2345(Xray-inbound:2345)
|
||||
X1 --> |path = /vmessws Traffic| X3456(Xray-inbound:3456)
|
||||
X1 --> |All other traffic| X1310(Xray-inbound:1310)
|
||||
|
||||
X1234 --> X2
|
||||
X2345 --> X2
|
||||
X3456 --> X2
|
||||
|
||||
X1310 --> |协议 = trojan 的流量| X2
|
||||
X1310 --> |其他所有流量| N80(Nginx:80)
|
||||
X1310 --> |Protocol = Trojan traffic| X2
|
||||
X1310 --> |All other traffic| N80(Nginx:80)
|
||||
|
||||
N80:::nginxclass --> H(index.html)
|
||||
|
||||
|
|
@ -384,12 +385,12 @@
|
|||
classDef nginxclass fill:#FFFFDE
|
||||
```
|
||||
|
||||
## 6. 结语
|
||||
## 6. Conclusion
|
||||
|
||||
至此，`Xray` 的【回落】功能就介绍完了。希望本文能够对你理解 `Xray` 的强大有所帮助。
|
||||
So far, the "fallback" function of `Xray` has been introduced. I hope this article can help you understand the power of `Xray`.
|
||||
|
||||
## 7. 附加题
|
||||
## 7. Additional questions
|
||||
|
||||
我再无耻的留一个附加题：本文详解的 [VLESS-TCP-XTLS-WHATEVER](https://github.com/XTLS/Xray-examples/blob/main/VLESS-TCP-XTLS-WHATEVER/) 模板？是否有可以优化的地方？
|
||||
I'll shamelessly leave you with a side question: Is there anything that can be optimized for the [VLESS-TCP-XTLS-WHATEVER](https://github.com/XTLS/Xray-examples/blob/main/VLESS-TCP-XTLS-WHATEVER/) template detailed in this article?
|
||||
|
||||
提示：HTTP 自动跳转 HTTPS
|
||||
Tip: HTTP automatically redirects to HTTPS
|
||||
|
|
|
|||
Loading…
Add table
Reference in a new issue