Диагностика блокировок: симптом → причина → что делать (большой разбор)

TrustMe · 04.Август.2026 20:25:34

«Не работает VPN» — это не диагноз, а жалоба. За этой фразой прячется минимум пять разных проблем, и лечатся они по-разному: где-то достаточно поменять порт, где-то нужен новый IP, а где-то вы просто упёрлись в шейпер провайдера и никакой смены транспорта не хватит. Самая частая ошибка — начинать с перебора конфигов наугад: человек меняет протокол, потом донора для Reality, потом хостера, тратит вечер и в итоге чинит не то.

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

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

Карта симптомов

Что вы наблюдаете	На что это похоже в первую очередь
Клиент вообще не подключается, таймаут, сервер не пингуется	Блокировка по IP или сервер лежит
SSH к серверу работает, а прокси-порт молчит	Блокировка по порту/протоколу или упавший сервис
Соединение устанавливается и сразу рвётся	SNI/TLS-фингерпринт, реже — обрыв по эвристике
Работает несколько минут, потом умирает и больше не поднимается	Активные пробы с последующей блокировкой
Соединение живо, но скорость деградировала до неюзабельной	Троттлинг (шейпинг), не блокировка
Hysteria2/TUIC нестабильны, а VLESS работает	Режется UDP/QUIC
Не работает у домашнего провайдера, работает с мобильного (или наоборот)	Блокировка на уровне конкретного оператора
Всё работает, кроме отдельных сайтов	Проблема не в туннеле, а в маршрутизации/DNS

Последняя строка важнее, чем кажется: примерно каждый третий «сломанный VPN» на деле оказывается ошибкой в правилах маршрутизации или DNS-резолвинге, а вовсе не блокировкой. Прежде чем перебирать транспорты, убедитесь, что проблема действительно снаружи.

Сценарий 1. Блокировка по IP

Самый грубый и самый частый способ. Ваш адрес просто перестаёт быть доступен из определённой сети — не «плохо работает», а не отвечает ни на одном порту.

Как проверить. Первым делом убедитесь, что сервер жив вообще: зайдите на него через веб-консоль хостера, а не через SSH (SSH может быть заблокирован ровно так же). Дальше сравните доступность из разных сетей:

# с проблемной сети
ping -c 4 ВАШ_IP
mtr -rwc 20 ВАШ_IP        # где именно обрывается маршрут
nc -zv ВАШ_IP 443         # отвечает ли конкретный порт

Ключевой признак — асимметрия по сетям. Если с мобильного интернета сервер доступен, а с домашнего провайдера нет (или наоборот), и при этом сам сервер в полном порядке — это блокировка, а не поломка. mtr покажет, на каком хопе теряются пакеты: обрыв в первых хопах внутри сети оператора говорит сам за себя.

Что делать. Смена IP у того же хостера часто помогает лишь ненадолго, если под блокировку попала вся подсеть — проверьте, доступны ли соседние адреса того же провайдера. Если недоступна вся подсеть или ASN, нужен переезд к другому хостеру, желательно в другую автономную систему. Долгосрочно спасает не «идеальный IP», а привычка иметь второй узел у другого провайдера и уметь переключаться за минуту.

Сценарий 2. Блокировка по SNI и TLS-фингерпринту

Здесь IP доступен, TCP-соединение устанавливается, но TLS-рукопожатие обрывается. Причина в том, что имя домена в ClientHello (SNI) передаётся открытым текстом, и фильтр видит, куда именно вы идёте.

Как проверить. Сравните поведение при разных SNI на одном и том же адресе:

# обращаемся к своему серверу, подставляя разные имена
openssl s_client -connect ВАШ_IP:443 -servername www.microsoft.com </dev/null
openssl s_client -connect ВАШ_IP:443 -servername ваш-домен.example </dev/null

Если с одним именем рукопожатие проходит, а с другим стабильно рвётся на этапе ClientHello — фильтруют по SNI. Отдельно проверьте, доходит ли ответ вообще: curl -v --resolve имя:443:ВАШ_IP https://имя/ покажет, где именно обрывается диалог.

Что делать. Для Reality это означает пересмотр донора: dest и serverNames должны указывать на популярный сторонний сайт с TLS 1.3, который заведомо не блокируют, желательно географически близкий к серверу и не спрятанный за Cloudflare. Проверьте, что на клиенте serverName совпадает с одним из serverNames, а fingerprint выставлен в актуальный браузерный профиль (chrome) — несовпадение отпечатка uTLS с массовым трафиком само по себе становится приметой. Механику Reality подробно разбирали в отдельном гайде.

Сценарий 3. Активные пробы

Характерный почерк: свежий сервер работает нормально несколько часов или дней, а потом внезапно и окончательно перестаёт. Часто это происходит после всплеска трафика — узел «засветился», к нему пришли постучаться, ответ показался подозрительным, адрес уехал в блок.

Как проверить. Смотрите логи вашего сервиса на предмет подключений, которые не прошли аутентификацию: незнакомые адреса, странные запросы, попытки говорить не тем протоколом. В Xray и sing-box такие соединения видны при поднятом уровне логирования. Признак пробы — обращение, которое приходит не от ваших клиентов и заканчивается ничем.

Что делать. Именно от этого защищает Reality со своим fallback: неаутентифицированный запрос проваливается на настоящий сайт-донор, и пробующий получает нормальный контент вместо подозрительного молчания или ошибки. Дополнительно помогает не светить узел лишний раз: не публиковать адрес в открытых чатах, использовать разные shortIds для разных групп пользователей, не держать на том же адресе очевидных «маркеров» вроде дефолтных панелей на стандартных портах, открытых наружу.

Сценарий 4. Троттлинг

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

Как проверить. Задача — отличить деградацию канала от деградации именно вашего трафика:

# скорость «чистого» HTTPS до того же сервера — для сравнения
curl -o /dev/null -w 'speed: %{speed_download} B/s\n' https://ВАШ_IP/большой_файл

# синтетика между вашим клиентом и сервером
iperf3 -c ВАШ_IP -p ПОРТ -t 30
iperf3 -c ВАШ_IP -p ПОРТ -u -b 100M -t 30   # то же по UDP

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

Что делать. Пробуйте сменить транспорт и порт: иногда достаточно уйти с очевидного сочетания на другое (RAW/XHTTP в терминах Xray). Проверьте, не упираетесь ли вы в MTU — при туннелировании фрагментация даёт ровно такую картину «работает, но медленно». И честно допустите вариант, что вас никто не режет, а просто канал плохой: измерение до соседнего сервера у другого хостера быстро расставит всё по местам.

Сценарий 5. Режется UDP и QUIC

Отдельная история для тех, кто перешёл на Hysteria2 или TUIC. Эти протоколы построены поверх QUIC, то есть работают по UDP, а UDP на пути к вам может резаться, приоритизироваться по остаточному принципу или просто теряться.

Как проверить. Сравните поведение TCP- и UDP-транспортов на одном сервере. Если VLESS поверх TCP держится стабильно, а Hysteria2 постоянно рассыпается на потерях — дело в UDP. Тест iperf3 -u из предыдущего раздела покажет процент потерь: единицы процентов терпимы, десятки означают, что UDP до вас доходит плохо.

Что делать. Держите TCP-вариант как запасной путь. Полезно понимать общую расстановку: в Xray транспорты RAW, XHTTP, WebSocket, gRPC и HTTPUpgrade работают поверх TCP, а mKCP и Hysteria — поверх UDP; WebSocket и HTTPUpgrade вдобавок дружат с CDN, потому что выглядят как обычный HTTP. То есть при проблемах с UDP логичный маневр — переключиться на TCP-транспорт с Reality, а если режут и это, посмотреть в сторону CDN-совместимого варианта.

Алгоритм на десять минут

Когда «всё сломалось» и думать некогда, порядок такой:

Проверьте сервер, а не туннель. Веб-консоль хостера, systemctl status вашего сервиса, свободное место на диске. Удивительно часто виноват не цензор, а забитый лог или упавший контейнер.
Проверьте с другой сети. Мобильный интернет против домашнего провайдера. Асимметрия сразу отделяет блокировку от поломки.
Проверьте IP и порт отдельно. ping, mtr, nc -zv — доступен ли адрес вообще и отвечает ли конкретный порт.
Проверьте TLS. openssl s_client с разными SNI: рвётся ли рукопожатие и на каком именно имени.
Сравните транспорты. TCP против UDP, другой порт — сужает круг до конкретного механизма.
Измерьте скорость. Если соединение живо, но медленное, вы имеете дело с троттлингом или каналом, а не с блокировкой, и лечение совсем другое.

Главное правило: меняйте по одному параметру за раз и записывайте, что уже проверили. Иначе через час вы будете смотреть на конфиг, в котором изменено семь вещей, и не сможете сказать, какая из них помогла или сломала.

Что стоит подготовить заранее

Диагностика тем быстрее, чем больше вы подготовили до того, как всё сломалось. Минимальный набор: второй узел у другого хостера в другой автономной системе — не для постоянной работы, а чтобы за минуту переключиться и понять, дело в конкретном сервере или во всём сразу. Запасной транспорт, настроенный и проверенный заранее, а не «в момент, когда уже не работает». Доступ к серверу помимо SSH — веб-консоль хостера спасает, когда заблокирован именно ваш адрес. И записанный baseline: какая скорость и пинг были, когда всё работало хорошо. Без этой цифры вы не отличите «стало хуже» от «всегда так было».

Источники

А какой сценарий у вас встречался чаще всего — тихая блокировка IP или троттлинг, который сначала принимали за блокировку? И какие проверки вы делаете первыми, когда «перестало работать»?