Какой MTU поставить для WireGuard и почему 1420 подходит не всем

MTU — единственная настройка туннеля, которая ломает соединение так, что оно выглядит исправным. Рукопожатие проходит, значок горит «подключено», лёгкие страницы открываются — а тяжёлые висят до бесконечности. Ниже — откуда берутся числа 1420 и 1360, как за минуту измерить свой предел и почему у AmneziaWG из этого числа надо вычитать ещё несколько байт. Все примеры — наши собственные замеры на живых линиях, вместе с одной ошибкой, которую мы на них сделали.

Короткий ответ: с какого числа начинать

Если разбираться некогда, вот готовые значения. Они верны для подавляющего большинства домашних и мобильных сетей:

• 1420 — обычный WireGuard, один туннель, канал даёт полные 1500 байт. Это же значение по умолчанию ставит wg-quick.
• 1420 минус S4 — AmneziaWG, если в профиле задан параметр S4. Почему именно так — ниже отдельный раздел.
• 1360 — когда трафик проходит два туннеля подряд.
• 1280 — заведомо безопасное значение: это минимальный размер пакета, который обязана пропускать любая сеть IPv6 (RFC 8200). Скорость от этого немного проседает, зато «страницы висят» не бывает.

Дальше — как эти числа получаются и что делать, если ни одно из них не подошло.

Сколько байт занимает сама упаковка

MTU — это наибольший размер пакета, который сеть согласна нести целиком, не разрезая. В обычном проводном или Wi-Fi-сегменте это 1500 байт. Туннель заворачивает ваш пакет в собственную обёртку, и обёртка тоже занимает место — значит внутри остаётся меньше 1500. Считается это точно, до байта:

• заголовок внешнего IP — 20 байт для IPv4, 40 для IPv6;
• заголовок UDP — 8 байт;
• служебная часть WireGuard плюс код проверки целостности — 32 байта.

Итого обёртка весит 60 байт над IPv4 и 80 над IPv6. Отсюда и числа: на канале в 1500 байт внутрь помещается 1440 при внешнем IPv4 и 1420 при внешнем IPv6. 1420 выбрано именно потому, что подходит в обоих случаях: какая версия протокола окажется снаружи, заранее не известно — это решает сеть, а не вы.

Важное следствие: 1420 верно ровно до тех пор, пока канал действительно даёт полные 1500. Не дают их, например, подключения по PPPoE (там 1492), некоторые мобильные сети и любой случай, когда ваш туннель идёт внутри другого туннеля — скажем, через служебную сеть работодателя.

Как выглядит неправильный MTU

Признак у этой поломки очень характерный, и по нему её можно узнать до всяких измерений:

• соединение устанавливается, приложение показывает «подключено»;
• небольшие запросы проходят: страница-заглушка открывается, ping идёт;
• а тяжёлые страницы висят, загрузка файла замирает на первых килобайтах, видео не стартует.

Причина в том, что пакеты рукопожатия и мелких запросов маленькие — они пролезают всегда. Полноразмерные пакеты с данными в канал уже не помещаются, и промежуточный узел их отбрасывает. По правилам он обязан прислать в ответ сообщение «пакет слишком велик», по которому отправитель уменьшил бы размер сам, но такие сообщения часто отфильтрованы по дороге — и тогда отправитель просто не узнаёт о потере и шлёт снова и снова. Это состояние называют чёрной дырой MTU.

Если картина другая — соединение не поднимается вовсе или обрывается через несколько секунд — дело почти наверняка не в MTU. Разбор того случая — в статье «Подключено», а интернета нет.

Как измерить свой предел за минуту

Гадать не нужно: размер, который проходит по вашему каналу, измеряется штатным ping с запретом на разрезание пакета. Смысл один и тот же, команды отличаются:

• Windows: ping -f -l 1392 1.1.1.1
• Linux: ping -M do -s 1392 1.1.1.1
• macOS: ping -D -s 1392 1.1.1.1

Подбирайте число после -l или -s, пока не найдёте наибольшее, при котором ответ ещё приходит. К нему прибавьте 28 — это заголовки IP и ICMP, которые в указанный размер не входят, — и получите MTU вашего канала.

Вот живой прогон с нашей рабочей машины, ровно две команды:

• -s 1392 — ответ пришёл за 96,7 мс;
• -s 1393 — message too long, mtu=1420.

1392 + 28 = 1420 — и система сама назвала это число в тексте ошибки. Дальше из измеренного MTU канала вычитаете 60 (или 80, если снаружи может оказаться IPv6) и получаете MTU туннеля.

⚠️ Мерить надо с того же соединения, которым будете пользоваться: у домашнего Wi-Fi, у мобильного интернета и у Wi-Fi в кафе пределы разные. И ещё: часть сетей не отвечает на ping вовсе — тогда возьмите другой адрес назначения, а не решайте, что канал не пропускает пакет.

Почему у AmneziaWG считать надо иначе

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

размер на проводе = MTU + 32 + S4 + 8 + 20 (для внешнего IPv4).

Наш живой случай 7 августа 2026 года. Линия с S4=15 и MTU 1420: полноразмерный пакет весил на проводе 1420 + 32 + 15 + 8 + 20 = 1495 байт. Туннель поднимался, данные не шли. Другая линия, с S4=0, из той же самой сети давала 1480 байт и работала. Разница между «работает» и «не работает» была в пятнадцати байтах мусора.

21 августа мы перемерили это на чистой ноде и получили числа, которые ставят точку: наружу проходит ровно 1500 байт и ни байтом больше, а линии с S4=23 и S4=27 при MTU 1420 выпускают пакеты по 1503 и 1507 байт. То есть при большом S4 стандартное значение 1420 не просто «рискованно» — оно гарантированно за пределом.

Отсюда правило: из MTU вычитается S4, а не S1, S2 или S3 — те добавляют байты только в пакеты рукопожатия, а они и так маленькие. И вычитать надо именно MTU, а не уменьшать S4: S4 обязан совпадать у клиента и сервера, и его правка на живом туннеле рвёт поток — мы это проверили, тоннель поднялся, трафик встал. MTU — величина односторонняя, её можно менять безопасно. Что делает S4 и какие ещё поля конфига обязаны совпасть с сервером — разбор всех полей конфига AmneziaWG.

MTU есть у обеих сторон туннеля

Это место, на котором мы сами споткнулись, и оно неочевидно. MTU на вашей стороне ограничивает только то, что летит ОТ вас. Размер того, что прилетает К вам, задаёт интерфейс на сервере. Поэтому правильное число, поставленное только в клиентском файле .conf, лечит ровно половину беды: запросы уходят, а крупные ответы по-прежнему не долезают.

У нас это выглядело так: клиенту выдавалось посчитанное значение 1408, а интерфейс ноды после каждой пересборки конфигурации поднимался на голых 1420 — разошлись на те же двенадцать байт S4. Симптом со стороны человека был всё тот же: «подключилось, а страницы висят». Если вы держите свой сервер — проверьте mtu у интерфейса на нём, а не только в клиентском конфиге.

Два туннеля подряд — минус ещё 60

Когда трафик проходит через два туннеля один внутри другого, обёртка накладывается дважды: те же 60 байт вычитаются ещё раз. Отсюда 1360. Это обычная ситуация не только у сервисов вроде нашего: два туннеля получаются, например, если вы поднимаете свой WireGuard поверх корпоративной сети, которая сама является туннелем.

Правило простое: каждый дополнительный слой упаковки — минус 60 байт (и минус 80, если этот слой идёт по IPv6).

Что стоит у нас и что из этого вышло

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

Июнь. На одной из нод при MTU 1380 крупные пакеты не пролезали: туннель поднимался, сайты не грузились. Поставили 1280 — заработало. На всякий случай включили ещё и страховку, которая принудительно уменьшает размер кусков TCP.

Конец июля. Владелец сервиса задал резонный вопрос: зачем занижать скорость «на всякий случай», если поломки нет? Обе страховки сняли разом и поставили стандартные 1420 и 1360. Результат смотрели по факту: 11,8 ГБ трафика за сутки на боевых линиях и ни одной жалобы на висящие страницы.

Август. Всплыл случай с S4, описанный выше, и правило «вычитать S4» появилось в трёх местах сразу: в выдаче клиентского конфига, в шаблоне настройки ноды и в пересборке конфигурации.

🔴 А теперь ошибка. Первую версию разбора того августовского случая мы объяснили так: «дома у человека PPPoE с MTU 1492, поэтому 1495 не пролезло». Объяснение выглядело безупречно и было выдуманным: две недели спустя выяснилось, что дома у него оптика с честными 1500. Симптом был настоящий, замер был настоящий, а названная причина — нет. Какое именно звено резало, мы так и не выяснили; правило «вычитать S4» от этого не зависит и подтверждено с другой стороны — теми самыми 1503 и 1507 байт.

Мораль, которая полезнее самого числа: «подходящее объяснение» и «проверенная причина» — это разные вещи. MTU как раз та область, где правдоподобных объяснений много, а измерение делается одной командой.