From a9ce566962db9ad2ea335b2da1d5e9768bd19537 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=E9=A3=8E=E6=89=87=E6=BB=91=E7=BF=94=E7=BF=BC?=
 <Fangliding.fshxy@outlook.com>
Date: Wed, 5 Feb 2025 01:36:13 +0800
Subject: [PATCH] correct sth

---
 docs/config/reverse.md | 30 ++++++++++++++++--------------
 1 file changed, 16 insertions(+), 14 deletions(-)

diff --git a/docs/config/reverse.md b/docs/config/reverse.md
index 3392238..edacc4f 100644
--- a/docs/config/reverse.md
+++ b/docs/config/reverse.md
@@ -2,6 +2,8 @@
 
 反向代理可以把服务器端的流量向客户端转发，即逆向流量转发。
 
+其底层协议为 Mux.cool, 作为一个多路复用协议，它还具有类似 QUIC 的性质，客户端和服务端是对等的，两边都可以新建一个子连接。一般情况情况下只有客户端打开，服务端打开子连接被这里用于发送反向代理请求。
+
 反向代理的大致工作原理如下:
 
 - 假设在主机 A 中有一个网页服务器，这台主机没有公网 IP，无法在公网上直接访问。另有一台主机 B，它可以由公网访问。现在我们需要把 B 作为入口，把流量从 B 转发到 A。
@@ -14,13 +16,13 @@
   - `bridge` 收到响应后，也会将响应原封不动地返回给`portal`。
 
 - `portal`
-  - `portal` 收到请求且domain匹配，则说明是由 `bridge` 发来的响应数据，这种连接数据会直接返回给请求的公网用户。
-  - `portal` 收到请求，domain不配置，则说明是公网用户发来的连接，这种连接数据会转发给bridge
+  - `portal` 收到请求且domain匹配，则说明是由 `bridge` 发来的响应数据，这条连接会用于建立反向通道。
+  - `portal` 收到请求，domain不匹配，则说明是公网用户发来的连接，这种连接数据会转发给bridge.
 
 - `bridge` 会根据流量的大小进行动态的负载均衡。
 
 ::: tip
-反向代理默认已开启 [Mux](../../development/protocols/muxcool/)，请不要在其用到的 outbound 上再次开启 Mux。
+如上所述，反向代理默认已开启 [Mux](../../development/protocols/muxcool/)，请不要在其用到的 outbound 上再次开启 Mux。
 :::
 
 ::: warning
@@ -135,7 +137,7 @@ outbound:
 
 ```jsonc
 {
-  // 转发到 portal
+  // 连接到 portal
   "protocol": "vmess",
   "settings": {
     "vnext": [
@@ -160,16 +162,16 @@ outbound:
 {
   "rules": [
     {
-      // 如果是带 bridge 标签，且域名为配置的域名，那么说明流量来自网页服务器，
-      // 则转发到 interconn，即转发给 portal
+      // bridge 发出的请求，且域名为配置的域名，那么说明这是尝试向 portal 建立反向隧道的请求，
+      // 则路由到 interconn，即连接到 portal
       "type": "field",
       "inboundTag": ["bridge"],
       "domain": ["full:reverse-proxy.xray.internal"],
       "outboundTag": "interconn"
     },
     {
-      // 从 portal 过来的流量，会经过bridge模块，带上bridge标签，且不带上面的domain
-      // 则转发到 out，即转发给网页服务器
+      // 从 portal 过来的流量，也会从 bridge 出来，但是不带上面的domain
+      // 则路由到 out，即转发给网页服务器
       "type": "field",
       "inboundTag": ["bridge"],
       "outboundTag": "out"
@@ -213,7 +215,7 @@ inbound:
 
 ```jsonc
 {
-  // 接收来自 bridge 的请求
+  // 接收来自 bridge 尝试建立反向隧道的请求
   "tag": "interconn",
   "port": 1024,
   "protocol": "vmess",
@@ -233,16 +235,16 @@ inbound:
 {
   "rules": [
     {
-      // 如果带 external 标签，说明是来自公网的请求，
-      // 则转发到 portal 模块，最终会转发给 bridge
+      // 如果入站是 external，说明是来自公网的请求，
+      // 则路由到 portal, 最终会转发给 bridge
       "type": "field",
       "inboundTag": ["external"],
       "outboundTag": "portal"
     },
     {
-      // 如果带 interconn 标签，说明是来自 bridge 的请求，
-      // 则转发到 portal 模块，最终会转发给对应的公网客户端
-      // 注意：这儿的流量带上了前文配置的domain，所以能够区分
+      // 如果来自 interconn 入站，说明是来自 bridge 的尝试建立反向隧道请求，
+      // 则路由到 portal, 最终会转发给对应的公网客户端
+      // 注意：这里进入的请求会带上了前文配置的domain，所以 portal 能够区分两种被路由到 portal 的请求
       "type": "field",
       "inboundTag": ["interconn"],
       "outboundTag": "portal"