Обход белого списка в 3x-ui через VLESS + XRay — инструкция

Обход белого списка в 3x‑ui с использованием vless + XRay (XTLS‑Reality) реализуется через маскировку TLS/SNI и «фейковый» веб‑контент: нужно выбрать подходящий whitelisted‑домен, получить для него сертификат и PTR, поставить веб‑сервер и направить реальный XRay‑inbound (vless + reality) на внутренний порт, делая SNI = выбранный домен. Такой подход помогает скрыть подпись протокола, но не гарантирует 100% успеха — многое зависит от типа фильтрации провайдера и дополнительных DPI‑правил.

Содержание

• Как работают белые списки и роль SNI
• Концепция обхода белого списка в 3x‑ui с vless + xray
• Практическая настройка 3x‑ui: высокоуровневые шаги
• Пример конфигурации XRay и SNI‑прокси (шаблон)
• Отладка и проверка работоспособности
• Ограничения, риски и рекомендации по безопасности и легальности
• Источники
• Заключение

Как работают белые списки и роль SNI

Провайдеры применяют разные варианты «белых списков»: фильтрация по IP, по DNS (подмена/ответы), по SNI/HTTP‑Host (во время TLS/HTTPS‑handshake и в первых пакетах) и глубокая DPI‑инспекция, которая ищет характерные подписи протоколов (VLESS/XRay/Trojan и т.д.). SNI обычно виден сетевым инспекторам при обычном TLS (до широкого внедрения ECH), поэтому провайдеры могут разрешать исходящие соединения только если SNI или IP соответствует списку разрешённых ресурсов.

Почему простая подстановка SNI часто не работает? Потому что фильтр смотрит не только на SNI — он проверяет согласованность сертификата, поведение сервера (HTTP/2, ALPN, ответы на GET), а также шаблоны начальных байтов протокола. Поэтому успешная маскировка требует, чтобы сервер выглядел «нативно»: совпадение PTR → домен, корректный сертификат, реальный веб‑контент и корректный TLS‑профиль. См. практические советы по маскировке в обзоре на Habr: FAQ по Shadowsocks/XRay/XTLS/Reality и руководство по 3X‑UI: 3X‑UI: Shadowsocks‑2022 & XRay (XTLS).

Концепция обхода белого списка в 3x‑ui с vless + xray

Общая архитектура — сделать внешний порт 443 «похожим» на обычный HTTPS‑хостинг, а внутри проксировать/обрабатывать реальные vless‑соединения через XRay с режимом reality, который усложняет сигнатуру протокола:

• Домен и инфраструктура:

• Выбираете домен, максимально «невредимый» для провайдера (TLS v1.3, HTTP/2 поддержка, в белом списке у оператора). Для поиска таких доменов используют утилиты/сканеры (встречается в практиках сообщества).

• На VPS настраиваете A‑запись домена, ставите PTR (reverse DNS) IP → домен, получаете TLS‑сертификат (Let’s Encrypt).

• На той же машине или в той же подсети держите минимальный веб‑сервис (fake‑site), чтобы при проверке он выглядел как настоящий сайт.

• XRay + Reality:

• XRay слушает внутренний порт (например, 8443) с inbound VLESS, streamSettings: security = “reality”, в realitySettings указываете serverName/SNI = ваш домен, publicKey и shortIds (генерируются для Reality).

• На внешний 443 ставите SNI‑прокси (nginx stream, HAProxy или прямое перенаправление), который по SNI направляет обычный TLS трафик на веб‑сервер, а «специфический» — на XRay. В 3x‑ui это настраивается через создание inbound VLESS + выбор TLS → XTLS/Reality и поля sni/publicKey/shortId.

• Почему Reality? XTLS‑Reality даёт дополнительные возможности маскировки handshake и работы поверх QUIC/TCP, что снижает распознаваемость типичных VLESS‑сигнатур. Однако она не магия: провайдеры, использующие сложную DPI‑логику, всё равно могут обнаружить аномалии.

Практическая настройка 3x‑ui: высокоуровневые шаги

Ниже — пошаговый, но в высокоуровневом виде (цель — дать понятную дорожную карту; конкретные команды адаптируйте под свою систему и соблюдайте законодательство).

1. Установка 3x‑ui (панель)

• Репозиторий и инструкции по установке есть в сообществе; кратко — клонируете и запускаете через Docker / docker‑compose. См. пошаговое руководство: 3X‑UI: установка и настройка на Habr и общие заметки в вики: руководство 3x‑ui.

2. Домен, PTR и сертификат

• Зарегистрируйте домен, поставьте A → IP VPS, настройте PTR в панели провайдера (IP → домен). Получите TLS‑сертификат (certbot/Let’s Encrypt) и убедитесь, что сайт отвечает корректно по HTTPS.

3. Настройка «fake‑site» (минимальный веб‑контент)

• На 443/80 разверните простой nginx/caddy, чтобы при проверке внешний адрес выглядел как обычный сайт (HTTP/2, корректные заголовки, 200 OK).

4. SNI‑маршрутизация (чтобы разделять «обычный» HTTPS и Reality)

• Рекомендуемый способ: nginx stream с ssl_preread (перехват SNI) и proxy_pass к backend‑ам (веб или xray). Это позволяет одновременно обслуживать легитимный сайт и направлять соединения с SNI = ваш‑домен → XRay.
• Альтернатива (грубая): перенаправление всего 443 на внутренний XRay‑порт через iptables — работает, но лишает вас возможности хостить реальный https‑сайт на том же IP/443.

5. Конфиг XRay / vless (локальный порт)

• XRay слушает на 127.0.0.1:8443 (например). Его inbound — vless с security = “reality” и параметрами realitySettings (serverNames = ваш домен, publicKey, shortIds). Далее на 3x‑ui создаёте inbound и в UI устанавливаете TLS → XTLS/Reality, указываете SNI/publicKey/shortId.

6. Клиент (v2rayNG, Nekobox и т.п.)

• В клиенте выбираете VLESS + security = reality, указываете serverName = ваш домен и те же publicKey/shortId; тестируете подключение.

7. Тестирование и адаптация

• Наблюдайте логи XRay, проверяйте TLS‑цепочку (openssl s_client -connect your.domain:443 -servername your.domain), тестируйте из мобильной сети, меняйте порт/ALPN/flow, пробуйте разные whitelisted домены.

Подробные практические примеры и обсуждения подобных схем описаны в сообществе и на Habr — посмотрите кейс‑FAQ: FAQ по Shadowsocks/XRay/XTLS/Reality.

Пример конфигурации XRay и SNI‑прокси (шаблон)

Привожу упрощённый шаблон (обязательно замените плейсхолдеры!):

Пример stream‑блока nginx (SNI‑маршрутизация):

stream {
 map $ssl_preread_server_name $backend {
 default web;
 your.domain.com xray;
 }

 upstream web {
 server 127.0.0.1:9443; # ваш "fake" веб‑сервер (HTTPS)
 }
 upstream xray {
 server 127.0.0.1:8443; # XRay inbound (реальность) на локальном порту
 }

 server {
 listen 443;
 proxy_pass $backend;
 ssl_preread on;
 }
}

Упрощённый пример inbound XRay (JSON, только ключевые поля):

{
 "inbounds": [
 {
 "port": 8443,
 "protocol": "vless",
 "settings": {
 "clients": [
 { "id": "ВАШ_UUID", "flow": "xtls-rprx-vision" }
 ]
 },
 "streamSettings": {
 "network": "tcp",
 "security": "reality",
 "realitySettings": {
 "dest": "127.0.0.1:8443",
 "serverNames": ["your.domain.com"],
 "publicKey": "ВАШ_PUBLIC_KEY",
 "shortIds": ["ВАШ_SHORTID"]
 }
 }
 }
 ]
}

Или (для грубой перенаправляющей схемы) пример iptables‑редиректа:

# Перенаправить входящие TCP 443 на локальный порт 8443
iptables -t nat -A PREROUTING -p tcp --dport 443 -j REDIRECT --to-port 8443

(этот метод прост, но не позволяет одновременно корректно обслуживать внешний веб‑сайт на 443).

Для настройки через 3x‑ui: создайте inbound VLESS, укажите порт 443, выберите TLS → XTLS/Reality и заполните поля SNI / publicKey / shortId — в интерфейсе панели эти поля обычно видны при выборе Reality. Подробности — в руководстве по 3x‑ui: статья‑инструкция на Habr.

Отладка и проверка работоспособности

• Проверка TLS и SNI:

• openssl s_client -connect your.domain.com:443 -servername your.domain.com -tls1_3

• Убедитесь, что сертификат правильный и ALPN/TLS‑версии совпадают с ожидаемыми.

• Логи:

• XRay: journalctl -u xray -f или tail -f /var/log/xray/xray.log — ищите строки типа “Reality handshake” или ошибки.

• Nginx: nginx -T (показ конфигурации), tail -f /var/log/nginx/error.log.

• Сетевые проверки:

• ss -lntp | grep 8443 — убедиться, что XRay слушает локально.

• Проверяйте подключение клиента в мобильной сети; смотрите логи клиента (v2rayNG/Nekobox).

• Что смотреть при проблемах:

• Несовпадение SNI и сертификата — вызывает блокировку.

• Провайдер может изменять ALPN/HTTP2 поведение — попробуйте менять ALPN (h2,http/1.1), flow, порт.

• Если соединение «падает» сразу, возможно DPI детектировал сигнатуру — попробуйте Reality с другими параметрами или сменить домен/хостинг.

Совет из практики: провайдеры отличаются — то, что работает у одного оператора, может не работать у другого; экспериментируйте аккуратно и фиксируйте изменения.

Ограничения, риски и рекомендации по безопасности и легальности

• Закон и правила: в некоторых юрисдикциях обход ограничений операторов или государственных фильтров может нарушать закон или правила оператора. Я не призываю к незаконным действиям — используйте техники только для легитимных задач и в пределах правовой зоны.
• Глушилки (физические подавители сигнала): если речь о физических глушилках (jammers), программные методы (SNI‑маскировка и т.п.) не помогут — сигнал просто не доходит до сети.
• Надёжность: маскировка — это игра в кошки‑мышки с провайдерами. Профилактические меры: используйте отдельные VPS, держите резервные точки доступа, журналируйте изменения и следите за отказами.
• Этическая сторона: не маскируйтесь под чужие сервисы без разрешения; лучше использовать собственный домен, корректно оформлять PTR/сертификаты и соблюдать правила хостинга.
• Альтернативы: если цель — приватный доступ или удалённая работа, рассмотрите проверенных коммерческих VPN с obfuscation, Tor (с ограничениями), или легальные каналам связи, прежде чем прибегать к сложной маскировке.

В обсуждениях пользователей и на Habr есть множество кейсов и предостережений о провайдерских детекторах и ограничениях — см. соответствующий Q&A: Как настроить шифрование xray на панели 3x-ui?.

Источники

1. FAQ по Shadowsocks/XRay/XTLS/Reality/Nekobox/etc. для обхода блокировок / Хабр
2. 3X-UI: Shadowsocks-2022 & XRay (XTLS) сервер с простой настройкой и приятным интерфейсом / Хабр
3. Как настроить шифрование xray на панели 3x-ui? — Хабр Q&A
4. Инструкция по настройке своего Xray‑сервера (репозиторий GitHub)
5. Руководство по установке и использованию панели 3X-UI (wiki)

Заключение

Обход белого списка в 3x‑ui при помощи vless + XRay возможен, но требует комплексной подготовки: корректный домен/PTR/сертификат, работающий «fake» веб‑сервер, SNI‑маршрутизация (nginx/HAProxy) и inbound XRay с realitySettings (sni/publicKey/shortId). Это не «кнопка‑включить» — придётся тестировать и подстраиваться под конкретного провайдера; и, пожалуйста, учитывайте правовые и этические ограничения при попытках обхода белых списков.