mirror of
https://github.com/XTLS/Xray-docs-next.git
synced 2025-02-22 09:23:14 +03:00
优化反向代理说明文档 (#649)
* Update reverse.md * correct sth --------- Co-authored-by: 风扇滑翔翼 <Fangliding.fshxy@outlook.com>
This commit is contained in:
parent
5bc939536f
commit
e0628a7666
@ -2,16 +2,27 @@
|
||||
|
||||
反向代理可以把服务器端的流量向客户端转发,即逆向流量转发。
|
||||
|
||||
其底层协议为 Mux.cool, 作为一个多路复用协议,它还具有类似 QUIC 的性质,客户端和服务端是对等的,两边都可以新建一个子连接。一般情况情况下只有客户端打开,服务端打开子连接被这里用于发送反向代理请求。
|
||||
|
||||
反向代理的大致工作原理如下:
|
||||
|
||||
- 假设在主机 A 中有一个网页服务器,这台主机没有公网 IP,无法在公网上直接访问。另有一台主机 B,它可以由公网访问。现在我们需要把 B 作为入口,把流量从 B 转发到 A。
|
||||
- 在主机 A 中配置 Xray,称为`bridge`,在 B 中也配置 Xray,称为 `portal`。
|
||||
- `bridge` 会向 `portal` 主动建立连接,此连接的目标地址可以自行设定。`portal` 会收到两种连接,一是由 `bridge` 发来的连接,二是公网用户发来的连接。`portal` 会自动将两类连接合并。于是 `bridge` 就可以收到公网流量了。
|
||||
- `bridge` 在收到公网流量之后,会将其原封不动地发给主机 A 中的网页服务器。当然,这一步需要路由的协作。
|
||||
- 在主机 B 中配置 Xray,接收外部请求,所以称为 `portal` (门户)。
|
||||
- 在主机 A 中配置 Xray,负责将B的转发和网页服务器桥接起来,称为`bridge`。
|
||||
|
||||
- `bridge`
|
||||
- `bridge` 会向 `portal` 主动建立连接以注册反向通道,此连接的目标地址(domain)可以自行设定。
|
||||
- `bridge` 在收到`portal`转发过来的公网流量之后,会将其原封不动地发给主机 A 中的网页服务器。当然,这一步需要路由模块的配置。
|
||||
- `bridge` 收到响应后,也会将响应原封不动地返回给`portal`。
|
||||
|
||||
- `portal`
|
||||
- `portal` 收到请求且domain匹配,则说明是由 `bridge` 发来的响应数据,这条连接会用于建立反向通道。
|
||||
- `portal` 收到请求,domain不匹配,则说明是公网用户发来的连接,这种连接数据会转发给bridge.
|
||||
|
||||
- `bridge` 会根据流量的大小进行动态的负载均衡。
|
||||
|
||||
::: tip
|
||||
反向代理默认已开启 [Mux](../../development/protocols/muxcool/),请不要在其用到的 outbound 上再次开启 Mux。
|
||||
如上所述,反向代理默认已开启 [Mux](../../development/protocols/muxcool/),请不要在其用到的 outbound 上再次开启 Mux。
|
||||
:::
|
||||
|
||||
::: warning
|
||||
@ -22,19 +33,19 @@
|
||||
|
||||
`ReverseObject` 对应配置文件的 `reverse` 项。
|
||||
|
||||
```json
|
||||
```jsonc
|
||||
{
|
||||
"reverse": {
|
||||
"bridges": [
|
||||
{
|
||||
"tag": "bridge",
|
||||
"domain": "test.xray.com"
|
||||
"domain": "reverse-proxy.xray.internal"
|
||||
}
|
||||
],
|
||||
"portals": [
|
||||
{
|
||||
"tag": "portal",
|
||||
"domain": "test.xray.com"
|
||||
"domain": "reverse-proxy.xray.internal"
|
||||
}
|
||||
]
|
||||
}
|
||||
@ -51,10 +62,10 @@
|
||||
|
||||
### BridgeObject
|
||||
|
||||
```json
|
||||
```jsonc
|
||||
{
|
||||
"tag": "bridge",
|
||||
"domain": "test.xray.com"
|
||||
"domain": "reverse-proxy.xray.internal"
|
||||
}
|
||||
```
|
||||
|
||||
@ -64,15 +75,15 @@
|
||||
|
||||
> `domain`: string
|
||||
|
||||
指定一个域名,`bridge` 向 `portal` 建立的连接,都会使用这个域名进行发送。
|
||||
指定一个域名,`bridge` 向 `portal` 建立的连接,都会借助这个域名进行发送。
|
||||
这个域名只作为 `bridge` 和 `portal` 的通信用途,不必真实存在。
|
||||
|
||||
### PortalObject
|
||||
|
||||
```json
|
||||
```jsonc
|
||||
{
|
||||
"tag": "portal",
|
||||
"domain": "test.xray.com"
|
||||
"domain": "reverse-proxy.xray.internal"
|
||||
}
|
||||
```
|
||||
|
||||
@ -82,7 +93,7 @@
|
||||
|
||||
> `domain`: string
|
||||
|
||||
一个域名。当 `portal` 接收到流量时,如果流量的目标域名是此域名,则 `portal` 认为当前连接上 `bridge` 发来的通信连接。而其它流量则会被当成需要转发的流量。`portal` 所做的工作就是把这两类连接进行识别并拼接。
|
||||
一个域名。当 `portal` 接收到流量时,如果流量的目标域名是此域名,则 `portal` 认为当前连接上是 `bridge` 发来的通信连接。而其它流量则会被当成需要转发的流量。`portal` 所做的工作就是把这两类连接进行识别并做对应的转发。
|
||||
|
||||
::: tip
|
||||
一个 Xray 既可以作为 `bridge`,也可以作为 `portal`,也可以同时两者,以适用于不同的场景需要。
|
||||
@ -100,12 +111,12 @@
|
||||
|
||||
反向代理配置:
|
||||
|
||||
```json
|
||||
{
|
||||
```jsonc
|
||||
"reverse": {
|
||||
"bridges": [
|
||||
{
|
||||
"tag": "bridge",
|
||||
"domain": "test.xray.com"
|
||||
"domain": "reverse-proxy.xray.internal"
|
||||
}
|
||||
]
|
||||
}
|
||||
@ -113,18 +124,20 @@
|
||||
|
||||
outbound:
|
||||
|
||||
```json
|
||||
```jsonc
|
||||
{
|
||||
// 转发到网页服务器
|
||||
"tag": "out",
|
||||
"protocol": "freedom",
|
||||
"settings": {
|
||||
"redirect": "127.0.0.1:80" // 将所有流量转发到网页服务器
|
||||
"redirect": "127.0.0.1:80"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
```json
|
||||
```jsonc
|
||||
{
|
||||
// 连接到 portal
|
||||
"protocol": "vmess",
|
||||
"settings": {
|
||||
"vnext": [
|
||||
@ -145,16 +158,20 @@ outbound:
|
||||
|
||||
路由配置:
|
||||
|
||||
```json
|
||||
```jsonc
|
||||
{
|
||||
"rules": [
|
||||
{
|
||||
// bridge 发出的请求,且域名为配置的域名,那么说明这是尝试向 portal 建立反向隧道的请求,
|
||||
// 则路由到 interconn,即连接到 portal
|
||||
"type": "field",
|
||||
"inboundTag": ["bridge"],
|
||||
"domain": ["full:test.xray.com"],
|
||||
"domain": ["full:reverse-proxy.xray.internal"],
|
||||
"outboundTag": "interconn"
|
||||
},
|
||||
{
|
||||
// 从 portal 过来的流量,也会从 bridge 出来,但是不带上面的domain
|
||||
// 则路由到 out,即转发给网页服务器
|
||||
"type": "field",
|
||||
"inboundTag": ["bridge"],
|
||||
"outboundTag": "out"
|
||||
@ -169,12 +186,12 @@ outbound:
|
||||
|
||||
反向代理配置:
|
||||
|
||||
```json
|
||||
{
|
||||
```jsonc
|
||||
"reverse": {
|
||||
"portals": [
|
||||
{
|
||||
"tag": "portal",
|
||||
"domain": "test.xray.com" // 必须和 bridge 的配置一样
|
||||
"domain": "reverse-proxy.xray.internal" // 必须和 bridge 的配置一样
|
||||
}
|
||||
]
|
||||
}
|
||||
@ -182,8 +199,9 @@ outbound:
|
||||
|
||||
inbound:
|
||||
|
||||
```json
|
||||
```jsonc
|
||||
{
|
||||
// 直接接收来自公网的请求
|
||||
"tag": "external",
|
||||
"port": 80,
|
||||
"protocol": "dokodemo-door",
|
||||
@ -195,10 +213,11 @@ inbound:
|
||||
}
|
||||
```
|
||||
|
||||
```json
|
||||
```jsonc
|
||||
{
|
||||
"port": 1024,
|
||||
// 接收来自 bridge 尝试建立反向隧道的请求
|
||||
"tag": "interconn",
|
||||
"port": 1024,
|
||||
"protocol": "vmess",
|
||||
"settings": {
|
||||
"clients": [
|
||||
@ -212,15 +231,20 @@ inbound:
|
||||
|
||||
路由配置:
|
||||
|
||||
```json
|
||||
```jsonc
|
||||
{
|
||||
"rules": [
|
||||
{
|
||||
// 如果入站是 external,说明是来自公网的请求,
|
||||
// 则路由到 portal, 最终会转发给 bridge
|
||||
"type": "field",
|
||||
"inboundTag": ["external"],
|
||||
"outboundTag": "portal"
|
||||
},
|
||||
{
|
||||
// 如果来自 interconn 入站,说明是来自 bridge 的尝试建立反向隧道请求,
|
||||
// 则路由到 portal, 最终会转发给对应的公网客户端
|
||||
// 注意:这里进入的请求会带上了前文配置的domain,所以 portal 能够区分两种被路由到 portal 的请求
|
||||
"type": "field",
|
||||
"inboundTag": ["interconn"],
|
||||
"outboundTag": "portal"
|
||||
|
Loading…
x
Reference in New Issue
Block a user