IHC не работает после 5 июня: пошаговое руководство по спасению сайта от блокировок ТСПУ

Вы уже поняли: сайт не открывается. Панель управления IHC показывает, что проблем нет, всё работает. НО при этом сайт все равно не открывается.

Техподдержка отвечает штампами. Это не единичный сбой. Это массовое явление, затронувшее тысячи клиентов IHC (да и в целом - всех хостингов) после 5 июня 2026 года.

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

Кто такой IHC и почему именно он попал под раздачу

IHC (ihc.ru) - хостинг-провайдер с почти двадцатилетней историей, ориентированный на малый и средний бизнес. У него нет дата-центров уровня Selectel, но своя аудитория стабильна: региональные интернет-магазины, корпоративные сайты, блоги. До 5 июня 2026 года основные жалобы касались медленной работы техподдержки, но не массовых блокировок. Потом случился взрыв: сотни клиентов обнаружили, что их сайты недоступны для посетителей из России, хотя через VPN всё работает. Поисковые запросы "ihc недоступен сайт", "ihc.ru не открывается", "сайт на IHC не грузится" взлетели в топ. Причина - не технический сбой на стороне хостинга, а изменение правил фильтрации на оборудовании Роскомнадзора - ТСПУ.

Техническая подноготная: как ECH поссорило ТСПУ с IHC

ECH (Encrypted Client Hello) - это расширение TLS 1.3, которое шифрует самое первое сообщение при установке HTTPS-соединения. Раньше в этом сообщении открыто передавалось имя сайта (SNI), и ТСПУ могло его прочитать. Теперь - нет.

Чтобы сохранить контроль, Роскомнадзор научил свои ТСПУ (Технические средства противодействия угрозам) распознавать сам факт использования ECH по характерным отпечаткам в самом начале рукопожатия.

Проблема в том, что современные версии веб-серверов (Nginx 1.29.4+, OpenSSL 4.0+, Apache с определёнными модулями) включают поддержку ECH по умолчанию. IHC, как ответственный провайдер, регулярно обновляет софт. Так что серверы IHC (как и всех остальных хостеров) отправляют ECH-приветствия, а ТСПУ начало их массово блокировать. При этом блокировка часто бывает "веерной": если на одном IP-адресе с вами находится несколько сайтов, и хотя бы у одного из них ECH активен, фильтр может заблокировать весь IP, или весь диапазон. Вот почему страдают все клиенты подряд - даже те, кто ничего не знает про ECH.

Как именно ТСПУ распознаёт ECH (для тех, кто любит копать глубже)

В сообщении ClientHello TLS 1.3 есть список расширений. ECH добавляет расширение с типом 0xfe0d. DPI-система (Deep Packet Inspection) не расшифровывает содержимое, но видит само наличие этого расширения, его размер и структуру.

Эти параметры образуют уникальный "отпечаток". Сигнатуры таких отпечатков были добавлены в ТСПУ, вероятно, в начале 2025 года, а массовое включение произошло 5 июня 2026. Это подтверждается паттернами блокировок - сначала пали единичные сайты, потом лавинообразно.

Диагностика без магии: как убедиться, что проблема именно в ECH

Онлайн-сервисы часто ошибаются, поэтому будем работать из командной строки. Если у вас Linux или Mac - открываете терминал. Если Windows - устанавливаете WSL или просто ставите утилиту dig через PowerShell с помощью Resolve-DnsName, но проще через WSL.

Команда для проверки ECH:

Если в ответе вы видите строку, содержащую ech=, например, ech="AEX+...", то для вашего домена опубликована ECH-конфигурация. Это почти 100% означает, что ваш сервер (или хостинг) поддерживает ECH, и блокировки вызваны именно этим. Если ответ пустой - ECH не используется, причина в другом (IP-блокировка, SNI, JA3). Для установки dig в Ubuntu/Debian: sudo apt install dnsutils, в CentOS: sudo yum install bind-utils.

Дополнительный тест: попросите знакомого из другого региона (или с другого оператора) открыть ваш сайт. Если у него не открывается, а через VPN - открывается, то проблема на сетевом уровне. Если открывается только у одного оператора - блокировка выборочная, что тоже характерно для новых фильтров ТСПУ.

Что делать, если dig вернул пустой ответ

Пустой ответ - хорошая новость: ECH не виноват. Тогда ваша проблема в другом. Начните с проверки доступности IP: ping ваш-домен.рф и traceroute ваш-домен.рф. Если пинг идёт, а обрыв происходит на каком-то узле - это блокировка на маршруте. Если пинг не идёт - возможно, хостинг сменил IP или у вас проблемы с DNS. Проверьте также, не попал ли ваш домен в реестр нарушителей: eais.rkn.gov.ru. Если всё чисто, а сайт всё равно не открывается - вероятно, блокировка по JA3-отпечатку. О том, как с ней бороться, будет отдельный раздел ниже.

Почему смена IP на IHC не помогает (или помогает на пару дней)

Логичный шаг: просим поддержку сменить IP-адрес. Вам дают новый. Вы меняете A-запись. Сайт оживает. Ура. Но через 6-48 часов - снова блокировка. Почему? Потому что ТСПУ анализирует не только IP, но и поведение. Ваш сервер продолжает отправлять те же ECH-паттерны, и система, увидев знакомый "почерк" на новом адресе, банит его. Иногда новый IP лежит в той же подсети /24, которая уже засвечена - тогда блокировка происходит мгновенно. Вы бежите менять IP снова - и попадаете в бесконечный цикл.

Сценарии спасения: от простого к сложному

Ниже я привожу три основных сценария, а также несколько дополнительных. Выбирайте тот, который соответствует вашему техническому уровню и тарифу IHC.

Сценарий 1: У вас VPS на IHC (доступ по SSH)

Заходим на сервер. Редактируем конфиг Nginx. Для этого: sudo nano /etc/nginx/sites-available/ваш_сайт. Внутри блока server { ... } добавляем строчку:

Сохраняем, проверяем конфиг: nginx -t. Если ошибок нет, перезагружаем Nginx: systemctl reload nginx. Если у вас Apache: в конфиге VirtualHost добавляем SSLECH off, затем systemctl reload apache2. Проверяем результат командой dig +short ваш-домен HTTPS - строка ech= должна исчезнуть. После этого сайт перестаёт "светить" ECH. Для дополнительной устойчивости можно заказать второй IP и настроить DNS-балансировку (две A-записи с разными IP, TTL 60 сек). Это защитит от возможных IP-блокировок.

Сценарий 2: У вас shared-хостинг на IHC (без доступа к конфигам)

Вы не можете отключить ECH сами. Ваше оружие - техподдержка и общественное давление. Пишем в тикет: "Проверьте, включена ли поддержка ECH на сервере с моим доменом. Я проверил через dig - запись ech есть. Это вызывает массовые блокировки ТСПУ. Прошу отключить ECH для моего аккаунта". Прикладываем скриншот вывода dig. Если отвечают отпиской, идём в социальные сети IHC (ВК, Telegram), пишем в публичных группах, привлекаем внимание других пострадавших.

Сценарий 3: У вас нет времени ждать, нужен результат здесь и сейчас

Вы регистрируетесь, добавляете домен, указываете реальный IP IHC. Сервис выдаёт два своих IP. Вы меняете A-записи в DNS на эти IP. Весь трафик идёт через прокси, на котором ECH отключено, поэтому ТСПУ не видит запретных отпечатков. Стоимость - от 1000 рублей в месяц в зависимости от дополнительных опций (количество сайтов, автоматическая блокировка поведенческих ботов с помощью ИИ, интеграция с Яндекс.Директ для корректировки ставок рекламных кампаний). Для бизнеса это дешевле простоя. Бонус: фильтрация ботов и простых DDoS, защита от скликивания рекламы.

Дополнительный сценарий 4: Подача заявки в ЛК ВТС (после отключения ECH)

Если вы отключили ECH, но IP всё ещё иногда блокируется веерными методами, можно подать заявление на исключение через ЛК ВТС РКН. Регистрация через Госуслуги, заполнение формы с указанием домена и IP. Там огромный опросник и еще более огромный файл с описанием того что необходимо. Наймите юриста, сами не справитесь. Приложите доказательства, что ECH отключён. Срок рассмотрения - от нескольких дней до месяца. Вероятность положительного решения - не 100%, но для легальных ресурсов с чистой историей она высока. Это легальный аналог "белого списка".

Сценарий 5: Полная смена хостинг-провайдера (крайний случай)

Если IHC не реагирует, а вы не хотите платить за прокси, можно переехать на другой хостинг, где ECH отключено "из коробки". Переезд - это стресс, но иногда это единственный способ сохранить бизнес, если IHC затягивает с решением.

Что делать, если отключение ECH не помогло (JA3 и другие отпечатки)

ТСПУ может блокировать не только ECH, но и JA3-отпечатки (цифровой паспорт TLS-библиотеки). У многих стандартных сборок Nginx на IHC отпечаток может совпадать с отпечатками прокси-серверов или VPN-клиентов. Это можно изменить, сменив версию OpenSSL, пересобрав Nginx с другими параметрами. Для рядового пользователя такой вариант сложен и дорог - проще сразу взять прокси.

Пошаговая инструкция по диагностике и действиям (сжатый алгоритм)

1. Выполните dig +short ваш-домен HTTPS. Если есть ech= - переходите к п.2. Если нет - к п.5.
2. Если у вас VPS - отключите ECH в конфиге веб-сервера. Если shared-хостинг - напишите в поддержку IHC с требованием отключить ECH.
3. После отключения повторно проверьте dig. Строка ech= должна исчезнуть.
4. Если сайт всё ещё недоступен, проверьте IP-блокировку через трассировку. При необходимости закажите второй IP и настройте DNS-балансировку.
5. Если ECH не было, а сайт не работает - проверьте доступность с разных операторов, выполните трассировку, проверьте реестр РКН. Подозревайте JA3 или блокировку по IP. Попробуйте сменить IP через поддержку. Если помогает временно - значит, IP-блокировка. Используйте DNS-балансировку или прокси.
6. Если ничего не помогает - подайте заявку в ЛК ВТС (после отключения ECH).

Часто задаваемые вопросы (FAQ) - 15 пунктов

1. Почему сайт работает через VPN, но не работает без него? - Это 95% блокировка ТСПУ по техническому признаку (ECH, JA3).

2. Команда dig не найдена. Что делать? - Установите dnsutils (sudo apt install dnsutils в Ubuntu).

3. После отключения ECH сайт всё равно не работает. - Возможна IP-блокировка или JA3. Проверьте трассировку, смените IP.

4. Сколько ждать ответа от IHC? - От 1 дня до бесконечности. Ускоряйте публичностью.

5. Безопасно ли отключать ECH? - Для обычного сайта - да. Вы теряете только шифрование SNI, но не само шифрование трафика.

6. Прокси-сервис - это не опасно? - Если сервис российский и легальный, то не опасно.

7. Может ли помочь смена DNS-сервера на Google (8.8.8.8)? - Иногда, если блокировка на уровне DNS. Но обычно нет.

8. Что делать, если IHC не отвечает неделю? - Жалуйтесь, выносите проблему в публичную плоскость.

9. Как узнать, не заблокирован ли IP РКН? - Используйте сервисы проверки блокировок.

10. Может ли помочь смена браузера? - Нет, блокировка на уровне сети.

11. Почему одни сайты на IHC работают, а другие нет? - Потому что у одних ECH отключён, у других включён, или разные IP.

12. Переезд на другой хостинг - гарантия? - Нет, если на новом хостинге включён ECH.

13. Может ли помочь добавление IPv6? - ТСПУ фильтрует и IPv6 тоже.

14. Что такое JA3 простыми словами? - Отпечаток вашей TLS-библиотеки, по которому вас могут заблокировать.

15. Самый быстрый способ восстановить доступ? - Прокси-сервис или отключение ECH на VPS.

Прогнозы на будущее: что ждёт IHC и его клиентов

Я предполагаю, что в ближайшие месяц-два IHC перенастроит сервера и откажется от сигнатур, на которые реагирует ТСПУ РКН. Некоторые хостинги уже это делают. Если IHC этого не сделает, клиенты начнут уходить к конкурентам. Экономически это невыгодно, поэтому, вероятнее всего, техническое решение появится. Пока же ответственность лежит на вас: проверяйте, требуйте, используйте обходные методы. Не надейтесь на чудо - действуйте.

Заключение: ваш сайт не обречён, но нужно пошевелиться

Проблема с доступностью на IHC - не навсегда. Она решается тремя основными способами: отключение ECH, DNS-балансировка, прокси-сервис Killbot. Не тратьте время на бесконечную смену IP. Не ждите, когда IHC одумается. Используйте диагностику, выбирайте сценарий под себя и действуйте. Если вы дочитали до этого места, вы уже на шаг ближе к тому, чтобы ваш сайт снова работал. Удачи.