Сайт не открывается в России: как отключение TLS 1.3 помогло моим сайтам и что делать при проблемах с ТСПУ

Обновлено: 2 сентября 2026 года.

Недавно у меня возникла довольно неприятная проблема: несколько сайтов на сервере работали, сам сервер был доступен, но часть пользователей из России не могла нормально открыть страницы.

На первый взгляд всё выглядело так, будто неисправность находится где-то на сервере. Я проверял обычные вещи, которые проверяет разработчик в такой ситуации, но в итоге причина оказалась не в WordPress, PHP или базе данных.

Я написал в поддержку Beget и получил конкретную рекомендацию: временно отключить TLS 1.3 в конфигурации веб-сервера и оставить TLS 1.2.

ssl_protocols TLSv1.2;

После изменения конфигурации мои сайты снова стали нормально открываться.

Самое интересное в этой истории то, что сервер до этого не был «сломан». Проблема проявлялась именно при подключении пользователей через определённые сети. Поэтому я решил подробно разобраться, что сейчас происходит с доступностью сайтов в России, как сюда относятся ТСПУ Роскомнадзора, TLS 1.3, HTTP/3, QUIC, разные браузеры и почему привычная проверка «у меня сайт открывается» уже ничего толком не доказывает.

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

Если сайт не работает прямо сейчас

Если сайт работает через VPN или другую сеть, а часть пользователей в России его не открывает, и у вас есть собственный VPS/VDS с Nginx, можно проверить тот же вариант, который помог мне.

sudo nginx -T 2>/dev/null | grep -n ssl_protocols

Если в активной конфигурации используется:

ssl_protocols TLSv1.2 TLSv1.3;

для теста можно оставить:

ssl_protocols TLSv1.2;

После изменения сначала обязательно проверяем конфигурацию:

sudo nginx -t

Только если Nginx сообщает, что синтаксис корректен, применяем настройку:

sudo systemctl reload nginx

Не делайте это вслепую на рабочем сервере с десятками проектов. Сначала сделайте резервную копию конфигурации. Если сервер управляется FASTPANEL, ISPmanager, Plesk, Hestia или другой панелью, настройки могут генерироваться автоматически.

Содержание

• Что произошло с моими сайтами
• Что говорит сам Beget
• Сайт заблокирован или просто не открывается
• Что такое ТСПУ и при чём здесь Роскомнадзор
• Какую роль играет Минцифры
• Что такое TLS 1.2 и TLS 1.3
• Почему Chrome может не работать, а Firefox работает
• HTTP/3 и QUIC
• Полная диагностика сайта
• Как отключить TLS 1.3 в Nginx
• Настройка Apache
• Что делать на обычном виртуальном хостинге
• Готовое обращение в техподдержку
• Как понять, доходит ли запрос до сервера
• Чем недоступность сайта опасна для SEO
• Частые вопросы
• Если самостоятельно решить проблему не получилось

Что произошло с моими сайтами

История началась не с падения сервера. Именно поэтому проблема сначала выглядела странно.

Если сервер действительно умер, обычно всё достаточно очевидно: не отвечает IP, не работает SSH, мониторинг показывает недоступность, Nginx или Apache остановлен. Здесь картина была другой. Сервер продолжал работать, но доступность сайтов зависела от того, откуда к ним подключались.

Я обратился в поддержку Beget и получил такой совет для Nginx:

ssl_protocols TLSv1.2;

То есть вместо поддержки TLS 1.2 и TLS 1.3 серверу предложили временно использовать только TLS 1.2.

После применения настройки сайты заработали. Для меня это стало важным практическим наблюдением: проблема находилась не на уровне самого WordPress. Изменение поведения TLS-соединения оказалось достаточным, чтобы доступ восстановился.

Это не означает, что любой сайт в России нужно срочно переводить на TLS 1.2. Если ваш проект нормально работает, трогать конфигурацию только ради эксперимента я бы не стал.

Но если симптомы похожи на мои, такой тест имеет смысл.

Beget публично описывает похожую проблему

После моего случая я посмотрел, что сам Beget пишет о текущей ситуации. У компании есть отдельный материал о проблемах доступности сервисов в Рунете. Beget сообщает, что его серверы могут работать штатно, а сложности при этом возникают на стороне внешней сетевой инфраструктуры и автоматических систем фильтрации трафика.

Компания отдельно отмечает избирательный характер проблемы: один сайт может открываться у одних пользователей и не открываться у других в зависимости от оператора и региона. Среди предлагаемых технических вариантов есть именно временное использование TLS 1.2 вместо TLS 1.3.

Причём Beget предупреждает, что универсального решения нет. Сетевые алгоритмы меняются, поэтому настройка, которая помогает сегодня, не обязательно останется актуальной навсегда.

На обычном виртуальном хостинге Beget самостоятельно отключить TLS 1.3 нельзя. Для этого нужен сервер, которым вы управляете сами, либо помощь хостинг-провайдера.

Сначала надо понять: сайт заблокирован или просто не открывается?

Это разные ситуации, хотя для посетителя выглядят одинаково: он нажимает ссылку и не получает страницу.

В России существует официальный механизм ограничения доступа к интернет-ресурсам. Если ограничение относится непосредственно к вашему домену или странице, изменение версии TLS не устраняет юридическую причину такого ограничения.

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

По одной ошибке ERR_CONNECTION_RESET определить блокировку нельзя. То же касается ERR_CONNECTION_TIMED_OUT. Такие ошибки могут появляться из-за маршрутизации, firewall, IPv6, CDN, TLS, самого веб-сервера и ещё десятка причин.

Что такое ТСПУ и при чём здесь Роскомнадзор

ТСПУ — технические средства противодействия угрозам. В российском законодательстве работа такого механизма связана с централизованным управлением сетью связи общего пользования.

Статья 65.1 Федерального закона №126-ФЗ «О связи» предусматривает мониторинг функционирования сетей и централизованное управление при возникновении угроз устойчивости, безопасности и целостности сети.

С 1 марта 2026 года действуют новые Правила централизованного управления сетью связи общего пользования, утверждённые постановлением Правительства РФ №1667 от 27 октября 2025 года. Само постановление официально опубликовано 6 ноября 2025 года.

Для владельца сайта здесь важна практическая сторона. Между браузером пользователя и вашим Nginx находится инфраструктура оператора связи, и сетевой трафик не обязательно проходит до сервера совершенно прозрачно.

Я бы при этом не писал «Роскомнадзор заблокировал мой сайт», пока это не подтверждено. В моём случае корректнее говорить о проблеме доступности, которая исчезла после изменения TLS-конфигурации.

Что такое DPI

Рядом с темой ТСПУ часто встречается аббревиатура DPI — Deep Packet Inspection, или глубокий анализ трафика.

Фильтрация сети давно не сводится к простой таблице запрещённых IP-адресов. Система может учитывать характеристики соединения: протокол, порт, SNI, данные TLS ClientHello, набор поддерживаемых алгоритмов, расширения TLS, ALPN, особенности QUIC и другие доступные ей признаки.

Само содержимое HTTPS-страницы при этом расшифровывать не обязательно. Много информации можно получить ещё на этапе установки соединения.

А что делает Минцифры?

Здесь в обсуждениях часто всё смешивают в одну кучу: Минцифры, Роскомнадзор, операторы и ТСПУ. Это не одно и то же.

Если сильно упростить, Роскомнадзор непосредственно связан с надзором и механизмом централизованного управления сетью, а Минцифры занимается государственной политикой и регулированием отрасли связи и цифрового развития.

Например, отдельно существует тема перечней сервисов, которым обеспечивается доступность во время временных ограничений мобильного интернета. В СМИ и обычной речи их часто называют «белыми списками». Это другой механизм, и связывать его напрямую с моей проблемой TLS 1.3 оснований нет.

Поэтому я бы не формулировал ситуацию как «Минцифры отключает сайты». Такая фраза удобна для громкого заголовка, но плохо описывает реальную техническую картину.

Что такое TLS 1.2 и TLS 1.3 и почему изменение версии вообще может помочь

Когда браузер открывает адрес с https://, перед передачей обычной страницы устанавливается защищённое TLS-соединение.

Современный Nginx по умолчанию поддерживает TLS 1.2 и TLS 1.3. Это прямо указано в документации Nginx.

ssl_protocols TLSv1.2 TLSv1.3;

TLS 1.3 новее и обычно его нет никаких причин отключать. Поэтому совет Beget сначала показался мне странным.

Но TLS 1.2 и TLS 1.3 — это не просто две надписи в конфиге. Меняется сам процесс согласования защищённого соединения. Если промежуточное сетевое оборудование по-разному обрабатывает разные варианты TLS-сеанса, изменение списка доступных протоколов способно повлиять на результат.

Важно ещё одно: если сервер предлагает и TLS 1.2, и TLS 1.3, это не означает, что браузер при любой сетевой проблеме обязательно попробует повторить соединение через TLS 1.2. Поэтому конфигурация «TLS 1.2 + TLS 1.3» и конфигурация «только TLS 1.2» в реальной сети могут вести себя по-разному.

Означает ли это, что TLS 1.3 запрещён в России?

Нет. Из моего опыта этого вывода сделать нельзя.

Я могу утверждать только то, что проверил сам: на моём сервере сайты испытывали проблемы с доступностью, поддержка Beget предложила отключить TLS 1.3, после изменения конфигурации доступ восстановился.

Причину конкретного поведения сетевой фильтрации без данных оператора или оборудования ТСПУ установить гораздо сложнее.

Почему сайт может работать в Firefox и не работать в Chrome

Beget в своём разборе отдельно советует при проблемах проверить Firefox и пишет о чувствительности систем фильтрации к параметрам браузеров на Chromium и WebKit.

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

Технически ничего мистического здесь нет. Разные программы могут по-разному формировать TLS ClientHello и использовать разные наборы параметров соединения.

В анализе сетевого трафика давно используются TLS fingerprint — своеобразные отпечатки клиента. Известные семейства таких методов называются JA3 и JA4. Они применяются не только для фильтрации: TLS fingerprint используют антибот-системы, WAF и средства информационной безопасности.

Поэтому тест с другим браузером я теперь считаю вполне нормальной частью диагностики.

Не надо путать TLS 1.3 и HTTP/3

В первой версии этой статьи, которую я делал для себя, слишком много внимания было уделено HTTP/3. После дополнительной проверки я бы так уже не писал.

HTTP/2 обычно передаётся поверх TCP и TLS. HTTP/3 работает поверх QUIC и UDP. QUIC использует TLS 1.3, но из этого не следует, что любая проблема TLS 1.3 связана именно с HTTP/3.

HTTP/2
  ↓
TLS
  ↓
TCP
  ↓
порт 443

HTTP/3 идёт другим путём:

HTTP/3
  ↓
QUIC
  ↓
UDP
  ↓
порт 443

В 2026 году исследователи Paderborn University опубликовали работу о российской фильтрации QUIC. Они обнаружили масштабное использование SNI-зависимой фильтрации QUIC устройствами ТСПУ.

Это хороший пример того, насколько сложнее стала современная фильтрация трафика. Однако этим исследованием нельзя доказывать, что мой конкретный случай с TLS 1.3 произошёл из-за QUIC. На сервере HTTP/3 может вообще не использоваться.

Что я бы тестировал сначала

Если сервер использует HTTP/3, сначала имеет смысл временно отключить именно его, сохранив TLS 1.3 для обычного HTTPS через TCP. Если проблема останется, можно отдельно протестировать TLS 1.2-only.

Так проще понять, какое изменение действительно помогло.

Как я бы сейчас диагностировал такой сайт

Первое правило — проводить часть проверок именно из проблемной сети. Если вы подключились по SSH к тому же серверу и оттуда выполняете curl https://site.ru, вы проверяете совсем другой сетевой маршрут.

1. Проверить DNS

dig +short site.ru

Если dig не установлен:

nslookup site.ru

Сравните полученный IP с реальным IP сервера или CDN.

2. Проверить IPv4

curl -4 -vkI https://site.ru/

3. Проверить IPv6

curl -6 -vkI https://site.ru/

Если через IPv4 сайт работает, а через IPv6 нет, сначала разберитесь с IPv6. Очень часто проблема оказывается банальнее, чем ТСПУ.

Особенно внимательно смотрите на DNS-запись AAAA. Если она есть, сервер должен действительно нормально принимать IPv6-соединения.

4. Проверить TCP-порт 443

nc -vz site.ru 443

Если TCP-соединение вообще не устанавливается, нет смысла сразу ковырять TLS. Сначала надо смотреть маршрут, firewall, IP и доступность порта.

5. Посмотреть HTTPS-соединение подробно

curl -vkI https://site.ru/

В выводе видно, к какому IP подключился curl, начался ли TLS handshake, какая версия TLS согласована, какой сертификат вернул сервер и удалось ли получить HTTP-ответ.

6. Отдельно проверить TLS 1.2

openssl s_client \
-connect site.ru:443 \
-servername site.ru \
-tls1_2

7. Отдельно проверить TLS 1.3

openssl s_client \
-connect site.ru:443 \
-servername site.ru \
-tls1_3

Если TLS 1.2 устанавливается нормально, а попытка TLS 1.3 из той же сети заканчивается timeout или reset, это уже полезный результат для дальнейшего разговора с хостером.

8. Проверить HTTP/2

curl --http2 -I https://site.ru/

Не все сборки curl поддерживают HTTP/2. Версию и возможности можно посмотреть:

curl -V

9. Проверить HTTP/3, если он вообще включён

curl --http3 -I https://site.ru/

Эта команда сработает только в сборке curl с поддержкой HTTP/3.

10. Сравнить несколько сетей

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

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

11. Сравнить браузеры

Проверяйте как минимум Chrome/Edge и Firefox. Если проблема проявляется только в одном семействе браузеров, обязательно сообщите это хостеру.

Как отключить TLS 1.3 в Nginx

Теперь непосредственно к варианту, который сработал у меня.

Сначала надо понять, где Nginx получает настройку ssl_protocols.

sudo nginx -T 2>/dev/null | grep -n ssl_protocols

Можно также поискать по конфигурационным файлам:

sudo grep -Rni "ssl_protocols" /etc/nginx /etc/letsencrypt 2>/dev/null

Обычно можно встретить что-то похожее на:

/etc/nginx/nginx.conf
/etc/nginx/sites-available/site.ru.conf
/etc/nginx/conf.d/
/etc/letsencrypt/options-ssl-nginx.conf

Перед изменением сделайте копию

sudo cp /etc/nginx/sites-available/site.ru.conf \
/etc/nginx/sites-available/site.ru.conf.$(date +%F-%H%M).bak

Путь, разумеется, должен соответствовать вашей конфигурации.

Меняем список TLS-протоколов

Было:

ssl_protocols TLSv1.2 TLSv1.3;

Для теста:

ssl_protocols TLSv1.2;

Редактировать можно через nano:

sudo nano /etc/nginx/sites-available/site.ru.conf

После сохранения никаких restart наугад. Сначала:

sudo nginx -t

Если вывод содержит:

syntax is ok
test is successful

применяем:

sudo systemctl reload nginx

Я предпочитаю reload, а не полный restart, если для перезапуска нет отдельной причины.

После изменения проверяем результат

openssl s_client \
-connect site.ru:443 \
-servername site.ru \
-tls1_2

TLS 1.2 должен успешно согласовываться.

А команда:

openssl s_client \
-connect site.ru:443 \
-servername site.ru \
-tls1_3

не должна устанавливать соединение TLS 1.3, если он действительно отключён.

Особенность Nginx с несколькими сайтами на одном IP

Вот здесь легко наступить на грабли.

Директива ssl_protocols разрешена как на уровне http, так и на уровне server. Но документация Nginx предупреждает, что при виртуальных HTTPS-серверах значение может зависеть от default server и используемой TLS-библиотеки.

Если на одном IP работает много HTTPS-сайтов, я бы не менял эту настройку на продакшене, не посмотрев сначала вывод:

sudo nginx -T

Нужно понимать, какой блок является default_server для 443-го порта и где в действительности задаётся TLS-конфигурация.

Это особенно важно на сервере с панелью управления или большим количеством проектов.

Если используется Certbot

Beget отдельно рекомендует проверить файл:

/etc/letsencrypt/options-ssl-nginx.conf

Наличие настройки можно проверить:

sudo grep -n "ssl_protocols" \
/etc/letsencrypt/options-ssl-nginx.conf

Не редактируйте этот файл только потому, что он существует. Сначала через nginx -T убедитесь, что он действительно подключён к активной конфигурации.

Что делать с Apache

Для Apache путь к SSL-конфигурации зависит от дистрибутива.

sudo grep -Rni "SSLProtocol" \
/etc/apache2 /etc/httpd /etc/letsencrypt 2>/dev/null

Beget приводит для режима TLS 1.2 такую настройку:

SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1 -TLSv1.3 +TLSv1.2

После изменения в Ubuntu/Debian:

sudo apachectl configtest

Если конфигурация корректна:

sudo systemctl reload apache2

В CentOS, AlmaLinux или Rocky Linux сервис может называться httpd:

sudo systemctl reload httpd

Если у вас Nginx перед Apache

Очень распространённая конфигурация на хостингах и серверах с панелями выглядит так:

Интернет
   ↓
Nginx
   ↓
Apache
   ↓
PHP / WordPress

В этом случае TLS от браузера пользователя обычно завершается именно на внешнем Nginx. Изменение SSLProtocol во внутреннем Apache может вообще никак не повлиять на соединение посетителя.

Сначала посмотрите, какой процесс слушает порт 443:

sudo ss -lntp | grep ':443'

Эта простая проверка иногда экономит час бесполезного редактирования не того сервиса.

Если у вас обычный виртуальный хостинг

На виртуальном хостинге у клиента обычно нет root-доступа и возможности менять глобальную TLS-конфигурацию веб-сервера.

Не пытайтесь искать команду SSH, которая магически даст доступ к /etc/nginx. Если провайдер не предоставляет управление TLS-протоколами, вопрос должен решать сам хостер.

У Beget для сайтов на виртуальном хостинге TLS 1.3 самостоятельно отключить нельзя. Компания указывает это прямо в своей инструкции.

Что написать хостинг-провайдеру

Если вы не администрируете сервер сами, можете отправить в поддержку примерно такое сообщение.

Здравствуйте.

Возникла выборочная проблема с доступностью сайта из российских сетей.

Домен: site.ru

IP сервера: укажите IP

Сам сайт и сервер работают, но часть пользователей не может установить нормальное HTTPS-соединение. Через другую сеть или VPN ресурс открывается.

Прошу проверить доступность TCP/443, IPv4/IPv6, TLS 1.2 и TLS 1.3, а также HTTP/2 и HTTP/3/QUIC, если HTTP/3 используется.

Также прошу проверить возможное влияние внешней сетевой фильтрации и маршрутизации.

Если возможно, прошу временно протестировать конфигурацию TLS 1.2-only без TLS 1.3 и проверить доступность сайта из нескольких российских сетей.

Для Nginx тестовая настройка:

ssl_protocols TLSv1.2;

Перед применением прошу сохранить действующую конфигурацию и проверить её корректность.

Что приложить к тикету

Хорошо, если вместе с обращением вы сообщите провайдера, регион, внешний IP пользователя, точное время ошибки, браузер, IP сервера и результат проверки через другую сеть.

Beget при собственной диагностике также просит исходящий IP пользователя, IP сервера и порт подключения.

Если вам отвечают «с нашей стороны всё работает»

Такой ответ не обязательно означает, что поддержка вас отфутболивает. Из сети дата-центра сайт действительно может работать идеально.

В ответ стоит уточнить, что проблема воспроизводится именно из внешней сети конкретного российского оператора, а не внутри инфраструктуры хостинга.

Сервер локально доступен. Проблема воспроизводится на внешнем подключении: через одного оператора сайт не открывается, через другую сеть открывается. Прошу проверить сетевой путь и отдельно сравнить соединение с TLS 1.2 и TLS 1.3.

Как понять, доходит ли проблемный пользователь до Nginx

Это один из моих любимых тестов, потому что он быстро отсекает половину версий.

На сервере открываем access log:

sudo tail -f /var/log/nginx/access.log

Параллельно пользователь из проблемной сети пытается открыть сайт.

Если запрос появляется в access log, значит он дошёл как минимум до HTTP-уровня Nginx.

Если браузер висит или выдаёт ошибку, а в access log вообще ничего нет, надо смотреть раньше: TCP, TLS, маршрутизацию или внешний сетевой путь.

Error log:

sudo tail -f /var/log/nginx/error.log

Для systemd:

sudo journalctl -u nginx --since "30 minutes ago"

Проверяем firewall

На Ubuntu с UFW:

sudo ufw status verbose

Для обычного HTTPS должен быть доступен TCP 443. Если вы используете HTTP/3, понадобится ещё UDP 443.

Если сервер использует nftables:

sudo nft list ruleset

Почему ping здесь почти бесполезен

Я периодически вижу такой диагноз:

Пинг идёт, значит сервер точно работает.

Ping проверяет ICMP. HTTPS использует TCP 443, TLS и затем HTTP. Это разные уровни.

Сервер может отвечать на ping и при этом не принимать HTTPS-соединения. Может быть и наоборот: ICMP специально закрыт firewall, а сайт прекрасно работает.

CDN тоже может менять картину

Если перед сайтом стоит CDN или reverse proxy, пользователь подключается уже не напрямую к вашему серверу.

Пользователь
   ↓
оператор связи
   ↓
CDN / reverse proxy
   ↓
ваш сервер

Поэтому отдельно проверяйте DNS, IP CDN, TLS на внешнем узле и соединение CDN с origin-сервером.

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

Стоит ли менять IP или переносить сервер?

Не первым действием.

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

Сначала проведите сравнительные тесты.

Если на сервере много сайтов

Здесь особенно аккуратно.

Когда на одном Nginx работают десять, двадцать или пятьдесят проектов, изменение общей TLS-конфигурации способно затронуть их все.

Перед изменением я бы сохранил полный вывод конфигурации:

sudo nginx -T > /root/nginx-config-before-tls-change.txt

И резервную копию каталога:

sudo tar -czf /root/nginx-backup-$(date +%F-%H%M).tar.gz /etc/nginx

После этого уже можно экспериментировать, понимая, как быстро вернуть исходное состояние.

Что делать с FASTPANEL, ISPmanager, Plesk и другими панелями

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

Поэтому сначала выясните, предусмотрены ли в вашей панели пользовательские директивы Nginx или Apache.

Если сервер рабочий и на нём находятся клиентские проекты, я бы не экспериментировал с шаблонами панели без резервной копии.

TLS 1.2 — это небезопасно?

Сам факт использования TLS 1.2 не превращает HTTPS в небезопасное соединение. Протокол всё ещё широко поддерживается.

TLS 1.3 современнее, поэтому я не предлагаю навсегда выкинуть его из всех российских серверов.

В моём случае TLS 1.2-only оказался рабочим режимом совместимости. Если ситуация со временем изменится, TLS 1.3 можно вернуть и снова проверить сайт через несколько сетей.

Как вернуть TLS 1.3

ssl_protocols TLSv1.2 TLSv1.3;

Затем:

sudo nginx -t
sudo systemctl reload nginx

После этого снова проверяем те сети и браузеры, где раньше возникала ошибка.

Почему проблема доступности касается SEO

Владелец коммерческого сайта может несколько месяцев улучшать Core Web Vitals, писать статьи, собирать ссылки и исправлять технические ошибки, но всё это мало помогает посетителю, который не смог установить HTTPS-соединение.

Избирательная недоступность опасна ещё и тем, что её сложнее заметить. Ваш мониторинг из европейского дата-центра показывает зелёный статус, сотрудники в офисе открывают сайт, а у части российской аудитории страница не загружается.

Для SEO и бизнеса это может означать потерянные переходы из поиска, рекламный трафик, который оплачивается впустую, меньше заявок и хуже пользовательский опыт.

Для проектов с российской аудиторией я бы поэтому добавил хотя бы одну точку мониторинга непосредственно из РФ, а лучше несколько независимых проверок.

Как мониторить такие проблемы

Обычной проверки HTTP 200 из одной страны недостаточно.

Для важного проекта полезно контролировать DNS, IPv4, IPv6, время TLS handshake, HTTP-код и срок сертификата. Если есть возможность, запускайте проверки из разных сетей или регионов.

Особенно полезен алерт, когда российская точка перестала видеть сайт, а зарубежная продолжает получать 200 OK. Это сразу указывает, что проблема может быть не в самом приложении.

Что я теперь проверяю, если сайт работает через VPN, но не работает напрямую

Я сначала выясняю, одинаково ли проблема проявляется через разных операторов. Потом смотрю IPv4 и IPv6, доступность TCP 443, TLS handshake, версию TLS, HTTP/2 и, если он используется, HTTP/3.

Только после этого лезу в WordPress, если факты действительно ведут туда.

Такой порядок намного быстрее, чем бесконечно отключать плагины и чистить кеш у сайта, до которого браузер даже не смог установить TLS-соединение.

Частые вопросы

Сайт работает через VPN, а без VPN не открывается. Это блокировка?

Не обязательно. VPN меняет сетевой маршрут и исходящий IP, поэтому такой тест показывает, что проблема, вероятно, связана с путём соединения. Но сам по себе он не доказывает официальную блокировку домена.

Поможет ли отключение TLS 1.3?

Мне помогло, и Beget сейчас публично рекомендует такой вариант как один из временных технических методов. Но гарантии для любого сервера нет.

Нужно ли отключать TLS 1.3 заранее?

Нет. Если сайт нормально работает у вашей аудитории, я бы оставил современную конфигурацию.

Почему сайт открывается в Firefox, но не в Chrome?

У браузеров отличаются сетевые реализации и характеристики TLS-соединений. При внешней фильтрации это иногда приводит к разному результату. Beget также отмечает подобное различие в текущей ситуации.

HTTP/3 и TLS 1.3 — одно и то же?

Нет. HTTP/3 работает через QUIC и использует TLS 1.3, но обычный HTTPS через TCP тоже может работать с TLS 1.3 без HTTP/3.

Можно ли изменить TLS на виртуальном хостинге?

Обычно нет, если провайдер не предоставляет такую настройку. Нужно обращаться в поддержку. Beget прямо пишет, что для его виртуального хостинга пользователь самостоятельно отключить TLS 1.3 не может.

Что делать, если после отключения TLS 1.3 сайт всё равно не работает?

Верните исходную конфигурацию и продолжайте диагностику. Проверяйте DNS, IPv6, firewall, маршрутизацию, CDN, HTTP/3, SSL-сертификат, логи веб-сервера и доступность IP через разные сети.

Можно ли просто поменять IP?

Технически можно, но без диагностики это лотерея. Сначала стоит подтвердить, что проблема действительно связана с текущим IP или подсетью.

Что в итоге сработало у меня

В моём случае поддержка Beget предложила отключить TLS 1.3.

На Nginx осталась такая настройка:

ssl_protocols TLSv1.2;

После проверки конфигурации я применил её на сервере, и сайты снова стали нормально открываться.

Я специально не называю это универсальным решением. Если у другого сайта проблема связана, например, с IPv6 или CDN, отключение TLS 1.3 ничего не исправит.

Но теперь это одна из первых вещей, которые я буду проверять при сочетании нескольких симптомов: сервер исправен, сайт нормально работает через одну сеть и не работает через другую, проблема меняется при использовании VPN или другого браузера.

Если техподдержка и ваш IT-отдел не смогли разобраться

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

Но реальная серверная конфигурация иногда выглядит совсем не так, как в типовой инструкции. На одном проекте стоит обычный Nginx, на другом используется панель управления, на третьем трафик сначала проходит через CDN, затем reverse proxy и только потом попадает в Docker. Бывают серверы с десятками сайтов, где менять глобальные TLS-параметры без предварительной проверки просто опасно.

Если вы уже обращались в хостинг, ваш разработчик или IT-отдел не смог определить причину, либо вы не хотите самостоятельно работать с сервером по SSH, можете написать мне.

Я могу отдельно посмотреть конфигурацию веб-сервера, TLS, DNS, IPv4/IPv6, SSL, CDN, логи, WordPress и сетевую часть проекта, чтобы понять, на каком этапе возникает проблема.

Такая работа выполняется платно. Фиксированной цены на эту услугу у меня нет, потому что один сайт на обычном VPS и сервер с несколькими десятками коммерческих проектов — совершенно разный объём и уровень ответственности.

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

Источники и документы

При подготовке материала я сверял технические рекомендации Beget по текущим проблемам доступности, статью 65.1 Федерального закона №126-ФЗ «О связи», постановление Правительства РФ №1667 от 27 октября 2025 года, официальную документацию Nginx по директиве ssl_protocols и исследование FOCI 2026 «On Russia’s Early Introduction of QUIC SNI Censorship».

Ситуация с сетевой фильтрацией меняется, поэтому технические рекомендации из статьи лучше рассматривать как актуальные на дату обновления материала — 2 сентября 2026 года.

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