MTU clamp и потеря пакетов в VPN: что делать

Страница открывается наполовину? Картинки грузятся, а CSS — нет? Это не "магия" и не сбой сайта. Почти всегда виноваты MTU/MSS и сломанный Path MTU Discovery. По факту это лечится — одной-двумя командами на сервере или роутере.

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

Обновлено: 2026-08-19

Что такое MTU, MSS и почему VPN начинает «ронять» пакеты

Если по‑простому: MTU — максимально допустимый размер IP‑пакета на конкретном участке сети. MSS — максимальный размер полезной нагрузки TCP внутри этого IP‑пакета, без TCP/IP заголовков. Туннели добавляют свой оверхед и «съедают» часть MTU. Когда приложение этого «не знает», оно шлёт слишком большие сегменты — и часть трафика теряется.

Стандартный MTU Ethernet — 1500 байт (802.3). Для PPPoE это 1492 — классика для домашних провайдеров.

При таком MTU типичное MSS для IPv4 равно около 1460 байт (1500 − 20 IP − 20 TCP) — это базовая арифметика, но она рушится моментально, как только мы включаем VPN.

Почему рушится? Туннель добавляет заголовки: UDP, шифрование, обфускация, обёртка протокола. Для WireGuard это приблизительно 60–80 байт оверхеда, по нашим тестам. Для обфусцированных реализаций вроде AmneziaWG эта величина чуть больше — где‑то на 10–20 байт, опять же по нашим тестам. А ещё есть IPv6, у которого минимальный MTU обязателен 1280 байт (IETF RFC 8200, 2017).

• MTU: максимальный размер IP‑пакета на линке.
• MSS: максимальный размер TCP payload внутри IP‑пакета.
• Туннельный оверхед: «минусуем» его из внешнего MTU, чтобы вычислить безопасный MSS.
• Если ICMP «Fragmentation Needed» не доходит — PMTUD ломается, пакеты «умирают».

Как работает Path MTU Discovery и где возникает «чёрная дыра»

Path MTU Discovery (PMTUD) — механизм, при котором хост узнаёт минимальный MTU вдоль пути до получателя. Он шлёт пакеты с флагом DF, и если где‑то по пути пакет слишком большой, роутер обязан вернуть ICMP «Fragmentation Needed» с сообщением о допустимом размере. Красиво на бумаге. На деле ICMP часто фильтруют.

Когда ICMP режут, PMTUD не получает ответов, а отправитель продолжает гнать «жирные» пакеты. Результат — таймауты на TLS‑рукопожатии, висящие загрузки, зависающие API‑вызовы. Есть и PLPMTUD (RFC 4821, 2007), который пытается обойтись без ICMP, но в реальных сетях он не всегда выручает — особенно сквозь VPN с дополнительным оверхедом и DPI.

Где чаще всего случается «black hole»? На мобильных сетях, CGNAT‑узлах, корпоративных файрволах и узлах DPI/ТСПУ, которые по разным причинам блокируют ICMP или фрагменты. Я недавно проверял на смартфоне с Yota и отдельно с Билайном — поведение разное, и это нормально.

• Фильтрация ICMP на межсетевых экранах.
• Отключённая фрагментация из‑за DF и политики безопасности.
• Туннельный оверхед «съел» MTU, но приложение шлёт крупные MSS.
• Неправильные MTU на промежуточных интерфейсах или VLAN.

Что такое MTU clamp (TCPMSS) и как он спасает TCP

MTU clamp — это приём, когда на пограничном узле (роутере/сервере VPN) мы автоматически уменьшаем MSS в TCP SYN‑пакетах в соответствии с реальным MTU пути. По сути, мы «подсказываем» конечным хостам, какой максимальный сегмент использовать, чтобы пакеты не разваливались по дороге.

Когда нужен clamp? Почти всегда, как только появляется туннельный оверхед и риск, что ICMP не дойдёт. Я включаю его по умолчанию. Он особенно полезен при UDP‑туннелях (WireGuard, QUIC‑обёртки, AmneziaWG): поверх UDP нет встроенного управления MSS, значит, надо подсказать TCP аккуратно и заранее.

Есть два подхода: фиксировать минимальный безопасный предел (например, 1280 байт для IPv6, 1360–1380 MSS в PPPoE‑сетях с MTU 1492) или динамически «прижимать» MSS к MTU пути — опция clamp‑to‑PMTU. Второй — гибче. Но, честно говоря, он не идеален там, где PMTUD полностью убит и нет надежных ICMP; в таких сетях я предпочитаю выставлять консервативный потолок руками.

• iptables: iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
• nftables: tcp flags syn tcp option maxseg size set clamp to pmtu (в chain mangle/forward)
• Фиксированное MSS: --set-mss 1360 для WireGuard поверх IPv4 (MTU 1500) или PPPoE 1492 — по нашим замерам это стабильно
• WireGuard‑клиент: параметр MTU = 1280..1380 в конфиге часто решает проблему

Практические значения MTU/MSS для WireGuard, AmneziaWG, VLESS+Reality и Trojan

Ниже — то, что у нас в команде стабильно даёт результат. Это не «серебряная пуля», сети разные. Но стартовые значения работают — и быстро экономят часы дебага. Я специально даю вилки, а не жёсткие числа.

Как мы мерили: ping с DF, tracepath, iperf3, скачивание больших бинарей и тяжёлых CSS с CDN (Cloudflare, Akamai), плюс tcpdump на SYN/SYN‑ACK. На мобильных операторах в Москве хорошие результаты у нас получались при MTU клиента 1280–1360 и MSS clamp 1300–1360 — по нашим тестам.

• IPv6 минимальный MTU — 1280 (IETF RFC 8200)
• Для TCP‑протоколов clamp на сервере/роутере — must have
• Для UDP‑туннелей дополнительно снижай MTU на клиенте
• Проверяй результат: tracepath, ping -M do, загрузки больших файлов (например, GitHub Releases/100MB.bin)

Кейсы из России: DPI, мобильные сети и «невидимые» потери

У мобильных операторов часто разный MTU по разным APN, да и CGNAT ведёт себя по‑разному. Мы не раз ловили истории, когда приложение «не понимает», что часть пакетов теряется, а пользователь видит пустой экран. Вот конкретные наблюдения из наших логов и полевых тестов.

Мы проверили все 4 протокола на мобильном Билайне в Москве — AmneziaWG прошёл, классический WireGuard напрямую — нет.

ТСПУ начали блокировать классический WireGuard handshake летом 2024 — мы это видели по росту support-тикетов на 40% за 2 недели.

У клиентов на мобильных операторах долго не работали приложения через VPN — оказалось MSS-clamp на ноде не настроен. После фикса в продакшене жалоб не стало.

• Симптом: грузится шапка сайта, а стили/скрипты — нет. Причина: большие HTTP‑ответы рвутся, PMTUD не отрабатывает.
• Симптом: видео стартует и «замирает» через 5–15 секунд (примерно). Причина: крупные сегменты на CDN, DF + резаный ICMP.
• Симптом: TLS‑рукопожатие дольше 3–5 секунд (примерно). Причина: ретраи из‑за потерь крупных пакетов на пути.

Диагностика: как поймать проблему MTU и потерь пакетов

Тут без магии — только измерения. Я обычно иду снизу вверх: ICMP + DF, потом tracepath, потом TCP‑поведение и pcap. Это быстро даёт ответ «ломается ли по MTU» или надо копать в другом месте.

Ниже — приёмы, которые я регулярно гоняю в проде; они безопасны и воспроизводимы. На Windows (10/11) — через PowerShell и ping -f -l.

• Подбор MTU по ICMP:
  ping -M do -s 1472 8.8.8.8 (Linux, IPv4) — уменьшай -s, пока не пойдёт. 1472 + 28 заголовков = 1500.
  ping -f -l 1472 8.8.8.8 (Windows) — аналогичный тест.
• Маршрут с оценкой MTU:
  tracepath ya.ru (или tracepath -6 ya.ru для IPv6) — покажет, где режется MTU.
• Слушаем SYN и MSS:
  tcpdump -i wg0 'tcp[tcpflags] & tcp-syn != 0' -n -vv — смотри поле MSS.
• Тест TCP через туннель:
  iperf3 -c <server> -p 5201 -R — наблюдай падения/ретраи.
• Проверка HTTP крупными объектами:
  curl -L --http1.1 -o /dev/null https://speed.cloudflare.com/__down?bytes=10M — ловим «зависоны».

Настройка: сервер, роутер, клиент. Что и где крутить

Грубо говоря, стратегия простая: на граничном узле включить TCPMSS clamp, на UDP‑клиенте снизить MTU, а на сервере VPN не допускать «слишком большого» внешний MTU. Это даёт быстрый выигрыш и предсказуемость.

Собрал минимальные рецепты, которые сам использую в проде. Они безопасны, их легко откатить. И они не требуют «перепрошивки» ваших приложений. 🛠️

• Linux iptables (IPv4/IPv6):
  iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
  ip6tables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
• Linux nftables:
  add table inet mangle
  add chain inet mangle forward { type filter hook forward priority -150; }
  add rule inet mangle forward tcp flags syn tcp option maxseg size set clamp to pmtu
• WireGuard клиент (Linux/macOS/Windows):
  В [Interface] добавить MTU = 1280..1380. На iOS — через UI выбрать «Custom MTU» и поставить 1280–1360.
• OpenWrt/роутеры:
  LuCI → Network → Firewall → General settings → MSS clamping (Clamp MSS to PMTU) — включить.
  Задать MTU на интерфейсе WireGuard: LuCI → Network → Interfaces → WireGuard → Advanced Settings → Override MTU: 1280–1360.
• Серверные интерфейсы:
  ip link set dev eth0 mtu 1500 (обычно для Ethernet); для PPPoE — 1492. Не опускайте MTU без причины.

Как мы делаем это в Tunari: политика MTU, протоколы и поддержка

Я практик. Мы закладываем clamp по умолчанию и тестируем его на реальном трафике. Да, сети разные, но хорошая дефолтная политика экономит всем нервы. А когда клиент пишет в чат — быстро проверяем и даём конкретику: что поставить и где.

Пара фактов о продукте, чтобы было понятно, на чём мы это обкатываем. По нашим данным, сеть Tunari — это 19 серверов в 15 странах, четыре из них — в Москве. Для России у нас тарифы от 199 ₽ в месяц или 1690 ₽ в год через СБП, а оплатой картой — $10 в месяц или $48 в год. Протоколы с обходом DPI (AmneziaWG, VLESS+Reality) доступны в приложениях для Windows и Android; на iOS — WireGuard. Средняя задержка до Москвы — около 60 мс п50, это комфортно для веба и мессенджеров.

Сервисом в России пользуются несколько тысяч — этого хватает, чтобы ловить краевые кейсы и быстро катить фиксы по MTU/МSS. Наше время ответа поддержки — примерно 15 минут. Аптайм за 30 дней — около 99.9% по нашим метрикам. Если нужно попробовать — есть бесплатные 3 дня на старте, а ещё реферальная программа.

• Включённый по умолчанию TCPMSS clamp на узлах выхода.
• Рекомендованные MTU профили в приложениях для WireGuard/AmneziaWG.
• DPI‑устойчивые профили: см. AmneziaWG и обход DPI.
• Скачай клиенты: /download, вопросы — /support и /faq.

Немного честности. Это не идеальное решение, потому что непредсказуемый DPI и опек‑правила у операторов иногда лезут «поверх» любой настройки MTU. И Tunari проигрывает гигантам в количестве локаций, но выигрывает скоростью реакции и гибкой настройкой под российские сети — по моему опыту это решает.

Минусы и контр-аргументы

Когда VPN не нужен? Если проблема только в MTU внутри локальной сети/на роутере, а доступ к ресурсам не блокируется, иногда проще один раз включить TCPMSS clamp на вашем домашнем маршрутизаторе — и всё. Ещё момент: clamp помогает TCP, но UDP‑приложения (игры/VoIP/QUIC) могут продолжать страдать — там важнее правильный MTU клиента. И да, я честно скажу: MTU‑тюнинг — это не лекарство от любой «медленности»; если узкое место — CPU на телефоне или очередь у провайдера, никакой clamp не ускорит. Tunari не идеален и здесь: у нас нет нативной утилиты под macOS для автоматического подбора MTU, но есть инструкции и поддержка — поможем вручную.

FAQ

Что такое MTU clamp простыми словами?

Это автоматическое уменьшение MSS в TCP SYN так, чтобы пакеты гарантированно пролезали через самый узкий участок пути. Работает на роутере или сервере VPN и спасает TCP, когда ICMP фильтруют, а туннель «съел» часть MTU.

Какой MTU ставить для WireGuard?

Стартово попробуй 1280–1380. По нашим тестам на мобильных сетях в РФ часто стабильно 1280–1360. Параллельно включи TCPMSS clamp на сервере — это критично для TCP поверх UDP‑туннеля.

Как понять, что проблема в MTU, а не «в интернете»?

Сайты открываются без стилей, крупные загрузки зависают на одном и том же проценте, а ping -M do с крупными пакетами не проходит — классика. Ещё помогает tracepath: он покажет «режущий» хоп.

Поможет ли MTU clamp для QUIC/HTTP3?

Напрямую — нет, TCPMSS влияет на TCP. Для QUIC важно задать корректный MTU на туннеле (например, 1280–1350 по нашим тестам), чтобы UDP‑датаграммы не рвались.

Какой стандартный MTU у Ethernet и IPv6?

Ethernet — 1500 байт; у PPPoE — 1492. Для IPv6 минимальный MTU — 1280 байт (IETF RFC 8200). Эти числа помогают выбрать «консервативный» предел.

Почему через VPN сайт открывается хуже, чем без него?

Потому что туннель добавляет оверхед, а ICMP на пути может быть отрезан. Без VPN PMTUD худо‑бедно работает, а внутри туннеля — уже нет. Решение: clamp + корректный MTU клиента.

Где в Tunari включить MTU‑профили и какие протоколы поддерживаются?

В нашем приложении для Windows 10+/Android 10+ доступны профили с AmneziaWG и VLESS+Reality; на iOS — WireGuard. Рекомендованные значения MTU включены по умолчанию. Если нужна помощь — напиши в поддержку, отвечаем примерно за 15 минут.

Попробовать Tunari 3 дня бесплатно ✅

Об авторе

Орест Родькин, основатель Tunari VPN. 7 лет в индустрии. Email: orest@tunarivpn.com. X: @orestrodkin