Сайт не открывается с мобильного, и это не ваш баг. Это ТСПУ
Жил-был сайт. Работал себе тихо: образовательный, детский, на Joomla 1.x в обнимку с PHP 5.6 (не спрашивайте). И вот однажды клиент пишет: «Слушай, что-то с мобильного не открывается. И знаешь что забавно — десктоп тоже падает. Может, долгие PHP в мобильном шаблоне забивают воркеры?»
Гипотеза разумная. Воркеры — вещь святая, забивают их регулярно. Полез разбираться.
Сервер живой, MariaDB не плачет, Apache не висит, nginx ругается в логах, но как-то слабо. Сел читать error.log повнимательнее — и тут начали всплывать друзья. Не один-два, а почти семьсот за полдня. Друзей зовут:
SSL_read failed: decryption failed or bad record mac while keepalive
В переводе на человеческий: клиент когда-то успешно установил TLS-соединение, какое-то время по нему гулял, а потом данные стали приходить битые. MAC (подпись внутри TLS-записи) не сходится, OpenSSL вежливо разводит руками. 181 уникальный IP — не один кривой бот, а целое сообщество.
Дальше — самое интересное. Я посмотрел, откуда они приходят. Ожидал увидеть мобильных операторов: МТС, Билайн, МегаФон. Увидел Амстердам, Стокгольм, Лондон, Франкфурт. AS-номера датацентров, хостинг-провайдеров, VPN-инфраструктуры. При этом User-Agent у всех — iPhone.
Стоп.
То есть на легитимный детский образовательный сайт сидят иностранцы с айфонами? Нет, конечно. Это российские пользователи айфонов, которые сидят через VPN. У них Apple Store нормально не работает, Instagram заблокирован — поэтому VPN включён по умолчанию, и весь трафик, в том числе на безобидный детский сайт, идёт через датацентр где-нибудь в Нидерландах.
Дальше я снял шапочку из фольги, надел вторую и пошёл изучать матчасть. Оказалось, что ТСПУ в 2026 году немножко научился новому. И вот тут начинается часть, ради которой я и пишу этот текст.
ТСПУ 2.0: дайте мне 12 ваших TLS-соединений, и я заморожу всё остальное
Раньше ТСПУ работал как тупой швейцар: открыл список запрещённых доменов, сверил SNI в ClientHello — либо пустил, либо завернул. С 2024–2025 годов у него появились новые хобби.
Первое — «сибирский триггер». Записано на провайдере МТС в Новосибирске, но всплывает у разных операторов. Логика такая: если клиент устанавливает примерно 12 параллельных TLS-соединений с одинаковым SNI к одному серверу за короткое время (с задержками меньше 20–50 мс) — ТСПУ это засчитывает как подозрение. И замораживает все новые TLS к этому серверу на 120 секунд. Базовый TCP всё ещё проходит. Сертификат сервер успешно отдаёт. Но внутри — ничего. Пакеты не идут.
Второе — «двойная ловушка». Если в момент заморозки клиентское приложение или браузер автоматически пробует сменить TLS-fingerprint (а они это любят делать на ошибках, считая, что «может, сервер не любит нашу версию TLS»), ТСПУ даёт штрафной бан на 600 секунд — 10 минут. И всё это время вообще никакие TLS-соединения к этому серверу не работают.
Прелесть в том, что это срабатывает на абсолютно легитимных сайтах. Никаких запрещённых SNI. Никакого VPN-трафика. Просто современный мобильный браузер открывает страницу. Страница тянет CSS, JS, шрифты, картинки, аналитику, какой-нибудь чат, какой-нибудь pixel — по чуть-чуть, но в сумме легко 15–20 параллельных коннектов. Плюс если приложение, плюс если несколько вкладок одного домена, плюс если пользователь обновил страницу — счётчик подскочил, триггер сработал.
Со стороны сайта симптомы такие: с десктопа всё открывается, с мобильного — крутится колесо. Не 502, не таймаут от вашего бэкенда — просто бесконечная загрузка, которая периодически проходит, периодически нет. Со стороны админа выглядит, как будто баг плавающий и непонятно где. А он не у вас.
Самое грустное в этой истории — это с вашей стороны не лечится. ТСПУ стоит между клиентом и вами. Вы не контролируете ни мобильного оператора, ни DPI, ни решение РКН включить новый эвристический фильтр. Но смягчить симптомы можно, и довольно прилично. Идея в одном: если триггер ловит «много параллельных TLS к одному SNI», то наша работа — этих параллельных TLS делать как можно меньше.
Что делать (а не паниковать)
1. Включите HTTP/2. Это самое важное действие во всей статье. С HTTP/2 один TCP-сокет и одна TLS-сессия мультиплексируют все запросы: HTML, CSS, JS, картинки, шрифты, AJAX. Вместо 20–30 параллельных TLS — одно. Триггер «12 параллельных» физически не достигается.
В nginx (1.25.1+):
listen 443 ssl;
http2 on;В nginx постарше:
listen 443 ssl http2;Проверка после рестарта:
curl -sI --http2 https://your-site.ru/ | head -1
# Должно быть: HTTP/2 200Если у вас панель (ISPmanager, FastPanel, cPanel) — она часто перезаписывает vhost. Смотрите в настройках сайта галочку «HTTP/2» и включайте через UI, чтобы не было сюрпризов после обновления панели.
2. Длинный keepalive. Пусть клиент переиспользует уже установленное соединение, а не открывает новое на каждый чих:
keepalive_timeout 75s;
keepalive_requests 1000;3. TLS session cache. Возвращающиеся клиенты в TLS 1.2 могут восстановить старую сессию без полного handshake. Это полезно вдвойне: меньше CPU на сервере, меньше шансов попасть под триггер при переподключении.
kssl_session_cache shared:SSL:50m;
ssl_session_timeout 1d;
ssl_session_tickets off;4. Меньше отдельных файлов на странице. Каждый отдельный URL — это потенциально отдельное соединение (даже на HTTP/2 их может быть больше одного). Бандлы JS и CSS, спрайты вместо коллекции иконок, lazy-loading картинок ниже первого экрана, шрифты с font-display: swap. Страница, которая тянет 80 файлов с одного домена, ловит триггер быстрее, чем страница на 15 файлов.
5. Отдельный поддомен для статики. Если запросы идут к site.ru (HTML, API) и параллельно к static.site.ru (CSS, JS, картинки), то у ТСПУ счётчик считается отдельно для каждого SNI. Это размывает нагрузку и снижает шансы триггера. Технически — самый простой способ выиграть пару порядков по «параллельным TLS на SNI».
6. Только TLS 1.2 и TLS 1.3, современные ciphers. Не из-за ТСПУ, а потому что держать TLSv1/1.1 в 2026 — это просто долг по технике безопасности.
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;
ssl_prefer_server_ciphers off;ChaCha20 в этом списке — это специально для мобильных. На iPhone без AES-NI на старых процессорах ChaCha20-Poly1305 работает быстрее, чем AES.
Что делать НЕ нужно
Несколько мифов, которые ходят по технической тусовке.
«Отключите TLS 1.3 — РКН блокирует». Нет. TLS 1.3 сам по себе не блокируется. Блокируется TLS 1.3 + ECH у Cloudflare — это история про шифрование SNI, которое РКН и ТСПУ не могут читать, поэтому Cloudflare с ECH в РФ режется на уровне IP. Если у вас сайт не на Cloudflare и вы не включали ECH специально — у вас TLS 1.3 работает абсолютно нормально. На нём, на минуточку, работают Сбер, Госуслуги, Яндекс и половина Рунета.
«Включите Cloudflare для скорости и ECH для приватности». Не надо. В РФ Cloudflare и так работает с переменным успехом, а с ECH — почти гарантированно лежит. Если вам нужен CDN под российскую аудиторию — смотрите Selectel CDN, VK Cloud, BeGet, российские edge-провайдеры.
«Если в логах ошибки bad record mac — что-то с сервером». Нет. На любом российском сайте с трафиком в логах будет 0.3–0.5% таких ошибок. Это фон от VPN-юзеров, антивирусов с TLS-инспекцией и CGNAT у мобильных операторов. Лечения со стороны сервера нет, и вам это не нужно лечить. Можно просто отделить эти ошибки в отдельный лог-файл, чтобы не путали при анализе.
«Поставить fail2ban на nginx-error и банить за TLS-ошибки». Тоже нет. Эти ошибки не от атакующих, а от живых пользователей с кривыми каналами. Забаните — потеряете трафик.
Чек-лист для админа
Каждая галочка не лечит ТСПУ — но снижает шансы, что ваш конкретный сайт окажется «странно недоступен» у мобильной аудитории. А таких сайтов с каждым месяцем больше.
Эпилог
В 2008 году, когда я начинал делать сайты, главными проблемами были IE6, кодировка cp1251 и MySQL 4.0, который не умел нормальный UTF-8. В 2026 я разбираюсь, почему государственное оборудование считает мой детский образовательный сайт подозрительным из-за того, что айфон открыл к нему 13 TCP-сокетов.
Прогресс налицо.
С другой стороны, инструменты тоже лучше. HTTP/2, TLS 1.3, ChaCha20 — это всё родилось не вчера, и почти всё лечится десятком строк в nginx.conf. Просто нужно знать, что чинить и в какую сторону смотреть.
Если вам кажется, что у вас «сайт работает, но не у всех» — пройдитесь по чек-листу выше. Это займёт полчаса, и может оказаться, что половина «жалоб клиентов» закроется сама собой.
А если не закроется — что ж, добро пожаловать в 2026. Дальше будет интереснее.
