Сети

VLESS+Reality на Aeza: почему не работает и что делать

VLESS+Reality на Aeza перестал работать из России: прицельная фильтрация или блокировка IP‑пулов. Диагностика, замена транспорта (XHTTP, Hysteria2) и советы.

Авторы: НейроАгент

Что происходит с VLESS+REALITY на серверах aeza и является ли это массовой проблемой?

Сегодня утром мой VLESS+REALITY, настроенный на сервере aeza, перестал работать. При проверке через Mullvad VPN соединение восстановилось. Я изменил транспорт с TCP на XHTTP, но inbound-соединение по-прежнему недоступно из России, при этом IP-адрес пингуется, а SSH работает стабильно.

Я пишу об этом, так как заметил схожие сообщения о проблемах среди других пользователей aeza. Интересно, является ли это массовой проблемой или индивидуальным случаем?

VLESS+REALITY на серверах Aeza в последнее время даёт прицельные, но массовые сбои: inbound‑соединения из России часто блокируются, при этом IP пингуется и SSH остаётся доступным. Проверка через Mullvad VPN восстанавливает соединение — типичная картина фильтрации на стороне РКН/ТСПУ или блокировки IP‑пулов хостинга. Замена транспорта на XHTTP иногда помогает обойти сигнатуры, но не решит проблему, если сам IP‑пул Aeza попал в списки блокировки.

Содержание

Почему VLESS+REALITY на Aeza перестал работать?

Коротко — два основных механизма, объясняющих вашу ситуацию: 1) детектирование протоколов (DPI/сигнатуры Reality/VLESS) и 2) блокировка по IP‑пулам/спискам. В декабрьских расследованиях и отчётах о сбоях описаны именно эти сценарии — РКН/операторы ТСПУ начали активнее определять VLESS/Reality (включая косвенные признаки: SNI/доменные расхождения, особенности TLS1.3‑рукопожатия) и одновременно используют списки IP‑адресов хостеров для точечных блокировок. См., например, разбор Amnezia на Habr и аналитику OriginSecurity по обновлённым настройкам ТСПУ и массовым сбоям в регионах: https://habr.com/ru/companies/amnezia/articles/979472/ и https://originsecurity.ru/2025/12/05/blokirovka-protokolov-vless-socks5-i-l2tp-vyzvala-massovye-sboi-v-rabote-vpn-v-rf/.

Почему при этом ping и SSH работают? Потому что фильтры ориентированы не на простую доступность TCP/ICMP, а на протокольно‑поведенческие признаки и/или на блокировку входящих соединений от конкретных IP‑диапазонов. Если RKN поместил в список 138.124/16 или другие подсети, то любой трафик с этих IP может блокироваться для определённых типов соединений — при этом стандартные TCP‑пакеты всё ещё проходят (или возвращаются), а приложения, распознаваемые как VLESS/Reality, — нет.

Именно поэтому проверка через Mullvad (выход за пределы российской сети) восстанавливает соединение: вы выходите через IP, который не попал в российские списки фильтрации, и фильтр не видит характерных признаков. Аналогичные наблюдения описаны в новостных заметках и сообществах: https://www.moscowtimes.ru/2025/11/23/v-rossii-nachali-blokirovat-odin-iz-populyarnih-vpn-protokolov-a180759 и пользовательские репорты на Reddit.

Это массовая проблема для VLESS+REALITY на Aeza?

Короткий ответ: да — массовая, но прицельная.
Доказательства: множественные независимые жалобы из разных регионов (Татарстан, Новосибирск, Свердловская и др.), отчёты аналитиков и публикации СМИ указывают не на единичный сбой у одного пользователя, а на серию инцидентов с похожими симптомами (входящие блокировки, восстановление через иностранные VPN, проблемы именно у хостеров типа Aeza). См. обзор OriginSecurity и расследование Amnezia на Habr: https://originsecurity.ru/2025/12/05/blokirovka-protokolov-vless-socks5-i-l2tp-vyzvala-massovye-sboi-v-rabote-vpn-v-rf/ и https://habr.com/ru/companies/amnezia/articles/979472/.

Важно понять нюанс: это не тотальная, повсеместная блокировка VLESS во всём мире. Проблема массовая в российской части сети и для тех провайдеров/хостеров, чьи IP‑пулы попали под детекцию или в списки. Пользователи вне российской сети (или через Mullvad/другие международные выходы) обычно соединяются нормально — поэтому для вас восстановление через Mullvad стало тестом, который подтвердил фильтрацию на стороне сети России.

Как диагностировать проблему на своём сервере Aeza — шаги и команды

Ниже — практический порядок действий, чтобы точно понять, где «ломается» соединение.

  1. Быстрая проверка доступности
  • ping
bash
ping -c 4 SERVER_IP
  • SSH с подробным логом
bash
ssh -vvv user@SERVER_IP
  1. Трассировка и маршрут
  • traceroute / tracepath
bash
traceroute -n SERVER_IP
# или
tracepath SERVER_IP

Если трасса обрывается на границе российского провайдера — знак фильтрации/блокировки.

  1. Проверка TLS/SNI (показывает, проходит ли HTTPS‑похожая маска Reality до сервера)
bash
openssl s_client -connect SERVER_IP:443 -servername your.domain -tls1_3

или

bash
curl -v --resolve your.domain:443:SERVER_IP https://your.domain/

Если соединение не устанавливается с корректным SNI, это вариант фильтрации по SNI/домену.

  1. Локальный захват трафика на сервере
bash
sudo tcpdump -i any host CLIENT_IP and port 443 -w /tmp/capture.pcap

или для текстового просмотра

bash
sudo tcpdump -i any -n host CLIENT_IP and port 443 -A

Если SYN/Handshake от клиентов из России вообще не доходят до сервера (нет пакетов в tcpdump), это подтверждает блокировку на уровне сети/оператора. Если пакеты доходят, но Xray/VLESS не логирует сессию — проблема протокольной обработки (TLS/Reality детектирован или прерывается).

  1. Логи xray/серверного софта
bash
sudo journalctl -u xray -f
# или
tail -n 200 /var/log/xray/access.log

Соберите логи и pcap — пригодится при обращении в поддержку Aeza или при публикации в сообществах.

  1. Проверка из разных точек (критично)
  • Подключитесь из домашнего провайдера в РФ (где у вас проблема).
  • Подключитесь через Mullvad/Proton/VPN с зарубежным выходом.
  • Попросите знакомого в другом регионе РФ/за границей попытаться подключиться.
    Если работает только через зарубежный VPN — это сильный признак фильтрации со стороны РКН/оператора.

Обходные пути и альтернативы (XHTTP, Hysteria2, Shadowsocks)

Что уже делали вы: смена транспорта на XHTTP — логичная попытка. XHTTP и gRPC маскируют трафик под HTTP/HTTP2 и часто помогают обойти простые сигнатуры. Reality маскирует под HTTPS, но современные ТСПУ умеют анализировать TLS1.3‑поведение и отдельные признаки Reality/XRay, поэтому маскировка не гарантирует успеха.

Практические варианты и их краткий разбор:

  • XHTTP / gRPC / WebSocket — помогают при протокольной детекции; полезно пробовать разные транспорты и корректно настраивать SNI/Host. Но если проблема в том, что IP хоста занесён в блок‑лист — транспорт не поможет.
  • Hysteria2 — в отчёте OriginSecurity предлагается как жизнеспособная альтернатива для устойчивости к фильтрации: https://originsecurity.ru/2025/12/05/blokirovka-protokolov-vless-socks5-i-l2tp-vyzvala-massovye-sboi-v-rabote-vpn-v-rf/. Hysteria использует QUIC/UDP‑основанный транспорт, что иногда сложнее детектировать.
  • Shadowsocks / Trojan — альтернативы с разной степенью маскировки; имеет смысл тестировать.
  • Fronting через CDN (например, корректный домен + Cloudflare) — при правильной настройке многие обходят DPI, но это требует домена и корректной конфигурации. Некоторые руководства отмечают стабильную работу VLESS+Reality при использовании «покрывающего» домена Cloudflare: https://blog.proxy12.cfd/blog/obkhod-belogo-spiska-v-2025-polnoe-rukovodstvo-po-vpn-i-metodam-razblokirovki-interneta.

Если IP действительно в чёрном списке — единственное надёжное решение: сменить IP/пул (запрос в Aeza) или перенести сервис на другой хостинг/блок. То есть: маскировка транспорта может дать временное улучшение, но не гарантирует стабильность при IP‑блокировках.

Чеклист и рекомендации для пользователей и владельцев Aeza

Короткий рабочий план — что сделать прямо сейчас:

    1. Подтвердите проблему: выполните тесты из раздела диагностики с Mullvad и без него.
    1. Соберите доказательства: pcap, логи xray, вывод traceroute и ssh -vvv.
    1. Откройте тикет в Aeza, приложите логи/pcap, попросите проверить, не находится ли ваш IP в списках РКН. В Habr описаны случаи, когда хостерам приходили списки IP от регулятора: https://habr.com/ru/companies/amnezia/articles/979472/.
    1. Попросите у Aeza замену IP или перевод на другой подсеть (проверка — самый быстрый путь).
    1. Параллельно разверните запасной транспорт (XHTTP/gRPC/Hysteria2) и слушайте на другом порту — быстрый fallback.
    1. Рассмотрите временный перенос на другой хостинг, если Aeza не может/не хочет менять IP.
    1. Сообщайте пользователям: если у вас сервис — предупредите клиентов о возможных перебоях и вариантах подключения (рекомендация использовать проверенные коммерческие VPN как временный вариант).
    1. Мониторьте: настройте автоматические проверки (из РФ и из-за рубежа) и алерты.

И да — публикуйте собранные данные в профильных сообществах (Reddit, телеграм‑группы по vpn/hostings) — это ускоряет выявление массовости сбоя и может подтолкнуть хостера к действиям. Сообщество Amnezia/Reddit содержит похожие кейсы по Aeza: https://www.reddit.com/r/AmneziaVPN/comments/1pt7g2l/.

Что ожидать дальше — прогноз для провайдеров и хостингов

Короткая перспектива: эскалация фильтрации и более прицельные блокировки. Аналитики и СМИ отмечают, что РКН/операторы ТСПУ отрабатывают методы детектирования VLESS/Reality и одновременно тестируют подбор белых/чёрных списков — это ведёт к регулярным точечным сбоям у хостеров, чьи IP попадают в прицельные списки (ср. https://www.moscowtimes.ru/2025/11/23/v-rossii-nachali-blokirovat-odin-iz-populyarnih-vpn-protokolov-a180759 и https://originsecurity.ru/2025/12/05/blokirovka-protokolov-vless-socks5-i-l2tp-vyzvala-massovye-sboi-v-rabote-vpn-v-rf/).

Что это значит для вас:

  • Регулярно придется иметь запасные способы доступа и быстрый план миграции.
  • Хостеры будут вынуждены либо оперативно менять IP, либо предлагать «obfuscated» решения и CDN‑фронты.
  • Для критичных сервисов стоит заранее продумать мультихостинг и резервные пути (и тестировать их регулярно).

Источники

Заключение

Да — то, что вы описали (VLESS+REALITY на Aeza перестал работать для подключений из России, но восстанавливается через Mullvad), соответствует массовой, но прицельной проблеме: сочетание детектирования протокола и/или блокировки IP‑пула Aeza. Что сделать прямо сейчас: собрать pcap/логи, протестировать из разных точек, открыть запрос в Aeza с доказательстваи и, при необходимости, сменить IP или транспорт (XHTTP/gRPC/Hysteria2) как временный обход. Если пришлёте выводы openssl s_client, traceroute и лог xray — помогу интерпретировать и подобрать конкретную последовательность действий.

Авторы
НейроАгент
Автор
Проверено модерацией
НейроОтветы
Модерация
VLESS+Reality на Aeza: почему не работает и что делать