mirror of
https://github.com/XTLS/Xray-docs-next.git
synced 2026-09-22 22:38:05 +03:00
Advanced Documentation: VLESS Reverse Proxy Examples (#846)
This commit is contained in:
Meow
@@ -246,6 +246,10 @@ export const sidebar: DefaultTheme.Config["sidebar"] = {
|
||||
{
|
||||
text: "Traffic Statistics",
|
||||
link: "/en/document/level-2/traffic_stats.md"
|
||||
},
|
||||
{
|
||||
text: "VLESS Reverse Proxy",
|
||||
link: "/en/document/level-2/vless_reverse.md"
|
||||
}
|
||||
]
|
||||
}
|
||||
|
||||
@@ -216,7 +216,11 @@ export const sidebar: DefaultTheme.Config["sidebar"] = {
|
||||
text: "通过 Cloudflare Warp 增强代理安全性",
|
||||
link: "/document/level-2/warp.md"
|
||||
},
|
||||
{ text: "流量统计", link: "/document/level-2/traffic_stats.md" }
|
||||
{ text: "流量统计", link: "/document/level-2/traffic_stats.md" },
|
||||
{
|
||||
text: "VLESS 反向代理",
|
||||
link: "/document/level-2/vless_reverse.md"
|
||||
}
|
||||
]
|
||||
}
|
||||
],
|
||||
|
||||
@@ -279,6 +279,10 @@ export const sidebar: DefaultTheme.Config["sidebar"] = {
|
||||
{
|
||||
text: "Статистика трафика",
|
||||
link: "/ru/document/level-2/traffic_stats.md"
|
||||
},
|
||||
{
|
||||
text: "Обратный прокси VLESS",
|
||||
link: "/ru/document/level-2/vless_reverse.md"
|
||||
}
|
||||
]
|
||||
}
|
||||
|
||||
@@ -120,12 +120,10 @@ XTLS 仅在以下搭配下可用
|
||||
|
||||
> `reverse`: struct
|
||||
|
||||
VLESS 极简反向代理配置，和核心内部自带的的通用反向代理作用相同但是配置更简单。
|
||||
VLESS 极简反向代理配置。
|
||||
|
||||
存在此项代表来自该用户的连接可以被用作可以用于建立反向代理隧道，同时禁用普通的正向代理用途。
|
||||
|
||||
当前写法
|
||||
|
||||
```json
|
||||
"reverse": {
|
||||
"tag": "r-outbound"
|
||||
@@ -135,3 +133,7 @@ VLESS 极简反向代理配置，和核心内部自带的的通用反向代理
|
||||
`tag` 为该反向代理的出站代理 tag. 使用路由将流量路由到该出站将会透过反向代理转发到连入的客户端路由系统中(客户端配置详见 VLESS 出站).
|
||||
|
||||
当有多个不同的连接(可以来自不同的设备)接入时核心会对每个请求随机选择一条派发反向代理数据。
|
||||
|
||||
::: tip
|
||||
完整教程：[VLESS 反向代理示例](../../document/level-2/vless_reverse.md)
|
||||
:::
|
||||
|
||||
@@ -105,12 +105,10 @@ level 的值, 对应 [policy](../policy.md#policyobject) 中 `level` 的值。
|
||||
|
||||
> `reverse`: struct
|
||||
|
||||
VLESS 极简反向代理配置，和核心内部自带的的通用反向代理作用相同但是配置更简单，并且会保留公网端的真实源 IP 信息。
|
||||
VLESS 极简反向代理配置，会保留公网端的真实源 IP 信息。
|
||||
|
||||
存在此项代表该出站可以被用作 VLESS 反向代理出站，其会自动向服务端建立连接注册反向代理隧道。
|
||||
|
||||
当前写法
|
||||
|
||||
```json
|
||||
"reverse": {
|
||||
"tag": "r-inbound",
|
||||
@@ -120,6 +118,10 @@ VLESS 极简反向代理配置，和核心内部自带的的通用反向代理
|
||||
|
||||
`tag` 为该反向代理的入站代理 tag. 当服务端派发反向代理请求时会从使用这个 tag 的入站进入路由系统，使用路由系统将其路由到你需要的出站。
|
||||
|
||||
使用的 UUID 需要是服务端同样配置了 reverse 的 UUID（详见 VLESS 入站）。
|
||||
使用的 UUID 需要是服务端同样配置了 `reverse` 的 UUID（详见 VLESS 入站）。
|
||||
|
||||
`sniffing` 见 [sniffingObject](../inbound.md#sniffingobject) 对从该反向代理进入的请求执行嗅探。
|
||||
|
||||
::: tip
|
||||
完整教程：[VLESS 反向代理示例](../../document/level-2/vless_reverse.md)
|
||||
:::
|
||||
|
||||
@@ -33,3 +33,7 @@ Xray v1.6.5 新增 WireGuard 出站的使用介绍。
|
||||
[Xray 流量统计](./traffic_stats.md) by <img src="https://avatars.githubusercontent.com/u/1588741?s=32" width="32" height="32" alt="a"/> [@yuhan6665](https://github.com/yuhan6665)
|
||||
|
||||
适配 Xray 的流量统计和脚本。
|
||||
|
||||
[VLESS 反向代理](./vless_reverse.md)
|
||||
|
||||
VLESS 反向代理教程。
|
||||
|
||||
@@ -0,0 +1,435 @@
|
||||
# VLESS 反向代理示例
|
||||
|
||||
本文演示如何使用 Xray 的 VLESS 反向代理能力，通过公网服务器把流量送回远程内网。这里给出两种常见用法：
|
||||
|
||||
- `入口转发`：远程端口映射，将公网入口端口映射到远程内网 Web 服务；
|
||||
- `远程回家`：远程内网漫游，用户通过公网服务器中转，回到家里的内网继续访问资源。
|
||||
|
||||
## 入口转发
|
||||
|
||||
远程端口映射，把公网入口端口映射到远程内网 Web 服务。
|
||||
|
||||
### 工作方式
|
||||
|
||||
这个模型里有三个角色：
|
||||
|
||||
- 用户：访问公网入口；
|
||||
- 公网服务器：接收流量，并将其转交给反向代理通道；
|
||||
- 内网设备：主动建立到公网服务器的连接，并在反向通道中接收请求。
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
U[用户]
|
||||
S[公网服务器]
|
||||
I[内网设备]
|
||||
L[内网 Web 服务]
|
||||
|
||||
I -- 主动建立 VLESS 反向连接 --> S
|
||||
U -- 访问公网 443 --> S
|
||||
S -- 通过 reverse 通道转发 --> I
|
||||
I -- 改写目标并转发 --> L
|
||||
```
|
||||
|
||||
可以简单理解为：
|
||||
|
||||
1. 内网设备先主动连接到公网服务器。
|
||||
2. 公网服务器保留这条反向通道。
|
||||
3. 用户访问公网服务器上的 `443` 入口。
|
||||
4. 公网服务器把请求通过反向通道送回内网设备。
|
||||
5. 内网设备再把目标改写到实际 Web 服务。
|
||||
|
||||
### 配置思路
|
||||
|
||||
VLESS 反向代理的关键点有两个：
|
||||
|
||||
- 在公网侧，为某个 VLESS 客户端声明 `reverse.tag`，这样它会表现为一个可路由的出站；
|
||||
- 在内网侧，为某个 VLESS 出站声明 `reverse.tag`，这样它会主动建立反向连接，并在本地表现为一个可接收流量的入口。
|
||||
|
||||
两端的 `reverse.tag` 不要求同名。它们只是各自配置里的本地标识，真正建立对应关系的是同一条反向连接本身。
|
||||
|
||||
### 公网服务器配置
|
||||
|
||||
下面的示例完成了两件事：
|
||||
|
||||
- 在 `8443` 端口提供一个 VLESS 入站，其中一个 `client` 因为带有 `reverse` 因此可以专门给内网设备建立反向连接；
|
||||
- 在 `443` 端口提供一个 `tunnel` 入站，对外作为 Web 服务入口，并把这个入口收到的流量转发到反向代理通道。
|
||||
|
||||
同时要注意，`freedom` 出站必须保留作为占位。否则一旦 `outbounds` 为空，那么 `reverse-out` 将被视为默认出站，导致未命中规则的流量可能错误地进入反向代理通道。
|
||||
|
||||
```json
|
||||
{
|
||||
"inbounds": [
|
||||
{
|
||||
"listen": "0.0.0.0",
|
||||
"port": 8443,
|
||||
"protocol": "vless",
|
||||
"settings": {
|
||||
"decryption": "mlkem768x25519plus.native.600s.aCF82eKiK6g0DIbv0_nsjbHC4RyKCc9NRjl-X9lyi0k",
|
||||
"clients": [
|
||||
{
|
||||
"id": "ac04551d-6ebf-4685-86e2-17c12491f7f4",
|
||||
"flow": "xtls-rprx-vision",
|
||||
"reverse": {
|
||||
"tag": "reverse-out"
|
||||
}
|
||||
}
|
||||
// ... 其它普通的 client
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"listen": "0.0.0.0",
|
||||
"port": 443,
|
||||
"protocol": "tunnel",
|
||||
"tag": "portal"
|
||||
}
|
||||
],
|
||||
"routing": {
|
||||
"rules": [
|
||||
{
|
||||
"inboundTag": ["portal"],
|
||||
"outboundTag": "reverse-out"
|
||||
}
|
||||
]
|
||||
},
|
||||
"outbounds": [
|
||||
{
|
||||
"protocol": "freedom"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
### 内网设备配置
|
||||
|
||||
内网设备的职责是主动连出，并建立反向通道。这里额外写一组路由，是为了把从 `reverse-in` 进入的流量明确送到指定的 `freedom` 出站，而不是完全依赖默认出站，因为通常你的内网端 Xray 还会承担日常的正向代理功能。
|
||||
|
||||
示例里保留了两个 `freedom` 出站：
|
||||
|
||||
- 一个普通 `freedom`，作为默认直连出口；<br>
|
||||
（假设你有正向代理需求）
|
||||
- 一个带 `tag` 的 `freedom`，专门用于承接从反向代理入口进来的流量。
|
||||
|
||||
假设你的内网 Web 服务监听在 `192.168.1.123:8888`：
|
||||
|
||||
- 需要在出站时把目标地址改写到这个内网地址；
|
||||
- 因为 Xray 存在默认安全策略，还需要在 `finalRules` 里显式放行目标端口。
|
||||
|
||||
```json
|
||||
{
|
||||
// 关于正向代理的其它配置略...
|
||||
"routing": {
|
||||
"rules": [
|
||||
{
|
||||
"inboundTag": ["reverse-in"],
|
||||
"outboundTag": "reverse-direct"
|
||||
}
|
||||
]
|
||||
},
|
||||
"outbounds": [
|
||||
{
|
||||
"protocol": "freedom"
|
||||
},
|
||||
{
|
||||
"protocol": "freedom",
|
||||
"tag": "reverse-direct",
|
||||
"settings": {
|
||||
"redirect": "192.168.1.123:8888",
|
||||
"finalRules": [
|
||||
{
|
||||
"action": "allow",
|
||||
"network": "tcp",
|
||||
"ip": "192.168.1.123",
|
||||
"port": "8888"
|
||||
}
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"protocol": "vless",
|
||||
"settings": {
|
||||
"address": "yourserver.com",
|
||||
"port": 8443,
|
||||
"encryption": "mlkem768x25519plus.native.0rtt.2PcBa3Yz0zBdt4p8-PkJMzx9hIj2Ve-UmrnmZRPnpRk",
|
||||
"id": "ac04551d-6ebf-4685-86e2-17c12491f7f4",
|
||||
"flow": "xtls-rprx-vision",
|
||||
"reverse": {
|
||||
"tag": "reverse-in"
|
||||
}
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
需要注意的是：
|
||||
|
||||
- 公网侧的 `reverse.tag` 会表现为一个出站；
|
||||
- 内网侧的 `reverse.tag` 会表现为一个入口；
|
||||
- 它们不必同名，只需要通过同一条反向连接 `ac04551d...` 对应起来；
|
||||
- 如果你希望内网侧对反向代理进来的流量做更细的控制，可以像上面的示例一样，在 `routing` 中显式指定它该走哪个 `freedom` 出站。
|
||||
- 内网侧还支持 `sniffing` 并且如果你在 freedom 配置了 `proxyProtocol` 甚至可以让 WebServer 看到真实的访客 IP 这里不做展开。
|
||||
|
||||
### 请求流向
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant U as 用户
|
||||
participant S as 公网服务器
|
||||
participant I as 内网设备
|
||||
participant L as 内网 Web 服务
|
||||
|
||||
I->>S: 建立 VLESS 反向连接
|
||||
U->>S: 访问公网 443 端口
|
||||
S->>S: portal 入站命中路由
|
||||
S->>I: 转发到 reverse-out
|
||||
I->>L: 改写到 192.168.1.123:8888
|
||||
L-->>I: 返回响应
|
||||
I-->>S: 经反向通道返回
|
||||
S-->>U: 响应用户
|
||||
```
|
||||
|
||||
这种用法的语义很明确：用户感知到的是“访问公网服务器上的 Web 服务”，而实际处理请求的是远程内网设备上的 Web 服务。
|
||||
|
||||
### 多线路与冗余
|
||||
|
||||
一个内网设备可以建立多条反向连接，例如分别通过不同网络、不同出口，或者不同入口地址连接到公网服务器。只要公网侧把这些连接都视为同一个反向代理目标，就可以形成冗余线路。
|
||||
|
||||
这种方式的好处是：
|
||||
|
||||
- 某条线路暂时不可用时，流量仍可走其他线路；
|
||||
- 公网侧无需为每条线路单独设计一套路由逻辑；
|
||||
- 对内网穿透场景来说，更方便做链路冗余。
|
||||
|
||||
### 安全建议
|
||||
|
||||
- 公网服务器务必保留明确的默认出站，根据你的实际需求可以是 `freedom` 或 `blackhole` 等，避免未命中路由的流量误入反向代理；
|
||||
- 示例配置偏重说明原理，真实公网环境中通常还需要结合更完整的传输与伪装方案。
|
||||
|
||||
## 远程回家
|
||||
|
||||
远程内网漫游，用户通过公网服务器中转，回到家里的内网继续访问资源。
|
||||
|
||||
### 场景说明
|
||||
|
||||
这一部分不是把某个公网端口暴露给外部访问，而是让用户先连接公网服务器上的 VLESS，再借助已经建立好的反向通道，把这个用户的流量继续送回家里的内网设备处理。
|
||||
|
||||
这种用法更接近：
|
||||
|
||||
- 在外漫游时访问家里的局域网资源；
|
||||
- 把特定用户的出口放回家里；
|
||||
- 通过公网服务器中转，回到家庭网络继续访问 NAS、路由器面板、家庭 DNS 或其他内网服务。
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
U[外部用户设备]
|
||||
S[公网服务器]
|
||||
I[家中设备]
|
||||
H[家庭局域网资源]
|
||||
|
||||
I -- 主动建立 VLESS 反向连接 --> S
|
||||
U -- 连接公网服务器上的 VLESS 入口 --> S
|
||||
S -- 用户流量经 reverse 转发 --> I
|
||||
I -- 再访问家庭局域网 --> H
|
||||
```
|
||||
|
||||
### 配置思路
|
||||
|
||||
和第一篇相比，这里最大的区别不在于反向连接本身，而在于公网侧的路由目标：
|
||||
|
||||
- 第一篇是 `inboundTag -> reverse-out`，把某个入口端口映射回内网；
|
||||
- 第二篇是 `user -> reverse-out`，把某个用户的代理流量交给内网设备继续处理。
|
||||
|
||||
也就是说，公网服务器在这里更像一个中转站。用户并不是直接“访问公网端口映射到的服务”，而是“先接入公网服务器上的 VLESS 入口，再从家里的设备继续出发”。
|
||||
|
||||
### 公网服务器配置
|
||||
|
||||
这个示例里：
|
||||
|
||||
- 第一个 UUID 仍然用于家中设备建立反向连接；
|
||||
- 第二个 UUID 用于外部用户接入公网服务器；
|
||||
- 路由根据 `email` 把该用户的流量转发到 `reverse-out`。
|
||||
|
||||
```json
|
||||
{
|
||||
"inbounds": [
|
||||
{
|
||||
"listen": "0.0.0.0",
|
||||
"port": 8443,
|
||||
"protocol": "vless",
|
||||
"settings": {
|
||||
"decryption": "mlkem768x25519plus.native.600s.aCF82eKiK6g0DIbv0_nsjbHC4RyKCc9NRjl-X9lyi0k",
|
||||
"clients": [
|
||||
{
|
||||
"id": "ac04551d-6ebf-4685-86e2-17c12491f7f4",
|
||||
"flow": "xtls-rprx-vision",
|
||||
"reverse": {
|
||||
"tag": "reverse-out"
|
||||
}
|
||||
},
|
||||
{
|
||||
"id": "e8758aff-d830-4d08-a59e-271df65b995a",
|
||||
"flow": "xtls-rprx-vision",
|
||||
"email": "roam@example.com"
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
],
|
||||
"routing": {
|
||||
"rules": [
|
||||
{
|
||||
"user": ["roam@example.com"],
|
||||
"outboundTag": "reverse-out"
|
||||
}
|
||||
]
|
||||
},
|
||||
"outbounds": [
|
||||
{
|
||||
"protocol": "freedom"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
### 家中设备配置
|
||||
|
||||
家中设备依然要主动连接公网服务器建立反向通道。和第一篇不同，这次它不是把流量统一改写到一个固定 Web 服务，而是把来自 `reverse-in` 的流量统一交给家里的直连出口处理。
|
||||
|
||||
下面这个示例假设：
|
||||
|
||||
- 家庭局域网网段为 `192.168.1.0/24`；
|
||||
- 用户设备侧已经负责决定哪些流量需要“回家”；
|
||||
- 家中设备这一侧只负责承接这些流量，并交给家庭网络继续处理。
|
||||
|
||||
```json
|
||||
{
|
||||
"routing": {
|
||||
"rules": [
|
||||
{
|
||||
"inboundTag": ["reverse-in"],
|
||||
"outboundTag": "home-direct"
|
||||
}
|
||||
]
|
||||
},
|
||||
"outbounds": [
|
||||
{
|
||||
"protocol": "freedom"
|
||||
},
|
||||
{
|
||||
"protocol": "freedom",
|
||||
"tag": "home-direct",
|
||||
"settings": {
|
||||
"finalRules": [
|
||||
{
|
||||
"action": "allow",
|
||||
"network": "tcp,udp",
|
||||
"ip": ["192.168.1.0/24"]
|
||||
}
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"protocol": "vless",
|
||||
"settings": {
|
||||
"address": "yourserver.com",
|
||||
"port": 8443,
|
||||
"encryption": "mlkem768x25519plus.native.0rtt.2PcBa3Yz0zBdt4p8-PkJMzx9hIj2Ve-UmrnmZRPnpRk",
|
||||
"id": "ac04551d-6ebf-4685-86e2-17c12491f7f4",
|
||||
"flow": "xtls-rprx-vision",
|
||||
"reverse": {
|
||||
"tag": "reverse-in"
|
||||
}
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
上面这组规则的含义是：
|
||||
|
||||
- 只要流量是从 `reverse-in` 进入的，就转给 `home-direct`；
|
||||
- 因为 Xray 存在默认安全策略，需要用 `finalRules` 显式放通家里内网。如果你只是想访问家里 NAS 那么建议你不要像示例配置那样放通全部 IP，而是按实际需要放通指定 IP 和 Port。
|
||||
|
||||
### 用户设备配置
|
||||
|
||||
用户设备这一侧不建议默认“全量回家”，更常见的做法是只把访问家庭资源的流量拨回去，其余流量仍然本地直连。下面给出一套和上面家中设备配置对应的示例。假设：
|
||||
|
||||
- 用户只想访问家里的 `192.168.1.0/24` 网段；
|
||||
- 其他流量继续本地直连。
|
||||
|
||||
```json
|
||||
{
|
||||
"routing": {
|
||||
"rules": [
|
||||
{
|
||||
"ip": ["192.168.1.0/24"],
|
||||
"outboundTag": "roam-home"
|
||||
}
|
||||
]
|
||||
},
|
||||
"outbounds": [
|
||||
{
|
||||
"protocol": "freedom"
|
||||
},
|
||||
{
|
||||
"protocol": "vless",
|
||||
"tag": "roam-home",
|
||||
"settings": {
|
||||
"address": "yourserver.com",
|
||||
"port": 8443,
|
||||
"encryption": "mlkem768x25519plus.native.0rtt.2PcBa3Yz0zBdt4p8-PkJMzx9hIj2Ve-UmrnmZRPnpRk",
|
||||
"id": "e8758aff-d830-4d08-a59e-271df65b995a",
|
||||
"flow": "xtls-rprx-vision"
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
上面这组规则的含义是：
|
||||
|
||||
- 发往 `192.168.1.0/24` 的流量走 `roam-home`；
|
||||
- 其他流量因为没有命中规则，继续走默认的 `freedom`，也就是本地直连。
|
||||
|
||||
这样用户看起来就像“只把访问家里资源的那部分流量拨回家”，而不是把所有上网流量都先绕到公网服务器再回家中转。
|
||||
|
||||
### 请求流向
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant U as 外部用户设备
|
||||
participant S as 公网服务器
|
||||
participant I as 家中设备
|
||||
participant H as 家庭局域网资源
|
||||
|
||||
I->>S: 建立 VLESS 反向连接
|
||||
U->>S: 使用 roam@example.com 接入公网服务器
|
||||
S->>S: user 路由命中 reverse-out
|
||||
S->>I: 将用户流量送入 reverse 通道
|
||||
I->>H: 访问 NAS / 路由器 / 家庭 DNS / 内网服务
|
||||
H-->>I: 返回响应
|
||||
I-->>S: 经反向通道返回
|
||||
S-->>U: 响应用户
|
||||
```
|
||||
|
||||
### 这种用法和第一篇的区别
|
||||
|
||||
- 第一篇是“把公网一个入口端口映射到远程内网某个固定服务”，无需额外身份验证，全世界谁都可以访问此服务；
|
||||
- 第二篇是“让某个用户先拨入公网的 Xray 服务器，再借道反向代理回家继续访问”；
|
||||
- 第一篇更像远程端口映射，也称内网穿透；
|
||||
- 第二篇更像远程漫游或轻量异地组网。
|
||||
|
||||
### 安全建议
|
||||
|
||||
- 如果有多个漫游用户，建议每个用户使用独立 UUID 或独立标识；
|
||||
- 示例配置为追求简化仅用了 VLESS-enc 实际使用时可能需要使用 REALITY/XHTTP 等伪装流量。
|
||||
|
||||
## 小结
|
||||
|
||||
VLESS 反向代理至少可以覆盖两类场景：
|
||||
|
||||
- 把公网入口端口映射到远程内网固定服务；
|
||||
- 让用户接入公网服务器后再通过反向通道漫游回家。
|
||||
|
||||
两者使用的是同一套反向连接机制，区别主要在公网侧如何路由流量，以及内网侧如何继续处理这些流量。理解这一点之后，就可以按自己的场景在“端口映射”和“远程漫游”之间自由扩展。
|
||||
@@ -121,12 +121,10 @@ XTLS is only available under the following combinations:
|
||||
|
||||
> `reverse`: struct
|
||||
|
||||
VLESS simplified reverse proxy configuration. It functions the same as the core's internal general reverse proxy but with simpler configuration.
|
||||
VLESS simplified reverse proxy configuration.
|
||||
|
||||
The presence of this item indicates that connections from this user can be used to establish a reverse proxy tunnel, while disabling normal forward proxy usage.
|
||||
|
||||
Current syntax:
|
||||
|
||||
```json
|
||||
"reverse": {
|
||||
"tag": "r-outbound"
|
||||
@@ -136,3 +134,7 @@ Current syntax:
|
||||
`tag` is the outbound proxy tag for this reverse proxy. Routing traffic to this outbound using routing rules will forward it through the reverse proxy to the connected client's routing system (see VLESS Outbound for client configuration details).
|
||||
|
||||
When multiple different connections (potentially from different devices) are connected, the core will randomly select one to dispatch reverse proxy data for each request.
|
||||
|
||||
::: tip
|
||||
Full tutorial: [VLESS Reverse Proxy Examples](../../document/level-2/vless_reverse.md)
|
||||
:::
|
||||
|
||||
@@ -105,12 +105,10 @@ The value of `level` corresponds to the value of `level` in [policy](../policy.m
|
||||
|
||||
> `reverse`: struct
|
||||
|
||||
VLESS minimalist reverse proxy configuration. It functions the same as the core's built-in generic reverse proxy but is simpler to configure, and it preserves the real source IP information from the public-facing side.
|
||||
VLESS minimalist reverse proxy configuration. It preserves the real source IP information from the public-facing side.
|
||||
|
||||
The existence of this item indicates that this outbound can be used as a VLESS reverse proxy outbound, and it will automatically establish a connection to the server to register the reverse proxy tunnel.
|
||||
|
||||
Current syntax:
|
||||
|
||||
```json
|
||||
"reverse": {
|
||||
"tag": "r-inbound",
|
||||
@@ -120,6 +118,10 @@ Current syntax:
|
||||
|
||||
`tag` is the inbound proxy tag for this reverse proxy. When the server dispatches a reverse proxy request, it enters the routing system from the inbound using this tag, and the routing system routes it to the outbound you need.
|
||||
|
||||
The UUID used needs to be a UUID that is also configured with reverse on the server side (see VLESS Inbound for details).
|
||||
The UUID used must be one that is also configured with `reverse` on the server side (see VLESS Inbound for details).
|
||||
|
||||
`sniffing` see [sniffingObject](../inbound.md#sniffingobject), performs sniffing on requests entering through this reverse proxy.
|
||||
|
||||
::: tip
|
||||
Full tutorial: [VLESS Reverse Proxy Examples](../../document/level-2/vless_reverse.md)
|
||||
:::
|
||||
|
||||
@@ -33,3 +33,7 @@ Introduction to the use of the WireGuard outbound added in Xray v1.6.5.
|
||||
[Xray Traffic Statistics](./traffic_stats.md) by <img src="https://avatars.githubusercontent.com/u/1588741?s=32" width="32" height="32" alt="a"/> [@yuhan6665](https://github.com/yuhan6665)
|
||||
|
||||
Traffic statistics and scripts adapted for Xray.
|
||||
|
||||
[VLESS Reverse Proxy](./vless_reverse.md)
|
||||
|
||||
VLESS reverse proxy tutorial.
|
||||
|
||||
@@ -0,0 +1,435 @@
|
||||
# VLESS Reverse Proxy Examples
|
||||
|
||||
This article demonstrates how to use Xray's VLESS reverse proxy capability to send traffic back into a remote private network through a public server. Two common use cases are covered here:
|
||||
|
||||
- `Ingress forwarding`: remote port mapping that maps a public entry port to a remote internal Web service;
|
||||
- `Remote return home`: remote private-network roaming where a user relays through a public server and continues accessing resources inside the home network.
|
||||
|
||||
## Ingress Forwarding
|
||||
|
||||
Remote port mapping that maps a public entry port to a remote internal Web service.
|
||||
|
||||
### How It Works
|
||||
|
||||
There are three roles in this model:
|
||||
|
||||
- User: accesses the public entry point;
|
||||
- Public server: receives traffic and hands it over to the reverse proxy tunnel;
|
||||
- Internal device: actively establishes a connection to the public server and receives requests through the reverse tunnel.
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
U[User]
|
||||
S[Public Server]
|
||||
I[Internal Device]
|
||||
L[Internal Web Service]
|
||||
|
||||
I -- Actively establishes a VLESS reverse connection --> S
|
||||
U -- Accesses public port 443 --> S
|
||||
S -- Forwards through the reverse tunnel --> I
|
||||
I -- Rewrites target and forwards --> L
|
||||
```
|
||||
|
||||
In simple terms:
|
||||
|
||||
1. The internal device first initiates a connection to the public server.
|
||||
2. The public server keeps this reverse tunnel open.
|
||||
3. The user accesses port `443` on the public server.
|
||||
4. The public server sends the request back to the internal device through the reverse tunnel.
|
||||
5. The internal device rewrites the target to the actual Web service.
|
||||
|
||||
### Configuration Idea
|
||||
|
||||
There are two key points in VLESS reverse proxying:
|
||||
|
||||
- On the public side, declare `reverse.tag` for a VLESS client so it appears as a routable outbound;
|
||||
- On the internal side, declare `reverse.tag` for a VLESS outbound so it actively establishes the reverse connection and appears locally as an inbound that can receive traffic.
|
||||
|
||||
The `reverse.tag` values on the two sides do not need to match. They are only local identifiers in their respective configurations. The actual correspondence is established by the reverse connection itself.
|
||||
|
||||
### Public Server Configuration
|
||||
|
||||
The example below does two things:
|
||||
|
||||
- It provides a VLESS inbound on port `8443`, where one `client` includes `reverse` and is therefore dedicated to establishing reverse connections for internal devices;
|
||||
- It provides a `tunnel` inbound on port `443`, exposed externally as the Web service entry point, and forwards traffic received there into the reverse proxy tunnel.
|
||||
|
||||
At the same time, note that a `freedom` outbound must remain as a placeholder. Otherwise, if `outbounds` is empty, `reverse-out` will be treated as the default outbound, and traffic that does not match any routing rule may mistakenly enter the reverse proxy tunnel.
|
||||
|
||||
```json
|
||||
{
|
||||
"inbounds": [
|
||||
{
|
||||
"listen": "0.0.0.0",
|
||||
"port": 8443,
|
||||
"protocol": "vless",
|
||||
"settings": {
|
||||
"decryption": "mlkem768x25519plus.native.600s.aCF82eKiK6g0DIbv0_nsjbHC4RyKCc9NRjl-X9lyi0k",
|
||||
"clients": [
|
||||
{
|
||||
"id": "ac04551d-6ebf-4685-86e2-17c12491f7f4",
|
||||
"flow": "xtls-rprx-vision",
|
||||
"reverse": {
|
||||
"tag": "reverse-out"
|
||||
}
|
||||
}
|
||||
// ... other normal clients
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"listen": "0.0.0.0",
|
||||
"port": 443,
|
||||
"protocol": "tunnel",
|
||||
"tag": "portal"
|
||||
}
|
||||
],
|
||||
"routing": {
|
||||
"rules": [
|
||||
{
|
||||
"inboundTag": ["portal"],
|
||||
"outboundTag": "reverse-out"
|
||||
}
|
||||
]
|
||||
},
|
||||
"outbounds": [
|
||||
{
|
||||
"protocol": "freedom"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
### Internal Device Configuration
|
||||
|
||||
The job of the internal device is to connect out actively and establish the reverse tunnel. An extra routing rule is added here so that traffic entering through `reverse-in` is explicitly sent to a specific `freedom` outbound instead of relying entirely on the default outbound, because in practice the Xray instance on the internal side often also handles regular forward-proxy traffic.
|
||||
|
||||
The example keeps two `freedom` outbounds:
|
||||
|
||||
- One normal `freedom`, used as the default direct outbound;<br>
|
||||
(assuming you also need forward-proxying, those other parts of the configuration are omitted here)
|
||||
- One tagged `freedom`, dedicated to handling traffic coming in from the reverse proxy inbound.
|
||||
|
||||
Assume your internal Web service listens on `192.168.1.123:8888`:
|
||||
|
||||
- You need to rewrite the destination address to this internal address on outbound;
|
||||
- Because Xray has a default security policy, you also need to explicitly allow the target port in `finalRules`.
|
||||
|
||||
```json
|
||||
{
|
||||
// Other forward-proxy-related configuration is omitted...
|
||||
"routing": {
|
||||
"rules": [
|
||||
{
|
||||
"inboundTag": ["reverse-in"],
|
||||
"outboundTag": "reverse-direct"
|
||||
}
|
||||
]
|
||||
},
|
||||
"outbounds": [
|
||||
{
|
||||
"protocol": "freedom"
|
||||
},
|
||||
{
|
||||
"protocol": "freedom",
|
||||
"tag": "reverse-direct",
|
||||
"settings": {
|
||||
"redirect": "192.168.1.123:8888",
|
||||
"finalRules": [
|
||||
{
|
||||
"action": "allow",
|
||||
"network": "tcp",
|
||||
"ip": "192.168.1.123",
|
||||
"port": "8888"
|
||||
}
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"protocol": "vless",
|
||||
"settings": {
|
||||
"address": "yourserver.com",
|
||||
"port": 8443,
|
||||
"encryption": "mlkem768x25519plus.native.0rtt.2PcBa3Yz0zBdt4p8-PkJMzx9hIj2Ve-UmrnmZRPnpRk",
|
||||
"id": "ac04551d-6ebf-4685-86e2-17c12491f7f4",
|
||||
"flow": "xtls-rprx-vision",
|
||||
"reverse": {
|
||||
"tag": "reverse-in"
|
||||
}
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
Points to note:
|
||||
|
||||
- On the public side, `reverse.tag` appears as an outbound;
|
||||
- On the internal side, `reverse.tag` appears as an inbound;
|
||||
- They do not need to share the same name, as long as they correspond through the same reverse connection `ac04551d...`;
|
||||
- If you want finer control over traffic coming in through the reverse proxy on the internal side, you can explicitly specify which `freedom` outbound it should use in `routing`, as shown above.
|
||||
- The internal side also supports `sniffing`, and if you configure `proxyProtocol` on `freedom`, your Web server can even see the real visitor IP. That topic is not expanded here.
|
||||
|
||||
### Request Flow
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant U as User
|
||||
participant S as Public Server
|
||||
participant I as Internal Device
|
||||
participant L as Internal Web Service
|
||||
|
||||
I->>S: Establish VLESS reverse connection
|
||||
U->>S: Access public port 443
|
||||
S->>S: portal inbound matches route
|
||||
S->>I: Forward to reverse-out
|
||||
I->>L: Rewrite to 192.168.1.123:8888
|
||||
L-->>I: Return response
|
||||
I-->>S: Return through reverse tunnel
|
||||
S-->>U: Respond to user
|
||||
```
|
||||
|
||||
The meaning of this setup is very clear: the user perceives it as "accessing a Web service on the public server," while the requests are actually processed by the Web service on the remote internal device.
|
||||
|
||||
### Multiple Paths and Redundancy
|
||||
|
||||
An internal device can establish multiple reverse connections, for example through different networks, different uplinks, or different entry addresses to the public server. As long as the public side treats these connections as the same reverse proxy target, they can form redundant paths.
|
||||
|
||||
Benefits of this approach:
|
||||
|
||||
- If one path becomes temporarily unavailable, traffic can still go through the others;
|
||||
- The public side does not need a separate routing design for each path;
|
||||
- It is more convenient for link redundancy in private network penetration scenarios.
|
||||
|
||||
### Security Recommendations
|
||||
|
||||
- The public server should always keep an explicit default outbound. Depending on your needs, it can be `freedom`, `blackhole`, or something similar, so unmatched traffic does not accidentally enter the reverse proxy;
|
||||
- The sample configuration focuses on explaining the mechanism. In a real public network environment, you will usually still want a more complete transport and camouflage setup.
|
||||
|
||||
## Remote Return Home
|
||||
|
||||
Remote private-network roaming where the user relays through a public server and returns to the home network to keep accessing resources.
|
||||
|
||||
### Scenario Description
|
||||
|
||||
This part is not about exposing a public port for external access. Instead, the user first connects to VLESS on the public server, then uses the already-established reverse tunnel to send that user's traffic back to the internal device at home for further handling.
|
||||
|
||||
This usage is closer to:
|
||||
|
||||
- Accessing home LAN resources while roaming outside;
|
||||
- Sending a specific user's egress back through the home network;
|
||||
- Relaying through a public server, then returning to the home network to access a NAS, router panel, home DNS, or other internal services.
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
U[External User Device]
|
||||
S[Public Server]
|
||||
I[Home Device]
|
||||
H[Home LAN Resources]
|
||||
|
||||
I -- Actively establishes a VLESS reverse connection --> S
|
||||
U -- Connects to the VLESS inbound on the public server --> S
|
||||
S -- User traffic forwarded through reverse --> I
|
||||
I -- Accesses the home LAN again --> H
|
||||
```
|
||||
|
||||
### Configuration Idea
|
||||
|
||||
Compared with the first part, the biggest difference here is not the reverse connection itself, but the routing target on the public side:
|
||||
|
||||
- The first part uses `inboundTag -> reverse-out` to map a specific entry port back into the private network;
|
||||
- The second part uses `user -> reverse-out` to hand a specific user's proxied traffic over to the internal device for continued processing.
|
||||
|
||||
In other words, the public server acts more like a relay station here. The user is not directly "accessing a service exposed through a public port mapping," but rather "first connecting to the VLESS inbound on the public server, then continuing from the device at home."
|
||||
|
||||
### Public Server Configuration
|
||||
|
||||
In this example:
|
||||
|
||||
- The first UUID is still used by the home device to establish the reverse connection;
|
||||
- The second UUID is used by the external user to access the public server;
|
||||
- Routing forwards that user's traffic to `reverse-out` based on `email`.
|
||||
|
||||
```json
|
||||
{
|
||||
"inbounds": [
|
||||
{
|
||||
"listen": "0.0.0.0",
|
||||
"port": 8443,
|
||||
"protocol": "vless",
|
||||
"settings": {
|
||||
"decryption": "mlkem768x25519plus.native.600s.aCF82eKiK6g0DIbv0_nsjbHC4RyKCc9NRjl-X9lyi0k",
|
||||
"clients": [
|
||||
{
|
||||
"id": "ac04551d-6ebf-4685-86e2-17c12491f7f4",
|
||||
"flow": "xtls-rprx-vision",
|
||||
"reverse": {
|
||||
"tag": "reverse-out"
|
||||
}
|
||||
},
|
||||
{
|
||||
"id": "e8758aff-d830-4d08-a59e-271df65b995a",
|
||||
"flow": "xtls-rprx-vision",
|
||||
"email": "roam@example.com"
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
],
|
||||
"routing": {
|
||||
"rules": [
|
||||
{
|
||||
"user": ["roam@example.com"],
|
||||
"outboundTag": "reverse-out"
|
||||
}
|
||||
]
|
||||
},
|
||||
"outbounds": [
|
||||
{
|
||||
"protocol": "freedom"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
### Home Device Configuration
|
||||
|
||||
The home device still needs to connect to the public server proactively and establish the reverse tunnel. Unlike the first part, this time it does not rewrite all traffic to a fixed Web service. Instead, it hands all traffic arriving from `reverse-in` to the direct outbound at home for further handling.
|
||||
|
||||
The following example assumes:
|
||||
|
||||
- The home LAN subnet is `192.168.1.0/24`;
|
||||
- The user device is already responsible for deciding which traffic needs to "go back home";
|
||||
- The home device only takes over that traffic and passes it on to the home network for continued processing.
|
||||
|
||||
```json
|
||||
{
|
||||
"routing": {
|
||||
"rules": [
|
||||
{
|
||||
"inboundTag": ["reverse-in"],
|
||||
"outboundTag": "home-direct"
|
||||
}
|
||||
]
|
||||
},
|
||||
"outbounds": [
|
||||
{
|
||||
"protocol": "freedom"
|
||||
},
|
||||
{
|
||||
"protocol": "freedom",
|
||||
"tag": "home-direct",
|
||||
"settings": {
|
||||
"finalRules": [
|
||||
{
|
||||
"action": "allow",
|
||||
"network": "tcp,udp",
|
||||
"ip": ["192.168.1.0/24"]
|
||||
}
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"protocol": "vless",
|
||||
"settings": {
|
||||
"address": "yourserver.com",
|
||||
"port": 8443,
|
||||
"encryption": "mlkem768x25519plus.native.0rtt.2PcBa3Yz0zBdt4p8-PkJMzx9hIj2Ve-UmrnmZRPnpRk",
|
||||
"id": "ac04551d-6ebf-4685-86e2-17c12491f7f4",
|
||||
"flow": "xtls-rprx-vision",
|
||||
"reverse": {
|
||||
"tag": "reverse-in"
|
||||
}
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
What these rules mean:
|
||||
|
||||
- Any traffic entering through `reverse-in` is sent to `home-direct`;
|
||||
- Because Xray has a default security policy, you need `finalRules` to explicitly allow access to the home LAN. If you only want to access a NAS at home, it is recommended not to allow all IPs as shown in the example, but only the specific IPs and ports you actually need.
|
||||
|
||||
### User Device Configuration
|
||||
|
||||
On the user device side, it is generally not recommended to "send everything back home" by default. A more common approach is to send back only the traffic that needs access to home resources, while all other traffic continues to connect directly from the local network. The example below matches the home device configuration above. Assume:
|
||||
|
||||
- The user only wants to access the home subnet `192.168.1.0/24`;
|
||||
- All other traffic continues to go out directly from the local network.
|
||||
|
||||
```json
|
||||
{
|
||||
"routing": {
|
||||
"rules": [
|
||||
{
|
||||
"ip": ["192.168.1.0/24"],
|
||||
"outboundTag": "roam-home"
|
||||
}
|
||||
]
|
||||
},
|
||||
"outbounds": [
|
||||
{
|
||||
"protocol": "freedom"
|
||||
},
|
||||
{
|
||||
"protocol": "vless",
|
||||
"tag": "roam-home",
|
||||
"settings": {
|
||||
"address": "yourserver.com",
|
||||
"port": 8443,
|
||||
"encryption": "mlkem768x25519plus.native.0rtt.2PcBa3Yz0zBdt4p8-PkJMzx9hIj2Ve-UmrnmZRPnpRk",
|
||||
"id": "e8758aff-d830-4d08-a59e-271df65b995a",
|
||||
"flow": "xtls-rprx-vision"
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
What these rules mean:
|
||||
|
||||
- Traffic destined for `192.168.1.0/24` goes through `roam-home`;
|
||||
- Other traffic does not match any rule, so it continues through the default `freedom`, meaning a direct local connection.
|
||||
|
||||
To the user, this feels like "only the traffic for home resources is sent back home," rather than sending all internet traffic through the public server first and then relaying it back home.
|
||||
|
||||
### Request Flow
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant U as External User Device
|
||||
participant S as Public Server
|
||||
participant I as Home Device
|
||||
participant H as Home LAN Resources
|
||||
|
||||
I->>S: Establish VLESS reverse connection
|
||||
U->>S: Connect using roam@example.com
|
||||
S->>S: user route matches reverse-out
|
||||
S->>I: Send user traffic into reverse tunnel
|
||||
I->>H: Access NAS / router / home DNS / internal services
|
||||
H-->>I: Return response
|
||||
I-->>S: Return through reverse tunnel
|
||||
S-->>U: Respond to user
|
||||
```
|
||||
|
||||
### How This Differs from the First Part
|
||||
|
||||
- The first part is "map a public entry port to a fixed service in a remote private network"; without extra authentication, anyone on the internet can access that service.
|
||||
- The second part is "let a specific user first connect to the public Xray server, then use the reverse proxy to continue back home."
|
||||
- The first part is more like remote port mapping, also known as private network penetration;
|
||||
- The second part is more like remote roaming or lightweight cross-site networking.
|
||||
|
||||
### Security Recommendations
|
||||
|
||||
- If there are multiple roaming users, it is recommended that each user have an independent UUID or identifier;
|
||||
- The sample configuration uses only VLESS-enc for simplicity. In real deployments, you may need REALITY, XHTTP, or similar traffic camouflage methods.
|
||||
|
||||
## Summary
|
||||
|
||||
VLESS reverse proxy can cover at least two types of scenarios:
|
||||
|
||||
- Map a public entry port to a fixed service inside a remote private network;
|
||||
- Let users connect to a public server and then roam back home through the reverse tunnel.
|
||||
|
||||
Both use the same reverse connection mechanism. The main difference lies in how the public side routes the traffic and how the private side continues processing it. Once you understand that, you can freely extend the model between "port mapping" and "remote roaming" according to your own needs.
|
||||
@@ -134,12 +134,10 @@ XTLS доступен только в следующих комбинациях
|
||||
|
||||
> `reverse`: struct
|
||||
|
||||
Упрощённая конфигурация обратного прокси VLESS. Имеет то же назначение, что и встроенный в ядро универсальный обратный прокси, но с более простой настройкой.
|
||||
Упрощённая конфигурация обратного прокси VLESS.
|
||||
|
||||
Наличие этого параметра означает, что соединение от данного пользователя может быть использовано для установления туннеля обратного прокси, при этом обычное использование в качестве прямого прокси отключается.
|
||||
|
||||
Текущая запись
|
||||
|
||||
```json
|
||||
"reverse": {
|
||||
"tag": "r-outbound"
|
||||
@@ -149,3 +147,7 @@ XTLS доступен только в следующих комбинациях
|
||||
`tag` — это тег исходящего прокси для данного обратного прокси. Использование маршрутизации для направления трафика на этот исходящий прокси приведет к пересылке данных через обратный прокси в систему маршрутизации подключенного клиента (подробнее о конфигурации клиента см. в разделе об исходящих соединениях VLESS).
|
||||
|
||||
Когда имеется несколько различных подключений (возможно, с разных устройств), ядро будет случайным образом выбирать одно из них для каждого запроса на отправку данных через обратный прокси.
|
||||
|
||||
::: tip
|
||||
Полное руководство: [Примеры обратного проксирования VLESS](../../document/level-2/vless_reverse.md)
|
||||
:::
|
||||
|
||||
@@ -107,12 +107,10 @@ Splice - это функция, предоставляемая ядром Linux,
|
||||
|
||||
> `reverse`: struct
|
||||
|
||||
Упрощённая конфигурация обратного прокси VLESS. Имеет то же назначение, что и встроенный в ядро универсальный обратный прокси, но с более простой настройкой, и при этом сохраняет информацию о реальном исходном IP-адресе со стороны публичной сети.
|
||||
Упрощённая конфигурация обратного прокси VLESS. При этом сохраняет информацию о реальном исходном IP-адресе со стороны публичной сети.
|
||||
|
||||
Наличие этого параметра означает, что данное исходящее соединение может быть использовано как исходящее соединение обратного прокси VLESS. Оно автоматически установит соединение с сервером для регистрации туннеля обратного прокси.
|
||||
|
||||
Текущая запись
|
||||
|
||||
```json
|
||||
"reverse": {
|
||||
"tag": "r-inbound",
|
||||
@@ -125,3 +123,7 @@ Splice - это функция, предоставляемая ядром Linux,
|
||||
Используемый UUID должен совпадать с UUID, для которого на сервере также настроен `reverse` (подробнее см. в разделе о входящих соединениях VLESS).
|
||||
|
||||
`sniffing` см. [sniffingObject](../inbound.md#sniffingobject) — выполняет распознавание (sniffing) запросов, поступающих через этот обратный прокси.
|
||||
|
||||
::: tip
|
||||
Полное руководство: [Примеры обратного проксирования VLESS](../../document/level-2/vless_reverse.md)
|
||||
:::
|
||||
|
||||
@@ -33,3 +33,7 @@
|
||||
[Статистика трафика Xray](./traffic_stats.md) от <img src="https://avatars.githubusercontent.com/u/1588741?s=32" width="32" height="32" alt="a"/> [@yuhan6665](https://github.com/yuhan6665)
|
||||
|
||||
Статистика трафика и скрипты для Xray.
|
||||
|
||||
[Обратный прокси VLESS](./vless_reverse.md)
|
||||
|
||||
Руководство по обратному проксированию VLESS.
|
||||
|
||||
@@ -0,0 +1,435 @@
|
||||
# Примеры обратного проксирования VLESS
|
||||
|
||||
В этой статье показано, как использовать возможность обратного проксирования VLESS в Xray, чтобы через публичный сервер возвращать трафик в удаленную внутреннюю сеть. Ниже рассмотрены два распространенных сценария:
|
||||
|
||||
- `Проброс входа`: удаленный проброс порта, то есть сопоставление публичного входного порта с Web-сервисом в удаленной внутренней сети;
|
||||
- `Удаленно домой`: удаленный роуминг по внутренней сети, когда пользователь проходит через публичный сервер и затем продолжает доступ к ресурсам домашней сети.
|
||||
|
||||
## Проброс Входа
|
||||
|
||||
Удаленный проброс порта, то есть сопоставление публичного входного порта с Web-сервисом в удаленной внутренней сети.
|
||||
|
||||
### Как Это Работает
|
||||
|
||||
В этой модели есть три роли:
|
||||
|
||||
- Пользователь: обращается к публичной точке входа;
|
||||
- Публичный сервер: принимает трафик и передает его в туннель обратного прокси;
|
||||
- Внутреннее устройство: само устанавливает соединение с публичным сервером и принимает запросы через обратный туннель.
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
U[Пользователь]
|
||||
S[Публичный сервер]
|
||||
I[Внутреннее устройство]
|
||||
L[Внутренний Web-сервис]
|
||||
|
||||
I -- Самостоятельно устанавливает обратное VLESS-соединение --> S
|
||||
U -- Обращается к публичному порту 443 --> S
|
||||
S -- Перенаправляет через reverse-туннель --> I
|
||||
I -- Переписывает цель и пересылает --> L
|
||||
```
|
||||
|
||||
Проще говоря:
|
||||
|
||||
1. Внутреннее устройство сначала само подключается к публичному серверу.
|
||||
2. Публичный сервер удерживает этот обратный туннель.
|
||||
3. Пользователь обращается к входу `443` на публичном сервере.
|
||||
4. Публичный сервер отправляет запрос обратно во внутреннее устройство через обратный туннель.
|
||||
5. Внутреннее устройство переписывает цель на реальный Web-сервис.
|
||||
|
||||
### Идея Конфигурации
|
||||
|
||||
В обратном проксировании VLESS есть два ключевых момента:
|
||||
|
||||
- На публичной стороне для одного из клиентов VLESS объявляется `reverse.tag`, и тогда он будет выглядеть как маршрутизируемый outbound;
|
||||
- На внутренней стороне для одного из outbound-соединений VLESS объявляется `reverse.tag`, и тогда оно будет само устанавливать обратное соединение и локально проявляться как inbound, способный принимать трафик.
|
||||
|
||||
Значения `reverse.tag` на обеих сторонах не обязаны совпадать. Это лишь локальные идентификаторы в своих конфигурациях. Реальное соответствие задается самой обратной связью.
|
||||
|
||||
### Конфигурация Публичного Сервера
|
||||
|
||||
Пример ниже делает две вещи:
|
||||
|
||||
- Поднимает inbound VLESS на порту `8443`, где один `client` содержит `reverse` и поэтому специально используется для установления обратных соединений с внутренних устройств;
|
||||
- Поднимает inbound `tunnel` на порту `443`, который снаружи используется как вход Web-сервиса, а весь пришедший туда трафик перенаправляется в туннель обратного прокси.
|
||||
|
||||
Также обратите внимание, что outbound `freedom` нужно оставить как заглушку. Иначе, если `outbounds` окажется пустым, `reverse-out` будет считаться outbound по умолчанию, и трафик, не совпавший ни с одним правилом маршрутизации, может по ошибке попасть в туннель обратного прокси.
|
||||
|
||||
```json
|
||||
{
|
||||
"inbounds": [
|
||||
{
|
||||
"listen": "0.0.0.0",
|
||||
"port": 8443,
|
||||
"protocol": "vless",
|
||||
"settings": {
|
||||
"decryption": "mlkem768x25519plus.native.600s.aCF82eKiK6g0DIbv0_nsjbHC4RyKCc9NRjl-X9lyi0k",
|
||||
"clients": [
|
||||
{
|
||||
"id": "ac04551d-6ebf-4685-86e2-17c12491f7f4",
|
||||
"flow": "xtls-rprx-vision",
|
||||
"reverse": {
|
||||
"tag": "reverse-out"
|
||||
}
|
||||
}
|
||||
// ... остальные обычные client
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"listen": "0.0.0.0",
|
||||
"port": 443,
|
||||
"protocol": "tunnel",
|
||||
"tag": "portal"
|
||||
}
|
||||
],
|
||||
"routing": {
|
||||
"rules": [
|
||||
{
|
||||
"inboundTag": ["portal"],
|
||||
"outboundTag": "reverse-out"
|
||||
}
|
||||
]
|
||||
},
|
||||
"outbounds": [
|
||||
{
|
||||
"protocol": "freedom"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
### Конфигурация Внутреннего Устройства
|
||||
|
||||
Задача внутреннего устройства состоит в том, чтобы само инициировать исходящее соединение и создать обратный туннель. Здесь дополнительно задается маршрут, чтобы трафик, приходящий через `reverse-in`, явно отправлялся в указанный outbound `freedom`, а не целиком зависел от outbound по умолчанию, потому что на практике Xray на внутренней стороне часто еще обслуживает обычный прямой прокси.
|
||||
|
||||
В примере сохранены два outbound `freedom`:
|
||||
|
||||
- Один обычный `freedom`, который используется как outbound прямого подключения по умолчанию;<br>
|
||||
(если вам также нужен прямой прокси, остальные части такой конфигурации здесь опущены)
|
||||
- Один `freedom` с `tag`, специально предназначенный для приема трафика, пришедшего через inbound обратного прокси.
|
||||
|
||||
Предположим, что ваш внутренний Web-сервис слушает на `192.168.1.123:8888`:
|
||||
|
||||
- На outbound нужно переписать целевой адрес на этот внутренний адрес;
|
||||
- Поскольку в Xray действует политика безопасности по умолчанию, целевой порт нужно явно разрешить в `finalRules`.
|
||||
|
||||
```json
|
||||
{
|
||||
// Остальная конфигурация, связанная с прямым прокси, опущена...
|
||||
"routing": {
|
||||
"rules": [
|
||||
{
|
||||
"inboundTag": ["reverse-in"],
|
||||
"outboundTag": "reverse-direct"
|
||||
}
|
||||
]
|
||||
},
|
||||
"outbounds": [
|
||||
{
|
||||
"protocol": "freedom"
|
||||
},
|
||||
{
|
||||
"protocol": "freedom",
|
||||
"tag": "reverse-direct",
|
||||
"settings": {
|
||||
"redirect": "192.168.1.123:8888",
|
||||
"finalRules": [
|
||||
{
|
||||
"action": "allow",
|
||||
"network": "tcp",
|
||||
"ip": "192.168.1.123",
|
||||
"port": "8888"
|
||||
}
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"protocol": "vless",
|
||||
"settings": {
|
||||
"address": "yourserver.com",
|
||||
"port": 8443,
|
||||
"encryption": "mlkem768x25519plus.native.0rtt.2PcBa3Yz0zBdt4p8-PkJMzx9hIj2Ve-UmrnmZRPnpRk",
|
||||
"id": "ac04551d-6ebf-4685-86e2-17c12491f7f4",
|
||||
"flow": "xtls-rprx-vision",
|
||||
"reverse": {
|
||||
"tag": "reverse-in"
|
||||
}
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
Важно понимать следующее:
|
||||
|
||||
- На публичной стороне `reverse.tag` проявляется как outbound;
|
||||
- На внутренней стороне `reverse.tag` проявляется как inbound;
|
||||
- Они не обязаны называться одинаково, главное, чтобы обе стороны соответствовали одной и той же обратной связи `ac04551d...`;
|
||||
- Если вы хотите тоньше управлять трафиком, приходящим через обратный прокси на внутренней стороне, можно, как в примере выше, явно указать в `routing`, через какой `freedom` outbound он должен идти.
|
||||
- На внутренней стороне также поддерживается `sniffing`, а если в `freedom` настроить `proxyProtocol`, ваш Web-сервер сможет видеть реальный IP посетителя. Здесь эту тему не раскрываем.
|
||||
|
||||
### Поток Запроса
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant U as Пользователь
|
||||
participant S as Публичный сервер
|
||||
participant I as Внутреннее устройство
|
||||
participant L as Внутренний Web-сервис
|
||||
|
||||
I->>S: Устанавливает обратное VLESS-соединение
|
||||
U->>S: Обращается к публичному порту 443
|
||||
S->>S: portal inbound попадает под маршрут
|
||||
S->>I: Перенаправляет в reverse-out
|
||||
I->>L: Переписывает в 192.168.1.123:8888
|
||||
L-->>I: Возвращает ответ
|
||||
I-->>S: Возвращает через обратный туннель
|
||||
S-->>U: Отвечает пользователю
|
||||
```
|
||||
|
||||
Смысл такого сценария вполне ясен: для пользователя это выглядит как "доступ к Web-сервису на публичном сервере", но фактически запросы обрабатывает Web-сервис на устройстве в удаленной внутренней сети.
|
||||
|
||||
### Несколько Каналов и Резервирование
|
||||
|
||||
Одно внутреннее устройство может устанавливать несколько обратных соединений, например через разные сети, разные исходящие каналы или разные адреса входа на публичном сервере. Если публичная сторона рассматривает все эти соединения как одну и ту же цель обратного прокси, получается резервирование каналов.
|
||||
|
||||
Преимущества такого подхода:
|
||||
|
||||
- Если один канал временно недоступен, трафик может идти по другим;
|
||||
- На публичной стороне не нужно проектировать отдельную схему маршрутизации для каждого канала;
|
||||
- Для сценариев проброса во внутреннюю сеть так удобнее организовывать резервирование.
|
||||
|
||||
### Рекомендации По Безопасности
|
||||
|
||||
- На публичном сервере обязательно должен оставаться явный outbound по умолчанию. В зависимости от ваших задач это может быть `freedom`, `blackhole` или что-то похожее, чтобы трафик, не совпавший с маршрутами, случайно не попадал в обратный прокси;
|
||||
- Пример конфигурации в первую очередь объясняет принцип. В реальной публичной сети обычно также требуется более полноценная транспортная схема и маскировка.
|
||||
|
||||
## Удаленно Домой
|
||||
|
||||
Удаленный роуминг по внутренней сети, когда пользователь проходит через публичный сервер и возвращается в домашнюю сеть, чтобы продолжать доступ к ресурсам.
|
||||
|
||||
### Описание Сценария
|
||||
|
||||
Здесь речь не о том, чтобы открыть какой-то публичный порт для внешнего доступа. Вместо этого пользователь сначала подключается к VLESS на публичном сервере, а затем с помощью уже установленного обратного туннеля его трафик отправляется обратно на домашнее внутреннее устройство для дальнейшей обработки.
|
||||
|
||||
Этот вариант ближе к следующим сценариям:
|
||||
|
||||
- Доступ к ресурсам домашней локальной сети во время поездок;
|
||||
- Возврат исходящего трафика конкретного пользователя домой;
|
||||
- Переход через публичный сервер с последующим доступом к NAS, панели роутера, домашнему DNS или другим внутренним сервисам.
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
U[Внешнее устройство пользователя]
|
||||
S[Публичный сервер]
|
||||
I[Домашнее устройство]
|
||||
H[Ресурсы домашней локальной сети]
|
||||
|
||||
I -- Самостоятельно устанавливает обратное VLESS-соединение --> S
|
||||
U -- Подключается к VLESS inbound на публичном сервере --> S
|
||||
S -- Пользовательский трафик пересылается через reverse --> I
|
||||
I -- Повторно обращается к домашней локальной сети --> H
|
||||
```
|
||||
|
||||
### Идея Конфигурации
|
||||
|
||||
По сравнению с первой частью, главное отличие здесь не в самой обратной связи, а в цели маршрутизации на публичной стороне:
|
||||
|
||||
- В первой части используется `inboundTag -> reverse-out`, чтобы сопоставить определенный входной порт с внутренней сетью;
|
||||
- Во второй части используется `user -> reverse-out`, чтобы передать проксируемый трафик конкретного пользователя внутреннему устройству для дальнейшей обработки.
|
||||
|
||||
Иными словами, здесь публичный сервер больше похож на транзитный узел. Пользователь не "обращается напрямую к сервису, проброшенному через публичный порт", а "сначала подключается к VLESS inbound на публичном сервере, а затем продолжает путь через домашнее устройство".
|
||||
|
||||
### Конфигурация Публичного Сервера
|
||||
|
||||
В этом примере:
|
||||
|
||||
- Первый UUID по-прежнему используется домашним устройством для установления обратного соединения;
|
||||
- Второй UUID используется внешним пользователем для подключения к публичному серверу;
|
||||
- Маршрутизация по `email` отправляет трафик этого пользователя в `reverse-out`.
|
||||
|
||||
```json
|
||||
{
|
||||
"inbounds": [
|
||||
{
|
||||
"listen": "0.0.0.0",
|
||||
"port": 8443,
|
||||
"protocol": "vless",
|
||||
"settings": {
|
||||
"decryption": "mlkem768x25519plus.native.600s.aCF82eKiK6g0DIbv0_nsjbHC4RyKCc9NRjl-X9lyi0k",
|
||||
"clients": [
|
||||
{
|
||||
"id": "ac04551d-6ebf-4685-86e2-17c12491f7f4",
|
||||
"flow": "xtls-rprx-vision",
|
||||
"reverse": {
|
||||
"tag": "reverse-out"
|
||||
}
|
||||
},
|
||||
{
|
||||
"id": "e8758aff-d830-4d08-a59e-271df65b995a",
|
||||
"flow": "xtls-rprx-vision",
|
||||
"email": "roam@example.com"
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
],
|
||||
"routing": {
|
||||
"rules": [
|
||||
{
|
||||
"user": ["roam@example.com"],
|
||||
"outboundTag": "reverse-out"
|
||||
}
|
||||
]
|
||||
},
|
||||
"outbounds": [
|
||||
{
|
||||
"protocol": "freedom"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
### Конфигурация Домашнего Устройства
|
||||
|
||||
Домашнее устройство по-прежнему должно само подключаться к публичному серверу и поднимать обратный туннель. В отличие от первой части, теперь оно не переписывает весь трафик на один фиксированный Web-сервис, а передает весь трафик, пришедший через `reverse-in`, на домашний outbound прямого подключения для дальнейшей обработки.
|
||||
|
||||
В примере ниже предполагается:
|
||||
|
||||
- Домашняя подсеть имеет вид `192.168.1.0/24`;
|
||||
- Пользовательское устройство уже само решает, какой трафик нужно "вернуть домой";
|
||||
- Домашнее устройство только принимает этот трафик и передает его домашней сети для дальнейшей обработки.
|
||||
|
||||
```json
|
||||
{
|
||||
"routing": {
|
||||
"rules": [
|
||||
{
|
||||
"inboundTag": ["reverse-in"],
|
||||
"outboundTag": "home-direct"
|
||||
}
|
||||
]
|
||||
},
|
||||
"outbounds": [
|
||||
{
|
||||
"protocol": "freedom"
|
||||
},
|
||||
{
|
||||
"protocol": "freedom",
|
||||
"tag": "home-direct",
|
||||
"settings": {
|
||||
"finalRules": [
|
||||
{
|
||||
"action": "allow",
|
||||
"network": "tcp,udp",
|
||||
"ip": ["192.168.1.0/24"]
|
||||
}
|
||||
]
|
||||
}
|
||||
},
|
||||
{
|
||||
"protocol": "vless",
|
||||
"settings": {
|
||||
"address": "yourserver.com",
|
||||
"port": 8443,
|
||||
"encryption": "mlkem768x25519plus.native.0rtt.2PcBa3Yz0zBdt4p8-PkJMzx9hIj2Ve-UmrnmZRPnpRk",
|
||||
"id": "ac04551d-6ebf-4685-86e2-17c12491f7f4",
|
||||
"flow": "xtls-rprx-vision",
|
||||
"reverse": {
|
||||
"tag": "reverse-in"
|
||||
}
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
Смысл этих правил:
|
||||
|
||||
- Любой трафик, входящий через `reverse-in`, отправляется в `home-direct`;
|
||||
- Поскольку в Xray есть политика безопасности по умолчанию, через `finalRules` нужно явно разрешить доступ во внутреннюю домашнюю сеть. Если вам нужен доступ только к домашнему NAS, лучше не открывать все IP, как в примере, а разрешить только конкретные IP и порты по необходимости.
|
||||
|
||||
### Конфигурация Устройства Пользователя
|
||||
|
||||
На стороне пользовательского устройства обычно не рекомендуется по умолчанию "возвращать домой весь трафик". Более распространенный вариант - отправлять назад только тот трафик, которому нужен доступ к домашним ресурсам, а остальной трафик оставлять на локальном прямом подключении. Ниже приведен пример, соответствующий домашней конфигурации выше. Предположим:
|
||||
|
||||
- Пользователь хочет обращаться только к домашней подсети `192.168.1.0/24`;
|
||||
- Остальной трафик продолжает идти напрямую из локальной сети пользователя.
|
||||
|
||||
```json
|
||||
{
|
||||
"routing": {
|
||||
"rules": [
|
||||
{
|
||||
"ip": ["192.168.1.0/24"],
|
||||
"outboundTag": "roam-home"
|
||||
}
|
||||
]
|
||||
},
|
||||
"outbounds": [
|
||||
{
|
||||
"protocol": "freedom"
|
||||
},
|
||||
{
|
||||
"protocol": "vless",
|
||||
"tag": "roam-home",
|
||||
"settings": {
|
||||
"address": "yourserver.com",
|
||||
"port": 8443,
|
||||
"encryption": "mlkem768x25519plus.native.0rtt.2PcBa3Yz0zBdt4p8-PkJMzx9hIj2Ve-UmrnmZRPnpRk",
|
||||
"id": "e8758aff-d830-4d08-a59e-271df65b995a",
|
||||
"flow": "xtls-rprx-vision"
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
Смысл этих правил:
|
||||
|
||||
- Трафик, направленный в `192.168.1.0/24`, идет через `roam-home`;
|
||||
- Остальной трафик не попадает ни под одно правило и продолжает идти через `freedom` по умолчанию, то есть напрямую через локальную сеть.
|
||||
|
||||
С точки зрения пользователя это выглядит как "домой отправляется только та часть трафика, которая нужна для доступа к домашним ресурсам", а не как перенаправление всего интернет-трафика через публичный сервер с последующим возвратом домой.
|
||||
|
||||
### Поток Запроса
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant U as Внешнее устройство пользователя
|
||||
participant S as Публичный сервер
|
||||
participant I as Домашнее устройство
|
||||
participant H as Ресурсы домашней локальной сети
|
||||
|
||||
I->>S: Устанавливает обратное VLESS-соединение
|
||||
U->>S: Подключается с использованием roam@example.com
|
||||
S->>S: user-маршрут попадает в reverse-out
|
||||
S->>I: Отправляет пользовательский трафик в reverse-туннель
|
||||
I->>H: Обращается к NAS / роутеру / домашнему DNS / внутренним сервисам
|
||||
H-->>I: Возвращает ответ
|
||||
I-->>S: Возвращает через обратный туннель
|
||||
S-->>U: Отвечает пользователю
|
||||
```
|
||||
|
||||
### Чем Этот Вариант Отличается От Первого
|
||||
|
||||
- Первый вариант - это "сопоставить один публичный входной порт с фиксированным сервисом в удаленной внутренней сети"; без дополнительной аутентификации такой сервис может быть доступен любому пользователю из интернета.
|
||||
- Второй вариант - это "дать конкретному пользователю сначала подключиться к публичному Xray-серверу, а затем через обратный прокси вернуться домой и продолжить доступ";
|
||||
- Первый вариант больше похож на удаленный проброс порта, то есть на проникновение во внутреннюю сеть;
|
||||
- Второй вариант больше похож на удаленный роуминг или легкую межплощадочную сеть.
|
||||
|
||||
### Рекомендации По Безопасности
|
||||
|
||||
- Если у вас несколько роуминговых пользователей, рекомендуется выдавать каждому отдельный UUID или отдельный идентификатор;
|
||||
- В примере ради упрощения используется только VLESS-enc. В реальной эксплуатации могут понадобиться REALITY, XHTTP или другие способы маскировки трафика.
|
||||
|
||||
## Итоги
|
||||
|
||||
Обратный прокси VLESS как минимум покрывает два типа сценариев:
|
||||
|
||||
- Сопоставление публичного входного порта с фиксированным сервисом в удаленной внутренней сети;
|
||||
- Подключение пользователя к публичному серверу с последующим возвратом домой через обратный туннель.
|
||||
|
||||
Оба сценария используют один и тот же механизм обратного соединения. Основное различие состоит в том, как публичная сторона маршрутизирует трафик и как внутренняя сторона продолжает его обрабатывать. Поняв это, можно свободно расширять схему между "пробросом порта" и "удаленным возвращением домой" под свои задачи.
|
||||
Reference in New Issue
Block a user