mirror of
https://github.com/XTLS/Xray-docs-next.git
synced 2025-04-02 21:06:15 +03:00
Update routing-lv1-part1.md
This commit is contained in:
parent
ede029d336
commit
b90f5a82e1
1 changed files with 119 additions and 115 deletions
|
@ -1,34 +1,34 @@
|
|||
# 路由 (routing) 功能简析(上)
|
||||
# Routing function analysis (Part 1)
|
||||
|
||||
如果说 Xray 的【强大】主要体现在它极致的速度和广泛的兼容性。那么 Xray 的【灵活】,则主要应该归功于它巧妙的【路由】功能。本文就稍微说明一下这个功能的逻辑以及使用方式。
|
||||
If Xray's [power] is mainly reflected in its extreme speed and wide compatibility. Then Xray's [flexibility] should be mainly attributed to its clever [routing] function. This article will briefly explain the logic and usage of this function.
|
||||
|
||||
## 1. 初识【路由】三兄弟
|
||||
## 1. Introduction to the three brothers of [routing]
|
||||
|
||||
要理解路由,就要理解完整的路由功能需要有三兄弟来合力完成:1. **入站**;2. **路由**;3. **出站**。
|
||||
To understand routing, you must understand that the complete routing function requires the joint efforts of three brothers: 1. **inbound**; 2. **routing**; 3. **outbound**.
|
||||
|
||||

|
||||

|
||||
|
||||
三兄弟桃园结义,不求同年同月同日生,但求同年同月同日死。
|
||||
The three brothers swore brotherhood in Taoyuan, not asking to be born on the same day of the same month of the same year, but to die on the same day of the same month of the same year.
|
||||
|
||||
所以谨记:任何一个元素错误,就可能导致路由功能无法正常工作。
|
||||
So remember: any error in any element may cause the routing function to not work properly.
|
||||
|
||||
因为路由的灵活性非常高,只看技术文档很容易把自己绕晕,所以本文我们用几个具体的示例来逐层讲解。
|
||||
Because routing is very flexible, it is easy to get confused just by reading the technical documentation, so in this article we use several specific examples to explain it layer by layer.
|
||||
|
||||
::: warning 啰嗦君
|
||||
路由功能实在过于灵活,所以本文的示例,都是为了讲解对应的概念,实际使用时请根据自己的需求进行调整。
|
||||
::: warning 噜咕君君
|
||||
The routing function is too flexible, so the examples in this article are all for explaining the corresponding concepts. Please adjust according to your needs when actually using it.
|
||||
:::
|
||||
|
||||
## 2. 基本功: “兄弟一条心”
|
||||
## 2. Basic skills: "Brothers are of one mind"
|
||||
|
||||
下图的示例,就是在客户端的 `Xray` 入站接收 APP 数据、在路由 100%转发给出站,并从出站流向 VPS。
|
||||
The example in the figure below is to receive APP data inbound on the client's `Xray`, forward it 100% to the outbound in the router, and flow from the outbound to the VPS.
|
||||
|
||||
```mermaid
|
||||
graph LR;
|
||||
|
||||
S(APP数据) .-> I[入站]
|
||||
S(APP data) .-> I[Inbounds]
|
||||
|
||||
subgraph Xray
|
||||
I --> R[路由] --> O[出站]
|
||||
I --> R[routing] --> O[outbounds]
|
||||
end
|
||||
|
||||
O .-> V(VPS)
|
||||
|
@ -41,15 +41,15 @@
|
|||
|
||||
```
|
||||
|
||||
下面我们来逐个分析:
|
||||
Let's analyze them one by one:
|
||||
|
||||
### 2.1 入站
|
||||
### 2.1 Inbounds
|
||||
|
||||
::: tip
|
||||
**入站:** 就是流量如何流入 `Xray`
|
||||
**Inbound:** is how traffic flows into `Xray`
|
||||
:::
|
||||
|
||||
下面的入站配置示例,用大白话说就是:数据按照 `socks` 协议,通过 `10808` 端口,从本机 `127.0.0.1` 流入`Xray`。同时,`Xray` 将这个入站用 `[tag]` 命名为 `inbound-10808`。
|
||||
The following inbound configuration example, in plain language, means that data flows from the local machine `127.0.0.1` to `Xray` through `10808` port according to the `socks` protocol. At the same time, `Xray` names this inbound `inbound-10808` with `[tag]`.
|
||||
|
||||
```json
|
||||
{
|
||||
|
@ -67,13 +67,14 @@
|
|||
}
|
||||
```
|
||||
|
||||
**2.2 出站**
|
||||
**2.2 Outbound**
|
||||
|
||||
::: tip
|
||||
**出站:** 就是流量如何流出 `Xray`
|
||||
**Outbound:** is how the traffic flows out of `Xray`
|
||||
|
||||
:::
|
||||
|
||||
下面的出站配置示例,用大白话说就是:数据按照 `VLESS` 协议,以 `tcp + xtls` 的方式、及其他相关设置,把流量发送给对应的 VPS。同时,`Xray` 将这个出站用 `[tag]` 命名为 `proxy-out-vless`:
|
||||
The following outbound configuration example, in plain words, is: data is sent to the corresponding VPS in the `VLESS` protocol, in the `tcp + xtls` way, and other related settings. At the same time, `Xray` names this outbound as `proxy-out-vless` with `[tag]`:
|
||||
|
||||
```json
|
||||
{
|
||||
|
@ -111,13 +112,12 @@
|
|||
}
|
||||
```
|
||||
|
||||
### 2.3 路由
|
||||
### 2.3 Routing
|
||||
|
||||
::: tip
|
||||
**路由:** 就是把【入站】和【出站】之间的通道,用某种【条件】串联起来
|
||||
:::
|
||||
**Routing:** is to connect the channels between [inbound] and [outbound] with some [conditions]
|
||||
|
||||
下面的路由配置示例,用大白话说就是:把所有通过 `[tag]="inbound-10808"` 入站流入 `Xray` 的流量,`100%` 全部流转导入 `[tag]="proxy-out-vless"` 的出站,没有任何分流或其他操作。
|
||||
The following routing configuration example, in plain words, is: all the traffic flowing into `Xray` through `[tag]="inbound-10808"` inbound, `100%` all flow into `[tag]="proxy-out-vless"` outbound, without any diversion or other operations.
|
||||
|
||||
```json
|
||||
{
|
||||
|
@ -134,11 +134,11 @@
|
|||
}
|
||||
```
|
||||
|
||||
至此,我们最开始设计的极简规则【客户端的 `Xray` 入站接收 APP 数据、在路由 100%转发给出站,并从出站流向 VPS】已经完成。
|
||||
So far, the minimalist rule we designed at the beginning [the client's `Xray` receives APP data inbound, forwards 100% of it to the outbound in the route, and flows from the outbound to the VPS] has been completed.
|
||||
|
||||
### 2.4 路由配置项解析之一:流量筛选的依据
|
||||
### 2.4 Analysis of routing configuration items 1: the basis of traffic screening
|
||||
|
||||
注意观察路由配置,我们可以看到几个新名词:
|
||||
Pay attention to the routing configuration, we can see several new terms:
|
||||
|
||||
1. `"domainStrategy": "AsIs"`
|
||||
2. `“rules”`
|
||||
|
@ -146,36 +146,36 @@
|
|||
4. `"inboundTag": ["inbound-10808"]`
|
||||
5. `"outboundTag": "proxy-out-vless"`
|
||||
|
||||
其中 `domainStrategy` 我们暂且按下不表,先简单说明后面几个:
|
||||
We will leave `domainStrategy` aside for now and briefly explain the following ones:
|
||||
|
||||
| 配置名称 | 配置值 | 配置说明 |
|
||||
| :-------------: | :-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | :--------------------------------------------------------------------------------------------------------------- |
|
||||
| `“rules”` | | 它的内层就是【路由规则】的明细设置 |
|
||||
| `"type"` | `"field"` | 该项暂时没有特别定义,但是不能省略,所以记得写上就好 |
|
||||
| `"inboundTag"` | `["inbound-10808"]` | 筛选流量的 **【依据】** 是【入站 Tag】,具体 **【条件】** 现在只有一个:【入站来源是 `inbound-10808`】 |
|
||||
| `"outboundTag"` | `"proxy-out-vless"` | 当上面的筛选条件成立时(即入站`[tag]="inbound-10808"`时 ),`Xray` 会将流量导入 `[tag]="proxy-out-vless"` 的出站 |
|
||||
| Configuration Name | Configuration Values | Configuration Instructions |
|
||||
| :-------------: | :-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | :---------------------------------------------------------------------------------------------------------------: |
|
||||
| `“rules”` | | Its inner layer is the detailed settings of [Routing Rules] |
|
||||
| `"type"` | `"field"` | This item has no special definition yet, but it cannot be omitted, so just remember to write it down. |
|
||||
| `"inboundTag"` | `["inbound-10808"]` | The **【basis】** for filtering traffic is the 【inbound tag】, and the specific **【condition】** is currently only one: 【Inbound source is `inbound-10808`】 |
|
||||
| `"outboundTag"` | `"proxy-out-vless"` | When the above filter condition is met (i.e. inbound `[tag]="inbound-10808"`), `Xray` will direct the traffic to the outbound `[tag]="proxy-out-vless"` |
|
||||
|
||||
本例中,我们只有一个入站,它的`"inboundTag" = "inbound-10808"` 。我们也只有一个出站,它的 `[tag]="proxy-out-vless"`。所以根据上面这个路由规则,从唯一入站端口 `10808` 流入`Xray`的流量,`100%` 符合筛选条件、会被路由模块选中,然后转发给唯一的出站。
|
||||
In this example, we have only one inbound, with "inboundTag" = "inbound-10808" . We also have only one outbound, with [tag] = "proxy-out-vless" . So according to the above routing rule, traffic flowing into Xray from the only inbound port 10808 will 100% meet the filter criteria, be selected by the routing module, and then forwarded to the only outbound.
|
||||
|
||||
至此,**入站**、**路由**、**出站** 三兄弟就已经可以携手工作了。当然,现在这个 100%转发的工作并没有什么特别的意义。那么接下来,我们就看看这种分工合作的机制可以带来什么好处。
|
||||
At this point, **inbound**, **routing**, and **outbound** can work together. Of course, the 100% forwarding work now has no special significance. Then, let's see what benefits this division of labor and cooperation mechanism can bring.
|
||||
|
||||
## 3. 小试牛刀: “三分天下” 之 “域名分流”
|
||||
## 3. Try it out: "Domain diversion" of "three-way division"
|
||||
|
||||
> `[geosite.dat]`
|
||||
|
||||
```mermaid
|
||||
graph LR;
|
||||
|
||||
S(APP数据) .-> I[入站]
|
||||
S(APP data) .-> I[inbound]
|
||||
|
||||
subgraph Xray
|
||||
I --> R[路由] -- "geosite:category-ads-all" --> O1[block]
|
||||
R[路由] -- "geosite:cn" --> O2[direct]
|
||||
R[路由] -- "geosite:geolocation-!cn" --> O3[proxy]
|
||||
I --> R[routing] -- "geosite:category-ads-all" --> O1[block]
|
||||
R[routing] -- "geosite:cn" --> O2[direct]
|
||||
R[routing] -- "geosite:geolocation-!cn" --> O3[proxy]
|
||||
|
||||
end
|
||||
|
||||
O2 .-> D(国内服务器)
|
||||
O2 .-> D(Domestic Server)
|
||||
O3 .-> V(VPS)
|
||||
|
||||
O1:::redclass
|
||||
|
@ -189,23 +189,23 @@
|
|||
|
||||
```
|
||||
|
||||
这个配置逻辑,其实就是最简单、最常用的(《小小白白话文》中也在用的)路由配置三件套:
|
||||
This configuration logic is actually the simplest and most commonly used routing configuration set (also used in "Little White Vernacular"):
|
||||
|
||||
1. 广告流量屏蔽 `[block]`
|
||||
2. 国内流量直连 `[direct]`
|
||||
3. 国外流量转发 VPS `[proxy]`
|
||||
1. Ad traffic blocking `[block]`
|
||||
2. Domestic traffic direct connection `[direct]`
|
||||
3. Foreign traffic forwarding VPS `[proxy]`
|
||||
|
||||
::: warning 注意
|
||||
小小白白话文中的直连配置是包括【国内域名】、【国内 IP】、【本机内部 IP】的。这里先讲解【国内域名】。
|
||||
::: warning
|
||||
The direct connection configuration in Xiaoxiaobai's vernacular text includes [domestic domain name], [domestic IP], and [internal IP of the local machine]. Here we will first explain [domestic domain name].
|
||||
:::
|
||||
|
||||
### 3.1 入站
|
||||
### 3.1 Inbound
|
||||
|
||||
保持上例的 `inbound-10808` 不变。
|
||||
Keep `inbound-10808` unchanged.
|
||||
|
||||
### 3.2 出站
|
||||
### 3.2 Outbound
|
||||
|
||||
在上例的基础上,我们已经有了 `[proxy]` 的出站 `"proxy-out-vless"`,所以它保持不变。显而易见,我们需要加入两个新的出站方式:`[block]` 和 `[direct]`,如下:
|
||||
Based on the above example, we already have the outbound `"proxy-out-vless"` of `[proxy]`, so it remains unchanged. Obviously, we need to add two new outbound methods: `[block]` and `[direct]`, as follows:
|
||||
|
||||
```json
|
||||
{
|
||||
|
@ -226,15 +226,17 @@
|
|||
}
|
||||
```
|
||||
|
||||
上面的配置用大白话翻译如下:
|
||||
The above configuration is translated into plain language as follows:
|
||||
|
||||
1. 上例中的 `[proxy-out-vless]` 出站配置保持不变
|
||||
2. 加入 **`blackhole` 黑洞协议**,通过这个协议出站的流量,其实都被发送到了 `Xray` 内部的黑洞里,再也无法逃脱,于是效果就是屏蔽 `[block]`
|
||||
3. 加入 **`freedom` 自由协议**,通过这个协议出站的流量,是自由的离开`Xray`去寻找原定的服务器,就像从没有来过,于是效果就是直连 `[direct]` (我这里起名叫做 `[direct-out]` 是为了强调它是一个出站)
|
||||
1. The `[proxy-out-vless]` outbound configuration in the above example remains unchanged
|
||||
|
||||
### 3.3 路由
|
||||
2. Add **`blackhole` black hole protocol**. The outbound traffic through this protocol is actually sent to the black hole inside `Xray` and can no longer escape, so the effect is to block `[block]`
|
||||
|
||||
接下来就是见证奇迹的时刻了,我们可以用【路由】的配置把这些连接起来!
|
||||
3. Add **`freedom` free protocol**. The outbound traffic through this protocol is free to leave `Xray` to find the original server, as if it has never been there, so the effect is to directly connect `[direct]` (I named it `[direct-out]` here to emphasize that it is an outbound)
|
||||
|
||||
### 3.3 Routing
|
||||
|
||||
The next step is to witness the miracle. We can use the [routing] configuration to connect these!
|
||||
|
||||
```json
|
||||
{
|
||||
|
@ -261,87 +263,89 @@
|
|||
}
|
||||
```
|
||||
|
||||
为了理解这个配置文件,我们要稍微解释一下这里出现的几个新配置项:
|
||||
In order to understand this configuration file, we need to explain a few new configuration items that appear here:
|
||||
|
||||
- `"domain": ["geosite:category-ads-all"]`
|
||||
- `"domain": ["geosite:cn"]`
|
||||
- `"domain": ["geosite:geolocation-!cn"]`
|
||||
|
||||
### 3.4 简析域名文件: `geosite.dat`
|
||||
### 3.4 Brief analysis of the domain name file: `geosite.dat`
|
||||
|
||||
其实,聪明的你大概可以通过这些配置项的名称猜出来个大概:
|
||||
In fact, you can probably guess the general idea from the names of these configuration items:
|
||||
|
||||
- `"domain"`:就是这次筛选流量的 **【依据】** 是 **【域名】** (而不再是入站 tag)
|
||||
- `"geosite"`:就是 `Xray` 会去 `geosite.dat` 文件中寻找 **【符合条件的域名】**
|
||||
- `"category-ads-all"`:就是该文件中的 **【所有广告类域名】**
|
||||
- `"cn"`:就是该文件中的 **【中国域名】**
|
||||
- `"geolocation-!cn"`:就是该文件中的 **【非中国域名】**
|
||||
- `"domain"`: The **[basis]** for filtering traffic this time is **[domain name]** (not inbound tag)
|
||||
- `"geosite"`: `Xray` will search for **[qualified domain names]** in the `geosite.dat` file
|
||||
- `"category-ads-all"`: **[all advertising domain names]** in the file
|
||||
- `"cn"`: **[Chinese domain names]** in the file
|
||||
- `"geolocation-!cn"`: **[non-Chinese domain names]** in the file
|
||||
-
|
||||
Combined with these instructions, the configuration in 3.3 is translated into plain language:
|
||||
|
||||
结合这些说明,3.3 中的配置用大白话翻译就是:
|
||||
1. APP attempts to access the traffic of the foreign domain name `"domain": "geolocation-!cn"`, and it is forwarded to the VPS through `[proxy-out-vless]`
|
||||
|
||||
1. APP 试图访问国外域名 `"domain": "geolocation-!cn"` 的流量,通过 `[proxy-out-vless]` 出站,转发至 VPS
|
||||
2. APP 试图访问国外域名广告域名 `"domain": "geosite:category-ads-all"` 的流量,通过 `[block]` 出站,转发至黑洞进行屏蔽
|
||||
3. APP 试图访问国内域名 `"domain": "geosite:cn"` 的流量,通过 `[direct-out]` 出站,自由离开完成直连
|
||||
2. APP attempts to access the traffic of the foreign domain name advertising domain name `"domain": "geosite:category-ads-all"`, and it is forwarded to the black hole for shielding through `[block]`
|
||||
|
||||
这时,才让【路由功能】的好处稍微得到了一些展现。
|
||||
3. APP attempts to access the traffic of the domestic domain name `"domain": "geosite:cn"`, and it is freely left through `[direct-out]` to complete the direct connection
|
||||
|
||||
### 3.5 所以 `geosite.dat` 到底是什么?不是有个 `GFWList` 吗?
|
||||
At this time, the benefits of the [routing function] are slightly demonstrated.
|
||||
|
||||
你想,这世界上的域名何止千万,如果我们每写一个基于【域名】匹配的路由规则,都要自己收集、手动输入域名,那效率将会何其低下!
|
||||
### 3.5 So what is `geosite.dat`? Isn't there a `GFWList`?
|
||||
|
||||
而如果所有的域名都只有一个种类,`[direct], [proxy], [block]` 只能三选其一,那又是多么的不方便!
|
||||
Think about it, there are tens of millions of domain names in the world. If we have to collect and manually enter domain names every time we write a routing rule based on [domain name] matching, the efficiency will be very low!
|
||||
|
||||
就如关羽需要他的青龙偃月刀,`geosite.dat` 文件便作为【路由功能】驱使的神兵利器横空出世了,它致力于为用户提供成熟完善的【域名分类表】。让用户可以简单的通过 `geosite:xxx` 这种格式方便的调用任何子类,定制符合自身需求的路由规则。
|
||||
If all domain names have only one type, and you can only choose one of the three options, `[direct], [proxy], [block]`, how inconvenient it would be!
|
||||
|
||||
这种模块化结构提供的灵活性,其实远超传统的一揽子防火墙域名列表 [`GFWList`](https://github.com/gfwlist/gfwlist)。为什么这么说呢?比如,你可以指定苹果的域名 `geosite:apple` 和 icloud 相关域名 `geosite:icloud` 通过代理 `[proxy]`,但是苹果的软件域名 `geosite:apple-update` 保持直连 `[direct]` 来保持最大下载速度。
|
||||
Just like Guan Yu needs his Green Dragon Crescent Blade, the `geosite.dat` file has emerged as a magic weapon driven by the [routing function]. It is committed to providing users with a mature and complete [domain name classification table]. Users can simply call any subclass through the `geosite:xxx` format and customize routing rules that meet their needs.
|
||||
|
||||
The flexibility provided by this modular structure is actually far beyond the traditional package firewall domain name list [`GFWList`](https://github.com/gfwlist/gfwlist). Why do you say that? For example, you can specify Apple's domain name `geosite:apple` and icloud-related domain name `geosite:icloud` through the proxy `[proxy]`, but Apple's software domain name `geosite:apple-update` remains directly connected to `[direct]` to maintain the maximum download speed.
|
||||
|
||||
::: warning
|
||||
**注意:** 现在,`geosite.dat` 文件其实有多种选择:
|
||||
**Note:** Now, there are actually multiple options for `geosite.dat` files:
|
||||
|
||||
最初,从 `Victoria Raymond` 主力维护 `Project V` 项目时期,便提供了最初的配套项目:[`domain-list-community`](https://github.com/v2ray/domain-list-community),用来收集、沉淀、分类各种常用的域名类型;
|
||||
Initially, when `Victoria Raymond` was the main maintainer of the `Project V` project, she provided the initial supporting project: [`domain-list-community`](https://github.com/v2ray/domain-list-community), which was used to collect, precipitate, and classify various commonly used domain name types;
|
||||
|
||||
之后,随着 V 姐突然消失导致 `Project V` 的原项目开发陷入停滞,`v2fly` 社区维护并持续更新了社区版本的 [`domain-list-community`](https://github.com/v2fly/domain-list-community);
|
||||
Afterwards, with the sudden disappearance of Sister V, the development of the original project of `Project V` stagnated, and the `v2fly` community maintained and continuously updated the community version of [`domain-list-community`](https://github.com/v2fly/domain-list-community);
|
||||
|
||||
同时,[@Loyalsoldier](Loyalsoldier) 维护了其个人修改增强的路由规则文件 [v2ray-rules-dat](https://github.com/Loyalsoldier/v2ray-rules-dat),提供了诸多不同的选择和分类逻辑;
|
||||
At the same time, [@Loyalsoldier](Loyalsoldier) maintained his personally modified and enhanced routing rules file [v2ray-rules-dat](https://github.com/Loyalsoldier/v2ray-rules-dat), providing many different options and classification logic;
|
||||
|
||||
另外,`Project X` 也计划于未来定制维护更适合 `Xray` 使用的路由规则文件 [Xray-rules-dat](https://github.com/XTLS/Xray-rules-dat)。~~(你们看,文件夹都建好了,所以快了快了)~~
|
||||
In addition, `Project X` also plans to customize and maintain a routing rule file [Xray-rules-dat](https://github.com/XTLS/Xray-rules-dat) that is more suitable for `Xray` in the future. ~~(Look, the folders are all built, so it's coming soon)~~
|
||||
|
||||
甚至,你还可以定制自己的 `geosite` 文件,外挂给 `Xray` 使用,但是这个就跑题了,本文不展开。
|
||||
You can even customize your own `geosite` file and plug it into `Xray` for use, but this is off topic and will not be expanded in this article.
|
||||
|
||||
如果你发现有些你遇到的域名没有被合理分类,请向上面的项目们提出 `issue` 甚至提交 `Pull Request` 吧!社区列表社区维护,人人为我我为人人!
|
||||
If you find that some domain names you encounter are not classified reasonably, please raise an `issue` or even submit a `Pull Request` to the above projects! Community list Community maintenance, everyone for me and I for everyone!
|
||||
|
||||
:::
|
||||
|
||||
### 3.6 军师锦囊藏奇兵:一条隐藏的路由规则
|
||||
### 3.6 A hidden weapon in the military strategist's bag: a hidden routing rule
|
||||
|
||||
事实上,当你认真思考上面的规则,不难发现一个问题,我们的所有规则都只规定了【当入站流量 **符合某种条件时** 应该被转发给哪个出站】,那么,如果 `geosite.dat` 文件不全面,我们的入站流量【**不符合任何条件时**】,`Xray` 会怎么处理呢?
|
||||
In fact, when you think carefully about the above rules, it is not difficult to find a problem. All our rules only stipulate [when the inbound traffic **meets certain conditions**, it should be forwarded to which outbound station], then, if the `geosite.dat` file is not comprehensive, our inbound traffic [**does not meet any conditions**], how will `Xray` handle it?
|
||||
|
||||
::: warning 注意
|
||||
如果你认为【不符合条件当然就无法连接啦!】的话,你可要重新思考一下哦。因为只有指定了 `[block]` 规则,才会被导入到 `blackhole` 黑洞协议从而阻断连接
|
||||
::: warning Attention
|
||||
If you think [of course you can't connect if you don't meet the conditions! ], you have to rethink it. Because only when the `[block]` rule is specified will it be imported into the `blackhole` black hole protocol to block the connection
|
||||
:::
|
||||
|
||||
事实上,`Xray` 为了避免路由规则不完全导致的规则混乱,已经贴心的提供了一条隐藏的路由规则:【**当入站流量不符合任何条件时,转发给第一个出站** 】
|
||||
In fact, in order to avoid confusion caused by incomplete routing rules, `Xray` has thoughtfully provided a hidden routing rule: [**When the incoming traffic does not meet any conditions, forward it to the first outbound** ]
|
||||
|
||||
这样,就不会有任何流量被漏掉了。所以,你一定要把你最信赖的心腹大将放在【第一条出站】,让它为你守城护池。
|
||||
In this way, no traffic will be missed. Therefore, you must put your most trusted general in the [first outbound] to let it guard the city for you.
|
||||
|
||||
### 3.7 再看“三分天下”的大地图
|
||||
### 3.7 Look at the big map of "Three-part World"
|
||||
|
||||
因为我们在前面的示例中把 `[proxy-out-vless]` 放在了出站的第一位,所以隐藏规则生效时,流量会通过 `VLESS` 协议被转发至远端的 VPS。因此,`Xray` 此时的完整工作逻辑如下:
|
||||
Because we put `[proxy-out-vless]` in the first outbound in the previous example, when the hidden rule takes effect, the traffic will be forwarded to the remote VPS through the `VLESS` protocol. Therefore, the complete working logic of `Xray` at this time is as follows:
|
||||
|
||||
```mermaid
|
||||
graph LR;
|
||||
|
||||
S(APP数据) .-> I[入站]
|
||||
S(APP data) .-> I[inbound]
|
||||
|
||||
subgraph Xray
|
||||
I --> R[路由] -- "geosite:category-ads-all" --> O1[block]
|
||||
R[路由] -- "geosite:cn" --> O2[direct]
|
||||
R[路由] -- "geosite:geolocation-!cn" --> O3[proxy]
|
||||
R[路由] -. "没有命中规则的流量" .-> O4[第一条出站]
|
||||
I --> R[routing] -- "geosite:category-ads-all" --> O1[block]
|
||||
R[routing] -- "geosite:cn" --> O2[direct]
|
||||
R[routing] -- "geosite:geolocation-!cn" --> O3[proxy]
|
||||
R[routing] -. "Traffic that does not match the rules" .-> O4[First exit]
|
||||
|
||||
end
|
||||
|
||||
O2 .-> D(国内服务器)
|
||||
O2 .-> D(Domestic Server)
|
||||
O3 .-> V(VPS)
|
||||
O4 .-> V(VPS)
|
||||
|
||||
|
@ -356,15 +360,15 @@
|
|||
|
||||
```
|
||||
|
||||
事实上,这就是传统所谓的 **【默认科学上网、国内网站白名单直连】** 的配置。
|
||||
In fact, this is the traditional so-called **[Default scientific Internet access, domestic website whitelist direct connection]** configuration.
|
||||
|
||||
## 4. “三分天下” 之 “蜀魏争雄”
|
||||
## 4. "Three Kingdoms" of "Shu Wei Struggle"
|
||||
|
||||
现在,你已经知道了隐藏的默认路由规则:【**当入站流量不符合任何条件时,转发给第一个出站** 】。这时候,你应该能看出来,究竟是【科学上网】为王,还是【直连】称霸,全看你的第一条出站是什么!
|
||||
Now, you already know the hidden default routing rule: [**When the inbound traffic does not meet any conditions, forward to the first outbound** ]. At this time, you should be able to see whether [Scientific Internet access] is king or [Direct connection] dominates, all depending on what your first outbound is!
|
||||
|
||||
上一步我们已经配置出了 **【默认科学上网、国内网站白名单直连】** 的规则。那么现在只要 **【把直连规则放在第一位】**,就立即变成了正好相反的 **【默认直连、国外网站白名单科学上网】** 规则。
|
||||
In the previous step, we have configured the **[Default scientific Internet access, domestic website whitelist direct connection]** rule. Now, as long as **[Put the direct connection rule first]**, it will immediately become the exact opposite **[Default direct connection, foreign website whitelist scientific Internet access]** rule.
|
||||
|
||||
是不是,非常地简单?
|
||||
Isn't it very simple?
|
||||
|
||||
```json
|
||||
{
|
||||
|
@ -385,22 +389,22 @@
|
|||
}
|
||||
```
|
||||
|
||||
此时,路由规则其实变成了:
|
||||
At this point, the routing rules actually become:
|
||||
|
||||
```mermaid
|
||||
graph LR;
|
||||
|
||||
S(APP数据) .-> I[入站]
|
||||
S(APP data) .-> I[inbound]
|
||||
|
||||
subgraph Xray
|
||||
I --> R[路由] -- "geosite:category-ads-all" --> O1[block]
|
||||
R[路由] -- "geosite:geolocation-!cn" --> O3[proxy]
|
||||
R[路由] -- "geosite:cn" --> O2[direct]
|
||||
R[路由] -. "没有命中规则的流量" .-> O4[第一条出站]
|
||||
I --> R[routing] -- "geosite:category-ads-all" --> O1[block]
|
||||
R[routing] -- "geosite:geolocation-!cn" --> O3[proxy]
|
||||
R[routing] -- "geosite:cn" --> O2[direct]
|
||||
R[routing] -. "Traffic that does not match the rules" .-> O4[First exit]
|
||||
|
||||
end
|
||||
|
||||
O2 .-> D(国内服务器)
|
||||
O2 .-> D(Domestic Server)
|
||||
O3 .-> V(VPS)
|
||||
O4 .-> D
|
||||
|
||||
|
@ -414,12 +418,12 @@
|
|||
|
||||
```
|
||||
|
||||
这就是路由功能的灵活之处了,你可以自由的改变它的顺序来实现不同的设计。
|
||||
This is the flexibility of the routing function. You can freely change its order to achieve different designs.
|
||||
|
||||
至此,我们已经解释完了 **【如何利用 `geosite.dat` 文件,通过路由规则,根据【域名】来分流网络流量】。**
|
||||
So far, we have explained ** [How to use the `geosite.dat` file to divert network traffic according to the [domain name] through routing rules]. **
|
||||
|
||||
## 5. 攻城略池 - 多种路由匹配条件
|
||||
## 5. Attack the city and the pool - multiple routing matching conditions
|
||||
|
||||
请确保你已经读懂了上面的内容,因为这样,你就已经理解了【路由】功能的工作逻辑。有了这个基础,我们就可以继续分析【路由】功能更多更详细的配置方式和匹配条件了。
|
||||
Please make sure you have read the above content, because in this way, you have understood the working logic of the [routing] function. With this foundation, we can continue to analyze more detailed configuration methods and matching conditions of the [routing] function.
|
||||
|
||||
等你看完后面的内容,就完全可以自由的定制属于自己的路由规则啦!还等什么,让我们一起进入 [《路由 (routing) 功能简析(下)》](./routing-lv1-part2.md) 吧!
|
||||
After you finish reading the following content, you can freely customize your own routing rules! What are you waiting for? Let's enter [《Brief Analysis of Routing Function (Part 2)》](./routing-lv1-part2.md) together!
|
||||
|
|
Loading…
Add table
Reference in a new issue