В июне 2026 тема частичной недоступности сайтов снова стала практической, а не теоретической. 9 июня 2026 на Habr вышел свежий разбор о проблемах доступа к части сайтов у отдельных пользователей, а 11 июня 2026 материал дополнили ссылками на проверки HTTP/2 и TLS 1.3. Для владельца бизнеса важен не сам спор о причинах, а другой вопрос: что делать, если сайт открывается у вас и у разработчика, но периодически не грузится у части аудитории на iPhone, в одной сети, у конкретного оператора или после нескольких быстрых переходов подряд.
Плохая новость в том, что такая симптоматика легко уводит команду в ложный диагноз. Хорошая в том, что её можно разложить на проверяемые шаги: версии TLS, цепочка сертификата, SNI, редиректы между `www` и без `www`, HTTP/2, CDN/WAF, логи веб-сервера и реакция площадки на разные типы подключений. Именно в такой последовательности и стоит действовать, если задача не в теории, а в восстановлении заявок и доступности сайта.
Почему сайт может ломаться не у всех
Типичный сигнал выглядит так: на ноутбуке разработчика всё открывается, на одном Android тоже, а на нескольких iPhone по LTE или Wi-Fi страница то загружается, то зависает на подключении. Иногда проблемы начинаются не на первом заходе, а после нескольких переходов по сайту. В этот момент опасно сразу объявлять виновником TLS 1.3, РКН, хостинг или браузер. Один и тот же симптом могут давать разные причины:
- версия TLS и способ рукопожатия;
- неочевидная проблема с сертификатом или его цепочкой;
- конфликт `www` и основного домена;
- отсутствие или некорректная работа SNI;
- отключенный HTTP/2 и слишком много параллельных TLS-соединений;
- фильтрация или нестабильность на стороне сети, CDN, WAF или провайдера;
- разница между прямым доступом к серверу и доступом через прокси или балансировщик.
Поэтому правильный подход здесь один: не лечить вслепую, а собирать короткую техническую карту инцидента.
С чего начать диагностику
1. Проверить проблему с разных сетей и устройств
Сначала подтвердите, что проблема действительно повторяется. Нужны минимум три сценария: домашний Wi-Fi, мобильная сеть и внешняя сеть без привычного кеша и истории браузера. Если жалобы приходят только от части пользователей, зафиксируйте:
- устройство и браузер;
- сеть и провайдера;
- точное время проблемы;
- открывается ли главная страница и что происходит на внутренних страницах;
- работает ли сайт с `www` и без `www`.
Эта информация потом пригодится и вашей команде, и хостингу, и оператору площадки.
2. Проверить TLS 1.2 и TLS 1.3 вручную
Дальше нужно понять, какие версии TLS реально доступны снаружи. Для быстрой проверки подойдут `curl` и `openssl`:
```bash curl -Iv --tlsv1.2 https://example.ru/ curl -Iv --tlsv1.3 https://example.ru/ openssl s_client -connect example.ru:443 -servername example.ru -tls1_2 openssl s_client -connect example.ru:443 -servername example.ru -tls1_3 openssl s_client -connect example.ru:443 -tls1_2 ```
Здесь важно не только то, открывается сайт или нет, но и как именно он отвечает. На одном из недавних разборов мы видели характерную картину: `curl --tlsv1.2` возвращал `HTTP 200`, а `curl --tlsv1.3` завершался с `tlsv1 alert protocol version`. Сам по себе такой результат не доказывает внешнюю фильтрацию, но отлично показывает, какая версия TLS сейчас реально доступна после изменения конфига.
Проверка без `-servername` тоже полезна: если без SNI и с SNI сервер отдает разный сертификат или ведет себя по-разному, проблема может быть не в сети, а в схеме виртуальных хостов и SSL-конфиге.
3. Проверить сертификат, редиректы и HTTP/2
После TLS-проверки посмотрите на базовые вещи, которые часто ломают доступ не хуже сетевых ограничений:
- срок действия сертификата и полную цепочку;
- одинаково ли обслуживаются `example.ru` и `www.example.ru`;
- нет ли лишней переадресации между доменами и прокси;
- включен ли HTTP/2 на внешнем контуре;
- не режет ли запросы CDN, WAF или антибот.
Публичный кейс на Habr от 9 июня 2026 описывает гипотезу, что в отдельных сценариях проблему могут усиливать не только версии TLS, но и большое количество параллельных TLS-соединений при HTTP/1.1. Поэтому проверка HTTP/2 здесь не формальность: если сайт или прокси вынуждает клиента открывать слишком много соединений, это стоит учитывать как рабочую гипотезу, а не как окончательный диагноз.
4. Посмотреть логи веб-сервера и внешнего контура
Если у вас Apache или Nginx за балансировщиком, CDN или reverse proxy, собирайте логи с обеих сторон. Важно понять, доходит ли запрос до origin-сервера вообще. Когда в access/error log пусто, а пользователи продолжают жаловаться, это сильный сигнал, что проблема может лежать на сети или на внешнем уровне доставки трафика.
Что можно проверить без сервера за 2 минуты
Для первичной самопроверки удобно использовать бесплатный чекер Web-Puls. После этого инцидента мы отдельно доработали самопроверку сетевого подключения: инструмент проверяет DNS, TCP, HTTP-ответ, TTFB, сертификат и показывает, какие версии TLS доступны на домене. В карточке SSL/TLS можно быстро увидеть, проходит ли сайт по TLS 1.2, что происходит с TLS 1.3 и нет ли очевидной проблемы с сертификатом.
Это не полная экспертиза сетевой блокировки и не замена логам, но как первый фильтр инструмент полезен: владелец сайта получает быстрый технический сигнал до подключения администратора, DevOps-инженера или подрядчика по поддержке. Если Web-Puls показывает, что сайт стабильно отвечает по TLS 1.2, а отдельная проверка TLS 1.3 падает, у команды появляется не догадка, а конкретная гипотеза для проверки в конфиге веб-сервера, CDN или SSL-терминатора.
Когда временное отключение TLS 1.3 оправдано
Если симптомы повторяются, а ручные проверки показывают, что через TLS 1.2 сайт стабилен, временный откат до TLS 1.2 может быть разумной аварийной мерой. Важно именно слово «временный». Официальная документация Nginx прямо показывает, что по умолчанию сервер часто работает с `TLSv1.2 TLSv1.3`, а документация Apache `mod_ssl` позволяет явно управлять допустимыми версиями протокола.
Примеры минимальной временной настройки:
```nginx # Nginx ssl_protocols TLSv1.2; ```
```apache # Apache mod_ssl SSLProtocol -all +TLSv1.2 ```
Дальше обязательны четыре шага:
- Сделать резервную копию текущего конфига.
- Прогнать проверку конфига: `nginx -t` или `apachectl -t`.
- Выполнить `reload`, а не грубую остановку сервиса.
- Повторить внешние проверки: `curl --tlsv1.2`, `curl --tlsv1.3`, проверку с разных сетей и самопроверку через Web-Puls.
Если у вас есть CDN, reverse proxy или отдельный SSL-терминатор, менять протоколы нужно не только на origin-сервере, но и на том слое, который реально принимает внешнее HTTPS-подключение.
Какие риски нельзя игнорировать
Отключение TLS 1.3 не должно становиться «магическим ритуалом» на всех проектах подряд. Если причина в редиректах, цепочке сертификата, антиботе, WAF, HTTP/2 или сетевом маршруте, вы просто замаскируете симптом и потеряете время. Кроме того, любое изменение SSL-контура должно быть зафиксировано:
- кто изменил конфиг;
- когда это сделали;
- на каком контуре меняли настройки;
- какие проверки подтвердили улучшение;
- когда команда вернется к повторной проверке TLS 1.3.
Такой журнал особенно важен для рабочих сервисов, интернет-магазинов и сайтов с заявками: иначе через месяц никто не вспомнит, почему сервер внезапно остался только на TLS 1.2.
Когда пора эскалировать проблему
Если после локальной проверки остаются признаки частичной сетевой недоступности, подключайте поддержку хостинга, ЦОД, CDN или оператора связи. На этом этапе лучше передавать не эмоции, а технический пакет:
- время инцидента;
- список сетей и устройств, где проблема повторилась;
- результат `curl` и `openssl`;
- данные по сертификату и SNI;
- факт наличия или отсутствия HTTP/2;
- выдержки из логов внешнего контура и origin-сервера.
Если есть основания считать, что проблема требует официальной эскалации, сначала уточните у хостинга или ЦОД, кто сопровождает сетевой контур и блокировки по вашему IP. В клиентских инцидентах могут всплывать специализированные технические контакты площадки или подрядчика, но их нельзя без проверки переносить в публичный чек-лист: актуальные адреса и телефоны нужно брать у провайдера, из договора или с официальных ресурсов. Для обращений в Роскомнадзор также используйте публичные каналы ведомства и формулируйте запрос технически: домен, IP, время, сети, результаты TLS-проверок и логи.
Как OpenStart помогает в таких инцидентах
Когда сайт не открывается только у части пользователей, бизнес теряет заявки особенно неприятным способом: проблема уже влияет на продажи, но команда еще не видит общего падения и не может быстро воспроизвести ошибку. В таких случаях нужна не абстрактная «проверка SSL», а короткая аварийная диагностика по цепочке:
- внешняя проверка доступности с разных сетей;
- TLS 1.2 / TLS 1.3, SNI и сертификат;
- редиректы `www` и без `www`;
- конфиги Apache/Nginx, CDN и прокси;
- безопасный временный workaround и план возврата.
Если вам нужно быстро восстановить доступность сайта и не потерять лиды, посмотрите услугу восстановления сайта или отправьте задачу в OpenStart: разберем, где именно ломается доступ, и предложим безопасный порядок действий без хаотичных правок в production.