Сайт не работает на айфоне: как DPI ломает TLS

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

Сервер работает. Nginx работает. Сертификат действителен. DNS отвечает. Сайт открывается с компьютера, через Wi-Fi и с Android. Но стоит открыть его на айфоне или айпаде через мобильную сеть российского оператора - соединение зависает или обрывается. 

VPN решает проблему мгновенно.

Подобную картину мы наблюдаем уже не на одном сайте. Домены разные, сервера разные, а симптомы подозрительно похожи. Всё указывает на то, что трафик случайно попадает под некорректную обработку системами фильтрации операторов или ТСПУ. Пикантности этому случаю добавляет то, что один из сайтов под нашей техподдержкой, который пал жертвой этой проблемы, даже находится в “белых списках”.

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

Как выглядела проблема

Исходные симптомы были достаточно странными:

• сайт стабильно открывался через домашний и офисный интернет;

• через Wi-Fi на iPhone всё работало;

• через мобильную сеть на Android сайт открывался;

• через ту же мобильную сеть на айфоне HTTPS-соединение не устанавливалось;

• после включения VPN сайт начинал работать сразу;

• в логах приложения не было никаких ошибок.

Последний пункт особенно важен.

Когда проблема находится в CMS, PHP или коде сайта, запрос хотя бы доходит до приложения. Его можно увидеть в access log, error log, логах PHP-FPM или самой системы.

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

Это означало, что соединение ломалось раньше - на этапе TLS-рукопожатия.

Почему это не похоже на обычную блокировку

При обычной блокировке домена или IP-адреса результат, как правило, не зависит от модели телефона и версии криптографической библиотеки на сервере.

Если IP заблокирован, он не работает ни на iPhone, ни на Android. Если блокируется домен по SNI, замена серверного OpenSSL обычно ничего не меняет: имя сайта передаётся клиентом ещё до того, как сервер успевает выбрать параметры шифрования.

Здесь картина была другой.

Доступность зависела сразу от четырёх факторов:

1. Операционной системы клиента

2. Мобильного оператора

3. Варианта TLS-рукопожатия

4. Версии OpenSSL на стороне сервера

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

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

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

Что изменилось в iOS

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

В ClientHello устройства передают поддержку группы X25519MLKEM768 и соответствующий key_share. Из-за этого первое сообщение TLS становится заметно больше и отличается от рукопожатий старых клиентов. Apple прямо предупреждает, что некоторые серверы и промежуточные сетевые устройства могут некорректно обрабатывать увеличенный ClientHello.

Нормальный TLS-сервер обязан либо выбрать X25519MLKEM768, либо договориться с клиентом о другой совместимой группе. На чистом соединении именно так и происходит.

Но между телефоном и сервером российского сайта находится не только оборудование оператора. Трафик проходит через системы глубокого анализа пакетов, которые пытаются определить назначение соединения ещё до передачи HTTP-запроса.

Что именно происходит внутри ТСПУ, извне увидеть невозможно. Однако результат эксперимента был слишком однозначным, чтобы списать его на совпадение.

Диагностика: последовательно исключаем всё обычное

Мы начали с базовой проверки:

• сравнили доступность через разных операторов;

• протестировали Wi-Fi и мобильную сеть;

• проверили iOS и Android;

• исключили локальный DNS-кэш;

• проверили IPv4 и IPv6;

• проверили сертификат и полную цепочку доверия;

• проверили TLS 1.2 и TLS 1.3;

• изучили логи nginx и PHP-FPM;

• проверили, доходит ли HTTP-запрос до сервера;

• сравнили поведение напрямую и через VPN.

DNS разрешался корректно. Порт 443 был доступен. Сертификат был действительным. Сайт нормально отвечал большинству клиентов.

Проблема воспроизводилась только в конкретной комбинации: iOS, мобильная сеть и определённый вариант TLS.

После этого мы изменили только один элемент - серверную версию OpenSSL.

Решение проблемы - установка OpenSSL 3.5, но не всё так просто

Мы провели эксперимент: системный OpenSSL 3.0 был временно заменён на OpenSSL 3.5.

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

Без изменений DNS. Без смены IP-адреса. Без переноса сайта. Без CDN. Без правок в коде.

Возврат к OpenSSL 3.0 снова ломал доступность. Повторное включение OpenSSL 3.5 снова её восстанавливало.

OpenSSL 3.5 изменил стандартный набор TLS-групп и начал предлагать X25519MLKEM768 вместе с обычным X25519.

Мы не можем заглянуть в конфигурацию ТСПУ и показать конкретное правило, которое выбрасывает соединение. Но эксперимент достаточно точно локализует проблему: изменение TLS-ответа сервера меняет решение промежуточной системы фильтрации. Сам сайт здесь ни при чём.

С высокой вероятностью трафик случайно попадал под некорректную эвристику DPI, а новый TLS-отпечаток позволил её обойти.

Почему нельзя просто обновить OpenSSL во всей системе

Глобальная замена системного OpenSSL решила проблему со входящим трафиком с айфонов, но сразу создала новую.

Новую библиотеку начали использовать не только nginx, но и:

• PHP-FPM;

• curl;

• фоновые обработчики;

• интеграции;

• другие системные службы.

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

Особенно неприятно, что команда “openssl version” в такой ситуации почти бесполезна. Она показывает версию консольной программы, но не версию библиотеки, уже загруженной конкретным процессом.

При диагностике выяснилось, что PHP был собран с заголовками OpenSSL 3.0, но во время работы подхватывал библиотеку OpenSSL 3.5 из отдельного каталога. Одновременно изменились пути сертификатов, конфигурации и криптографических модулей.

То есть грубая замена TLS-стека починила один симптом и потенциально сломала половину сервера. По итогам от глобальной замены OpenSSL мы отказались.

Что мы сделали в итоге

Системную версию OpenSSL 3.0 мы оставили нетронутой и переключили обратно на неё PHP, консольные приложения и всё остальное. Новую версию OpenSSL 3.5 мы изолировали и подключили только к nginx, который принимает входящие HTTPS-соединения.

Дополнительно мы:

• отделили новый TLS-стек от системных библиотек;

• исключили его автоматическую загрузку другими процессами;

• проверили реальную карту библиотек каждого сервиса;

• отключили устаревшие версии TLS;

• протестировали разные варианты обмена ключами;

• проверили входящие и исходящие соединения независимо друг от друга;

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

Подробную конфигурацию намеренно не публикуем: она зависит от версии ОС, сборки nginx, способа линковки библиотек и структуры systemd-сервисов. Слепое копирование команд, скорее всего, закончится неработающим PHP, сломанными интеграциями или невозможностью перезапустить веб-сервер, а то и всем сразу.

Распространённость

О том, насколько широко обнаруженная проблема влияет на рунет, красноречиво свидетельствует график из Вордстата:

Мы видим резкий подъём в апреле 2026 - ровно в тот момент начались ковровые блокировки ряда ресурсов.

Результат

После установки изолированного OpenSSL 3.5 и переключения nginx на работу с ним:

• проблемные сайты начали открываться на iPhone через мобильные сети;

• доступность через Android, Wi-Fi и обычных провайдеров сохранилась;

• исходящие запросы к внешним API снова заработали;

• PHP-FPM остался на штатном системном OpenSSL;

• операционная система не получила неподдерживаемую глобальную подмену библиотек.

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

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

Как мы решаем подобные проблемы

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

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

• TLS 1.3;

• сетевой фильтрации;

• поведении iOS;

• OpenSSL;

• динамической линковке;

• nginx;

• systemd;

• исходящих HTTPS-запросах к сервисам третьих лиц.

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

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

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

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

Сергей Семёнов

Руководитель Синвеб. Веду проекты и организую разработку с фокусом на юзабилити. Пишите, поболтаем.