MTU и VPN: почему сайты грузятся наполовину

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

Очень часто за этим стоит несовпадение размеров пакетов, то есть неправильно подобранный MTU. Особенно если проблема появилась ровно после включения VPN. Разберём механизм по шагам: что такое MTU, почему туннель отнимает часть места, почему сбой выглядит именно так и как самостоятельно подобрать рабочее значение.

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

MTU (Maximum Transmission Unit) — максимальный размер одного пакета, который можно передать через конкретный участок сети целиком, без разрезания. Для обычного Ethernet и большинства Wi-Fi-сетей это 1500 байт. Часть из них занимают служебные заголовки: 20 байт уходит на заголовок IPv4 и ещё 20 — на заголовок TCP. На полезные данные остаётся 1460 байт; это значение называется MSS, максимальный размер сегмента.

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

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

Почему в туннеле полезного места меньше

VPN упаковывает ваш исходный пакет в новый: добавляет собственный заголовок, счётчик, метку проверки целостности и внешние заголовки для доставки до VPN-сервера. Всё это занимает место — от нескольких десятков байт и больше, в зависимости от протокола и версии IP. Как устроен VPN-туннель изнутри.

Арифметика простая. Если по маршруту проходит 1500 байт, а обвязка туннеля забирает 60, то внутри туннеля должно ездить не больше 1440. Если же виртуальный сетевой интерфейс продолжает считать, что у него честные 1500, каждый крупный пакет на выходе оказывается больше допустимого — и тут начинается самое интересное.

Что происходит, когда MTU подобран неверно

Здесь важна одна деталь протокола: практически весь современный TCP-трафик отправляется с установленным флагом DF (Don't Fragment) — «не фрагментировать». Это не каприз, а часть механизма Path MTU Discovery, которым отправитель нащупывает максимальный размер пакета, проходящий по маршруту.

Механизм рассчитан на обратную связь. Когда слишком большой пакет с флагом DF доходит до участка с меньшим MTU, маршрутизатор обязан его отбросить и отправить назад служебное ICMP-сообщение: пакет слишком велик, фрагментация запрещена, допустимый максимум — столько-то байт. Получив такое сообщение, отправитель уменьшает размер и продолжает работу.

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

Почему пинг идёт, а страница не грузится

Стандартный пинг отправляет крошечные пакеты: 32 байта полезной нагрузки в Windows, 56 байт в macOS и Linux. Такой пакет пролезет в любую щель. Точно так же пролезают DNS-запросы, TCP-рукопожатие, начало TLS-рукопожатия и небольшие HTTP-запросы. Поэтому соединение устанавливается, сайт начинает открываться, а инструменты проверки связи бодро рапортуют, что всё в порядке.

Ломается ровно тот момент, когда сервер переходит к передаче данных полными сегментами: HTML-страница, скрипты, изображения, объёмный ответ API. Эти пакеты максимального размера — и именно они не проходят. Браузер получил начало ответа и ждёт продолжения, которого не будет, пока не сработает таймаут.

Почему проблема выглядит хаотично

Мелкие запросы проходят, крупные нет — лёгкие страницы и короткие ответы работают, а тяжёлые зависают на полпути.
Одни сайты открываются, другие нет — часть серверов и CDN сами используют консервативные размеры сегментов, часть полагается на стандартный механизм.
HTTP/3 иногда работает там, где не работает HTTP/2 — QUIC изначально использует небольшие датаграммы и умеет сам нащупывать рабочий размер.
Отправка ломается чаще приёма — особенно заметно при загрузке файлов, отправке вложений и синхронизации.
Помогает смена сети или перезагрузка роутера — но лишь потому, что меняется маршрут, а не потому, что проблема исчезла.

Из-за этой пестроты MTU редко подозревают первым. Обычно грешат на скорость канала, провайдера или сам сайт.

Как найти рабочее значение: пошагово

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

Windows

Откройте командную строку и выполните:

ping -f -l 1472 8.8.8.8

Флаг f запрещает фрагментацию, флаг l задаёт размер полезной нагрузки. Число 1472 выбрано не случайно: 1472 байта данных плюс 8 байт заголовка ICMP плюс 20 байт заголовка IP дают ровно 1500.

Если пакет проходит, вы увидите обычные ответы. Если нет — Windows сообщит, что требуется фрагментация пакета, но установлен запрещающий флаг. Это значит, что 1472 байта не помещаются: уменьшайте размер шагами по 8–10 байт (1464, 1456, 1448 и так далее), пока ответы не пойдут. Посмотреть текущие значения MTU у интерфейсов можно командой netsh interface ipv4 show subinterfaces.

macOS и Linux

В macOS запрет фрагментации включается флагом D:

ping -D -s 1472 8.8.8.8

В Linux та же задача решается параметром M do:

ping -M do -s 1472 8.8.8.8

Реакция на превышение будет похожей: сообщение о необходимости фрагментации с указанием допустимого MTU либо локальная ошибка «Message too long». Логика подбора та же — уменьшайте размер, пока пакеты не начнут доходить. Текущий MTU интерфейсов показывают команды ifconfig в macOS и ip link в Linux.

Как посчитать итоговый MTU

К найденному максимальному размеру полезной нагрузки прибавьте 28 байт — это 20 байт заголовка IPv4 плюс 8 байт заголовка ICMP. Например, если последним прошёл пакет с размером 1464, MTU маршрута равен 1492 — типичное значение для линий с PPPoE.

Дальше вычтите накладные расходы туннеля: для WireGuard по IPv4 это 60 байт, значит внутри туннеля остаётся 1432. Это и есть значение, которое стоит указать в настройках VPN-клиента, если он позволяет их менять. Если поле MTU в приложении недоступно, остаются варианты со стороны системы или роутера — либо обращение в поддержку сервиса.

Правило большого пальца: если возиться с точным подбором некогда, начните с 1400. Это значение с запасом проходит в большинстве сетей и почти не сказывается на скорости. Гарантированно безопасный минимум — 1280 байт: столько обязан пропускать любой участок сети с поддержкой IPv6.

Типовые значения для разных протоколов

Точные цифры зависят от версии IP-протокола, выбранного шифра и того, есть ли по пути дополнительная упаковка. Ориентиры такие:

WireGuard — 60 байт накладных расходов по IPv4 (20 байт внешнего IP, 8 байт UDP, 16 байт заголовка и 16 байт метки целостности) и 80 байт по IPv6. Отсюда классическое значение 1420 при маршруте в 1500 байт.
OpenVPN по UDP — примерно 40–70 байт в зависимости от шифра и режима; на практике рабочий диапазон 1400–1450, а регулируется он чаще параметром mssfix, а не самим MTU.
IKEv2/IPsec — 50–80 байт, а при прохождении через NAT добавляется ещё 8 байт инкапсуляции; типичный ориентир — 1400 и ниже.
Мобильные сети — нередко имеют собственные ограничения, поэтому значение, идеально работающее на домашнем Wi-Fi, в сотовой сети может оказаться великоватым.

Занижать MTU «на всякий случай» до минимума не стоит: чем меньше пакет, тем больше их нужно на тот же объём данных и тем выше доля служебных байтов. Разница между 1420 и 1280 в пропускной способности невелика, но на медленных каналах и больших объёмах она заметна.

MSS clamping: когда правится не MTU, а размер сегмента

Есть более аккуратный приём, который применяют на роутерах и VPN-серверах, — MSS clamping, «зажим MSS». Оборудование на лету правит значение MSS в пакетах установки TCP-соединения, сообщая обеим сторонам меньший допустимый размер сегмента. В результате хосты сразу начинают отправлять пакеты подходящего размера, и механизм Path MTU Discovery с его теряющимися ICMP-сообщениями оказывается не нужен.

Плюс подхода — на клиентских устройствах ничего менять не надо. Минус — он работает только для TCP. Трафик по UDP, включая QUIC и HTTP/3, MSS clamping не затрагивает: там размер регулируется механизмами самого приложения. Настраивается всё это на стороне сервера или роутера, поэтому пользователю мобильного VPN-приложения обычно доступен только один путь — изменение MTU в настройках клиента.

Когда дело не в MTU

Похожие симптомы дают и другие причины. Прежде чем менять цифры, стоит проверить:

Потери пакетов на канале — при 5–10% потерь страницы тоже грузятся рывками, но пинг покажет пропуски и разброс задержки.
Проблемы с DNS — страница «висит» ещё до установки соединения; косвенный признак в том, что сайт открывается по IP-адресу, но не по имени.
Неисправный IPv6 — система пытается использовать IPv6, он не работает, и каждое соединение начинается с ожидания таймаута.
Перегруженный или слишком удалённый VPN-сервер — высокий пинг и низкая скорость при полностью исправном MTU.
Сбой на стороне сайта или его CDN — проверяется открытием того же адреса с другой сети или устройства.
Расширения браузера, блокировщики и антивирусы с проверкой HTTPS — обрывают часть запросов независимо от состояния сети.
Неверное системное время — ломает проверку сертификатов, из-за чего часть соединений просто не устанавливается.

Разумный порядок диагностики: сначала проверить, воспроизводится ли проблема без VPN, затем на другой сети, затем на другом устройстве. Если сбой появляется только при включённом туннеле и только на тяжёлых страницах — это классическая картина MTU. Подробный чек-лист есть в материале о том, как диагностировать проблемы с VPN самостоятельно.

Чего VPN здесь не решает

Подбор MTU — это про совместимость, а не про качество связи. Полезно понимать, где заканчивается зона влияния VPN и настроек туннеля.

Не лечит плохой канал — при потерях пакетов, высокой загрузке линии или нестабильном Wi-Fi туннель не сделает соединение стабильнее, а иногда сделает хуже: любая потеря внутри туннеля обходится дороже.
Не ускоряет интернет — маршрут через VPN-сервер почти всегда длиннее прямого, и часть скорости уходит на шифрование и служебные байты.
Не чинит сломанный PMTUD в чужой сети — если ICMP режут на участке между VPN-сервером и сайтом, повлиять на это со своей стороны нельзя, остаётся только уменьшать размер пакета.
Не помогает при проблемах на стороне сайта — если сервис лежит или его CDN отдаёт ошибки, туннель тут ни при чём.
Не заменяет базовой диагностики — понижение MTU иногда маскирует другую проблему, и через неделю она возвращается в другом виде.

И отдельно стоит сказать: правильный MTU не влияет на приватность и безопасность. Это чисто транспортная настройка, от которой зависит, дойдут пакеты или нет, — и ничего больше.

Частые вопросы

Может ли слишком маленький MTU навредить?

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

Нужно ли менять MTU на роутере или достаточно на устройстве?

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

Почему после смены сети всё сломалось снова?

Потому что MTU — свойство маршрута, а не приложения. У домашнего провайдера, мобильного оператора и публичного Wi-Fi значения различаются, поэтому подобранное вручную число может не подойти в другой сети.

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