Настройка сети Linux для дальних соединений: буферы TCP, BBR + fq, MTU/MSS и sysctl

На длинном маршруте с большой задержкой (например, VPS в Токио, Сеуле или Москве, который обслуживает пользователей в Европе или материковом Китае) скорость одного TCP-соединения чаще всего упирается в буферы сокетов ядра и алгоритм управления перегрузкой, а не в порт 500 Mbps. В этой инструкции вы рассчитаете этот предел, примените безопасный профиль sysctl с большими буферами TCP и BBR + fq, исправите проблемы MTU/MSS в туннелях, сравните результат до и после с помощью iperf3 и узнаете, как всё откатить.

Почему расстояние ограничивает скорость одного соединения

TCP может держать «в пути» только определённый объём неподтверждённых данных. Этот объём называется произведением полосы на задержку (BDP): пропускная способность × время приёма-передачи (RTT). Если окно, которое позволяют буферы, меньше BDP, соединение ждёт подтверждений и не загружает канал, каким бы быстрым ни был порт.

Пример расчёта: порт 500 Mbps и RTT 180 мс.

• BDP = 500 000 000 бит/с × 0,18 с = 90 000 000 бит = около 11,25 МБ.
• Обычный максимальный приёмный буфер Linux по умолчанию (tcp_rmem) — 6 МБ, и часть его уходит на служебные данные. 6 МБ ÷ 0,18 с ≈ 280 Mbps в самом лучшем случае, а на практике часто 150–200 Mbps на одно соединение.
• С потолком 32 МБ теоретический предел при 180 мс превышает 1 Gbps, и на порту 500 Mbps буфер перестаёт быть узким местом.

Потери пакетов усугубляют ситуацию: классический алгоритм CUBIC резко снижает скорость при каждой потере и на длинном маршруте очень долго разгоняется обратно. BBR же оценивает доступную полосу и RTT, поэтому гораздо спокойнее переносит редкие потери на международных маршрутах. Измерьте свой RTT через ping: он зависит от того, где находятся ваши пользователи.

О самом маршруте: московская площадка JUSTG использует China Telecom CN2 GIA, что даёт более чистый путь в материковый Китай; в Токио и Сеуле — маршруты, оптимизированные для Азии. Хороший маршрут снижает потери и джиттер, но RTT всё равно определяет физика, поэтому настройка буферов полезна на любой площадке.

Шаг 1: Проверьте текущие настройки

uname -r
sysctl net.ipv4.tcp_congestion_control net.ipv4.tcp_available_congestion_control
sysctl net.core.default_qdisc net.core.rmem_max net.core.wmem_max
sysctl net.ipv4.tcp_rmem net.ipv4.tcp_wmem net.ipv4.tcp_mtu_probing
ip -br link
tc qdisc show

Запишите версию ядра, текущий алгоритм управления перегрузкой (обычно cubic), очередь по умолчанию (обычно fq_codel), значения буферов и имя сетевого интерфейса (eth0, ens3 и т. п.; ниже замените eth0 на своё).

Шаг 2: Сохраните резервную копию и найдите конфликтующие файлы

sudo sysctl -a 2>/dev/null | grep -E 'tcp_(rmem|wmem|congestion_control|mtu_probing|notsent_lowat)|core\.(rmem_max|wmem_max|default_qdisc|somaxconn)' | sudo tee /root/sysctl-before.txt
grep -rnE 'congestion|qdisc|rmem|wmem' /etc/sysctl.conf /etc/sysctl.d/ 2>/dev/null

Первая команда сохраняет текущие значения в /root/sysctl-before.txt, чтобы потом их можно было вернуть. Вторая показывает другие файлы, где уже заданы те же параметры. Файлы из /etc/sysctl.d/ применяются в порядке имён, а /etc/sysctl.conf (если он есть) — последним, так что старая строка в нём может незаметно перекрыть ваш новый файл. Удалите или закомментируйте дубли.

Шаг 3: Создайте профиль настройки

sudo tee /etc/sysctl.d/99-network-tuning.conf > /dev/null <<'EOF'
# Queueing discipline and congestion control
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr

# Socket buffer ceilings (32 MB) for high-RTT paths
net.core.rmem_max = 33554432
net.core.wmem_max = 33554432
net.ipv4.tcp_rmem = 4096 131072 33554432
net.ipv4.tcp_wmem = 4096 16384 33554432

# Recover from PMTU black holes
net.ipv4.tcp_mtu_probing = 1

# Keep unsent data in the send buffer small (lower latency)
net.ipv4.tcp_notsent_lowat = 131072

# Larger accept queue for busy services
net.core.somaxconn = 4096
EOF
echo tcp_bbr | sudo tee /etc/modules-load.d/bbr.conf

Что делает каждая часть:

• default_qdisc = fq и bbr: BBR для управления перегрузкой и очередь fq для равномерной отправки пакетов (pacing). Начиная с ядра 4.13 BBR работает и без fq, но эта пара по-прежнему рекомендуется.
• rmem_max/wmem_max и tcp_rmem/tcp_wmem: три числа — минимум, значение по умолчанию и максимум в байтах на сокет. Автонастройка Linux увеличивает буфер соединения только тогда, когда это нужно, так что потолок 32 МБ не означает, что каждое соединение займёт 32 МБ. На тарифе mini (512 МБ RAM) можно взять 16777216 (16 МБ): этого хватает для 500 Mbps при RTT примерно до 150 мс.
• tcp_mtu_probing = 1: если ядро обнаружит «чёрную дыру» MTU (большие пакеты молча отбрасываются), оно уменьшит размер пакетов для этого соединения, вместо того чтобы зависнуть.
• tcp_notsent_lowat: ограничивает объём ещё не отправленных данных в сокете. Это снижает задержку для интерактивного трафика и HTTP/2 без потери пропускной способности.
• somaxconn = 4096: размер очереди принятия соединений. В ядрах 5.4 и новее он уже равен 4096; строка важна только для старых систем и фиксирует намерение.

Последняя строка гарантирует, что модуль tcp_bbr загрузится при старте до применения параметров sysctl.

Шаг 4: Примените и проверьте

sudo modprobe tcp_bbr
sudo sysctl --system
sysctl net.ipv4.tcp_congestion_control net.core.default_qdisc net.ipv4.tcp_rmem net.ipv4.tcp_wmem

Вы должны увидеть bbr, fq и новые значения буферов. Изменение default_qdisc влияет только на очереди, созданные после него, поэтому у существующего интерфейса старая очередь останется до перезагрузки. Чтобы переключить её сразу:

sudo tc qdisc replace dev eth0 root fq
tc -s qdisc show dev eth0

Затем откройте новое соединение (например, новую SSH-сессию или загрузку) и посмотрите на него через ss, указав IP другой стороны:

ss -tin dst 203.0.113.20

В выводе для каждого соединения видны bbr, измеренный rtt и текущее окно перегрузки. Соединения, открытые до изменений, сохраняют старые настройки, пока не переподключатся.

Шаг 5: Найдите и устраните проблемы MTU/MSS

Проблемы с MTU выглядят совсем не так, как маленькие буферы. Типичные признаки:

• ping и мелкие запросы работают, а большие загрузки или выгрузки зависают после нескольких килобайт;
• SSH пускает на сервер, но замирает, когда команда выводит много текста;
• часть HTTPS-сайтов загружается не полностью или не открывается, чаще всего через VPN, WireGuard, GRE или PPPoE.

Обычно причина — участок с MTU меньше 1500, на котором блокируются ICMP-сообщения «fragmentation needed». Проверьте с флагом «не фрагментировать». Полезная нагрузка 1472 байта плюс 28 байт заголовков дают пакет ровно 1500 байт:

ping -c 3 -M do -s 1472 203.0.113.20
ping -c 3 -M do -s 1400 203.0.113.20
tracepath -n 203.0.113.20
ip link show dev eth0

Если 1472 не проходит, а 1400 проходит, уменьшайте размер шаг за шагом, пока пакет не пройдёт: максимальный рабочий размер + 28 и есть MTU пути. tracepath тоже показывает pmtu по маршруту. Не блокируйте весь ICMP в файрволе: от него зависит определение MTU пути.

Если сервер маршрутизирует трафик других устройств (сервер WireGuard или другого VPN, GRE-туннель, NAT-шлюз), ограничьте TCP MSS для транзитных соединений, чтобы обе стороны договорились о размере сегмента, который помещается в туннель. С nftables (по умолчанию в Debian 12/13 и Rocky/Alma 9):

sudo tee /etc/nftables-mssfix.nft > /dev/null <<'EOF'
table inet mssfix
delete table inet mssfix
table inet mssfix {
    chain forward {
        type filter hook forward priority mangle; policy accept;
        tcp flags & (syn | rst) == syn tcp option maxseg size set rt mtu
    }
}
EOF
sudo nft -f /etc/nftables-mssfix.nft
sudo nft list table inet mssfix

Правило переписывает MSS в SYN-пакетах под MTU исходящего маршрута. Чтобы оно сохранилось после перезагрузки в Debian/Ubuntu, добавьте include "/etc/nftables-mssfix.nft" в конец /etc/nftables.conf и выполните sudo systemctl enable nftables. В Rocky/Alma с firewalld не включайте отдельную службу nftables — используйте способ с PostUp для WireGuard ниже. То же правило для iptables (при необходимости установите пакет iptables):

sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Для WireGuard проще всего прописать правило в конфиг wg-quick (например, /etc/wireguard/wg0.conf): тогда оно будет появляться и исчезать вместе с туннелем:

[Interface]
MTU = 1420
PostUp = iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
PostDown = iptables -t mangle -D FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

MTU 1420 — значение WireGuard по умолчанию, безопасное на обычном пути с MTU 1500. Для TCP поверх IPv4 MSS = MTU − 40, то есть при 1420 MSS равен 1380. Если сервер только отправляет свой собственный трафик и ничего не маршрутизирует, ограничение MSS обычно не нужно: ядро выбирает MSS по MTU интерфейса, а остальное берёт на себя tcp_mtu_probing.

Шаг 6: Сравните результат до и после с iperf3

Запустите одинаковый тест до изменений и после них, примерно в одно и то же время суток. Установите iperf3 на обеих сторонах (apt install iperf3 или dnf install iperf3):

# On the VPS (allow TCP 5201 in the firewall only for the test)
iperf3 -s

# On your own computer
iperf3 -c 203.0.113.10 -t 20            # upload: you -> VPS
iperf3 -c 203.0.113.10 -t 20 -R         # download: VPS -> you
iperf3 -c 203.0.113.10 -t 20 -R -P 4    # download, 4 parallel streams

Как читать результат:

• -R — это направление, которое видят посетители сайта и те, кто скачивает файлы: отправителем здесь выступает VPS. Важнее всего алгоритм перегрузки и буфер отправки на VPS.
• -P 4 открывает четыре соединения. Если четыре потока вместе заметно быстрее одного, одиночное соединение ограничено окном или потерями — именно это и решают буферы и BBR. Если оба варианта одинаково медленные, смотрите на маршрут, на подключение клиента или на его приёмный буфер.
• В режиме -R ваш компьютер — получатель, поэтому его приёмный буфер тоже имеет значение. Современные Windows, macOS и Linux настраивают его автоматически, но старый роутер или VPN на вашей стороне всё ещё могут быть узким местом.

Шаг 7: При необходимости откатите изменения

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

sudo rm /etc/sysctl.d/99-network-tuning.conf /etc/modules-load.d/bbr.conf
sudo reboot

Если просто удалить файл и выполнить sysctl --system, значения не сбросятся: они действуют до перезагрузки. Чтобы вернуть их без перезагрузки, задайте значения из файла резервной копии. Типичные значения по умолчанию для текущих ядер Debian/Ubuntu:

cat /root/sysctl-before.txt
sudo sysctl -w net.ipv4.tcp_congestion_control=cubic net.core.default_qdisc=fq_codel
sudo sysctl -w net.ipv4.tcp_rmem="4096 131072 6291456" net.ipv4.tcp_wmem="4096 16384 4194304"
sudo sysctl -w net.core.rmem_max=212992 net.core.wmem_max=212992

Если вы добавляли правило MSS, удалите его командой sudo nft delete table inet mssfix (или замените -A на -D в команде iptables) и уберите из конфига строку include или строки PostUp/PostDown.

FAQ

Станет ли ping ниже после этих настроек?

Нет. RTT определяется расстоянием и маршрутом. Буферы и BBR позволяют одному соединению использовать больше доступной полосы при этом RTT, а fq вместе с tcp_notsent_lowat помогают держать задержку очередей низкой под нагрузкой, но базовая задержка не меняется.

Безопасно ли ставить буферы 32 МБ на тарифе с 1 ГБ RAM?

Да, для обычной нагрузки. Это потолки на один сокет, автонастройка увеличивает буфер только тогда, когда соединению это действительно нужно, а глобальный лимит ядра tcp_mem рассчитывается от объёма памяти. На тарифе mini с 512 МБ разумно выбрать 16 МБ.

После настройки скорость всё ещё низкая. Что отправить в поддержку?

Откройте тикет в отдел Technical support и приложите IP сервера, время с часовым поясом, результаты iperf3 с -R и -P 4 и без них, а также вывод mtr в обе стороны. Как их собрать, описано в инструкции по тесту скорости. В JUSTG работает AI-поддержка 24/7 через тикеты, а вопросы, которым нужен человек, подхватывают инженеры.