Ускоряем ноду: тюнинг сети

22 мин чтенияОбновлено 22.09.2026

Полная настройка ноды под нагрузку: sysctl (bbr + cake, буферы, keepalive, conntrack), MSS-clamp, лимиты файлов и логов Docker, гигиена профиля Xray - с замерами до и после и разбором случаев, когда дело не в настройках, а в канале или диске.

Доступ к руководству — 349 ₽

Чтобы купить, войдите в кабинет - доступ привяжется к аккаунту, а статья будет ждать здесь же.

Разовая оплата · доступ навсегда · обновления материала включены

Содержание (23)

Оглавление

0. Зачем оптимизировать ноду

1. Что нужно перед началом

2. Шаг 1 - подключаемся к серверу

3. Шаг 2 - смотрим, что уже есть на сервере

4. Шаг 3 - замеряем скорость до настройки

5. Шаг 4 - настройка сети на уровне ядра (sysctl)

Почему bbr + cake, а не cubic

net.core.default_qdisc не работает «задним числом»

6. Шаг 5 - применяем настройки

7. Шаг 6 - добавки под свою нагрузку

8. Шаг 7 - MSS-clamp: чиним фрагментацию пакетов

9. Шаг 8 - включаем и запускаем сервис

10. Шаг 9 - лимит файлов и размер логов Docker

11. Шаг 10 - чтобы диск не забился

12. Шаг 11 - гигиена профиля в панели

13. Шаг 12 - проверяем, что всё применилось

14. Шаг 13 - замеряем после

15. Как это ощущается пользователем

16. Если осталось медленно - это уже не тюнинг

17. Как всё откатить

18. Чего не делать

19. Контрольный список

20. Опционально - автоматизация на новые ноды

Фрагмент руководства

У любой ноды с VPN-трафиком из коробки есть два слабых места. Ядро Linux по умолчанию не заточено под долгоживущие, «подвисающие» соединения - а именно такие гоняют мобильные клиенты, которые скачут между вышками и wifi по несколько раз на дню. Плюс крупные пакеты Reality/TCP по пути до клиента иногда просто не пролезают и застревают на фрагментации. Лечится всё это двумя файлами на сервере - в сам Remnawave и rw-core лезть не придётся.

Полный текст, команды и разбор доступны после открытия материала.

← Все материалы