HTTPS timeout на мобильных: MTU/PMTUD, blackhole MTU и MSS clamping в Linux

Классический симптом: сайт по HTTPS стабильно работает из офисной сети или домашнего Wi‑Fi, но с мобильного интернета (LTE/5G), через некоторые VPN или «умные» маршрутизаторы начинает долго грузиться, зависать на «Connecting…», давать ERR_CONNECTION_TIMED_OUT или открываться через раз. При этом HTTP (без TLS) может вести себя лучше, а мелкие запросы иногда проходят.

Одна из самых частых причин такого поведения — несовпадение MTU на пути и провал PMTUD (Path MTU Discovery). На практике это выглядит как blackhole MTU: соединение есть, SYN/SYN‑ACK проходят, но часть пакетов с данными (особенно в начале TLS/HTTP2) «пропадает», потому что они слишком большие и требуют уменьшения размера, а ICMP-уведомления о необходимости уменьшить размер блокируются.

Почему HTTPS «умирает» именно на мобильных и почему это похоже на MTU

На мобильных сетях и в туннелях путь часто имеет меньший эффективный MTU: добавляются накладные заголовки (GTP, CGNAT, PPPoE, IPsec/WireGuard и т.п.). Плюс где-то по дороге нередко фильтруют ICMP «для безопасности», что и ломает PMTUD.

HTTPS заметнее страдает, потому что в начале соединения передается больше служебных данных: TLS ClientHello/ServerHello, ALPN, расширения, а со стороны сервера — цепочка сертификатов и параметры. При HTTP/2 стартовый обмен тоже может оказаться «толстым». В итоге пакеты на грани MTU начинают теряться, и вы получаете зависания/ретрансляции вместо быстрого хэндшейка.

Отдельно важный момент для админов: при blackhole MTU запрос часто не доходит до HTTP-уровня. TLS не завершился — значит, в access.log веб-сервера может быть пусто, и «по логам сайта» вы ничего не поймете.

Быстрый ликбез: MTU, PMTUD и MSS — в чем разница

MTU — максимальный размер IP-пакета (L3) в байтах, который может пройти по каналу без фрагментации. На Ethernet обычно 1500, но поверх туннелей и некоторых доступов он меньше: 1492 (PPPoE), 1450/1420 и ниже (разные VPN/оверлеи), иногда 1400 и меньше.

PMTUD — механизм определения «реального» MTU по пути. Идея простая: отправляем пакеты с DF (Don’t Fragment), а если где-то по пути пакет не проходит, маршрутизатор должен вернуть ICMP “Fragmentation Needed” (IPv4) или “Packet Too Big” (IPv6). После этого стек уменьшит размер.

MSS (Maximum Segment Size) — параметр TCP: максимальная полезная нагрузка TCP-сегмента (без IP/TCP заголовков). MSS договаривается в SYN/SYN‑ACK. Если «поджать» MSS, TCP изначально не будет пытаться отправлять слишком крупные сегменты — и это часто спасает, когда PMTUD сломан из‑за фильтрации ICMP.

PMTUD — корректный путь, но в реальном мире его ломают фильтры ICMP. MSS clamping — практичный костыль, который часто быстро возвращает работоспособность HTTPS, особенно при туннелях и мобильных сетях.

Как выглядит blackhole MTU на уровне TCP/TLS

Типичная картина по пакетам:

• TCP 3-way handshake проходит (SYN/SYN‑ACK/ACK).
• Клиент отправляет первые данные (например, TLS ClientHello) — обычно несколькими TCP-сегментами.
• Сервер отвечает «крупно» (сертификаты, TLS параметры). Если сегменты близки к MSS 1460 при MTU 1500, а реальный MTU на пути меньше, часть сегментов теряется.
• Дальше идут ретрансляции, растут таймеры, и в итоге клиент видит таймаут или обрыв.

Это объясняет, почему проблема бывает «плавающей»: разные маршруты, разные соты/аплинки у оператора, разные VPN-туннели — и один из путей оказывается с меньшим MTU или с более агрессивной фильтрацией ICMP.

Диагностика в Linux: от симптома к доказательству

1) Проверяем MTU интерфейсов и туннелей

На сервере (и по возможности на граничном узле/шлюзе) посмотрите MTU:

ip -br link

Если у вас VPN/оверлей/контейнерные сети — проверьте MTU у wg0, tun0, ppp0, vxlan*, docker0 и любых veth/bridge интерфейсов, через которые реально ходит трафик.

2) «Пропинговать MTU» с DF (IPv4)

Для IPv4 можно оценить проходящий размер. Логика: подобрать такой ICMP payload, чтобы пакет проходил с DF. Важно: ping задает размер payload, а не общий размер IP-пакета.

ping -M do -s 1472 your.test.host
ping -M do -s 1464 your.test.host
ping -M do -s 1400 your.test.host

Если на каком-то размере вы видите “Frag needed and DF set” — это сильный индикатор MTU/PMTUD. Но при «черной дыре» ICMP может не возвращаться вообще, и тогда ping просто будет «молчать».

3) Ловим ICMP “Fragmentation Needed”/“Packet Too Big” через tcpdump

Практический запрос, который часто ищут: tcpdump icmp fragmentation needed. Снимите трафик на внешнем интерфейсе сервера, пока воспроизводите проблему с клиента:

tcpdump -ni eth0 'icmp or (tcp port 443 and (tcp[tcpflags] & (tcp-syn|tcp-ack) != 0))'

Если PMTUD работает, вы увидите ICMP type 3 code 4 (IPv4) — “fragmentation needed”. Если PMTUD сломан, нужных ICMP может не быть, зато будут повторные ретрансляции TCP-сегментов на 443 без прогресса.

Для IPv6 полезно ловить ICMPv6 “Packet Too Big”:

tcpdump -ni eth0 'icmp6 and (ip6[40] == 2)'

Если вам нужно глубже разобрать, где именно «зависает» TLS (до HTTP или после), пригодится отдельная памятка по диагностике SNI/ALPN и рукопожатия: диагностика TLS (SNI/ALPN) и этапов handshake.

4) Проверяем TLS-уровень: зависание до HTTP

С тестовой машины удобно проверить, на каком этапе «умирает» соединение:

curl -vk --http2 https://your-domain.example/

Если зависает на TLS handshake или сразу после него, а в логах веб-сервера пусто — это типичный профиль MTU/PMTUD.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Что чинить в первую очередь: ICMP и PMTUD

Технически правильное решение — восстановить нормальную работу PMTUD:

• не блокировать критичные ICMP (IPv4 “fragmentation needed”, IPv6 “packet too big”) на границе;
• избегать «запретим весь ICMP» как универсального рецепта;
• проверить политики firewall/маршрутизаторов, которые «съедают» ICMP полностью или режут их выборочно.

Для IPv6 это особенно критично: фрагментацию по пути маршрутизаторы не делают, и без “Packet Too Big” соединения будут деградировать массово и непредсказуемо.

Практичное решение: MSS clamping на Linux (iptables/nftables)

Когда вы не контролируете весь путь (мобильные сети, внешние VPN, странные провайдеры), либо нужно быстро «погасить пожар», чаще всего помогает MSS clamping на вашей стороне — на сервере или граничном шлюзе. Идея: подправить MSS в SYN/SYN‑ACK так, чтобы TCP изначально не слал сегменты, которые упрется в MTU.

Linux умеет автоматически подбирать MSS по MTU интерфейса через --clamp-mss-to-pmtu. Это особенно удобно на узлах, где есть туннели и маршрутизация.

iptables: clamp MSS для транзитного трафика и для хоста

Если узел является шлюзом (трафик идет через него), обычно нужен FORWARD:

iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Если проблема на самом хосте (его собственные исходящие подключения), применяйте OUTPUT:

iptables -t mangle -A OUTPUT -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Входящая цепочка INPUT используется реже и обычно нужна только при нестандартных схемах (асимметричная маршрутизация, сложный policy routing):

iptables -t mangle -A INPUT -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Если вы активно работаете с фильтрацией на хосте, может пригодиться разбор типичных ошибок и готовых паттернов: iptables/nftables и правила firewall (в том числе для контейнеров).

nftables: аналогичный MSS clamping

В nftables логика та же: правим MSS только в SYN. Пример для отдельной таблицы (адаптируйте под вашу структуру):

nft add table inet mangle
nft 'add chain inet mangle forward { type filter hook forward priority mangle; policy accept; }'
nft add rule inet mangle forward tcp flags syn tcp option maxseg size set rt mtu

На разных версиях nft синтаксис и доступные выражения могут отличаться. Если ваша цель — быстро и предсказуемо, иногда проще временно использовать iptables-правило или поставить фиксированный MSS числом.

Когда лучше фиксированное значение MSS

Если вы знаете, что у вас туннель с MTU, например 1420, можно задать MSS вручную (обычно MTU минус 40 для IPv4 TCP):

iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1380

Почему иногда это лучше, чем --clamp-mss-to-pmtu? В «черной дыре» PMTUD не дает корректной оценки пути, а вам нужна консервативная, но стабильная настройка.

Проверка результата: как понять, что стало лучше

После включения MSS clamping проверьте:

• мобильные клиенты перестали ловить таймауты при открытии HTTPS;
• в tcpdump исчезли бесконечные ретрансляции крупных сегментов на 443;
• сократилось время до первого байта на проблемных сетях (особенно на первом заходе).

Полезно в момент теста снять короткий дамп и убедиться, что в SYN/SYN‑ACK действительно рекламируется меньший MSS.

Типовые причины MTU-проблем в проде

• VPN/туннели без корректного MTU (WireGuard/IPsec/OpenVPN, L2TP, GRE/VXLAN).
• PPPoE на стороне провайдера/клиента и «слепое» 1500 на одном из участков.
• CGNAT/мобильные сети с дополнительными заголовками и меньшим эффективным MTU.
• Файрволы, которые блокируют ICMP “fragmentation needed” и “packet too big”.
• Смешанные маршруты: часть трафика идет по пути с нормальным MTU, часть — по пути с меньшим MTU, из-за чего проблема «плавает».

Частые ошибки при «лечении» MTU

Запретить весь ICMP

Это ломает PMTUD и провоцирует blackhole MTU. Без ICMP сеть теряет механизм сигнализации о проблемах размера пакета.

Поднять MTU до jumbo без проверки пути

Jumbo frames полезны в контролируемом сегменте (например, внутри одной стойки), но для интернета и мобильных клиентов часто создают «узкие горлышки», если где-то на пути MTU меньше.

Путать MTU и MSS

MTU — про IP-пакет. MSS — про TCP payload. MSS clamping не меняет MTU интерфейса, но ограничивает размер TCP сегментов так, чтобы они гарантированно «влезали» в типичный путь.

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

Короткий чеклист: что делать, если подозреваете MTU/PMTUD

1. Зафиксируйте симптом: HTTPS с мобильных сетей тормозит или таймаутится, с Wi‑Fi нормально.
2. Снимите tcpdump на сервере и ищите ретрансляции или ICMP “Fragmentation Needed”/“Packet Too Big”.
3. Проверьте MTU интерфейсов и наличие туннелей.
4. Если контролируете границу — разрешите нужные ICMP типы (особенно для IPv6).
5. Как быстрый фикс — включите MSS clamping на шлюзе или на хосте-терминаторе туннеля.
6. Повторите тест и убедитесь, что проблема ушла.

Когда это особенно актуально на VDS

На VDS вы часто сами отвечаете за сетевой стек: VPN, reverse proxy, контейнерные сети, дополнительные интерфейсы, пользовательские правила firewall. Любой туннель поверх VDS почти всегда «съедает» MTU, и если не учитывать это в маршрутизации и фильтрации ICMP, проблемы проявятся именно на «краю» — у мобильных пользователей и удаленных провайдеров.

Если веб-узел одновременно выступает шлюзом (например, VDS с WireGuard + Nginx), сразу закладывайте проверку MTU/PMTUD и политику MSS clamping в базовый плейбук. Это один из тех сетевых нюансов, который напрямую превращается в деньги: «сайт не открывается» пользователи не дебажат — они уходят.