24 марта 2026 года разбираю настройку BBR на VPS по документации разработчиков из Google. Это алгоритм управления перегрузкой TCP: он оценивает доступную пропускную способность и время прохождения пакета туда и обратно, чтобы выбирать темп отправки данных. Прибавка к скорости зависит от сети, а не от самого факта появления слова bbr в настройках.
Сначала отделяем сеть от приложения
BBR не добавляет процессорные ядра и не ускоряет запросы к базе. Если WordPress долго собирает страницу, начинать нужно с PHP, базы и кэша. Если сервер быстро готовит ответ, но передача большого файла нестабильна, уже есть смысл сравнить алгоритмы TCP. Это разные задачи, хотя посетитель в обоих случаях говорит «сайт тормозит».
Алгоритм управляет отправкой на той стороне, где он включён. Настройка VPS относится к TCP-соединениям самого сервера, а не ко всему трафику пользователя в интернете. HTTP/3 работает поверх QUIC, поэтому переносить на него эффект этого sysctl нельзя.
Проверяем поддержку и действующее соединение
uname -r sysctl net.ipv4.tcp_congestion_control sysctl net.ipv4.tcp_available_congestion_control sysctl net.core.default_qdisc tc qdisc show ss -tin
Первый sysctl показывает алгоритм по умолчанию для новых соединений. Список available показывает уже доступные ядру алгоритмы; модуль BBR может потребоваться загрузить отдельно командой sudo modprobe tcp_bbr. В контейнерной виртуализации такие изменения могут зависеть от хоста. Не стоит менять ядро вслепую только потому, что команда вернула ошибку.
Значение default_qdisc не доказывает, какая очередь уже установлена на сетевом интерфейсе. Её показывает tc qdisc show. Для конкретного активного TCP-соединения полезен ss -tin: так можно увидеть применяемый алгоритм, а не только желаемую настройку для будущих сокетов.
Включаем без набора случайных твиков
До изменения сохраните вывод команд и проверьте, нет ли другого файла sysctl с теми же параметрами. Следующий пример создаёт отдельный файл; существующий файл с таким именем сначала нужно сохранить. Команды выполняются на вашем VPS, не на рабочем компьютере.
sudo tee /etc/sysctl.d/99-bbr.conf >/dev/null <<'EOF' net.core.default_qdisc=fq net.ipv4.tcp_congestion_control=bbr EOF sudo sysctl -p /etc/sysctl.d/99-bbr.conf
Здесь fq выбран как подходящая очередь, но это не обязательное условие работы BBR на любом современном Linux. В инструкции Google прямо описан TCP pacing и отсутствие строгого требования fq начиная с Linux 4.20. При этом fq может быть полезен на сильно нагруженных серверах. После применения повторите проверку и создайте новое тестовое соединение.
Сравниваем результат и готовим откат
Измерять стоит с одних и тех же внешних машин, на одинаковых файлах и при сопоставимой нагрузке. Запишите скорость передачи, задержку и повторные передачи до изменения, затем повторите несколько прогонов. Один удачный speedtest не показывает поведение сервиса за сутки. Лимит тарифа и плохой маршрут настройка не отменит.
Для отката удалите созданный файл и явно верните прежние значения sysctl. Одно удаление файла не меняет уже работающую систему. Если менялась очередь интерфейса отдельной командой tc, возвращать её нужно отдельно. Полезно заранее оставить доступ к консоли провайдера.
Я бы начинал с понятной диагностики, а не с обещаний «ускорить VPS вдвое». В соседней заметке о Bash разобрано, почему важно понимать команды, которые копируешь в терминал. С BBR принцип тот же: небольшое изменение, воспроизводимый замер и понятный способ вернуться назад.
