Цепочка прокси Xray передает соединение выбранного приложения через входной сервер A, затем через выходной сервер B. Сначала проверьте узлы по отдельности, направьте установление соединения с B через A и убедитесь, что отказ любого узла прекращает выбранный запрос, а не незаметно переводит его на прямой доступ.

Ключевые выводы

Контролируйте оба сервера и цель либо получите явное разрешение владельцев.

Конечный адрес выхода не доказывает, через какой вход прошел запрос.

Разделяйте проверки аутентификации, TLS, маршрутизации и DNS.

Пример охватывает выбранные TCP-приложения, но не весь компьютер и не UDP.

Какие соединения охватывает цепочка прокси Xray?

Инструкция составлена по официальной документации для Xray-core v26.3.27, клиента командной строки Ubuntu 24.04 LTS и двух уже настроенных разрешенных узлов Trojan поверх TLS. Полное сквозное испытание автором не выполнялось. Фиксация выпуска определяет пример, а не означает, что это последняя версия или что можно игнорировать обновления безопасности.［1］

До изменений изучите ответственность за собственную сеть. Модель доверия для двух узлов VPN объясняет, что такая схема скрывает и чего не скрывает: дополнительный узел не доказывает анонимность, большую скорость или устойчивость к блокировкам. Различия ролей Xray и V2Ray помогают отделить ядро от приложения, которое им управляет.

Если нужен обычный выход для устройства без управления двумя серверами, сравните охват устройства и прокси отдельного приложения. Это другой выбор задачи, а не исправление данной цепочки покупкой сервиса.

Шаг 1: Закрепите топологию и путь восстановления

Используйте отдельный клиент и специальные тестовые учетные данные. Не закрывайте и не изменяйте повседневный прокси- или VPN-клиент ради примера. Если его существующий маршрут влияет на проверку, зафиксируйте дополнительный слой либо используйте разрешенную изолированную машину; не называйте такой результат чистым путем из двух узлов.

Роль	Необходимый контроль	Что сохранить непублично
Клиент C	Тестовый процесс и loopback-порт	Версия ядра, путь конфигурации, владелец процесса
Вход A	TLS-узел с аутентификацией	Тестовая учетная запись, ограничение источника, соединение с B
Выход B	TLS-узел с аутентификацией	Соединение от A, разрешенная цель, семейство выходного адреса
Цель T	Разрешенный HTTPS-сервис	Идентичность сертификата и сопоставимая по времени запись запроса

Сохраните консоль или независимое управляющее соединение вне цепочки. Запишите исходные слушающие порты, конкретных владельцев правил межсетевого экрана, DNS и настройки прокси приложения. Сделайте закрытые резервные копии только изменяемых файлов. Если процесс или конфигурация обслуживает других пользователей, остановитесь и выделите отдельный тестовый экземпляр.

У A и B должны быть разные учетные данные Trojan, действительные сертификаты для соответствующих имен, совместимые параметры транспорта и узко разрешенный трафик. Сверьте входящие и исходящие поля с официальным описанием протокола.［2］ По возможности разрешите A только утвержденный источник клиента, B для проверки цепочки — только A, а обоим серверам — разрешенные цели. Не создавайте анонимный слушатель, не отключайте межсетевой экран и не используйте чужой домашний выход без разрешения.

Шаг 2: Настройка Xray dialerProxy и владелец конфигурации

dialerProxy называет outbound, используемый для установления нижележащего соединения другого outbound. Приложение здесь выбирает exit-b, а он подключается к B через entry-a. Обратная ссылка из entry-a на B или на себя недопустима.［3］ Теги должны быть уникальными, граф ссылок — без циклов.

Создайте закрытый рабочий каталог от обычного тестового пользователя. Сохраните полную клиентскую конфигурацию ниже в chain.json. Замените документальные адреса, имена сертификатов, порты и оба заполнителя паролей разрешенными значениями; это не рабочие узлы. Не помещайте пароли в аргументы командной строки или общедоступные журналы.

{
  "log": {"loglevel": "warning"},
  "inbounds": [
    {
      "tag": "lab-socks",
      "listen": "127.0.0.1",
      "port": 10818,
      "protocol": "socks",
      "settings": {"auth": "noauth", "udp": false}
    }
  ],
  "outbounds": [
    {"tag": "deny", "protocol": "blackhole", "settings": {}},
    {
      "tag": "entry-a",
      "protocol": "trojan",
      "settings": {
        "servers": [{"address": "192.0.2.10", "port": 18443,
          "password": "REPLACE_ENTRY_PASSWORD"}]
      },
      "streamSettings": {
        "network": "raw", "security": "tls",
        "tlsSettings": {"serverName": "a.example.com", "allowInsecure": false}
      }
    },
    {
      "tag": "exit-b",
      "protocol": "trojan",
      "settings": {
        "servers": [{"address": "198.51.100.20", "port": 18443,
          "password": "REPLACE_EXIT_PASSWORD"}]
      },
      "streamSettings": {
        "network": "raw", "security": "tls",
        "tlsSettings": {"serverName": "b.example.com", "allowInsecure": false},
        "sockopt": {"dialerProxy": "entry-a"}
      }
    }
  ],
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {"type": "field", "inboundTag": ["lab-socks"],
        "network": "tcp", "outboundTag": "exit-b"}
    ]
  }
}

Локальный SOCKS-слушатель рассчитан на доверенную машину с одним пользователем: другие локальные пользователи тоже могут подключаться к нему. Не применяйте этот вход без аутентификации на общей машине. UDP явно выключен.［4］ Имена TLS должны соответствовать действительным сертификатам. Пример не добавляет REALITY, Vision, мультиплексирование или прозрачный перехват: защита транспорта и выбор dialer — разные параметры.［2］［5］

Правила маршрутизации проверяются по порядку; без совпадения используется первый outbound. Поэтому первым стоит deny, отклоняющий непредусмотренный трафик, а явное TCP-правило выбирает B для лабораторного входа.［6］ Не добавляйте прямой outbound или балансировщик с резервным прямым маршрутом. Будущему прямому исключению нужны отдельные цель, область действия и доказательства поведения при отказе.

Шаг 3: Проверка цепочки прокси по отдельным компонентам

Запустите проверки выбранным бинарным файлом, при необходимости указав его точный путь:

xray version
xray run -test -config ./chain.json
ss -lntp '( sport = :10818 )'

Перед запуском порт должен быть свободен. Успешная проверка конфигурации означает только корректный разбор: она не устанавливает оба соединения, не подтверждает аутентификацию или реальный путь. При несовпадении версии либо загруженного файла с зафиксированной парой остановитесь.

Сделайте две закрытые копии для одиночных узлов. В копии A выберите entry-a в правиле маршрутизации. В копии B оставьте exit-b, удалив только его sockopt.dialerProxy. Запускайте по одному процессу переднего плана на зарезервированном порту, обращайтесь к T, сохраняйте соответствующие записи сервера и завершайте этот процесс через Ctrl-C до следующего запуска.

Одиночная проверка B должна исходить из уже разрешенного источника или собственной контролируемой среды B. Если B принимает только A, проверьте B с A, не расширяя публичный доступ ради клиентского эталона. Отдельно запишите источник и ожидаемый выход одиночной проверки, чтобы не спутать их с итоговой цепочкой.

Используйте известную HTTPS-цель под вашим контролем и обычную проверку ее сертификата. Команда ниже предназначена читателю, а не является опубликованным результатом испытания:

curl --fail --show-error --connect-timeout 5 --max-time 15 \
  --noproxy "" --proxy socks5h://127.0.0.1:10818 https://target.example.com/health

Перед запуском замените цель. socks5h передает имя назначения прокси, но не перехватывает посторонний системный DNS или собственные запросы защищенного DNS браузера. До объединения узлов различите отказ подключения, ошибку TLS, неверные учетные данные и запрет со стороны цели.

--noproxy "" отменяет для этой команды исключения из NO_PROXY/no_proxy, иначе совпавшая цель может обходить даже явно заданный --proxy. Сохраняйте параметр при проверке отдельных узлов, всей цепочки и отказов; настройки прокси других приложений он не меняет.［7］

Шаг 4: Соедините узлы и сопоставьте доказательства

Верните исходный файл цепочки, снова проверьте его и запустите xray run -config ./chain.json на переднем плане. Отправьте новый запрос с явно заданным прокси. Сопоставьте время и разрешенную цель в C, A, B и T, учитывая расхождение часов; повторно использованное соединение может скрывать новую ошибку аутентификации.

На A подтвердите разрешенную клиентскую учетную запись и исходящее соединение к B. На B подтвердите источник, соответствующий A, и запрос к цели. Выход A может проходить NAT: записывайте ожидаемый преобразованный источник, не предполагая, что B увидит адрес интерфейса A.

Для сравнения публичного выхода используйте профиль браузера, явно настроенный на этот SOCKS-вход, и проверьте адрес, видимый сайту. Для данного запроса ожидается выход B. Наблюдение относится только к нему: оно не заменяет записи отдельных узлов и не доказывает, что все приложения используют B.

Собирайте журналы недолго и ограничьте доступ. Если временно включаете access logging через документированную конфигурацию экземпляра, оставьте только диагностический интервал и восстановите прежнюю политику. Не собирайте содержимое запросов, не публикуйте пароли и не считайте отсутствие записи самостоятельным доказательством блокировки трафика.

Шаг 5: Проверьте DNS, семейства адресов и отказы

Таблица задает проверки читателя и ожидаемую политику, а не измеренные результаты. Меняйте одно условие за раз, создавайте новые соединения и возвращайте исправную конфигурацию перед следующим случаем.

Метод проверки	Ожидаемое наблюдение	При расхождении
Новый TCP-запрос через цепочку	Записи A и B сопоставляются с T	Остановитесь, проверьте теги, TLS и правила
Неверный тестовый пароль сначала A, затем B	Соответствующие новые запросы отклоняются	Проверьте выбор учетной записи и неожиданные маршруты
Остановлен только выделенный A	Новые запросы цепочки не проходят	Найдите прямую ветку или лишний слой прокси
A восстановлен, остановлен выделенный B	Новые запросы цепочки не проходят	Выход только через A не считается успехом
Контролируемые цели IPv4-only и IPv6-only	Каждое заявленное семейство достигает T через B	Укажите неподдерживаемые семейства, проверьте маршруты B
Сравнение запросов по имени и числовому адресу	DNS цели соответствует описанной схеме	Раздельно проверьте резолверы клиента, A, B и приложения
Приложению требуется UDP или QUIC	Этого TCP-примера недостаточно	Нужна отдельно документированная и проверенная схема

Не останавливайте общий сервис ради проверки отказа. IP-адреса узлов A/B в примере исключают их начальное разрешение имен, однако TLS продолжает проверять имена сертификатов. Имя цели, переданное SOCKS, требует резолвера на соответствующем выходном пути; одного routing.domainStrategy недостаточно для политики предотвращения утечек DNS.［3］［6］

Браузер может выбрать другой протокол или обойти свою настройку прокси. Если доступ к контролируемой частной цели не работает из-за совпадающих адресов, сначала исправьте топологию пересекающихся подсетей. Еще один прокси-узел не различает две машины с одним адресом.

Шаг 6: Отзовите доступ и восстановите исходное состояние

Завершите только запущенный вами процесс переднего плана и убедитесь, что loopback-слушатель исчез. Отзовите специальные учетные данные на A и B, проверьте отказ новых аутентифицированных соединений с ними. Если механизм отзыва сервера не закрывает старые соединения, отдельно завершите оставшиеся тестовые сеансы.

Восстановите только настройку прокси тестового приложения, временное журналирование и точные исключения межсетевого экрана. Сохраните минимальные обезличенные доказательства по своей политике, затем удалите закрытые копии конфигураций. Не удаляйте общий каталог настроек и не очищайте весь межсетевой экран для уборки.

Независимо проверьте управляющий доступ, исходные слушатели, маршруты и DNS. Если восстановление не подтверждается, прекратите дальнейшие эксперименты и используйте аварийную консоль. Для постоянной цепочки отдельно назначьте ответственность за ротацию учетных данных, продление сертификатов, хранение журналов и поведение при отказе.

Итоги

Подтвердите каждый узел до включения цепочки dialer.
Сопоставляйте журналы узлов с конечным выходом.
Явно объявляйте ограничения TCP, DNS и семейств адресов.
Неожиданный прямой выход означает провал приемки.

Часто задаваемые вопросы (FAQ)

Обеспечивают ли два узла анонимность автоматически?

Нет. Операторы, временные характеристики, учетные записи и идентификаторы цели могут связывать действия; второй узел меняет путь, но не доказывает анонимность.

Где задавать dialerProxy: на outbound A или B?

В этой клиентской схеме задавайте его на outbound B со ссылкой на тег A, чтобы нижележащее соединение с B проходило через A.

Можно оставить прямой outbound по умолчанию?

Для этой политики приемки нельзя. Непредусмотренный трафик должен отклоняться, а отдельно разрешенной прямой ветке нужны явные границы и проверки отказа.

Доказывает ли сайт с адресом B всю цепочку прокси Xray?

Нет. Сайт определяет только наблюдаемый им выход; сопоставьте доказательства A и B, чтобы отличить цепочку от прямого подключения к B.

Охватывает ли конфигурация UDP и все устройство?

Нет. Слушатель отключает UDP и принимает только явно проксируемые приложения; системные службы и остальные приложения сохраняют прежние сетевые пути.

Нужно отключить проверку сертификата для диагностики?

Нет. Отдельно проверьте имя сертификата, цепочку доверия, время системы и узел; обход проверки меняет условия безопасности вместо устранения ошибки.

Что делать без контроля над обоими узлами?

Прекратите процедуру, если владельцы не предоставили необходимые разрешение и доказательства. Неизвестный сторонний узел не удовлетворяет заявленным условиям приемки.

Источники:

Sources checked 11 октября 2026 г.

Рекомендуемые статьи:

Цепочка прокси Xray с проверкой каждого узла