Коротко — сначала выяснить, на каком этапе «коллапс» соединения: DNS → TCP → TLS → HTTP. Ниже — план действий с практическими командами и интерпретацией результатов, а также самые вероятные причины (в вашем случае — очень похоже на проблемы с IPv6/AAAA или с сетевым путём со стороны провайдера).
1) Быстрая проверка с компьютера (или с сервера)
- Посмотреть какие адреса отдает DNS:
- dig A example.com +short
- dig AAAA example.com +short
Если есть AAAA — это первый подозреваемый: старые iOS могли попробовать IPv6 и «зависнуть», если по этому адресу нет реального сервиса или путь битый.
- Принудительно протестировать по IPv4/IPv6:
- curl -v --ipv4 https://example.com/
- curl -v --ipv6 https://example.com/
Если по IPv6 запрос виснет/таймаутится, значит проблема в IPv6-маршруте/настройке.
- Тест TLS:
- openssl s_client -connect example.com:443 -servername example.com -tls1_2
- openssl s_client -connect example.com:443 -servername example.com -tls1_3
Посмотрите, проходят ли рукопожатия, какие шифры, нет ли ошибок сертификата.
- Онлайн-инструменты:
- SSL Labs (https://www.ssllabs.com/ssltest/) — покажет поддерживаемые протоколы/шифры и совместимость со старыми iOS.
- DNS checker (dig, online DNS check) — убедиться, что по разным резолверам адреса одинаковы.
2) Наблюдение на сервере (очень важно)
- Посмотрите, попадают ли SYN/пакеты от проблемных устройств на сервер:
- sudo tcpdump -n host <IP_клиента> and port 443
или отслеживать вообще: sudo tcpdump -n port 443
Если от проблемного клиента нет вообще пакетов — проблема на уровне DNS/маршрута/провайдера.
Если есть SYN, но нет TLS ClientHello — возможно пакеты обрываются/фильтруются или сервер не успевает/отбивает.
Если есть ClientHello — смотрите ответ сервера.
- Логи nginx:
- tail -f /var/log/nginx/access.log /var/log/nginx/error.log
Если запросы не попадают в access.log — значит TCP/TLS не дошло до уровня HTTP.
Интерпретация результатов tcpdump/nginx:
- Нет DNS ответа / клиент не делает TCP соединение → проверяйте DNS (AAAA) и маршруты.
- TCP SYN приходит, SYN/ACK уходит, но клиент не продолжает → возможны проблемы MTU/PMTU (через Wi-Fi/мобильный/провайдера), рекламация MSS, или middlebox у провайдера режет пакеты.
- Клиент отправляет TLS ClientHello, сервер не отвечает → возможно firewall/IPS/NGFW или плохая поддержка ALPN/HTTP2/TLS, или сервер генерирует RST.
- Сервер отвечает и в логах — тогда проблема на уровне приложения/редиректа.
3) Проверки, специфичные для вашего описания (VPN помогает)
Факт, что VPN помогает, сильно склоняет к сетевой проблеме у провайдера/маршрута или к тому, что при VPN идёт другой DNS/IPv4-путь:
- Проверьте AAAA: если есть неверная AAAA — клиент попытается по IPv6 и зависнет; VPN может давать доступ по IPv4 и работать.
- Проверьте, какой DNS использует проблемный iPhone (операторы/мобильные сети подставляют свой резолвер). Попробуйте на проблемном устройстве вручную прописать 8.8.8.8/1.1.1.1 и повторить.
- Проверьте IPv6-доступность сервера: traceroute6, ping6 (если сервер не слушает IPv6 или путь битый — удалить/исправить AAAA).
- Проверьте, не появилось ли где-то правило firewall/acl, которое блокирует «старые» user-agents, или блокировка по гео/IP (при этом VPN меняет исходный IP).
4) Стоит проверить и такие вещи
- HTTP/2 и ALPN: некоторые старые стеки реализации HTTP/2 плохо работают с некоторыми middlebox — временно отключите http2 в nginx и проверьте.
- TLS конфигурация: если вы недавно жестко ограничили протоколы/шифры (например только TLS1.3 или нестандартные шифры), старые iOS не смогут договориться. Откатите на поддерживающий TLS1.2 набор шифров.
- OCSP/Stapling: если OCSP виснет, старые клиенты могут ждать. Попробуйте временно выключить ssl_stapling и проверить.
- MTU/fragmentation: если пакет MSS слишком большой через определённый провайдер, соединение может виснуть. В логах/pcap это видно как многократные Retransmit. Решение — MSS clamping на роутере/неправильный PFsense/ISP.
- CDN / прокси: если вы используете CDN, проверьте маршруты и конфигурацию CDN и наличие проблем в их edge.
5) Короткий план действий для вас прямо сейчас
1. На сервере запустите tcpdump и попросите владельца проблемного iPhone открыть сайт (или подключите его к Wi‑Fi и воспроизведите):
- sudo tcpdump -n host <IP_телефона> and port 443
Если пакетов нет — сначала смотрим DNS/маршрут.
2. С компьютера/серверa:
- dig A/AAAA example.com +short
- curl -v --ipv4 https://example.com/
- curl -v --ipv6 https://example.com/
3. Временно отключите http2 в nginx и перезапустите, проверьте (на всякий случай).
4. Проверьте nginx ssl_protocols/ssl_ciphers и откатите на более совместимые настройки (включить TLS1.2 и обычные ECDHE шифры).
5. Проверьте DNS-провайдера и TTL/AAAA: если AAAA не нужна — временно удалите и проверьте.
6) Вероятные причины в порядке вероятности для вашего случая
- Неправильная AAAA-запись / битый IPv6-маршрут у провайдера (VPN помогает) — самое вероятное.
- Изменение TLS/шифров/HTTP2, несовместимое со старой iOS.
- Провайдерская/сетевой middlebox фильтрация (по IP/порт/паттерну), DNS-перенаправление.
- MTU/fragmentation проблемы.
Если хотите, могу:
- Проанализировать выводы dig/curl/openssl, которые вы получите;
- Сформировать конкретные команды tcpdump/wireshark-фильтры для вашего сервера и объяснить, что искать в захвате;
- Помочь подобрать безопасную (совместимую) ssl конфигурацию nginx, чтобы поддержать старые iOS.
Напишите результаты dig/ curl/tcpdump или выдайте выводы логов — помогу интерпретировать и предложить точный фикс.