VPN отвалился после блокировки: почему перестал работать и как понять причину

Три разных «vpn отвалился» — и почему их нельзя лечить одинаково

«VPN отвалился» — это симптом, а не диагноз. За фразой прячется минимум три сценария, и лечатся они противоположными способами:

• Клиент подключается, но интернета нет. Хендшейк проходит, индикатор зелёный, а трафик не идёт или обрывается через секунды. Обычно это DPI: соединение пропускают, а сам поток режут по сигнатуре.
• Клиент вообще не подключается. Таймаут на этапе TCP/TLS, «бесконечное подключение». Чаще всего — блокировка IP или порта: до ноды не доходят пакеты.
• Работает через раз. Плавающая деградация, троттлинг, потери на конкретном операторе или в часы нагрузки.

Главный вопрос при разборе «vpn перестал работать после блокировки» один: режут признаки трафика (протокол, TLS-фингерпринт, SNI) или сам адрес (IP ноды, диапазон, порт)? От ответа зависит всё. Перепутать эти два случая — значит потратить вечер на перебор протоколов там, где проблема в адресе, или наоборот. Поэтому сначала диагностика, потом действия — порядок в следующих двух разделах.

Почему VPN не подключается: нода вне белого списка

Самая частая причина массового «дня Х», когда VPN отваливается сразу у многих — переход оператора или региона в режим белых списков. Это не точечная блокировка вашего сервиса, а смена логики ТСПУ: вместо «блокируем плохое» — «пропускаем только разрешённое». Что такое белые списки и как они устроены — подробно в отдельной статье; здесь только механика отвала.

На практике:

• Оборудование пропускает трафик только к IP из разрешённых диапазонов (крупные российские хостеры, CDN, соцсети, госсервисы, банки).
• Ваша нода стоит в обычном дата-центре — зарубежный VPS или привычный хостер. Её адрес в whitelist не входит.
• Пакеты до ноды не доходят вообще. Клиент показывает бесконечное подключение или таймаут.

Признаки именно этого сценария:

• Отвалилось резко (в пределах минут-часов) и одновременно у многих на одном операторе/регионе.
• Не подключается ни один протокол и порт на этом сервере.
• С других сетей (другой оператор, роуминг, зарубежный Wi-Fi) тот же сервер работает нормально.
• Трассировка до IP ноды из проблемной сети обрывается на операторском узле.

Важные честные оговорки. Whitelist — не рубильник на всю страну: по наблюдениям режим включается точечно, по операторам и регионам, и усиливается в периоды «учений» и локальных шатдаунов. Диапазоны проверяются вплоть до отдельных /24 и постоянно меняются — адрес, который вчера проходил, сегодня выпадает. И whitelist — не единственная причина: бывает и обычный DPI по протоколу (тогда IP доходит, а режут поток). Поэтому не угадывайте — проверьте.

Как понять, почему VPN не подключается: диагностика командами

Пять минут проверки экономят часы бесполезных переустановок. Идём от сети к адресу и порту.

1. Проверьте с другой сети. Включите VPN на мобильном другого оператора или раздайте зарубежный Wi-Fi. Работает там — режут не аккаунт и не сервис, а конкретную сеть/регион. Это главный признак IP-блокировки в whitelist-режиме.

2. Проверьте маршрут до IP ноды. С проблемной сети:

tracert -d IP_ноды # Windows
traceroute -n IP_ноды # Linux/macOS
mtr -n IP_ноды # если есть — точнее видно, где обрыв

Трасса обрывается на узле оператора и не доходит до сервера — блокируется путь к адресу.

3. Проверьте TCP-порт (это важнее ping). ICMP операторы часто режут сами по себе, поэтому по одному ping судить нельзя. Стучитесь в порт напрямую:

Test-NetConnection IP -Port 443 # PowerShell
nc -vz -w3 IP 443 # Linux/macOS

Порт закрыт со всех клиентских протоколов, но сервер жив с whitelisted-сети — блокировка на стороне сети.

4. Отделите адрес от протокола. На одном IP не заходит ничего (VLESS, Reality, XHTTP, обычный TLS) — это адрес. Один вариант работает, другой нет — это уже про признаки трафика (DPI), и тогда чтение про маскировку и XHTTP по делу.

5. Убедитесь, что нода жива. Зайдите в панель (Remnawave/Marzban/3x-ui) и по SSH с любой рабочей сети. Сервер онлайн, но клиенты из РФ не доходят — окончательное подтверждение.

Вывод: обрыв на пути к IP + закрытый TCP-порт со всех протоколов при живой панели = адрес вне белого списка.

Что бесполезно: смена протокола, порта, SNI и ключей на том же IP

Типичная ошибка после отвала — судорожно перебирать протоколы и порты, оставаясь на том же сервере. В режиме белых списков это не работает по одной причине: фильтрация идёт по адресу назначения, а не по содержимому пакета. Оборудованию всё равно, что внутри — VLESS, Reality, Shadowsocks или XHTTP: если IP не в whitelist, пакет отбрасывается до того, как кто-то посмотрит на протокол.

Что не поможет, если причина в IP:

• Переключение VLESS → Reality → XHTTP на том же сервере.
• Смена порта 443 → 8443 → любого другого на том же IP.
• «Продвинутая» маскировка TLS, подмена SNI, смена фингерпринта.
• Перевыпуск ключей и переустановка клиента.

Всё это адресует DPI по признакам трафика — другой сценарий, когда IP проходит, но поток режут по сигнатуре. Там смена транспорта осмысленна. Но если ваш адрес выпал из белого списка, любые манипуляции с протоколом на том же IP — перестановка мебели в комнате, куда закрыта дверь. Единственное, что меняет ситуацию, — сменить точку входа на адрес, который whitelist пропускает.

Что помогает: точка входа на whitelisted-IP

Раз проблема в адресе ноды, решение — сделать так, чтобы клиент подключался не напрямую к серверу в дата-центре, а к IP из белого диапазона, который дальше свяжется с вашей нодой. Варианты по возрастанию устойчивости:

• Переезд ноды к whitelisted-хостеру. Помогает временно и точечно. По наблюдениям, из российских хостеров стабильно проходит не так много (например, замечен Selectel), а часть облаков — нет; диапазоны меняются, и каждую /24 нужно проверять отдельно. Плюс зарубежный трафик такой сервер уже не спрячет.
• Резидентный/домашний fallback. IP домашнего провайдера часто проходит там, где дата-центр режут, но упирается в CGNAT, узкий upload и нестабильность. Годится как запасной канал, не как основной.
• Фронт через whitelisted-CDN. Клиент подключается к адресу CDN (он в белом списке как легитимная инфраструктура), а CDN проксирует трафик к вашей ноде. Для ТСПУ это обращение к разрешённому ресурсу, а реальный IP сервера наружу не светится — блокировать нечего. Даже если дата-центр вашей ноды режут целиком, точка входа остаётся на белом адресе.

Это и есть ключевой принцип: сервер в ДЦ блокируется легко, устойчивость даёт фронт на whitelisted-IP. Практическая оговорка — раздача через CDN накладывает требования к транспорту (типично XHTTP с корректным режимом под ограничения CDN на HTTP-методы) и настраивается на уровне вашей панели, без переустановки инфраструктуры; детали вынесения ноды за CDN — в отдельном разборе. Специализированные whitelist-CDN для VPN-операторов (класса Clearway) закрывают ровно эту задачу, но это лишь одна из реализаций общего подхода «вынести точку входа в белый диапазон».

Чек-лист: что делать прямо сейчас

1. Подтвердите, что это IP, а не протокол. Проверка с другой сети + трасса и TCP-порт до ноды (раздел о диагностике). Не чините вслепую.
2. Убедитесь, что нода жива — панель и SSH доступны с рабочей сети. Значит, проблема сетевая, а не поломка сервера.
3. Не перебирайте протоколы и порты на том же IP, если блокировка адреса подтвердилась — это потерянное время.
4. Поднимите точку входа на whitelisted-IP — фронт через CDN как основной путь, резидентный канал как запасной.
5. Для пользователей — обновите подписку. Некоторые клиенты кэшируют старый профиль и продолжают долбиться в мёртвый IP; особенно этим грешит Happ на iOS. Принудительно обновите подписку, не помогло — удалите и добавьте заново (re-add).
6. Заложите запас на будущее. Одиночная нода в дата-центре в режиме белых списков нестабильна по определению. Держите фронт на белом адресе и мониторьте, не выпал ли диапазон из whitelist.