Диагноз: HTTPS виснет, HTTP летит, и вы уже всё перепробовали
Картина знакомая: сайт по HTTP открывается мгновенно. Переходишь на HTTPS — и браузер задумывается, крутит колесо, потом тайм-аут. Или VPN поднялся, туннель стоит, пинги идут — а тяжёлые страницы не грузятся. Или подключили офис через PPPoE, всё работает, но корпоративный портал на TLS висит намертво.
Причина в девяти случаях из десяти — неправильный MSS. В этой статье разберём, что такое MSS (Maximum Segment Size), как он связан с MTU, почему HTTPS особенно чувствителен к этой проблеме и как настроить MSS Clamping на MikroTik и Keenetic буквально за пять минут.
После прочтения вы получите: понимание механизма, готовые команды для MikroTik и Keenetic, инструменты диагностики и чёткие критерии — когда менять MSS нужно, а когда трогать не стоит.
Что такое MSS (Maximum Segment Size)
MSS — это максимальный размер полезной нагрузки одного TCP-сегмента без учёта заголовков IP и TCP. Проще говоря: сколько байт данных влезает в один TCP-пакет.
MSS неразрывно связан с MTU (Maximum Transmission Unit) — максимальным размером кадра на уровне канала. Связь прямая:
MSS = MTU - 40 байт # 20 байт — заголовок IP # 20 байт — заголовок TCP
Примеры для популярных типов соединений:
| Тип соединения | MTU | MSS |
|---|---|---|
| Ethernet (стандартный) | 1500 | 1460 |
| PPPoE (интернет через DSL/GPON) | 1492 | 1452 |
| L2TP без шифрования | ~1460 | ~1420 |
| IPsec (ESP, AES) | ~1418 | ~1378 |
| GRE-туннель | ~1476 | ~1436 |
| WireGuard VPN | 1420 | 1380 |
MSS анонсируется в момент TCP-рукопожатия (handshake) — в пакете SYN. Каждая из сторон сообщает, какой максимальный сегмент она готова принять. Дальше соединение работает с наименьшим из двух значений.
Проблема возникает, когда реальный MTU на пути меньше того, что анонсировали стороны в SYN.
Почему HTTPS «зависает» из-за MSS
Здесь важно понять механизм Path MTU Discovery (PMTUD). Когда отправитель шлёт пакет, который не влезает в MTU промежуточного узла, маршрутизатор должен либо фрагментировать пакет, либо — если установлен флаг DF (Don’t Fragment) — отправить назад ICMP-сообщение «Fragmentation Needed». Получив его, отправитель снижает размер сегмента.
Но вот беда: многие провайдеры и файрволы блокируют ICMP. Причины разные — от паранойи безопасника до кривой конфигурации. В результате:
- Отправитель никогда не узнаёт, что пакет не прошёл.
- Пакеты молча отбрасываются.
- Соединение зависает.
Почему HTTPS страдает больше, чем HTTP? Всё дело в TLS-рукопожатии. Пакет ClientHello в TLS 1.3 содержит список поддерживаемых шифров, расширений, SNI и прочее — он легко достигает 1400–1500 байт. Если на пути есть PPPoE или VPN-туннель с уменьшенным MTU, именно этот пакет не пролезает.
Сценарий из жизни:
- HTTP работает — запросы и ответы влезают в маленькие пакеты.
- HTTPS виснет на ClientHello — большой пакет, флаг DF, ICMP заблокирован, пакет отброшен, браузер ждёт вечно.
Это классический симптом неправильного MSS в связке с заблокированным PMTUD.
Что такое MSS Clamping и зачем он нужен
MSS Clamping (подстройка TCP MSS) — это механизм, при котором маршрутизатор на лету изменяет значение MSS в TCP SYN-пакетах, приводя его к безопасному значению для данного канала.
Ключевые особенности MSS Clamping:
- Работает только с SYN-пакетами — пакетами, которые открывают TCP-соединение. Установившиеся сессии не затрагиваются.
- Не ломает соединение — просто уменьшает анонсируемый MSS до допустимого предела.
- Решает проблему заблокированного PMTUD — даже если ICMP фильтруется, стороны изначально договариваются на правильный размер сегмента.
- Не требует изменений на конечных узлах — всё происходит прозрачно на уровне маршрутизатора.
Change MSS (изменение MSS) — это именно то, что делает MSS Clamping: маршрутизатор перехватывает SYN-пакет и подменяет в нём поле MSS на нужное значение.
Где MSS Clamping применяется обязательно:
- PPPoE-подключения к провайдеру
- Любые VPN-туннели (IPsec, L2TP, GRE, WireGuard)
- LTE/4G/5G-подключения с нестандартным MTU
- Туннели поверх туннелей
Настройка MSS на MikroTik
MikroTik — один из самых популярных маршрутизаторов в корпоративном и провайдерском сегменте. Настройка MSS Clamping здесь реализована через правила mangle в файрволе.
Шаг 1 — Проверяем текущий MTU интерфейса
/interface print detail # Смотрим поле actual-mtu для нужного интерфейса (ether1, pppoe-out1 и т.д.) # Или конкретно для PPPoE: /interface pppoe-client print detail
Также можно проверить MTU через ping с флагом DF:
/tool ping address=8.8.8.8 size=1472 do-not-fragment=yes # Если получаем ответ — MTU 1500, MSS 1460 # Если тайм-аут — уменьшаем size до получения ответа
Шаг 2 — Настраиваем MSS Clamping через mangle
Фиксированное значение MSS (например, для PPPoE с MTU 1492):
/ip firewall mangle add \ chain=forward \ protocol=tcp \ tcp-flags=syn \ action=change-mss \ new-mss=1452 \ comment="MSS Clamping for PPPoE"
Разбираем параметры:
chain=forward— правило применяется к транзитному трафику (проходящему через роутер). Если нужно защитить сам роутер — используйтеchain=output.protocol=tcp— только TCP.tcp-flags=syn— только SYN-пакеты (открытие соединения).action=change-mss— изменить значение MSS в пакете.new-mss=1452— новое значение MSS (для PPPoE: MTU 1492 − 40 = 1452).
Шаг 3 — Автоматическая подстройка MSS (рекомендуется)
Вместо фиксированного значения можно использовать динамическую подстройку:
/ip firewall mangle add \ chain=forward \ protocol=tcp \ tcp-flags=syn \ action=change-mss \ new-mss=clamp-to-pmtu \ comment="MSS Clamping dynamic PMTU"
clamp-to-pmtu автоматически определяет допустимый MSS на основе MTU исходящего интерфейса. Это более надёжный вариант — не нужно вручную считать и обновлять значение при смене MTU канала.
Шаг 4 — Добавляем правило для входящего трафика (опционально)
/ip firewall mangle add \ chain=forward \ protocol=tcp \ tcp-flags=syn \ in-interface=pppoe-out1 \ action=change-mss \ new-mss=clamp-to-pmtu \ comment="MSS Clamping inbound PPPoE"
Фильтрация по in-interface позволяет применять MSS Clamping только на нужном интерфейсе, не затрагивая локальные соединения.
Проверка через Winbox / WebFig
Если CLI не для вас — в Winbox путь такой: IP → Firewall → Mangle → Add Rule. Выбираете Chain: forward, Protocol: tcp, TCP Flags: syn, Action: change-mss, New MSS: clamp-to-pmtu. Применяете. Готово.
Настройка MSS на Keenetic
Keenetic — популярный роутер для дома и малого офиса с понятным интерфейсом. MSS Clamping здесь настраивается как через веб-интерфейс, так и через CLI.
Способ 1 — Через веб-интерфейс Keenetic
Путь зависит от версии прошивки, но общий маршрут:
Интернет → [Выбрать нужное подключение] → Дополнительно (или Параметры) → TCP MSS
В поле TCP MSS вводите нужное значение. Для PPPoE — 1452. Для L2TP — считайте по формуле под ваш туннель. Сохраняете — роутер автоматически применяет Change MSS для этого интерфейса.
На некоторых прошивках параметр называется «Ограничить MSS TCP» или «Подстройка MSS». Ищите в разделе дополнительных параметров соединения.
Способ 2 — Через CLI Keenetic
Подключаетесь по SSH или через веб-консоль (Система → Командная строка):
# Включаем подстройку MSS для PPPoE-интерфейса interface PPPoE0 ip tcp adjust-mss 1452 # Для автоматической подстройки (если поддерживается прошивкой): interface PPPoE0 ip tcp adjust-mss pmtu # Сохраняем конфигурацию: system configuration save
Важно: Синтаксис CLI Keenetic может отличаться в зависимости от версии KeeneticOS. Перед применением проверьте актуальный синтаксис командой help ip tcp в консоли роутера или в официальной документации Keenetic.
Проверяем результат на Keenetic
# Смотрим активные интерфейсы и их параметры: show interface # Или через веб: Системный монитор → Интерфейсы
Когда нужно менять MSS
Настройка MSS Clamping обязательна в следующих ситуациях:
- PPPoE-подключение к провайдеру — MTU 1492, без MSS Clamping HTTPS будет периодически виснуть.
- L2TP/PPTP VPN — заголовки туннеля уменьшают полезный MTU.
- IPsec (ESP) — шифрование добавляет overhead, MSS нужно пересчитывать.
- GRE-туннели — GRE-заголовок 24 байта, MTU уменьшается.
- WireGuard, OpenVPN — у каждого своё overhead, требуется подстройка MSS.
- LTE/4G/5G-подключения — MTU нестандартный, зависит от оператора.
- Туннель внутри туннеля — каждый уровень добавляет заголовки, MSS нужно считать суммарно.
- Site-to-site VPN — объединение офисов через VPN без MSS Clamping — верный путь к проблемам с HTTPS.
Когда менять MSS НЕ нужно
Не стоит трогать MSS в следующих случаях:
- Обычное Ethernet-подключение без туннелей — MTU 1500, MSS 1460, всё работает штатно.
- PMTUD работает корректно — если ICMP не блокируется и Path MTU Discovery функционирует, Change MSS не нужен.
- Проблема в DNS, а не в MSS — медленная загрузка сайтов часто объясняется плохим DNS, а не MTU. Диагностируйте правильно.
- MSS уже настроен провайдером — некоторые провайдеры сами делают MSS Clamping на своём оборудовании.
Диагностика: как определить проблему с MSS
Прежде чем что-то менять — убедитесь, что проблема действительно в MSS. Вот инструментарий.
Метод 1 — Ping с флагом Don’t Fragment
На Windows:
ping 8.8.8.8 -f -l 1472 # -f — флаг DF (Don't Fragment) # -l 1472 — размер пакета (1472 + 28 байт заголовков = 1500 MTU) # Если ответ есть — MTU 1500, MSS 1460, всё ок # Если Request timeout — уменьшаем -l до получения ответа
На Linux/macOS:
ping -M do -s 1472 8.8.8.8 # -M do — Don't Fragment # -s 1472 — размер payload
Бинарным поиском находим максимальный размер пакета, который проходит. Формула MSS:
MSS = максимальный_проходящий_размер - 8 (ICMP header) - 20 (IP header) # Или проще: если ping с -l 1452 проходит, а с -l 1453 нет — MTU = 1480, MSS = 1440
Метод 2 — Traceroute для поиска узла с проблемой
tracert 8.8.8.8 # Windows traceroute 8.8.8.8 # Linux
Ищем узел, на котором пакеты начинают теряться при увеличении размера. Это и есть узкое место по MTU.
Метод 3 — Wireshark / tcpdump
# Захватываем TCP SYN-пакеты и смотрим поле MSS в TCP Options: tcpdump -i eth0 "tcp[tcpflags] & tcp-syn != 0" -v # В Wireshark фильтр: tcp.flags.syn == 1 # В деталях пакета: TCP → Options → Maximum segment size
Если в SYN видите MSS=1460, а на пути PPPoE — проблема найдена. MSS нужно снизить до 1452.
Метод 4 — Torch на MikroTik
/tool torch interface=pppoe-out1 ip-protocol=tcp # Смотрим трафик в реальном времени # Видим, что крупные пакеты не проходят — подтверждение проблемы MSS
Побочные эффекты и типичные ошибки
Ошибка 1 — Слишком маленький MSS
Если выставить MSS 576 «на всякий случай» — соединения будут работать, но медленно. Каждый мегабайт данных придётся передавать большим числом мелких пакетов. Overhead на заголовки вырастет, производительность упадёт.
Правило: MSS должен быть максимально возможным для данного MTU, но не превышать его.
Ошибка 2 — MSS Clamping только в одну сторону
Если настроить Change MSS только для исходящего трафика, входящие SYN-ACK пакеты могут нести неправильный MSS. Настраивайте mangle правила для обоих направлений или используйте clamp-to-pmtu.
Ошибка 3 — Забыть про IPv6
# На MikroTik — отдельные правила для IPv6: /ipv6 firewall mangle add \ chain=forward \ protocol=tcp \ tcp-flags=syn \ action=change-mss \ new-mss=clamp-to-pmtu \ comment="MSS Clamping IPv6"
Ошибка 4 — Применить правило в неправильном chain
Если компьютеры находятся за роутером и соединяются с внешним миром — используйте chain=forward. Если сам роутер инициирует соединения (например, проверяет обновления) — chain=output.
Где тестировать и разворачивать: выбор хостинга и VPS для сетевых задач
Если вы настраиваете VPN, GRE-туннели или тестируете MSS в лабораторных условиях — вам понадобится VPS с полным контролем над сетевыми настройками. Обратите внимание на возможность настройки MTU и доступ к root.
| Провайдер | Минимальный тариф | Root-доступ | Настройка MTU | Датацентры в РФ |
|---|---|---|---|---|
| Timeweb Cloud | от 130 ₽/мес | ✅ | ✅ | ✅ Москва |
| Selectel | от 200 ₽/мес | ✅ | ✅ | ✅ Москва, СПб |
| Reg.ru VPS | от 149 ₽/мес | ✅ | ✅ | ✅ Москва |
| Hetzner | от €3.79/мес | ✅ | ✅ | ❌ (EU/US) |
Для тестирования сетевых сценариев (PPPoE, GRE, IPsec) удобнее всего брать VPS с поддержкой вложенной виртуализации или bare-metal серверы — на них можно запустить CHR MikroTik прямо в облаке и тренироваться без риска уронить рабочую инфраструктуру.
Лучшие практики и профилактика
- Всегда настраивайте MSS Clamping при использовании любого туннеля — это не опциональная настройка, это обязательная гигиена.
- Используйте
clamp-to-pmtuвместо фиксированного значения — если только у вас нет специфических требований к конкретному числу. - Документируйте MTU каждого интерфейса — при добавлении нового туннеля сразу пересчитывайте MSS.
- Проверяйте MSS после смены провайдера или типа подключения — новый провайдер может иметь другой MTU.
- Мониторьте ICMP unreachable — рост таких сообщений сигнализирует о проблемах с Path MTU Discovery.
- Не блокируйте ICMP полностью — блокировка ICMP echo (ping) оправдана, но ICMP Type 3 (Destination Unreachable) нужен для PMTUD.
Прогноз и итоги
Резюмируем. MSS (Maximum Segment Size) — это максимальный размер TCP-сегмента, производный от MTU: MSS = MTU − 40. При использовании PPPoE, VPN-туннелей и прочих инкапсуляций MTU уменьшается, а вместе с ним должен уменьшаться и анонсируемый MSS.
Когда MSS не подстроен, а PMTUD заблокирован провайдером — HTTPS-сессии зависают на TLS-рукопожатии. Решение — MSS Clamping: маршрутизатор на лету исправляет значение MSS в SYN-пакетах.
На MikroTik это делается одной командой в mangle с action=change-mss new-mss=clamp-to-pmtu. На Keenetic — либо через веб-интерфейс в параметрах подключения, либо через CLI командой ip tcp adjust-mss.
Если после настройки MSS Clamping HTTPS заработал — вы молодец, диагноз был верным. Если нет — проверьте DNS, маршрутизацию и правильность применения правила mangle.
Пишите в комментарии, если возникли вопросы или нестандартные конфигурации — разберём вместе. Подписывайтесь на телеграм-канал, чтобы не пропустить новые рецепты из IT-аптеки.
