Сервера для 3x-ui: как выбрать VPS под ноду и не потерять её вместе с IP

Сколько ресурсов реально ест 3x-ui

3x-ui — это Go-панель поверх Xray-core: панель сама по себе почти ничего не потребляет (50–100 МБ RSS, SQLite-база), вся нагрузка приходится на xray — TLS-хендшейки и копирование буферов между сокетами.

Ориентиры по наблюдениям на нодах с VLESS+REALITY и XHTTP:

Важная поправка: одновременные сессии ≠ проданные подписки. На сервисе с ~600 подписками в пике онлайн держится порядка 10–20% базы. То есть 1 vCPU / 1 ГБ — это не «десять клиентов», а рабочая нода на первую сотню подписок.

Один современный поток EPYC/Xeon Gold прокачивает 1,5–3 Гбит шифрованного трафика, так что ядра почти никогда не узкое место. Реальная проблема дешёвых сервисов для 3x-ui — не количество ядер, а oversell: в прайсе «AMD EPYC», а single-thread вдвое медленнее соседа по цене. Проверяйте в первые часы, пока действует возврат:

apt -y install sysbench
sysbench cpu --threads=1 --time=15 run | grep 'events per second'
openssl speed -evp aes-128-gcm 2>/dev/null | tail -2 # без AES-NI цифры падают в разы

По наблюдениям, здоровое ядро даёт 2500–5000 events/sec на поток; 800–1200 — перепроданный хост, меняйте тариф или площадку, пока не раздали конфиги.

Память: 1–2 ГБ swap, чтобы OOM-killer не убивал xray на пиках. На btrfs fallocate под swap не работает — отсюда запасной вариант через dd:

fallocate -l 2G /swapfile || dd if=/dev/zero of=/swapfile bs=1M count=2048
chmod 600 /swapfile && mkswap /swapfile && swapon /swapfile
echo '/swapfile none swap sw 0 0' >> /etc/fstab

Диск съедает не система, а логи и статистика. /etc/x-ui/x-ui.db растёт от почасовой статистики трафика, а access.log xray на активной ноде набирает гигабайты за неделю (в типовой сборке пути относительные, файлы лежат рядом с бинарником в /usr/local/x-ui/bin/). В JSON-настройках Xray в панели поставьте:

"log": { "access": "none", "error": "./error.log", "loglevel": "warning" }

Это заодно снимает вопрос «а что там пишется про пользователей».

Сеть важнее ядер: канал, лимит трафика и PPS

Главный параметр при выборе VPS для 3x-ui — сеть, и именно её в прайсе описывают честнее всего в последнюю очередь.

Лимит трафика. Считайте 10–20 ГБ в месяц на активного пользователя (смартфон плюс периодическое видео); тяжёлые выбирают 50–100 ГБ. Сотня активных — это 1–2 ТБ. Тариф «1 ТБ включено, дальше 1 €/ТБ» и «unmetered 200 Мбит» — разные экономики, посчитайте оба под свой профиль. Отдельно выясните, что происходит при превышении: у части хостеров это счёт, у части — шейп до 10 Мбит, что для сервиса означает лавину тикетов за вечер.

Скорость порта. 1 Гбит на 100–150 сессий комфортно, 200 Мбит начинают чувствоваться в вечерний пик. Полосу меряйте не браузерным спидтестом, а между двумя своими машинами:

# на сервере
apt -y install iperf3 && iperf3 -s
# с другой точки
iperf3 -c IP_НОДЫ -P 8 -t 30 # TCP, 8 потоков
iperf3 -c IP_НОДЫ -u -b 200M -t 20 # UDP: смотрим loss/jitter

PPS. Про это забывают, а на дешёвых KVM встречаются потолки в 50–100 kpps. VPN-трафик — это много мелких пакетов, и нода упирается в PPS при формально свободном гигабите. Симптом: скорость у клиентов просела, а счётчик интерфейса показывает далеко не Гбит.

ip -br link # узнать имя интерфейса: eth0, ens3, enp1s0
apt -y install vnstat && systemctl enable --now vnstat
vnstat -l -i eth0 # live: биты и пакеты в секунду
ss -s # сколько всего сокетов держим

Чего избегать: NAT-VPS и shared IP (нельзя занять 443 и нормально жить с REALITY), OpenVZ/LXC (нет своего сетевого стека, BBR и tcp-тюнинг недоступны), площадки без IPv6, если часть аудитории сидит у мобильных операторов на IPv6-only.

Гео: считайте маршрут, а не километры

Типовые RTT из Москвы по наблюдениям (в регионах прибавляйте 10–30 мс):

Видео при 40 и при 90 мс грузится одинаково, а вот открытие сайта с десятком доменов ощущается по-разному — там последовательные хендшейки. Берите ближе, если нет причины брать дальше.

Главное: география не равна маршруту. Один и тот же Франкфурт отдаёт 45 мс одному оператору и 120 мс другому из-за стыка. Почти все хостеры дают тестовый IP в каждой локации — проверяйте до оплаты, с машины в целевой сети:

mtr -rwzc 50 IP_КАНДИДАТА # где растёт задержка и где теряются пакеты
# RTT именно по TCP/443 — ICMP часто приоритизируется иначе:
nping --tcp -p 443 -c 20 IP_КАНДИДАТА
# без установки nmap:
for i in $(seq 5); do curl -sko /dev/null -w '%{time_connect}\n' --max-time 5 https://IP_КАНДИДАТА/; done

Если ICMP отвечает ровно, а TCP/443 даёт потери и рваный RTT — это не «плохой хостер», а уже фильтрация. Об этом дальше.

Одна панель — один сервер: чем это ограничивает схему

Момент, который меняет планирование серверов для 3x-ui и о котором редко думают до покупки второй VPS: 3x-ui управляет только локальным Xray. В ней нет агента удалённой ноды — в отличие от Remnawave или Marzban, где панель и ноды разнесены по разным машинам. Панель и xray живут на одном хосте, всегда.

Практические следствия:

• Вторая нода — это вторая независимая панель: свои инбаунды, свои UUID, свой x-ui.db, свой бэкап. Клиенты между панелями не синхронизируются.
• Отдельная «дешёвая VPS под панель» смысла не имеет: панели нечем управлять на другой машине.
• У 3x-ui есть встроенный subscription-сервер (в свежих сборках — отдельный порт, по умолчанию 2096), он тоже локальный для этой панели. Раздать одну ссылку на несколько независимых нод им не получится.
• Если в планах больше трёх-четырёх нод, вопрос уже не «какой VPS», а «какая панель»: ручная синхронизация клиентов по нескольким 3x-ui съест больше времени, чем стоит переезд.

Отсюда — что делать с самой панелью на ноде. Спрятать, а не разносить:

• В настройках выставить listen 127.0.0.1 и ходить SSH-туннелем. Текущий порт и web base path свежий инсталлятор генерирует случайными, посмотреть их можно командой x-ui settings.
• Сменить дефолтные логин/пароль сразу после установки, до раздачи первых конфигов.
• Если панель всё же смотрит наружу — только на нестандартном порту, со случайным base path и валидным TLS-сертификатом.

x-ui settings # текущий порт панели и base path
ssh -L 2053:127.0.0.1:ПОРТ_ПАНЕЛИ root@IP_НОДЫ # панель открывается на localhost:2053

Отдельная ловушка: если вы ставите x-ui в Docker с пробросом портов, ufw его не закроет — правила надо писать в цепочке DOCKER-USER, иначе панель и транспортный порт остаются открытыми миру при «включённом файрволе».

IP — расходник: закладывайте это в выбор хостера

Ключевая вещь, которую стоит принять до покупки: ТСПУ работает по адресу назначения. Он не «ломает VLESS» — он перестаёт пропускать пакеты на конкретный IP, иногда сразу на всю /24. Конфиг при этом идеален, панель зелёная, systemctl status x-ui в порядке.

Типичный сценарий деградации:

1. Растут потери на этапе TLS-хендшейка: клиент подключается с третьей-пятой попытки.
2. Через несколько дней 443/TCP к адресу не отвечает вообще, при этом ICMP может продолжать ходить.
3. Иногда следом отваливаются соседние адреса той же подсети — накрыли /24.

Что повышает шанс попасть под это: ASN хостера, давно и массово используемый под VPN; публикация адреса в открытой подписке или бесплатном агрегаторе конфигов (попадание в чужие списки — вопрос дней); концентрация сотен долгих сессий на 443 к одному адресу; ответ на активное зондирование — если сервер на «неправильный» хендшейк отвечает не как обычный веб-сервер. Отсюда требование к REALITY: dest/serverNames указывают на реальный чужой сайт, живой на 443 с валидным TLS и не в РФ (детали — в отдельном материале по настройке REALITY).

Проверять «жива ли нода» можно только снаружи, из целевой сети — с самого сервера curl всегда успешен:

# с телефона на раздаче в проблемном регионе или с машины в РФ
nc -vz IP_НОДЫ 443
curl -sv --max-time 8 https://ваш-домен-ноды/ 2>&1 | head -20

Что делать по факту блока, по возрастанию полезности:

1. Сменить IP. У большинства хостеров дополнительный адрес стоит 1–3 €/мес и переезжает за минуты. Лечит на недели, не навсегда. Запасной адрес держите заранее: менять надо в момент инцидента, а не после ответа на тикет.
2. Раздавать домен, а не IP. Тогда переезд — правка A-записи с TTL 60, а не перевыпуск подписок у всей базы.
3. Убрать IP ноды из-под удара совсем — фронт на «белом» домене: клиент подключается к CDN-адресу, который у операторов в whitelist, а CDN уже ходит к вашей ноде. Блокировать по IP нечего — адрес ноды клиент не видит. Это то, что даёт Clearway; тот же контур собирается самостоятельно на любом CDN, умеющем проксировать нужный транспорт.

Про связку с CDN — нюанс, на который натыкаются все: у Yandex CDN нет POST, поэтому XHTTP-аплинк уходит GET, а GET разрешён только при "mode": "packet-up" — режим нужно задать явно и на ноде, и в клиенте. Поле extra должно совпадать с обеих сторон байт в байт, а экзотические obfuscation-поля лучше не включать: они ломают совместимость между версиями Xray, и получается классическое «в одном приложении работает, в другом нет».

Про российские whitelist-подсети коротко и честно, подробный разбор есть отдельно: whitelist проверяется по каждой /24 и меняется со временем, а российский VPS плохо подходит на роль exit-ноды — трафик выходит в интернет через те же фильтры. Белая подсеть внутри страны имеет смысл как входная точка, но не как выход.

Подготовка сервера под 3x-ui: команды

Порядок, который стоит выполнить сразу после установки Debian 12 / Ubuntu 22.04+, до раздачи первых конфигов.

1. Базовое и панель

apt update && apt -y upgrade
apt -y install curl socat ufw jq mtr-tiny
bash <(curl -Ls https://raw.githubusercontent.com/mhsanaei/3x-ui/master/install.sh)

2. Сетевой тюнинг (BBR + буферы)

cat >/etc/sysctl.d/99-xray.conf <<'EOF'
net.core.default_qdisc=fq
net.ipv4.tcp_congestion_control=bbr
net.core.rmem_max=16777216
net.core.wmem_max=16777216
net.ipv4.tcp_rmem=4096 87380 16777216
net.ipv4.tcp_wmem=4096 65536 16777216
net.ipv4.tcp_mtu_probing=1
net.ipv4.tcp_max_syn_backlog=8192
net.ipv4.ip_local_port_range=10240 65000
net.core.somaxconn=8192
fs.file-max=1048576
EOF
sysctl --system
sysctl net.ipv4.tcp_congestion_control # должно быть bbr

Если sysctl --system ругается на несуществующий ключ — уберите строку: часть параметров (например conntrack) появляется только после загрузки соответствующего модуля.

3. Лимит файловых дескрипторов

Самая частая причина «нода работает, но с какого-то момента новые клиенты не подключаются» — упёрлись в nofile. Xray запускается как дочерний процесс панели и наследует её лимит, поэтому правка нужна в юните x-ui:

mkdir -p /etc/systemd/system/x-ui.service.d
cat >/etc/systemd/system/x-ui.service.d/limits.conf <<'EOF'
[Service]
LimitNOFILE=1048576
EOF
systemctl daemon-reload && systemctl restart x-ui
# проверка — бинарь называется xray-linux-amd64, не xray:
grep 'Max open files' /proc/$(pgrep -f 'xray-linux' | head -1)/limits

4. Firewall

Наружу — только SSH и транспортный порт; панель уже на 127.0.0.1.

ufw allow 22/tcp
ufw allow 443/tcp
ufw --force enable
ufw status numbered

5. Бэкап x-ui.db

Этот файл — все ваши клиенты, ключи и лимиты. Он должен уезжать с сервера автоматически: если ноду блокируют, вы переезжаете за 15 минут, а не собираете базу заново.

systemctl stop x-ui
cp /etc/x-ui/x-ui.db /root/x-ui-$(date +%F).db
systemctl start x-ui
scp /root/x-ui-*.db backup@ваш-хост:/backups/ # обязательный шаг: копия вне ноды

В cron знак процента надо экранировать (\%F), иначе задание молча оборвётся на первом %. Самый дешёвый вариант хранения копии вне сервера — встроенная в панель отправка бэкапа в Telegram-бот; настраивается в разделе с ботом и не требует второй машины.

Чек-лист перед оплатой VPS для 3x-ui

Список экономит больше денег, чем экономия двух евро на тарифе.

• [ ] KVM, не OpenVZ; выделенный IPv4, не NAT, не shared.
• [ ] Порт 1 Гбит; лимит трафика посчитан как *активные × 15 ГБ* с запасом ×1,5.
• [ ] Известно, что происходит при превышении лимита: доплата или шейп.
• [ ] mtr и TCP/443 проверены из целевой сети до тестового IP этой локации, не только ping.
• [ ] Single-thread измерен через sysbench, сравнён с соседним тарифом или хостером.
• [ ] Дополнительный IP: есть, стоит ≤3 €/мес, выдаётся из панели без тикета.
• [ ] Проверены ASN и «история» выданного адреса (curl -s https://ipinfo.io/$(curl -s ifconfig.me) | jq '{ip,org,country}').
• [ ] Есть снапшоты — чтобы переезд на новый IP был копией, а не переустановкой.
• [ ] Включён BBR, поднят LimitNOFILE, отключены access-логи xray.
• [ ] Панель на 127.0.0.1, дефолтный пароль сменён, наружу только 22 и транспортный порт.
• [ ] Клиентам раздаётся домен с TTL 60, x-ui.db уезжает с сервера по расписанию.
• [ ] Учтено, что каждая новая нода — это ещё одна независимая панель 3x-ui.
• [ ] Продумано, что делать в день блокировки IP: запасной адрес, вторая нода или фронт на белом домене.

Последний пункт — не паранойя, а плановая работа. Сервер для 3x-ui выбирают один раз, а IP на нём меняют регулярно; закладывайте это в архитектуру и в цену подписки сразу.