Симптом выглядит однозначно: без VPN браузер долго ждёт или показывает ошибку, а после подключения к VPN тот же адрес открывается. Но это ещё не доказывает блокировку. VPN меняет сетевой маршрут и внешний IP-адрес, часто использует другой DNS-резолвер, а иногда иначе обрабатывает IPv4, IPv6 и транспортные протоколы. Поэтому владельцу сайта важно не угадывать причину, а сравнить результаты по уровням: DNS, маршрут, TCP, TLS, HTTP и правила CDN или WAF.
Ниже — последовательная диагностика, которая помогает отделить локальную проблему от сбоя у провайдера, ошибки конфигурации сайта и ограничения доступа.
Короткий ответ: что делать в первую очередь
Если сайт открывается только через VPN, выполните четыре проверки:
- Откройте тот же URL без VPN через домашний интернет и через мобильную сеть.
- Сравните DNS-ответы, включая записи A и AAAA.
- Отдельно проверьте подключение по IPv4 и IPv6.
- Сохраните точное время ошибки, текст сообщения браузера, результат HTTP-запроса и трассировку маршрута.
Одна успешная загрузка через VPN показывает лишь то, что сайт доступен по другому сетевому пути. Она не объясняет, где именно ломается обычное подключение.
Почему VPN может «починить» сайт
Меняется DNS-резолвер
Без VPN устройство обычно получает DNS-настройки от роутера или оператора. VPN-клиент может направить запросы к другому резолверу. Если у провайдера сохранился устаревший ответ, перехватывается DNS-трафик или одна из авторитетных DNS-зон отвечает нестабильно, через VPN домен может разрешаться иначе.
Сравнивать нужно не только наличие ответа, но и сами записи. Для веб-сайта особенно важны A для IPv4 и AAAA для IPv6. Разные IP-адреса допустимы у CDN, однако неожиданное расхождение — повод проверить настройки зоны и панель провайдера DNS.
Меняется маршрут и внешний IP
Трафик без VPN идёт от сети пользователя к хостингу или ближайшей точке CDN по маршруту, выбранному операторами. Через VPN сначала устанавливается туннель до промежуточного узла, а уже оттуда запрос идёт к сайту. Так можно обойти проблемный участок маршрутизации, но одновременно меняется внешний IP посетителя.
Это важно для диагностики WAF: сайт может разрешать запросы от IP VPN и отклонять обычный адрес пользователя из-за правила по стране, ASN, репутации адреса или частоте запросов. Такой случай отличается от ограничения на стороне интернет-провайдера.
Может измениться выбор IPv4, IPv6 или протокола
На обычном подключении браузер способен предпочесть IPv6, а внутри VPN использовать IPv4. Если у домена опубликована AAAA-запись, но сервер по IPv6 недоступен, результат будет похож на «сайт работает только с VPN». Похожая картина возможна при различиях сетевого пути для TLS, HTTP/2 или HTTP/3.
Сам по себе TLS 1.3, HTTP/2 или конкретный браузер не доказывает блокировку. Отключать современные протоколы на production вслепую не стоит: сначала нужно подтвердить, что ошибка воспроизводится только при определённом сочетании сети и протокола.
Зафиксируйте исходные данные до изменений
Проверки полезны только тогда, когда их можно сопоставить. Запишите:
- полный URL, включая протокол и путь;
- дату, время и часовой пояс;
- название провайдера и тип подключения: кабель, Wi-Fi или мобильная сеть;
- регион пользователя;
- точный текст ошибки браузера;
- загружается ли главная страница и ломаются ли внутренние URL;
- работает ли сайт в другом браузере на том же подключении;
- что происходит с VPN и без него на одном устройстве.
Не меняйте одновременно DNS, CDN, сертификат и настройки сервера. После нескольких параллельных изменений невозможно понять, какое из них повлияло на результат.
Диагностика по уровням
1. Сравните DNS
Проверьте домен через системный резолвер:
nslookup example.ruЗатем сравните ответ с публичным DNS-сервисом или с результатом из другой сети. Смотрите записи A, AAAA и CNAME. Если без VPN возвращается другой адрес, ошибка DNS становится рабочей гипотезой. Если адреса одинаковы, переходите к проверке подключения: корректный DNS-ответ ещё не означает доступность веб-сервера.
Официальное руководство Google Public DNS рекомендует отдельно проверять разрешение домена и сетевую доступность резолвера, а при обращении за помощью сохранять диагностический вывод. Этот принцип полезен и для любого другого DNS-провайдера.
2. Проверьте IPv4 и IPv6 отдельно
На компьютере с curl можно выполнить:
curl -4 -I -v https://example.ru/
curl -6 -I -v https://example.ru/Если IPv4 стабильно отвечает, а IPv6 завершается тайм-аутом или ошибкой маршрута, проверьте AAAA-запись, доступность сервера по IPv6 и правила firewall. Не удаляйте AAAA только потому, что один клиент получил ошибку: повторите тест из другой сети и убедитесь, что проблема относится именно к IPv6.
3. Посмотрите маршрут
Для Windows подойдёт:
tracert example.ru
tracert -6 example.ruДля Linux и macOS:
traceroute example.ru
traceroute -6 example.ruПри плавающем сбое полезен MTR, который повторяет измерения и показывает задержку по пути. Но звёздочки на промежуточном узле не являются самостоятельным доказательством поломки: маршрутизатор может не отвечать на диагностические пакеты и при этом нормально пересылать веб-трафик. Важнее сравнить трассировки с VPN и без него, по IPv4 и IPv6, а также проверить, достигается ли конечный адрес.
4. Отделите TLS от HTTP
Команда curl -I -v показывает этап, на котором оборвалось соединение. Возможны разные результаты:
- соединение не установлено — проверяйте маршрут, firewall и доступность порта;
- TLS-рукопожатие завершилось ошибкой — проверяйте сертификат, имя хоста и настройки TLS;
- сервер вернул 403 или страницу проверки — изучайте WAF, CDN и правила доступа;
- получен 5xx — ищите проблему на origin-сервере или обратном прокси;
- ответ 200 пришёл, но браузер не загрузил страницу — проверяйте ресурсы, JavaScript и сетевой журнал браузера.
Для сравнения можно выполнить запросы по HTTP/1.1 и HTTP/2:
curl --http1.1 -I -v https://example.ru/
curl --http2 -I -v https://example.ru/Разница между результатами помогает сузить поиск, но не называет виновника автоматически. Нужны логи сервера, CDN и точное время запроса.
5. Проверьте CDN и WAF
Если сайт использует CDN, сравните аналитику по регионам, события безопасности и ошибки в момент обращения. Ищите блоки по IP, ASN, стране, User-Agent и частоте запросов. Убедитесь, что origin доступен CDN и не блокирует адреса его узлов.
Не публикуйте origin-IP и не отключайте защиту целиком ради теста. Безопаснее создать ограниченное диагностическое правило, проверить конкретный запрос и затем удалить исключение.
Как читать сочетания результатов
Несколько типичных сценариев помогают выбрать следующую проверку:
- сайт работает через VPN и мобильную сеть, но не работает у одного проводного провайдера — вероятна проблема маршрута или политики этого провайдера;
- через разные сети домен получает разные устаревшие адреса — сначала проверяйте DNS и распространение актуальных записей;
- по IPv4 сайт отвечает, а по IPv6 нет — проверяйте AAAA, IPv6-маршрут и firewall;
- без VPN приходит 403, а сервер или CDN фиксирует запрос — проверяйте WAF и правила по источнику;
- без VPN соединение обрывается до HTTP и запросов нет в логах сайта — изучайте маршрут, TCP/TLS и данные оператора;
- сбой повторяется и с VPN, и без него из нескольких сетей — причина, скорее всего, ближе к CDN, хостингу или origin-серверу.
Слово «вероятна» здесь принципиально. Один тест формирует гипотезу, а не окончательный диагноз.
Что учитывать владельцам сайтов с аудиторией в России
У некоторых провайдеров возможны ограничения или деградация доступа к отдельным IP-адресам и сетям. В актуальной справке Cloudflare есть отдельные материалы о возможном нарушении доступа для пользователей из России и о блокировке общих IP-адресов на уровне интернет-провайдера. Cloudflare также подчёркивает, что ограничение провайдера нужно отличать от правил, настроенных владельцем сайта в WAF.
Эти сведения относятся к инфраструктуре Cloudflare и не объясняют автоматически любой случай «работает только через VPN». Если сайт использует другого поставщика или проблема заметна у одного пользователя, всё равно начинайте со сравнительных измерений. Не приписывайте сбой ТСПУ, TLS 1.3, CDN или хостингу без подтверждающих данных.
Как проверить доступность из нескольких точек
Попросите двух-трёх затронутых пользователей выполнить одинаковую проверку и указать провайдера, регион и время. Дополнительно можно проверить сайт онлайн и сравнить результат с локальным браузером.
Для более глубокой сетевой диагностики подходит RIPE Atlas: его распределённые узлы выполняют DNS, ping, traceroute, TLS и HTTP-измерения. Результаты из нескольких сетей помогают увидеть частичную доступность, но их тоже нужно интерпретировать осторожно: состав узлов и маршрут конкретного клиента могут отличаться.
Чтобы не ждать ручных жалоб, можно добавить URL в Web-Puls. Регулярный внешний мониторинг покажет историю ответов и время появления сбоя. Однако проверка из одной внешней точки не заменяет региональные тесты, если проблема проявляется только у части провайдеров.
Что передать хостингу, CDN или интернет-провайдеру
Хорошая заявка содержит факты, которые можно сопоставить с логами:
- домен и точные URL;
- время каждого неудачного теста с часовым поясом;
- сеть, регион и внешний IP пользователя, если его безопасно передать поддержке;
- ответы A и AAAA;
- результаты curl по IPv4 и IPv6;
- трассировку или MTR до адреса сайта;
- текст ошибки и скриншот без персональных данных;
- результат с VPN и без него;
- идентификатор запроса CDN, если он отображается;
- сведения о наличии или отсутствии запроса в серверных логах.
Если проблему нужно не только зафиксировать, но и технически разобрать, можно отправить заявку на профессиональную поддержку или воспользоваться контактной информацией. Не передавайте в открытом сообщении пароли, cookie, токены и несаницированные HAR-файлы.
Чего не стоит делать
Не используйте VPN как постоянное «исправление» для посетителей: это обход симптома, а не восстановление обычной доступности. Не меняйте IP-адрес, DNS-провайдера, CDN и TLS-настройки одновременно. Не отключайте IPv6 или современные протоколы для всех пользователей без подтверждённого теста. И не обещайте, что смена одного параметра снимет внешнее ограничение: сначала соберите доказательства, затем меняйте минимально необходимую часть конфигурации.
Вывод
Когда сайт открывается только через VPN, правильный вопрос звучит не «кто заблокировал сайт», а «на каком уровне расходятся два подключения». Сначала зафиксируйте симптом, затем сравните DNS, IPv4 и IPv6, маршрут, TLS, HTTP и события CDN. Проверки из нескольких сетей и история мониторинга превращают предположение в воспроизводимый инцидент, с которым уже можно обращаться к провайдеру, хостингу или техническому специалисту.