Ошибки и коды · Инструкция
VPN и MTU: что делать, если сайты зависают или открываются не полностью
Если VPN подключается, но часть сайтов зависает на загрузке, крупные запросы не проходят или соединение «умирает».
Короткий ответ
Сначала подтвердите, что проблема появляется только через VPN и связана с размером пакетов. Для OpenVPN официальный manual прямо отмечает: MTU-проблемы часто выглядят как зависание соединения при активном использовании; вместо случайной правки десятка параметров начните с диагностики пути и документированных MTU/MSS-настроек.
Почему VPN уменьшает полезный размер пакета
Обычный IP-пакет проходит по пути с определённым максимальным размером кадра, а VPN добавляет собственные заголовки и иногда дополнительную транспортную оболочку. Если исходный пакет уже близок к пределу физического канала, после инкапсуляции он может перестать помещаться. В нормальной сети Path MTU Discovery помогает отправителю уменьшить размер, но ICMP-сообщения о необходимости фрагментации иногда фильтруются, а отдельные туннели и NAT усложняют картину. Получается неприятный «полурабочий» режим: маленькие запросы, ping и DNS проходят, а TLS-сессия, загрузка изображений или отправка формы зависают. Это отличает MTU-сбой от полного отсутствия маршрута. OpenVPN в официальном manual отдельно предупреждает, что такие проблемы часто проявляются именно при активной передаче данных, а не на этапе установления VPN.
Важно: Наличие ping не доказывает, что MTU в порядке: стандартный ping-пакет намного меньше реального HTTPS-трафика.
Диагностика: от простого к изменению MTU
- Сравните один и тот же сайт с включённым и выключенным VPN. Если без туннеля симптом остаётся, MTU VPN маловероятен.
- Проверьте несколько доменов и типов трафика: обычный HTTPS, загрузку файла, видеосервис. Один проблемный сайт может быть отдельной серверной ошибкой.
- На системе, где это доступно, выполните ping с запретом фрагментации и постепенно уменьшайте payload. Учитывайте, что прибавка IP/ICMP-заголовков зависит от семейства адресов и ОС.
- Посмотрите фактический MTU туннельного интерфейса и маршрута. Не меняйте одновременно MTU, DNS, протокол и сервер — иначе вы не узнаете, что помогло.
- Для OpenVPN используйте документированные опции вроде `mssfix` только после подтверждения симптома и с пониманием конфигурации сервера/клиента. Для других VPN следуйте настройкам конкретной реализации.
- После изменения повторите тот же набор тестов и сохраните исходное значение, чтобы быстро откатиться.
Предупреждение: Не переносите значения MTU из случайной инструкции один-в-один: PPPoE, IPv6, WireGuard, OpenVPN/UDP, OpenVPN/TCP и мобильные сети имеют разный overhead.
Как отличить MTU-проблему от соседних неисправностей
- VPN подключён, DNS-имя не разрешается. DNS/политика резолвера, не MTU
- Маленькие запросы работают, большие зависают. MTU/PMTU/MSS
- Не работает только один домен. маршрут/CDN/блокировка конкретного ресурса
- Весь трафик пропал сразу после connect. маршрут, kill switch, AllowedIPs/redirect-gateway
- Проблема только при нагрузке OpenVPN. проверить MTU и mssfix по manual
Почему нельзя сразу ставить MTU 1280 или 1200
Слишком маленький MTU действительно может «спрятать» проблему, потому что пакеты начинают помещаться почти в любой путь, но это не лучший финальный тюнинг. Чем меньше MTU, тем больше пакетов требуется для того же объёма данных, растёт относительная доля заголовков и нагрузка на обработку. Кроме того, можно замаскировать неправильную маршрутизацию или блокировку ICMP, которые позже проявятся в другом месте. Правильнее найти наибольшее стабильное значение для конкретного пути либо использовать механизм, предусмотренный вашим VPN-клиентом. В OpenVPN `mssfix` ограничивает размер TCP MSS так, чтобы TCP-пакеты после инкапсуляции легче проходили через путь; актуальный manual OpenVPN отмечает, что `tun-mtu` по умолчанию обычно лучше не менять без причины, а для подтверждения MTU-проблемы предусмотрены отдельные механизмы вроде `mtu-test` и `mssfix`.
Совет: Если вы управляете только клиентом коммерческого VPN, сначала проверьте настройку MTU в приложении/поддержке сервиса: ручная правка интерфейса может быть перезаписана при следующем подключении.
Как искать рабочее значение, не превращая тест в угадайку
Смысл теста не в том, чтобы найти «самую маленькую цифру, с которой открылся сайт», а в том, чтобы определить границу стабильного размера пакета и связать её с реальным туннелем. Делайте несколько попыток с одинаковым маршрутом и сервером, меняя только размер тестового пакета. Учитывайте заголовки: payload утилиты ping не равен MTU интерфейса один к одному. Если после небольшого уменьшения MTU или корректного MSS-clamping проблемные HTTPS-сеансы начинают работать стабильно, это подтверждает направление поиска. Затем верните значение ближе к максимально рабочему и повторите тесты скорости, загрузки файлов и нескольких сайтов. Если любое изменение даёт хаотичный результат, вероятнее проблема не в MTU.
Минимальный протокол проверки после изменения
- Туннель подключается и публичный IP меняется ожидаемо.
- Открываются сайты, которые раньше зависали на середине загрузки.
- Проходит загрузка и отправка файла, а не только короткий HTTP-запрос.
- Нет заметного падения скорости из-за чрезмерно маленького MTU.
- После переподключения VPN значение сохраняется или применяется штатной конфигурацией.
- Вы сохранили исходные параметры и можете выполнить обратный тест.
Почему HTTPS особенно хорошо проявляет проблему
Современная веб-страница состоит из множества параллельных HTTPS-запросов, поэтому граничная ошибка MTU заметна не как один понятный «обрыв», а как зависшие изображения, бесконечный индикатор загрузки или форма, которая не отправляется. Иногда первая страница открывается из кэша, а переход дальше ломается. Для проверки полезно использовать не только браузер, но и загрузку достаточно большого файла через `curl` или другой инструмент, чтобы отделить сетевой транспорт от расширений браузера и кэша. Если крупная передача стабильно зависает только через туннель, это сильнее поддерживает гипотезу MTU/PMTU.
Дополнительная проверка по ситуации
При диагностике полезно фиксировать не только число MTU, но и контекст пути: какой VPN-сервер выбран, какой транспорт используется, есть ли PPPoE, мобильная сеть, IPv6 или дополнительный туннель. Один и тот же ноутбук может иметь разный рабочий MTU дома и в мобильном хот-споте. Поэтому финальная настройка должна жить в том профиле, к которому относится, а не становиться глобальной системной правкой без необходимости. Если клиент автоматически вычисляет MTU, сначала убедитесь, что ручное переопределение действительно поддерживается. После обновления VPN-клиента повторите тест: реализация и overhead могут измениться, а старая ручная настройка — стать лишней.
Что учитывать
Обычный IP-пакет проходит по пути с определённым максимальным размером кадра, а VPN добавляет собственные заголовки и иногда дополнительную транспортную оболочку. Если исходный пакет уже близок к пределу физического канала, после инкапсуляции он может перестать помещаться. В нормальной сети Path MTU Discovery помогает отправителю уменьшить размер, но ICMP-сообщения о необходимости фрагментации иногда фильтруются, а отдельные туннели и NAT усложняют картину. Получается неприятный «полурабочий»…
Источники и проверка
Фактическая часть сверена по первичным источникам (в т.ч. OpenVPN 2.7 Manual — MTU, mtu-test and mssfix). Пример и формулировки — редакция N1RO на 2026-09-21.