Skip to content

Commit 7b7e43c

Browse files
oweidxiaokangwang
oweid
authored and
xiaokangwang
committed
Create EN-US version of reverse.md
1 parent 469a487 commit 7b7e43c

File tree

1 file changed

+226
-2
lines changed

1 file changed

+226
-2
lines changed

‎docs/en_US/config/reverse.md‎

Lines changed: 226 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,3 +1,227 @@
1-
# Reverse
1+
# Reverse Proxy
22

3-
The documentation for this page is missing. Please submit a [pull request](https://github.com/v2fly/v2fly-github-io/pulls) or refer to the Chinese documentation.
3+
Reverse proxy is an additional feature of V2Ray that allows forwarding server-side traffic to the client, effectively enabling reverse traffic forwarding.
4+
5+
:::tip
6+
The reverse proxy feature is available in V2Ray 4.0+. It is currently in beta and may have some issues.
7+
:::
8+
9+
The basic working principle of reverse proxy is as follows:
10+
11+
* Suppose there is a web server on host A that has no public IP address and cannot be accessed directly from the internet. There is another host B that can be accessed from the public internet. We need to use B as an entry point to forward traffic from B to A.
12+
* Configure a V2Ray instance called `bridge` on host A, and another V2Ray instance called `portal` on host B.
13+
* `bridge` actively establishes connections to `portal` with a configurable destination address. `portal` receives two types of connections: ones from `bridge` and ones from public internet users. `portal` automatically merges these two types of connections, allowing `bridge` to receive public internet traffic.
14+
* After receiving public traffic, `bridge` forwards it unchanged to the web server on host A. This step requires routing cooperation.
15+
* `bridge` performs dynamic load balancing based on traffic volume.
16+
17+
:::warning
18+
Reverse proxy has [Mux](mux.md) enabled by default. Do not enable Mux again on the outbound proxies it uses.
19+
:::
20+
21+
## ReverseObject
22+
23+
`ReverseObject` corresponds to the `reverse` entry in the configuration file.
24+
25+
```json
26+
{
27+
"bridges": [
28+
{
29+
"tag": "bridge",
30+
"domain": "test.v2fly.org"
31+
}
32+
],
33+
"portals": [
34+
{
35+
"tag": "portal",
36+
"domain": "test.v2fly.org"
37+
}
38+
]
39+
}
40+
```
41+
42+
> `bridges`: \[[BridgeObject](#bridgeobject)\]
43+
44+
An array where each item represents a `bridge`. Each `bridge` configuration is a [BridgeObject](#bridgeobject).
45+
46+
> `portals`: \[[PortalObject](#portalobject)\]
47+
48+
An array where each item represents a `portal`. Each `portal` configuration is a [PortalObject](#portalobject).
49+
50+
## BridgeObject
51+
52+
```json
53+
{
54+
"tag": "bridge",
55+
"domain": "test.v2fly.org"
56+
}
57+
```
58+
59+
> `tag`: string
60+
61+
An identifier that all connections from the `bridge` will carry. This can be used in [routing](routing.md) with `inboundTag` for identification.
62+
63+
> `domain`: string
64+
65+
A domain name used for connections from `bridge` to `portal`. This domain name is only used for communication between `bridge` and `portal` and doesn't need to actually exist.
66+
67+
## PortalObject
68+
69+
```json
70+
{
71+
"tag": "portal",
72+
"domain": "test.v2fly.org"
73+
}
74+
```
75+
76+
> `tag`: string
77+
78+
The `portal` identifier. Used in [routing](routing.md) with `outboundTag` to forward traffic to this `portal`.
79+
80+
> `domain`: string
81+
82+
A domain name. When `portal` receives traffic, if the destination domain matches this domain, `portal` considers it a communication connection from `bridge`. Other traffic is treated as traffic to be forwarded. The `portal`'s job is to identify and merge these two types of connections.
83+
84+
:::tip
85+
Like other configurations, a V2Ray instance can act as a `bridge`, a `portal`, or both simultaneously, depending on your needs.
86+
:::
87+
88+
## Complete Configuration Examples
89+
90+
A `bridge` typically needs two outbound proxies: one for connecting to the `portal` and another for sending actual traffic. This means you need to use routing to distinguish between these two types of traffic.
91+
92+
Reverse proxy configuration:
93+
94+
```json
95+
{
96+
"bridges": [
97+
{
98+
"tag": "bridge",
99+
"domain": "test.v2fly.org"
100+
}
101+
]
102+
}
103+
```
104+
105+
Outbound proxy:
106+
107+
```json
108+
{
109+
"tag": "out",
110+
"protocol": "freedom",
111+
"settings": {
112+
"redirect": "127.0.0.1:80" // Forward all traffic to web server
113+
}
114+
},
115+
{
116+
"protocol": "vmess",
117+
"settings": {
118+
"vnext": [
119+
{
120+
"address": "portal's IP address",
121+
"port": 1024,
122+
"users": [
123+
{
124+
"id": "27848739-7e62-4138-9fd3-098a63964b6b"
125+
}
126+
]
127+
}
128+
]
129+
},
130+
"tag": "interconn"
131+
}
132+
```
133+
134+
Routing configuration:
135+
136+
```json
137+
"routing": {
138+
"rules": [
139+
{
140+
"type": "field",
141+
"inboundTag": [
142+
"bridge"
143+
],
144+
"domain": [
145+
"full:test.v2fly.org"
146+
],
147+
"outboundTag": "interconn"
148+
},
149+
{
150+
"type": "field",
151+
"inboundTag": [
152+
"bridge"
153+
],
154+
"outboundTag": "out"
155+
}
156+
]
157+
}
158+
```
159+
160+
A `portal` typically needs two inbound proxies: one for receiving connections from `bridge` and another for receiving actual traffic. You also need routing to distinguish between these two types of traffic.
161+
162+
Reverse proxy configuration:
163+
164+
```json
165+
{
166+
"portals": [
167+
{
168+
"tag": "portal",
169+
"domain": "test.v2fly.org" // Must match bridge configuration
170+
}
171+
]
172+
}
173+
```
174+
175+
Inbound proxy:
176+
177+
```json
178+
{
179+
"tag": "external",
180+
"port": 80, // Open port 80 for external HTTP access
181+
"protocol": "dokodemo-door",
182+
"settings": {
183+
"address": "127.0.0.1",
184+
"port": 80,
185+
"network": "tcp"
186+
}
187+
},
188+
{
189+
"port": 1024, // For receiving bridge connections
190+
"tag": "interconn",
191+
"protocol": "vmess",
192+
"settings": {
193+
"clients": [
194+
{
195+
"id": "27848739-7e62-4138-9fd3-098a63964b6b"
196+
}
197+
]
198+
}
199+
}
200+
```
201+
202+
Routing configuration:
203+
204+
```json
205+
"routing": {
206+
"rules": [
207+
{
208+
"type": "field",
209+
"inboundTag": [
210+
"external"
211+
],
212+
"outboundTag": "portal"
213+
},
214+
{
215+
"type": "field",
216+
"inboundTag": [
217+
"interconn"
218+
],
219+
"outboundTag": "portal"
220+
}
221+
]
222+
}
223+
```
224+
225+
:::tip
226+
During operation, it's recommended to start the `bridge` first, then start the `portal`.
227+
:::

0 commit comments

Comments
 (0)