RU Update reverse.md

docs/ru/config/reverse.md

@@ -1,48 +1,51 @@
 # Обратный прокси
 
-Обратный прокси позволяет перенаправлять трафик с сервера на клиент, то есть перенаправлять трафик в обратном направлении.
+Обратный прокси может перенаправлять трафик с сервера на клиент, то есть выполнять обратную переадресацию трафика.
 
-Принцип работы обратного прокси:
+В основе его лежит протокол Mux.cool, который, будучи протоколом мультиплексирования, также обладает свойствами, подобными QUIC. Клиент и сервер равноправны, и обе стороны могут создавать новые подсоединения. Обычно только клиент открывает подсоединения, но здесь открытие подсоединения сервером используется для отправки запросов обратного прокси.
+
+Принцип работы обратного прокси примерно следующий:
+
+- Предположим, на хосте A находится веб-сервер, у которого нет публичного IP-адреса и к которому нельзя получить прямой доступ из Интернета.  Есть другой хост B с публичным IP-адресом. Нам нужно использовать B в качестве точки входа, перенаправляя трафик с B на A.
+    - На хосте B настраивается Xray для приема внешних запросов, поэтому он называется `portal` (портал).
+    - На хосте A настраивается Xray, который отвечает за соединение переадресации от B с веб-сервером. Он называется `bridge` (мост).
+
+- `bridge`
+    - `bridge`  активно устанавливает соединение с `portal` для регистрации обратного канала. Целевой адрес (домен) этого соединения можно задать самостоятельно.
+    - После получения трафика из Интернета, перенаправленного `portal`, `bridge`  пересылает его без изменений на веб-сервер на хосте A. Конечно, для этого требуется настройка модуля маршрутизации.
+    - После получения ответа `bridge` также возвращает его без изменений `portal`.
+
+- `portal`
+    - Если `portal` получает запрос, и домен совпадает, это означает, что данные ответа пришли от `bridge`. Это соединение будет использовано для установления обратного канала.
+    - Если `portal` получает запрос, и домен не совпадает, это означает, что соединение установлено пользователем из Интернета. Данные этого соединения будут перенаправлены на `bridge`.
 
-- Предположим, что на хосте A запущен веб-сервер, но у этого хоста нет публичного IP-адреса, и к нему нельзя получить доступ из Интернета.  
-    У нас есть другой хост B с публичным IP-адресом.  
-    Мы хотим использовать хост B в качестве шлюза и перенаправлять трафик с B на A.
-- На хосте A настроен Xray, называемый `bridge`, и на хосте B также настроен Xray, называемый `portal`.
-- `bridge` устанавливает соединение с `portal`.  
-    Целевой адрес этого соединения можно настроить произвольно.  
-    `portal` получает два типа соединений: соединения от `bridge` и соединения от пользователей из Интернета.  
-    `portal` автоматически объединяет эти два типа соединений.  
-    Таким образом, `bridge` может получать трафик из Интернета.
-- После получения трафика из Интернета `bridge` перенаправляет его на веб-сервер на хосте A без изменений.  
-    Конечно, для этого требуется настроить маршрутизацию.
 - `bridge` выполняет динамическую балансировку нагрузки в зависимости от объема трафика.
 
 ::: tip
-Обратный прокси по умолчанию использует [Mux](../../development/protocols/muxcool/).  
+Как указано выше, обратный прокси по умолчанию использует [Mux](../../development/protocols/muxcool/). Пожалуйста, не включайте Mux повторно на используемых исходящих соединениях.
-Не включайте Mux для исходящих подключений, используемых обратным прокси.
 :::
 
 ::: warning
-Функция обратного прокси находится в стадии тестирования и может работать некорректно.
+Функция обратного прокси все еще находится в стадии тестирования и может иметь некоторые проблемы.
 :::
 
 ## ReverseObject
 
-`ReverseObject` соответствует полю `reverse` в конфигурационном файле.
+`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,96 +54,91 @@
 
 > `bridges`: \[[BridgeObject](#bridgeobject)\]
 
-Массив, каждый элемент которого представляет собой `bridge`.  
+Массив, каждый элемент которого представляет собой `bridge`. Конфигурация каждого `bridge` является [BridgeObject](#bridgeobject).
-Настройки каждого `bridge` определяются в [BridgeObject](#bridgeobject).
 
 > `portals`: \[[PortalObject](#portalobject)\]
 
-Массив, каждый элемент которого представляет собой `portal`.  
+Массив, каждый элемент которого представляет собой `portal`. Конфигурация каждого `portal` является [PortalObject](#bridgeobject).
-Настройки каждого `portal` определяются в [PortalObject](#bridgeobject).
 
 ### BridgeObject
 
-```json
+```jsonc
 {
   "tag": "bridge",
-  "domain": "test.xray.com"
+  "domain": "reverse-proxy.xray.internal"
 }
 ```
 
 > `tag`: string
 
-Все соединения, исходящие от `bridge`, будут иметь этот тег.  
+Все соединения, исходящие от `bridge`, будут иметь эту метку. Ее можно использовать для идентификации в [конфигурации маршрутизации](./routing.md) с помощью `inboundTag`.
-Его можно использовать для идентификации соединений в [настройках маршрутизации](./routing.md) с помощью `inboundTag`.
 
 > `domain`: string
 
-Доменное имя, которое `bridge` будет использовать для установления соединения с `portal`.  
+Указывает домен, который `bridge` будет использовать для установления соединения с `portal`.
-Это доменное имя используется только для связи между `bridge` и `portal` и не должно существовать на самом деле.
+Этот домен используется только для связи между `bridge` и `portal` и не обязательно должен существовать.
 
 ### PortalObject
 
-```json
+```jsonc
 {
   "tag": "portal",
-  "domain": "test.xray.com"
+  "domain": "reverse-proxy.xray.internal"
 }
 ```
 
 > `tag`: string
 
-Тег `portal`.  
+Метка `portal`. Используется в [конфигурации маршрутизации](./routing.md) с `outboundTag` для перенаправления трафика на этот `portal`.
-Используйте `outboundTag` в [настройках маршрутизации](./routing.md), чтобы перенаправить трафик на этот `portal`.
 
 > `domain`: string
 
-Доменное имя.  
+Домен. Когда `portal` получает трафик, если целевой домен трафика совпадает с этим доменом, `portal` считает, что текущее соединение является соединением связи, установленным `bridge`.  Другой трафик будет рассматриваться как трафик, требующий пересылки.  `portal`  занимается идентификацией этих двух типов соединений и выполняет соответствующую пересылку.
-Когда `portal` получает трафик, если целевое доменное имя трафика совпадает с этим доменным именем, `portal` считает, что это соединение для связи с `bridge`.  
+
-Весь остальной трафик считается трафиком, который нужно перенаправить.  
-`portal` идентифицирует и объединяет эти два типа соединений.
 
 ::: tip
-Один и тот же экземпляр Xray может выступать в роли `bridge`, `portal` или и того, и другого, в зависимости от сценария использования.
+Один Xray может быть `bridge`, `portal` или одновременно и тем, и другим, чтобы соответствовать требованиям различных сценариев.
 :::
 
-## Примеры полных конфигураций
+## Полный пример конфигурации
 
 ::: tip
-Рекомендуется сначала запустить `bridge`, а затем `portal`.
+Во время работы рекомендуется сначала запустить `bridge`, а затем `portal`.
 :::
 
-### Настройка bridge
+### Конфигурация bridge
 
-`bridge` обычно требуется два исходящих подключения: одно для подключения к `portal`, а другое - для отправки фактического трафика.  
+`bridge` обычно требует двух исходящих соединений (outbound): одно для подключения к `portal`, другое для отправки фактического трафика.  Другими словами, вам нужно использовать маршрутизацию для различения двух типов трафика.
-Другими словами, вам нужно использовать маршрутизацию, чтобы разделять эти два типа трафика.
 
-Настройки обратного прокси:
+Конфигурация обратного прокси:
 
-```json
+```jsonc
-{
+"reverse": {
   "bridges": [
     {
       "tag": "bridge",
-      "domain": "test.xray.com"
+      "domain": "reverse-proxy.xray.internal"
     }
   ]
 }
 ```
 
-Исходящие подключения:
+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": [
@@ -159,18 +157,23 @@
 }
 ```
 
-Настройки маршрутизации:
+Конфигурация маршрутизации:
 
-```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, но без указанного выше домена
+      // маршрутизируем на out, то есть перенаправляем на веб-сервер
       "type": "field",
       "inboundTag": ["bridge"],
       "outboundTag": "out"
@@ -179,28 +182,28 @@
 }
 ```
 
-### Настройка portal
+### Конфигурация portal
 
-`portal` обычно требуется два входящих подключения: одно для приема соединений от `bridge`, а другое - для приема фактического трафика.  
+`portal` обычно требует двух входящих соединений (inbound): одно для приема соединений от `bridge`, другое для приема фактического трафика.  Вам также нужно использовать маршрутизацию для различения двух типов трафика.
-Вам также нужно использовать маршрутизацию, чтобы разделять эти два типа трафика.
 
-Настройки обратного прокси:
+Конфигурация обратного прокси:
 
-```json
+```jsonc
-{
+"reverse": {
   "portals": [
     {
       "tag": "portal",
-      "domain": "test.xray.com" // Должно совпадать с настройками bridge
+      "domain": "reverse-proxy.xray.internal" // Должно совпадать с конфигурацией bridge
     }
   ]
 }
 ```
 
-Входящие подключения:
+inbound:
 
-```json
+```jsonc
 {
+  //  Прямой прием запросов из Интернета
   "tag": "external",
   "port": 80,
   "protocol": "dokodemo-door",
@@ -212,10 +215,11 @@
 }
 ```
 
-```json
+```jsonc
 {
-  "port": 1024,
+  // Прием запросов от bridge для установления обратного туннеля
   "tag": "interconn",
+  "port": 1024,
   "protocol": "vmess",
   "settings": {
     "clients": [
@@ -227,21 +231,27 @@
 }
 ```
 
-Настройки маршрутизации:
+Конфигурация маршрутизации:
 
-```json
+```jsonc
 {
   "rules": [
     {
+      // Если входящее соединение помечено external, значит, это запрос из Интернета,
+      // маршрутизируем на portal, который в конечном итоге перенаправит его на bridge
       "type": "field",
       "inboundTag": ["external"],
       "outboundTag": "portal"
     },
     {
+      // Если входящее соединение от interconn, значит, это запрос от bridge для установления обратного туннеля,
+      // маршрутизируем на portal, который в конечном итоге перенаправит его соответствующему клиенту в Интернете.
+      // Обратите внимание: этот запрос будет содержать домен, настроенный ранее, поэтому portal сможет различать два типа запросов,
+      // маршрутизируемых на portal.
       "type": "field",
       "inboundTag": ["interconn"],
       "outboundTag": "portal"
     }
   ]
 }
-```
+```