mirror of
https://github.com/XTLS/Xray-docs-next.git
synced 2025-04-04 22:03:35 +03:00
Update routing-lv1-part2.md
This commit is contained in:
parent
ede029d336
commit
894194c3ca
1 changed files with 155 additions and 143 deletions
|
@ -1,73 +1,77 @@
|
|||
# 路由 (routing) 功能简析(下)
|
||||
# Routing Function Analysis (Part 2)
|
||||
|
||||
欢迎继续学习 `Xray` 的【路由】功能!
|
||||
Welcome to continue learning about `Xray`'s [Routing] function!
|
||||
|
||||
在 [《路由 (routing) 功能简析(上)》](./routing-lv1-part1.md) 中,我们已经对【路由】功能的工作逻辑有了清晰的理解,也基于 `geosite.dat` 文件做了简单的域名分流配置。
|
||||
In [《Routing Function Analysis (Part 1)》](./routing-lv1-part1.md), we have a clear understanding of the working logic of the [Routing] function, and have also made a simple domain name diversion configuration based on the `geosite.dat` file.
|
||||
|
||||
如前面所说,域名分流仅仅是【路由】功能的牛刀小试而已。下面就让我们来看看除了域名之外,还什么可以用做分流依据的东西吧!
|
||||
As mentioned earlier, domain name diversion is just a small test of the [Routing] function. Let's take a look at what else can be used as a basis for diversion besides domain names!
|
||||
|
||||
## 5. 攻城略池 - 多种路由匹配条件
|
||||
## 5. Attack the city and the pool - multiple routing matching conditions
|
||||
|
||||
> `[域名], [IP], [协议], etc.`
|
||||
> `[Domain name], [IP], [Protocol], etc.`
|
||||
|
||||
基于域名的分流,已经可以让我们对网络流量进行基本合理的分流。为什么说【基本合理】呢?
|
||||
Diversion based on domain names can already allow us to perform basically reasonable diversion of network traffic. Why is it [basically reasonable]?
|
||||
|
||||
因为【三分天下】虽然是正确的战略方向,但如果只用【域名】来实现这个战略,其实漏洞百出,比如:
|
||||
Because [Dividing the world into three parts] is the correct strategic direction, but if you only use [domain name] to implement this strategy, it is actually full of loopholes, such as:
|
||||
|
||||
1. 我读了《小小白白话文》后,给 VPS 新申请了一个 `proxy.yourdomain.com` 的域名, 我希望它无论如何都代理,`geosite.dat` 里面有吗?
|
||||
2. 如果我还有个 `direct.yourdomain.com` 的域名,我希望它无论如何都直连, `geosite.dat` 里面有吗?
|
||||
3. 本机 `127.0.0.1` 的内部流量,是否正确直连了?(比如 `docker` 等)
|
||||
4. 路由器、本地局域网 `192.168.*.*` 的流量,是否正确直连了?(比如路由器、群晖等)
|
||||
5. 我的国内 DNS 查询(如 `223.5.5.5`)是否正确直连了?
|
||||
6. 我的国外 DNS 查询(如 `1.1.1.1`)是否正确代理了?
|
||||
7. 其他类似国内公共 DNS 一样没有域名、只有 IP 地址的国内网站,是否正确直连了?
|
||||
8. 其他类似国外公共 DNS 一样没有域名、只有 IP 地址的国外网站,是否正确代理了?
|
||||
9. BT 下载的流量,虽然来源是国外,但如果通过 VPS 下载很可能导致违规使用被封,这该如何强制直连?
|
||||
1. After reading "Little White Vernacular", I applied for a new domain name of `proxy.yourdomain.com` for my VPS. I hope it will always be a proxy. Is it in `geosite.dat`?
|
||||
|
||||
2. If I also have a domain name of `direct.yourdomain.com`, I hope it will always be directly connected. Is it in `geosite.dat`?
|
||||
|
||||
3. Is the internal traffic of the local machine `127.0.0.1` connected directly? (For example, `docker`, etc.)
|
||||
|
||||
4. Is the traffic of the router and local LAN `192.168.*.*` connected directly? (For example, router, Synology, etc.)
|
||||
|
||||
5. Is my domestic DNS query (such as `223.5.5.5`) connected directly?
|
||||
6. Is my foreign DNS query (such as `1.1.1.1`) correctly proxied?
|
||||
7. Are other domestic websites that do not have domain names but only IP addresses, like domestic public DNS, correctly proxied?
|
||||
8. Are other foreign websites that do not have domain names but only IP addresses, like foreign public DNS, correctly proxied?
|
||||
9. Although the source of BT download traffic is from abroad, if it is downloaded through VPS, it is likely to be blocked for illegal use. How can I force a direct connection?
|
||||
10. ......
|
||||
|
||||
我之所以说只用【域名分流】会漏洞百出,是因为 `geosite.dat` 文件内只包含了一部分常用的域名。换言之,仅仅依赖它,则会:
|
||||
The reason why I say that only using [Domain Diversion] will be full of loopholes is that the `geosite.dat` file only contains a part of the commonly used domain names. In other words, relying solely on it will:
|
||||
|
||||
- 无法匹配文件里没有的新域名
|
||||
- 无法匹配基于 IP 地址的规则
|
||||
- 无法匹配基于网络协议的规则
|
||||
- Unable to match new domain names that are not in the file
|
||||
- Unable to match rules based on IP addresses
|
||||
- Unable to match rules based on network protocols
|
||||
|
||||
::: warning 啰嗦君
|
||||
那我们来复习一下,当上面这些情况无法匹配时,会发生什么?对了,会触发隐藏路由规则,即【**转发给第一个出站** 】。这其实就是说:
|
||||
::: warning
|
||||
Then let's review what happens when the above situations cannot be matched? By the way, it will trigger the hidden routing rule, that is, [**Forward to the first outbound station** ]. This actually means:
|
||||
|
||||
- 当你的第一个出站是 `[direct-out]` 时:**需要直连的都正确了,但需要代理的则都错误**
|
||||
- 当你的第一个出站是 `[proxy-out-vless]` 时:**需要代理的都正确了,但需要直连的则都错误**
|
||||
:::
|
||||
- When your first outbound station is `[direct-out]`: **All those that need direct connection are correct, but those that need proxy are wrong**
|
||||
- When your first outbound station is `[proxy-out-vless]`: **All those that need proxy are correct, but those that need direct connection are wrong**
|
||||
:::
|
||||
|
||||
所以,我们需要一个办法,让我们鱼与熊掌兼得。这样的办法是否存在呢?**当然存在!** 我们需要的只是【域名】之外更多的【**分流判断依据**】而已。
|
||||
So, we need a way to let us have the best of both worlds. Does such a method exist? **Of course it exists! ** All we need is more [**Diversion Judgment Basis**] besides [Domain Name].
|
||||
|
||||
### 5.1 基于指定域名分流:`[domain], [full]` 等
|
||||
### 5.1 Diversion based on specified domain name: `[domain], [full]`, etc.
|
||||
|
||||
1. 如果需要匹配某个子域名,如 `a-name.yourdomain.com`,我们使用 `full: "a-name.yourdomain.com"`
|
||||
2. 前面的 `问题1` 和 `问题2`,就可以通过给 `proxy.yourdomain.com` 指定 `[proxy-out-vless]` 出站,给 `direct.yourdomain.com` 指定 `[direct-out]` 出站来解决
|
||||
3. 如果需要匹配 `yourdomain.com` 的所有子域名,我们使用 `domain: "yourdomain.com"` 实现
|
||||
4. 上述两个可以成为两个独立的路由规则,达到某些子域名直连,其他子域名代理的配置
|
||||
5. 另外,`[domain]` 还支持正则表达式等匹配方式。详情请参考 [《基础配置模块 - 路由》文档](../../../config/base/routing/)
|
||||
1. If you need to match a subdomain, such as `a-name.yourdomain.com`, we use `full: "a-name.yourdomain.com"`
|
||||
2. The previous `Question 1` and `Question 2` can be solved by specifying `[proxy-out-vless]` outbound for `proxy.yourdomain.com` and `[direct-out]` outbound for `direct.yourdomain.com`
|
||||
3. If you need to match all subdomains of `yourdomain.com`, we use `domain: "yourdomain.com"` to achieve it
|
||||
4. The above two can become two independent routing rules to achieve the configuration of direct connection for some subdomains and proxy for other subdomains
|
||||
5. In addition, `[domain]` also supports matching methods such as regular expressions. For details, please refer to [《Basic Configuration Module - Routing》document](../../../config/base/routing/)
|
||||
|
||||
上述配置如下:
|
||||
The above configuration is as follows:
|
||||
|
||||
```json
|
||||
{
|
||||
"routing": {
|
||||
"domainStrategy": "AsIs",
|
||||
"rules": [
|
||||
// 指定子域名直连
|
||||
// Direct connection to a specified subdomain
|
||||
{
|
||||
"type": "field",
|
||||
"domain": ["full:direct.yourdomain.com"],
|
||||
"outboundTag": "direct-out"
|
||||
},
|
||||
// 指定子域名转发VPS
|
||||
// Specify subdomain forwarding VPS
|
||||
{
|
||||
"type": "field",
|
||||
"domain": ["full:proxy.yourdomain.com"],
|
||||
"outboundTag": "proxy-out-vless"
|
||||
},
|
||||
// 指定泛域名转发VPS
|
||||
// Specify wildcard domain name to forward to VPS
|
||||
{
|
||||
"type": "field",
|
||||
"domain": ["yourdomain.com"],
|
||||
|
@ -78,28 +82,28 @@
|
|||
}
|
||||
```
|
||||
|
||||
### 5.2 基于 IP 文件分流:`geoip.dat`
|
||||
### 5.2 Diversion based on IP file: `geoip.dat`
|
||||
|
||||
除了使用 `geosite.dat` 核心自然也支持直接使用IP进行路由以满足各种需求。
|
||||
In addition to using `geosite.dat`, the core also supports direct use of IP for routing to meet various needs.
|
||||
|
||||
1. 解决前面的 `[问题3], [问题4]`,我们使用 `geoip:private` 类别来指定 `[direct-out]`
|
||||
2. 解决前面的 `[问题7]`,我们使用 `geoip:cn` 类别来指定 `[direct-out]`
|
||||
3. 解决前面的 `[问题8]`,由于 `geoip` 中没有【非中国 IP】这个分类(因为这等于要收集全世界的 IP 段),所以我们用隐藏规则代替,也就是将 `[proxy-out-vless]` 放在第一个出站
|
||||
1. To solve the previous `[problem 3], [problem 4]`, we use the `geoip:private` category to specify `[direct-out]`
|
||||
2. To solve the previous `[problem 7]`, we use the `geoip:cn` category to specify `[direct-out]`
|
||||
3. To solve the previous `[problem 8]`, since there is no [non-Chinese IP] category in `geoip` (because this is equivalent to collecting IP segments from all over the world), we use hidden rules instead, that is, put `[proxy-out-vless]` in the first outbound
|
||||
|
||||
上述配置如下:
|
||||
The above configuration is as follows:
|
||||
|
||||
```json
|
||||
{
|
||||
"routing": {
|
||||
"domainStrategy": "AsIs",
|
||||
"rules": [
|
||||
// 本机内部地址、局域网地址直连
|
||||
// The local address and LAN address are directly connected
|
||||
{
|
||||
"type": "field",
|
||||
"ip": ["geoip:private"],
|
||||
"outboundTag": "direct-out"
|
||||
},
|
||||
// 国内IP集直连
|
||||
// Domestic IP set direct connection
|
||||
{
|
||||
"type": "field",
|
||||
"ip": ["geoip:cn"],
|
||||
|
@ -110,27 +114,28 @@
|
|||
}
|
||||
```
|
||||
|
||||
### 5.3 基于指定 IP 地址分流
|
||||
### 5.3 Diversion based on specified IP address
|
||||
|
||||
与 `geosite.dat` 规则文件十分类似的,我们还有 `geoip.dat` 这个规则文件,它是供【路由功能】驱使的**第二个神兵利器**,它致力于为用户提供成熟完善的【IP 分类表】。让用户可以简单的通过 `geoip:xxx` 这种格式方便的调用任何子类,定制符合自身需求的路由规则 。
|
||||
Similar to the `geosite.dat` rule file, we also have the `geoip.dat` rule file, which is the **second magic weapon** driven by the [routing function]. It is committed to providing users with a mature and complete [IP classification table]. Allow users to simply call any subclass through the `geoip:xxx` format and customize routing rules that meet their needs.
|
||||
|
||||
1. 解决前面的 `[问题5]`,我们使用 `ip: "223.5.5.5"` 来指定 `[direct-out]`
|
||||
2. 解决前面的 `[问题6]`,我们使用 `ip: "1.1.1.1"` 来指定 `[proxy-out-vless]`
|
||||
1. To solve the previous `[problem 5]`, we use `ip: "223.5.5.5"` to specify `[direct-out]`
|
||||
|
||||
上述配置如下:
|
||||
2. To solve the previous `[problem 6]`, we use `ip: "1.1.1.1"` to specify `[proxy-out-vless]`
|
||||
|
||||
The above configuration is as follows:
|
||||
|
||||
```json
|
||||
{
|
||||
"routing": {
|
||||
"domainStrategy": "AsIs",
|
||||
"rules": [
|
||||
// 指定IP地址直连
|
||||
// Direct connection by specifying an IP address
|
||||
{
|
||||
"type": "field",
|
||||
"ip": ["223.5.5.5"],
|
||||
"outboundTag": "direct-out"
|
||||
},
|
||||
// 指定IP地址转发VPS
|
||||
// Specify IP address to forward to VPS
|
||||
{
|
||||
"type": "field",
|
||||
"ip": ["1.1.1.1"],
|
||||
|
@ -141,12 +146,12 @@
|
|||
}
|
||||
```
|
||||
|
||||
### 5.4 基于协议类型分流:`[protocol]` 等
|
||||
### 5.4 Divert based on protocol type: `[protocol]` etc.
|
||||
|
||||
1. 解决前面的 `[问题9]`,我们使用 `"protocol": ["bittorrent"]` 类别来指定 `[direct-out]`
|
||||
1. To solve the previous `[problem 9]`, we use the `"protocol": ["bittorrent"]` category to specify `[direct-out]`
|
||||
|
||||
::: tip
|
||||
你需要打开入站代理中的 `sniffing` 才能使用此种方式分流。
|
||||
You need to turn on `sniffing` in the inbound proxy to use this diversion method.
|
||||
:::
|
||||
|
||||
```json
|
||||
|
@ -154,7 +159,7 @@
|
|||
"routing": {
|
||||
"domainStrategy": "AsIs",
|
||||
"rules": [
|
||||
// 指定 BT 协议直连
|
||||
// Specify BitTorrent protocol direct connection
|
||||
{
|
||||
"type": "field",
|
||||
"protocol": ["bittorrent"],
|
||||
|
@ -165,18 +170,18 @@
|
|||
}
|
||||
```
|
||||
|
||||
### 5.5 基于更多条件的分流
|
||||
### 5.5 Traffic diversion based on more conditions
|
||||
|
||||
到目前位置,我们仍然只讲了【路由功能】分流能力的冰山一角!因为它还支持很多其他的判断条件!我在此简单罗列如下:
|
||||
So far, we have only talked about the tip of the iceberg of the [routing function] traffic diversion capability! Because it also supports many other judgment conditions! I will briefly list them as follows:
|
||||
|
||||
本文已经讲过的:
|
||||
This article has already talked about:
|
||||
|
||||
- `inboundTag`
|
||||
- `domain`
|
||||
- `ip`
|
||||
- `protocol`
|
||||
|
||||
本文尚未讲到的:
|
||||
Not yet covered in this article:
|
||||
|
||||
- `port`
|
||||
- `sourcePort`
|
||||
|
@ -185,14 +190,14 @@
|
|||
- `user`
|
||||
- `attrs`
|
||||
|
||||
但这些内容实在是过多,全部展开就远远不是 `level-1` 的内容了,所以,需要这些复杂条件的朋友,请仔细阅读 [《基础配置模块 - 路由》文档](../../config/base/routing/) 自学哦!有问题就去 TG 群里面问问吧!
|
||||
But there are too many contents. If you want to expand them all, it is far from the content of `level-1`. Therefore, friends who need these complex conditions, please read [《Basic Configuration Module - Routing》Document](../../config/base/routing/) carefully and learn by yourself! If you have any questions, please ask in the TG group!
|
||||
|
||||
## 6. “霸业初定”:路由规则整体回顾
|
||||
## 6. "The hegemony is initially determined": a review of the routing rules
|
||||
|
||||
到现在为止,我们已经累积出了一套战略雄伟、战术精准的路由规则,为了避免混乱,现在就对它进行一次完整的整理和回顾。
|
||||
So far, we have accumulated a set of strategically magnificent and tactically precise routing rules. In order to avoid confusion, we will now conduct a complete sorting and review of it.
|
||||
|
||||
::: warning 注意
|
||||
路由生效的顺序是:【从上往下,依次判断】,所以我一般推荐的规则顺序是:
|
||||
::: warning Note
|
||||
The order in which the routing takes effect is: [from top to bottom, judge in turn], so the order of rules I generally recommend is:
|
||||
|
||||
`[1-block] --> [2-direct] --> [3-proxy] --> [4-first-outbound]`
|
||||
:::
|
||||
|
@ -202,34 +207,34 @@
|
|||
"routing": {
|
||||
"domainStrategy": "AsIs",
|
||||
"rules": [
|
||||
// [1-block 广告流量屏蔽]
|
||||
// 1.1 广告域名集屏蔽
|
||||
// [1-block Ad traffic blocking]
|
||||
// 1.1 Advertisement domain name set blocking
|
||||
{
|
||||
"type": "field",
|
||||
"domain": ["geosite:category-ads-all"],
|
||||
"outboundTag": "block"
|
||||
},
|
||||
// [2-direct 国内流量直连]
|
||||
// 2.1 国内域名集、指定子域名直连
|
||||
// [2-direct Domestic traffic direct connection]
|
||||
// 2.1 Domestic domain name set, designated subdomain direct connection
|
||||
{
|
||||
"type": "field",
|
||||
"domain": ["geosite:cn", "full:direct.yourdomain.com"],
|
||||
"outboundTag": "direct-out"
|
||||
},
|
||||
// 2.2 本机内部地址+局域网、国内IP、指定IP直连
|
||||
// 2.2 Local internal address + LAN, domestic IP, designated IP direct connection
|
||||
{
|
||||
"type": "field",
|
||||
"ip": ["geoip:private", "geoip:cn", "223.5.5.5"],
|
||||
"outboundTag": "direct-out"
|
||||
},
|
||||
// 2.3 BT协议流量直连
|
||||
// 2.3 BT protocol traffic direct connection
|
||||
{
|
||||
"type": "field",
|
||||
"protocol": ["bittorrent"],
|
||||
"outboundTag": "direct-out"
|
||||
},
|
||||
// [3-proxy 国外流量转发VPS]
|
||||
// 3.1 国外域名集、指定子域名、指定泛域名转发VPS
|
||||
// [3-proxy Foreign traffic forwarding VPS]
|
||||
// 3.1 Foreign domain name set, designated subdomain, designated wildcard domain forwarding VPS
|
||||
{
|
||||
"type": "field",
|
||||
"domain": [
|
||||
|
@ -239,46 +244,46 @@
|
|||
],
|
||||
"outboundTag": "proxy-out-vless"
|
||||
},
|
||||
// 3.2 指定IP转发VPS
|
||||
// 3.2 Specify IP forwarding VPS
|
||||
{
|
||||
"type": "field",
|
||||
"ip": ["1.1.1.1"],
|
||||
"outboundTag": "proxy-out-vless"
|
||||
}
|
||||
// [4-default-routing 第一条出站]
|
||||
// 没有匹配到任何规则的流量,默认使用第一条出站处理
|
||||
// [4-default-routing First exit]
|
||||
// Traffic that does not match any rule is processed by the first outbound rule by default.
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
此时,路由规则其实变成了:
|
||||
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]
|
||||
I --> R[routing] -- "geosite:category-ads-all" --> O1[block]
|
||||
|
||||
R[路由] -- "geosite:cn" --> O2[direct]
|
||||
R[路由] -- "direct.yourdomain.com" --> O2[direct]
|
||||
R[路由] -- "geoip:private" --> O2[direct]
|
||||
R[路由] -- "geoip:cn" --> O2[direct]
|
||||
R[路由] -- "ip:223.5.5.5" --> O2[direct]
|
||||
R[路由] -- "protocol:bittorrent" --> O2[direct]
|
||||
R[routing] -- "geosite:cn" --> O2[direct]
|
||||
R[routing] -- "direct.yourdomain.com" --> O2[direct]
|
||||
R[routing] -- "geoip:private" --> O2[direct]
|
||||
R[routing] -- "geoip:cn" --> O2[direct]
|
||||
R[routing] -- "ip:223.5.5.5" --> O2[direct]
|
||||
R[routing] -- "protocol:bittorrent" --> O2[direct]
|
||||
|
||||
R[路由] -- "geosite:geolocation-!cn" --> O3[proxy]
|
||||
R[路由] -- "proxy.yourdomain.com" --> O3[proxy]
|
||||
R[路由] -- "*.yourdomain.com" --> O3[proxy]
|
||||
R[路由] -- "ip:1.1.1.1" --> O3[proxy]
|
||||
R[routing] -- "geosite:geolocation-!cn" --> O3[proxy]
|
||||
R[routing] -- "proxy.yourdomain.com" --> O3[proxy]
|
||||
R[routing] -- "*.yourdomain.com" --> O3[proxy]
|
||||
R[routing] -- "ip:1.1.1.1" --> O3[proxy]
|
||||
|
||||
R[路由] -. "没有命中规则的流量" .-> O4[第一条出站]
|
||||
R[routing] -. "Traffic that does not match the rules" .-> O4[First exit]
|
||||
|
||||
end
|
||||
|
||||
O2 .-> D(国内服务器)
|
||||
O2 .-> D(Domestic Server)
|
||||
O3 .-> V(VPS)
|
||||
|
||||
O1:::redclass
|
||||
|
@ -291,20 +296,21 @@
|
|||
|
||||
```
|
||||
|
||||
至于第一条出站是 `[direct-out]` 还是 `[proxy-out-vless]`,这就全看你的需求了。
|
||||
As for whether the first outbound is `[direct-out]` or `[proxy-out-vless]`, it all depends on your needs.
|
||||
|
||||
## 7. 路由配置常见错误
|
||||
## 7. Common mistakes in routing configuration
|
||||
|
||||
请大家注意看,我上面每一条路由规则,都是一个独立的匹配依据,只有这样才能确保生效。而新人在自定义路由规则时常犯的一个错误就是:**在一条规则内同时匹配了多种不同的匹配依据,造成匹配无效。**
|
||||
Please note that each of my routing rules above is an independent matching basis, only in this way can it be guaranteed to take effect. A common mistake made by newcomers when customizing routing rules is: **Matching multiple different matching criteria in one rule at the same time, resulting in invalid matching. **
|
||||
|
||||
比如,他希望实现的配置是:
|
||||
For example, the configuration he hopes to achieve is:
|
||||
|
||||
1. 自己的 `direct.yourdomain.com` 直连
|
||||
2. 国内 DNS 查询(如 `223.5.5.5`)直连
|
||||
1. Direct connection to his own `direct.yourdomain.com`
|
||||
|
||||
### 7.1 错误示范
|
||||
2. Direct connection to domestic DNS query (such as `223.5.5.5`)
|
||||
|
||||
为了实现上面的目标,他写出了以下路由规则:
|
||||
### 7.1 Error demonstration
|
||||
|
||||
In order to achieve the above goal, he wrote the following routing rules:
|
||||
|
||||
```json
|
||||
{
|
||||
|
@ -322,19 +328,20 @@
|
|||
}
|
||||
```
|
||||
|
||||
你能看出这里面的错误吗?乍一看,似乎是对的?
|
||||
Can you spot the error here? At first glance, it seems correct?
|
||||
|
||||
::: warning Note
|
||||
**In the same rule, each basis must be established at the same time for the match to succeed**, the logical relationship is `and`, not `or`.
|
||||
|
||||
::: warning 注意
|
||||
**同一个规则之内,各个依据需要同时成立,才会匹配成功**,逻辑关系是 `和`,而不是 `或`。
|
||||
:::
|
||||
|
||||
换言之,这条规则的意思是:【当你访问的 `目标 = direct.yourdomain.com`, **并且** 同时还满足 `目标 = 223.5.5.5` 时,`Xray` 才会将流量转发给 `[direct-out]` 直连出站】
|
||||
In other words, this rule means: [When you visit `target = direct.yourdomain.com`, **and** it also satisfies `target = 223.5.5.5`, `Xray` will forward the traffic to `[direct-out]` direct connection outbound]
|
||||
|
||||
很显然,一个目标不可能同时等于两个不同的值,所以这不但是一个永远不可能实现的无效规则,更与原本的目标风马牛不相及。
|
||||
Obviously, a target cannot be equal to two different values at the same time, so this is not only an invalid rule that can never be implemented, but also has nothing to do with the original goal.
|
||||
|
||||
### 7.2 正确示范
|
||||
### 7.2 Correct Demonstration
|
||||
|
||||
正确示范,自然就是将不同的匹配依据独立出来:
|
||||
Correct demonstration is naturally to separate different matching criteria:
|
||||
|
||||
```json
|
||||
{
|
||||
|
@ -356,78 +363,83 @@
|
|||
}
|
||||
```
|
||||
|
||||
其实,第 6 点已经是我整理过的规则了,原则就是【相同的匹配依据可以合并,不同的匹配依据保持独立】。
|
||||
In fact, point 6 is the rule I have sorted out. The principle is [the same matching criteria can be merged, and different matching criteria remain independent].
|
||||
|
||||
## 8. 明修栈道、暗渡陈仓
|
||||
## 8. Repairing the plank road in the open and crossing Chencang in secret
|
||||
|
||||
> `[domain]` 转化 `[ip]` 的密道:`domainStrategy`
|
||||
> The secret way of converting `[domain]` to `[ip]`: `domainStrategy`
|
||||
|
||||
我们在 5.4 中提交了多种流量判断的【依据】,其中一种是域名 `[domain]`、一种是 `[IP]`。
|
||||
In 5.4, we submitted multiple [basis] for traffic judgment, one of which is the domain name `[domain]` and the other is `[IP]`.
|
||||
|
||||
如果你初步了解过 DNS 的运作过程,就会知道,我们对一个域名 `[domain]` 发起访问请求时,其实需要先向 `DNS` 发起请求来解析域名 `[domain]` 对应的 `[IP]`,在得到 `[IP]` 后再向它发起实际请求。
|
||||
If you have a preliminary understanding of the operation process of DNS, you will know that when we initiate an access request to a domain name `[domain]`, we actually need to initiate a request to `DNS` to resolve the `[IP]` corresponding to the domain name `[domain]`, and then initiate an actual request to it after obtaining the `[IP]`.
|
||||
|
||||
所以,面对入站的一次域名请求,`Xray` 其实有两次机会去判断它的类型。那么,究竟是否要用这两次机会呢?这就是由 `domainStrategy` 这个配置来决定的。它有三个选项:
|
||||
Therefore, facing an incoming domain name request, `Xray` actually has two opportunities to determine its type. So, should we use these two opportunities? This is determined by the configuration of `domainStrategy`. It has three options:
|
||||
|
||||
- `AsIs`
|
||||
- `IPIfNonMatch`
|
||||
- `IPOnDemand`
|
||||
|
||||
按么我们逐个来解释一下:
|
||||
Let's explain them one by one:
|
||||
|
||||
### 8.1 域名策略: `"AsIs"`
|
||||
### 8.1 Domain strategy: `"AsIs"`
|
||||
|
||||
就是 "As Domain Is",也就是说 【域名什么样,就什么样,不多折腾】。
|
||||
It means "As Domain Is", which means [Domain is what it is, no more trouble].
|
||||
|
||||
简单粗暴理解就是说【仅用 `[domain]` 来匹配】。
|
||||
A simple and rough understanding is [match only with `[domain]`].
|
||||
|
||||
::: tip
|
||||
`AsIs` 的实际意义为 【如原先所示,不加修改】,🍉 老师这里描述的不是很恰当。
|
||||
The actual meaning of `AsIs` is [as originally shown, without modification]. 🍉 The teacher's description here is not very appropriate.
|
||||
:::
|
||||
|
||||
这个方式的处理都在 `Xray` 内部完成,没有与外界的数据往来,所以速度最快。它的兜底策略也很清晰:即前面所说的、无法匹配的域名自动转入第一条出站处理。所以,对于常规使用路由功能这最推荐的策略。
|
||||
This method is processed inside `Xray`, without data exchange with the outside world, so the speed is the fastest. Its bottom-line strategy is also very clear: that is, the domain name that cannot be matched mentioned above is automatically transferred to the first outbound processing. Therefore, this is the most recommended strategy for regular use of routing functions.
|
||||
|
||||
### 8.2 域名策略: `"IPIfNonMatch"`
|
||||
### 8.2 Domain Name Strategy: `"IPIfNonMatch"`
|
||||
|
||||
就是 "lookup IP if (there's) no matching rule",也就是说【如果其他所有规则都匹配不上,那就转化成 `IP` 去匹配 `IP` 规则】。
|
||||
It means "lookup IP if (there's) no matching rule", which means [if all other rules cannot be matched, then convert it to `IP` to match the `IP` rule].
|
||||
|
||||
简单粗暴理解就是说【先把访问目标和其他所有类型规则匹配,如果匹配不上,那就通过 `DNS` 查询转化成 `IP`,再从头和所有规则匹配一次】。
|
||||
In simple terms, it means [match the access target with all other types of rules first. If it cannot be matched, convert it to `IP` through `DNS` query, and then match it with all rules again from the beginning].
|
||||
|
||||
该策略下没有命中任何规则的这一部分域名,会需要再经历 `DNS` 查询过程、以及第二轮规则匹配的过程,其耗时会多于 `AsIs` 策略,所以并不是首选推荐的策略。
|
||||
Under this strategy, the domain names that do not match any rules will need to go through the `DNS` query process and the second round of rule matching process, which will take more time than the `AsIs` strategy, so it is not the preferred recommended strategy.
|
||||
|
||||
### 8.3 域名策略: `"IPOnDemand"`
|
||||
### 8.3 Domain Name Strategy: `"IPOnDemand"`
|
||||
|
||||
这里其实说 `Demand IP` 更准确些,也就是说【当匹配时碰到任何基于 IP 的规则,将域名立即解析为 IP 进行匹配】。
|
||||
It is more accurate to say `Demand IP` here, which means [when matching any IP-based rules, the domain name will be immediately resolved to IP for matching].
|
||||
|
||||
简单粗暴理解就是说【只要路由规则中有 `IP` 类规则,那么所有基于域名 `[domain]` 的请求都要解析成 `[IP]` 然后去匹配 `[IP]` 类规则】。
|
||||
A simple and rough understanding is that [as long as there is an `IP` class rule in the routing rules, all requests based on the domain name `[domain]` must be resolved into `[IP]` and then matched against the `[IP]` class rule].
|
||||
|
||||
它要对所有首次域名访问进行 `DNS` 解析,所以首次查询比较耗时。虽然由于 `Xray` 中 `DNS` 缓存机制的存在,后续对相同域名的访问速度会重回巅峰,但总体来说也不是首选推荐的策略。
|
||||
It needs to perform `DNS` resolution for all first-time domain name accesses, so the first query is time-consuming. Although the subsequent access speed to the same domain name will return to its peak due to the existence of the `DNS` caching mechanism in `Xray`, it is not the preferred strategy in general.
|
||||
|
||||
::: warning 啰嗦君
|
||||
`domainStrategy` 仅对域名生效,不要搞混了哦~
|
||||
::: warning
|
||||
`domainStrategy` is only effective for domain names, don't get confused~
|
||||
:::
|
||||
|
||||
## 9. 思考题
|
||||
## 9. Thinking questions
|
||||
|
||||
迄今为止,我们都是在【单入站】和【单出站】的基础上,讲解【路由】内部的各种配置逻辑。
|
||||
So far, we have explained the various configuration logics inside [routing] based on [single inbound] and [single outbound].
|
||||
|
||||
但是,如你所知,`Xray` 本身是支持多端口,多协议的。那么,如果我问你:
|
||||
However, as you know, `Xray` itself supports multiple ports and multiple protocols. So, if I ask you:
|
||||
|
||||
1. 我希望 `VLESS` 协议将我日常的网页浏览和 APP 流量转发给美国的大流量服务器
|
||||
2. 我希望 `trojan` 协议将我的所有 Netflix 流量转发给日本的服务器解锁各种二次元
|
||||
3. 我希望 `shadowsocks` 协议将我所有的游戏流量转发给香港的服务器达到最低的延迟
|
||||
4. 我希望有一个独立的端口,能够把 `telegram` 的流量全都转发给 VPS
|
||||
5. 我希望有一个独立的端口,能够把 `bittorrent` 下载流量全都转发给欧洲大盘鸡
|
||||
6. 我希望......
|
||||
1. I hope that the `VLESS` protocol will forward my daily web browsing and APP traffic to the high-traffic server in the United States
|
||||
|
||||
这些想法,是否能通过【路由】功能配置实现呢?
|
||||
2. I hope that the `trojan` protocol will forward all my Netflix traffic to the Japanese server to unlock various ACG
|
||||
|
||||
答案当然是 **【完全可以】** 啦! 但是这些对于 `level-1` 来说已经超纲了,就留给各位自由的探索吧!
|
||||
3. I hope that the `shadowsocks` protocol will forward all my game traffic to the Hong Kong server to achieve the lowest latency
|
||||
|
||||
## 10. 结语
|
||||
4. I hope there is a separate port to forward all `telegram` traffic to the VPS
|
||||
|
||||
至此,`Xray` 的【路由】功能就介绍完了。希望本文能够对你理解 `Xray` 的灵活有所帮助。
|
||||
5. I hope there is a separate port to forward all `bittorrent` download traffic to the European Big Plate Chicken
|
||||
|
||||
## 11. 尾注
|
||||
6. I hope...
|
||||
|
||||
- 现在你可以重新阅读一遍 [路由](../../config/routing.md),看看是否有更加深刻的理解。
|
||||
Can these ideas be implemented through the [routing] function configuration?
|
||||
|
||||
The answer is of course **[absolutely yes]**! But these are beyond the scope of `level-1`, so I will leave it to you to explore freely!
|
||||
|
||||
## 10. Conclusion
|
||||
|
||||
So far, the [routing] function of `Xray` has been introduced. I hope this article can help you understand the flexibility of `Xray`.
|
||||
|
||||
## 11. Endnote
|
||||
|
||||
- Now you can re-read [routing](../../config/routing.md) to see if you have a deeper understanding.
|
||||
- 🍉🍉🍉🍉🍉 :D
|
||||
|
|
Loading…
Add table
Reference in a new issue