Скорость упирается в 100 Мбит независимо от тарифа: где искать бутылочное горлышко

MAATRIX

Тариф обещает гигабит, в панели провайдера порт помечен как 1 Гбит/с, а любой тест скорости — хоть scp, хоть speedtest, хоть загрузка в браузере — упорно показывает ровно 100 Мбит/с, и ни граммом больше. Это не совпадение и не «просто такой у вас интернет»: круглая цифра в потолке скорости почти всегда означает, что где-то в цепочке между вашим сервером и получателем данных стоит конкретное техническое ограничение, которое можно найти и снять. Разберём, где именно искать, по какому порядку проверять и какими командами это подтверждать.

Почему именно круглая цифра — это диагностический признак

Если бы дело было в перегруженном маршруте, потерях пакетов на дальней связи или в TCP-окне, которое не успевает разогнаться на большом RTT, скорость обычно выглядела бы неровно — 340 Мбит/с, 78 Мбит/с, 615 Мбит/с, с разбросом между замерами. Такой случай, когда гигабитный канал на практике даёт 30-40 Мбит/с из-за произведения полосы на задержку, разобран отдельно в статье про гигабитный канал, который кончается на 40 мегабитах — там разброс от теста к тесту заметный.

А вот стабильный, воспроизводимый потолок ровно в 100 Мбит/с (или 10 Мбит/с, или 1 Гбит/с при тарифе 10 Гбит/с) — это почти всегда следствие того, что где-то в цепочке физически или программно стоит ограничитель именно на этом значении. 100 Мбит/с — не случайное число: это скорость стандарта Fast Ethernet, самого распространённого «резервного» режима, на который откатывается оборудование, если не может согласовать более быстрый. Отсюда и стратегия поиска: от физического уровня (согласование интерфейса) вверх — к виртуализации, операционной системе и промежуточным устройствам сети. Начинать стоит с интерфейса — на практике это причина такого потолка чаще всего, и проверяется быстрее всего.

Шаг 1: физический интерфейс застрял на 100 Мбит вместо гигабита

Сетевые интерфейсы Ethernet, работающие на скоростях 10/100/1000 Мбит/с, по умолчанию используют автосогласование (auto-negotiation) — оба конца линии (сетевая карта сервера и порт коммутатора) обмениваются сигналами и договариваются о максимальной общей скорости и режиме дуплекса, которые оба умеют поддерживать. Если процесс автосогласования проходит некорректно, стороны договариваются не о максимально возможном режиме, а о заведомо заниженном — и почти всегда это заниженное значение оказывается именно 100 Мбит/с, потому что это самый распространённый «резервный» режим, который поддерживает практически любое оборудование.

Три типичные причины сбоя автосогласования, по убыванию частоты:

• Рассинхронизация autonegotiation между сервером и портом коммутатора. Одна сторона выставлена в режим автоопределения, а другая — жёстко зафиксирована на конкретной скорости, либо драйвер сетевой карты после обновления или переустановки ОС вернулся к настройкам по умолчанию, отличным от порта коммутатора. Результат — откат на 100 Мбит/с, а в старых случаях ещё и duplex mismatch (одна сторона в полном дуплексе, другая в полудуплексном), что дополнительно роняет реальную пропускную способность из-за коллизий.
• Кабель категории 5 вместо 5e или 6. Старый Cat5 физически не рассчитан на гигабитную передачу по всем четырём парам проводников — на короткой длине он иногда всё равно даёт гигабит, но на кабеле подлиннее, с плохой обжимкой разъёма или наводками автосогласование само откатывается на 100 Мбит/с, потому что линия не тянет более высокую скорость надёжно. Особенно вероятно в старой стойке с проводкой, которую не меняли годами, или при изношенной патч-панели между сервером и коммутатором.
• Неисправный или деградировавший порт коммутатора. Порты физически изнашиваются и иногда переходят в защитный режим пониженной скорости при частых ошибках на линии (CRC-ошибки, наводки, плохой контакт) — встроенная защита оборудования, которая незаметно «подрезает» скорость вместо отключения порта. Проверяется переключением кабеля в заведомо исправный соседний порт того же коммутатора.

Как проверить согласованную скорость интерфейса на Linux

Основной инструмент диагностики — ethtool. Общая идея команды одна и та же почти на всех дистрибутивах Linux (конкретное имя интерфейса — eth0, ens3, enp1s0 и подобные — зависит от вашей системы, посмотреть список интерфейсов можно через ip link):

ethtool eth0

В выводе интересуют прежде всего три поля:

• Speed: — реально согласованная скорость. Если тариф гигабитный, а тут написано 100Mb/s — вот и подтверждение диагноза с первого шага.
• Duplex: — должен быть Full. Значение Half при современном оборудовании почти всегда означает проблему согласования, а не осознанную настройку.
• Auto-negotiation: — показывает, включено ли автосогласование вообще; если оно выключено (off) на одной стороне линии при включённом на другой, это прямая причина отката на пониженную скорость.

Если ethtool показывает пониженную скорость, не гадайте, а исключайте кабель и порт по отдельности: сначала замените патч-корд на заведомо исправный (категории не ниже 5e, лучше 6), затем, если не помогло, переключитесь на другой порт коммутатора. Если оба шага физику не подтвердили, стоит явно зафиксировать скорость и дуплекс вручную (ethtool -s eth0 speed 1000 duplex full autoneg on, конкретный синтаксис уточняйте под вашу карту и ядро). Если после этого интерфейс не поднимается или сыпет ошибками — это подтверждает, что линия или порт коммутатора реально не тянут гигабит.

Шаг 2: ограничение на уровне виртуализации или облака

Если вы арендуете VPS, а не физический сервер с прямым доступом к сетевой карте, ethtool на гостевой ОС покажет скорость виртуального интерфейса — а она может быть искусственно ограничена гипервизором на уровне конфигурации вашего конкретного тарифа, независимо от того, что физический аплинк хост-машины гигабитный или ещё быстрее. Это самая частая причина ровного потолка именно на виртуальных серверах: провайдер продаёт тариф с определённой полосой, и эта полоса технически реализована как шейпинг на уровне гипервизора или виртуального коммутатора (например, ограничение на интерфейсе virtio-net, правило tc на хост-стороне моста, или лимит в конфигурации облачного сетевого стека).

Отличить эту причину от физического отката на шаге 1 просто: на виртуальной машине ethtool для виртуального интерфейса часто вообще не показывает реальную согласованную скорость линии (виртуальные адаптеры нередко рапортуют фиксированное значение вроде 10 Гбит/с независимо от фактического лимита) — то есть Speed: тут не аргумент, он показывает возможности эмулируемой карты, а не то, что реально пропускает гипервизор. Диагностика идёт не через интерфейс гостя, а через:

• Сверку с описанием тарифа. Проверьте панель управления и договор — не оказался ли выбранный тариф действительно ограничен 100 Мбит/с, а не гигабитом, как казалось. Путаница между «канал 1 Гбит/с» (характеристика порта хост-машины, разделяемого между арендаторами) и «выделенная полоса вашего тарифа» встречается чаще, чем кажется — подробнее о том, что у виртуалок бывает несколько независимых сетевых лимитов одновременно, не только по мегабитам, в статье про лимиты виртуалки по PPS.
• Обращение в поддержку провайдера с прямым вопросом. Спросите явно: какая полоса реально выделена вашему тарифу на сетевом уровне, и есть ли шейпинг на стороне хоста. Добросовестный провайдер отвечает конкретной цифрой.
• Сравнение с более дорогим тарифом. Кратковременный тестовый апгрейд, если он возможен без долгосрочных обязательств, быстро подтверждает или опровергает гипотезу: если скорость выросла пропорционально — ограничение было тарифным.

Шаг 3: ограничение на уровне операционной системы сервера

Если интерфейс согласован на полную скорость (шаг 1) и тариф провайдера не ограничен (шаг 2), а потолок в 100 Мбит/с всё равно есть — причина смещается внутрь ОС сервера. Чаще всего это случайно оставленное правило шейпинга (traffic shaping), о котором забыли — например, после теста ограничения полосы для какого-то сервиса, или унаследованное от образа диска, с которого разворачивался сервер.

Основной инструмент управления трафиком в Linux — подсистема tc (traffic control) из пакета iproute2. Проверить, не висит ли на интерфейсе активное правило ограничения полосы:

tc qdisc show dev eth0
tc class show dev eth0

Если вывод tc qdisc show показывает что-то отличное от стандартного pfifo_fast или noqueue — например, дисциплину tbf (token bucket filter, классический инструмент именно для ограничения полосы по битрейту) или htb (hierarchical token bucket) с классами, ограничивающими скорость — это прямое подтверждение шейпинга на уровне ОС. Убрать такое правило (после того как убедились, что оно действительно лишнее, а не намеренная настройка QoS):

tc qdisc del dev eth0 root

Второе место, где может прятаться ограничение — правила firewall с модулем ограничения скорости. В iptables это чаще всего модуль limit или hashlimit (обычно ограничивают частоту пакетов/соединений, но иногда встречаются схемы приблизительного шейпинга через них); в nftables — конструкции с limit rate. Смотрите текущие правила:

iptables -L -n -v
nft list ruleset

Ищите строки с явным упоминанием limit, rate, конкретных значений в мегабитах или мегабайтах в секунду — особенно на цепочках OUTPUT и FORWARD, если сервер что-то проксирует или маршрутизирует. Проверьте также /etc/rc.local, systemd-юниты и скрипты автозапуска сети (netplan, NetworkManager dispatcher-скрипты) — иногда шейпинг настраивается там при старте системы, и после перезагрузки правило появляется заново, даже если вы его один раз удалили командой tc qdisc del.

Шаг 4: ограничение на промежуточном сетевом устройстве

Если сервер целиком чист — интерфейс согласован на гигабит, тариф провайдера не режет полосу, а в ОС нет шейпинга — но потолок всё равно держится ровно на 100 Мбит/с, значит ограничение стоит где-то между сервером и точкой измерения, но не на самом сервере. Это может быть:

• Файрвол или IPS/IDS-устройство на границе сети провайдера или дата-центра, применяющее шейпинг ко всему трафику вашего сервера как часть политики безопасности — например, автоматическое ограничение полосы при срабатывании защиты от DDoS, без явного уведомления.
• Балансировщик нагрузки, через который реально идёт ваш трафик (если сервер стоит за балансировщиком провайдера, а не имеет прямой внешний IP) — у балансировщиков часто есть собственные лимиты на бэкенд, отдельные от заявленной скорости порта сервера.
• Пограничное оборудование или канал на стороне получателя — если тест идёт до внешней точки, а не до соседнего сервера в том же дата-центре, потолок может быть на стороне получателя, а не у вас вовсе.

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

Тест iperf3: как отделить внешнюю сеть от собственной проблемы

Ключевой диагностический приём, который расставляет все гипотезы по своим местам — сравнение результата iperf3 внутри дата-центра (до соседнего сервера в той же сети провайдера) и наружу (до внешней точки в интернете). Методика самого инструмента и разбор типичных ошибок измерения подробно разобраны в статье про измерение скорости через iperf3; здесь — конкретно как использовать тест для локализации ровного потолка в 100 Мбит.

На одном сервере поднимаете iperf3 в режиме сервера:

iperf3 -s

На втором (клиенте) запускаете тест:

iperf3 -c ip_адрес_сервера -t 30

Если оба сервера в одном дата-центре у одного провайдера, а тест всё равно упирается в 100 Мбит/с — внешняя сеть исключена полностью: проблема на одном из двух серверов (шаги 1-3 выше) либо в инфраструктуре самого дата-центра между ними (вопрос к поддержке провайдера, с результатом теста на руках).

Если тест внутри дата-центра показывает честный гигабит, а тест до внешней точки упирается в 100 Мбит/с — сервер чист, а причина в промежуточном устройстве на выходе в интернет (шаг 4) или на стороне маршрута/получателя. Стоит повторить тест до нескольких разных внешних точек, чтобы понять, специфично это для одного маршрута или проявляется везде.

Полезно сразу прогнать тест ещё и с несколькими параллельными потоками (-P 4 или -P 8): если сумма всё равно не превышает 100 Мбит/с, это дополнительно подтверждает жёсткий шейпинг по битрейту. А если параллельные потоки в сумме дают ощутимо больше одного — это уже ближе к теме TCP-окна и задержки (BDP), а не к жёсткому шейпингу, и разбирать это стоит отдельно.

iperf3 -c ip_адрес_сервера -t 30 -P 8

Таблица ниже суммирует, куда указывает каждая комбинация результатов:

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