Оптимизация ноды: отмечаете нужное, получаете готовый скрипт

Свежая нода едет на умолчаниях. Докер не ограничивает ей память, логи Xray пишутся без ротации, политики перезапуска нет. У 3x-ui и нативных установок к этому добавляется лимит открытых файлов в 1024.

Первый месяц вы этого не замечаете. Потом клиентов становится триста, и нода начинает отваливаться по ночам.

Почему она отваливается и как отличить одну причину от другой, разобрано в статье «Почему ноды перестают работать». Здесь только починка.

Всё, что ниже, делает HUBTune — наш скрипт под MIT. Он не правит чужие файлы: настройки уходят в отдельный *.override.yml рядом с вашим compose, в systemd drop-in или в свою таблицу nftables. Откат удаляет один файл.

curl -fsSL https://raw.githubusercontent.com/qwe8nxtroud/HUBTune/main/hubtune.sh -o hubtune.sh
less hubtune.sh          # прочитайте, прежде чем запускать от root
chmod +x hubtune.sh
sudo ./hubtune.sh status

Скрипт запускается от root и трогает фаервол. Читать чужой код перед таким запуском — не паранойя, а норма; это же правило действует для любого скрипта из интернета, включая наш.

status ничего не меняет. Он показывает текущий лимит памяти, счётчик OOM, пик потребления с момента запуска контейнера, размер логов и nofile. С него стоит начать: половина пунктов ниже у вас может быть уже закрыта.

⚠️ На ноде Remnawave пункт про дескрипторы, скорее всего, окажется пустым: официальный compose уже ставит nofile в 1048576, и скрипт этот шаг пропустит. Пункт нужен 3x-ui и нативным установкам, где лимит остаётся заводским.

Что можно включить

Первые четыре пункта скрипт называет безопасным режимом: они трогают только сам сервис. Swap, sysctl и BBR меняют настройки хоста, поэтому живут в полном режиме.

Конфигуратор

Отметьте, что нужно, и заберите команду.

Сколько памяти отдать ноде

Лимит считается по одной формуле: системе оставляем 20% оперативки, но не меньше 192 МБ и не больше 1 ГБ. Остальное забирает сервис.

Ниже 256 МБ скрипт лимит не поставит: на таком потолке Xray перезапускается по кругу и клиенты видят вечный разрыв вместо честной ошибки.

Своё значение задавайте, когда знаете пик потребления. status читает его из cgroup, то есть считает с момента запуска контейнера: после перезапуска отсчёт начинается заново, и на свежеподнятой ноде цифра ничего не значит.

⚠️ Лимит памяти не лечит утечку, он её локализует. Если Xray на вашей ноде растёт пилой до потолка и перезапускается каждые несколько часов, ищите причину: чаще всего это старая версия ядра Xray или включённый stats с накоплением. Лимит только гарантирует, что вместе с Xray не умрёт панель.

Файрвол, который откатится сам

Отдельная команда, потому что это единственный шаг, которым реально теряют сервер.

sudo ./hubtune.sh firewall

Скрипт собирает свою таблицу nftables, применяет её и запускает таймер на пять минут. Если за это время вы не подтвердите правила из нового подключения, всё откатится.

sudo ./hubtune.sh firewall confirm

Порядок именно такой: применили, открыли второй SSH-сеанс, вошли, подтвердили. Проверять правила в той сессии, где вы их применили, бессмысленно: она уже установлена и живёт по conntrack, даже когда новые подключения запрещены. На этом теряют доступ чаще, чем на любой другой ошибке в правилах.

⛔ Порты инбаундов надо перечислить руками. Политика цепочки — запрет всего, чего нет в правилах. Порты ваших инбаундов Xray заданы в панели, и скрипт про них не знает: он видит только SSH и порт связи с панелью. Сам он об этом предупреждает на этапе plan, но предупреждение легко проскочить.

Ловушка в том, что автооткат вас не спасёт. Вы применяете правила, заходите вторым SSH-сеансом (SSH разрешён), подтверждаете — и в этот момент 443 закрыт, а весь парк клиентов уже отвалился. Таймер израсходован, откатывать нечего.

bash sudo ./hubtune.sh firewall --allow-tcp 443,8443

Выпишите порты из панели до запуска и передайте их флагом. UDP-инбаунды (Hysteria2) добавляются через --allow-udp.

Порт связи ноды с панелью скрипт читает из .env ноды. По умолчанию он открывается со всех адресов: чтобы ограничить его адресом вашей панели, передайте --panel-ip.

sudo ./hubtune.sh firewall --allow-tcp 443 --panel-ip 203.0.113.10

При активном ufw или firewalld скрипт отказывается работать. Два фаервола на одной машине пишут в разные места и переопределяют друг друга в непредсказуемом порядке.

Что останется на диске

Скрипт держит всё своё отдельно и помечает маркером managed-by: hubtune:

Ваш docker-compose.yml остаётся нетронутым. Это важно, когда ноду переустанавливают штатным скриптом панели: он перезапишет свои файлы и не заметит соседние.

Откат

sudo ./hubtune.sh rollback

Откат читает манифест последнего запуска и снимает ровно то, что этот запуск поставил. Чужие настройки, которые лежали на сервере до вас, он не трогает.

Проверить, что помогло

Через сутки после применения:

sudo ./hubtune.sh status

Смотрите три цифры. Счётчик OOM должен перестать расти. Пик памяти должен остаться под лимитом: применение лимита пересоздаёт контейнер, поэтому отсчёт пика начинается с этого момента и сутки набора статистики как раз дают показательную цифру. Размер логов должен встать на потолке max-size × max-file вместо бесконечного роста.

Если OOM продолжается при живом лимите, проблема не в настройках хоста: нода умирает по другой причине, и лимит только не даёт ей утащить за собой панель.

Мониторинг, который покажет это без ручных заходов на сервер, разобран в статье «Мониторинг ресурсов». Защита от сканеров и переборов вынесена в HUBGuard.