Velocity SMP-сеть: лобби, survival, creative и minigames на одном прокси

Когда сервер вырастает из одного мира, появляется идея сделать сеть: лобби с порталами, основной survival, креатив для строителей и блок мини-игр. Velocity сшивает это в один точечный адрес play.example.net:25565. Ниже разбор, как поднять такую сеть с нуля, что прописать в velocity.toml, как синхронизировать права и чат, и какие ошибки на бэкендах открывают сервер для подделки UUID.

Зачем вообще прокси и почему именно Velocity

Прокси нужен, когда серверов больше одного и игроки должны переключаться между ними без пересоединения по новому IP. BungeeCord и Waterfall с этим справляются, но они оба написаны под старую модель Netty и нагружены легаси-кодом. Velocity от PaperMC переписали с нуля на Java 21, с асинхронной обработкой пакетов и нормальной системой плагинов. На практике один Velocity спокойно тянет 1000+ конкурентных подключений на 1 GB RAM и не упирается в GC так, как Bungee на тех же цифрах.

Главные практические плюсы:

• modern forwarding - современный протокол передачи UUID и IP игрока на бэкенд, защищённый секретом
• запрет прямых подключений - бэкенды отвергают соединения, которые не пришли от прокси
• Java 21 нативно, без костылей с --enable-preview
• актуальная поддержка новых версий Minecraft без ожидания патчей от мейнтейнеров Bungee

Если вы стоите перед выбором "Velocity или BungeeCord" в 2026 - выбор очевиден. Bungee остаётся только в нишевых случаях, где плагины ещё не портировали под Velocity API.

Архитектура сети

Базовая раскладка для типичной SMP-сети выглядит так:

                  ┌──────────────┐
   Игроки ───────▶│ Velocity     │ :25565 (publlic)
                  │ proxy        │
                  └──────┬───────┘
                         │ modern forwarding
        ┌────────────────┼────────────────┐
        ▼                ▼                ▼
   ┌─────────┐    ┌──────────┐    ┌──────────┐
   │ lobby   │    │ survival │    │ creative │   ┌──────────┐
   │ :25566  │    │ :25567   │    │ :25568   │   │minigames │
   └─────────┘    └──────────┘    └──────────┘   │ :25569   │
                                                  └──────────┘

Все бэкенды слушают только локальный интерфейс или закрыты файрволом от внешнего мира. Игрок видит только play.example.net:25565, а внутреннюю топологию сети ему знать не надо и не положено.

По ресурсам: Velocity сам по себе занимает 512 MB - 1 GB RAM, остальное расходуют бэкенды. Lobby обычно достаточно 2 GB, survival и creative от 4 GB и выше в зависимости от онлайна, minigames блок - 2-4 GB.

Установка Velocity

Скачиваем последний билд Velocity 3.x с paper.io. Создаём отдельного пользователя, отдельный каталог, кладём jar:

sudo useradd -m -s /bin/bash velocity
sudo -u velocity mkdir /home/velocity/proxy
cd /home/velocity/proxy
sudo -u velocity wget https://api.papermc.io/v2/projects/velocity/versions/3.4.0/builds/.../downloads/velocity-3.4.0.jar

systemd-юнит для автозапуска:

[Unit]
Description=Velocity Proxy
After=network.target

[Service]
Type=simple
User=velocity
WorkingDirectory=/home/velocity/proxy
ExecStart=/usr/bin/java -Xms1G -Xmx1G -XX:+UseG1GC -XX:+ParallelRefProcEnabled \
  -XX:MaxGCPauseMillis=200 -jar velocity-3.4.0.jar
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

Первый запуск создаст velocity.toml, forwarding.secret и каталог plugins/. Главный файл, который мы будем редактировать, - velocity.toml.

Настройка velocity.toml

Минимальный рабочий конфиг для нашей сети:

config-version = "2.7"
bind = "0.0.0.0:25565"
motd = "<bold><green>Example Network</green></bold>\n<gray>SMP - Creative - Minigames</gray>"
show-max-players = 500
online-mode = true
force-key-authentication = true
prevent-client-proxy-connections = true
player-info-forwarding-mode = "modern"
forwarding-secret-file = "forwarding.secret"
announce-forge = false

[servers]
lobby = "127.0.0.1:25566"
survival = "127.0.0.1:25567"
creative = "127.0.0.1:25568"
minigames = "127.0.0.1:25569"
try = ["lobby", "survival"]

[forced-hosts]
"smp.example.net" = ["survival"]
"build.example.net" = ["creative"]
"play.example.net" = ["lobby"]

[advanced]
compression-threshold = 256
compression-level = -1
login-ratelimit = 3000
connection-timeout = 5000
read-timeout = 30000
haproxy-protocol = false
tcp-fast-open = false

Что важно:

• online-mode = true на прокси - проверка лицензии происходит здесь и только здесь
• player-info-forwarding-mode = "modern" - передача UUID/IP с подписью секретом
• try = ["lobby", "survival"] - если lobby упал, игроков кидает в survival вместо отбоя
• forced-hosts - удобный трюк, если у вас разные субдомены на одном порту 25565

Файл forwarding.secret создаётся автоматически. Его содержимое скопируем в каждый бэкенд.

Подготовка бэкендов: Paper config

Каждый Paper-сервер за прокси настраивается одинаково по идеологии. Возьмём survival для примера. Открываем paper-global.yml:

proxies:
  bungee-cord:
    online-mode: false
  proxy-protocol: false
  velocity:
    enabled: true
    online-mode: true
    secret: 'СЮДА_СОДЕРЖИМОЕ_FORWARDING_SECRET'

Затем server.properties:

server-port=25567
online-mode=false
prevent-proxy-connections=false
server-ip=127.0.0.1
network-compression-threshold=-1

Ключевые моменты:

1. online-mode=false в server.properties - обязательно. Иначе Paper попытается сам валидировать сессию и сломает modern forwarding.
2. online-mode: true в paper-global.yml в секции velocity - вот где включается реальная проверка по UUID, который Velocity передал.
3. server-ip=127.0.0.1 - сервер слушает только loopback. Никто извне не сможет подключиться напрямую, даже если найдёт порт.

Повторяем то же самое для lobby (порт 25566), creative (25568), minigames (25569). Каждый со своим forwarding.secret копированным от прокси, каждый с уникальным портом.

Безопасность: главная ловушка online-mode

Самая частая дыра в self-hosted сетях - оставить online-mode=true на бэкенде вместе с modern forwarding. Логика тут какая: если бэкенд работает в online-режиме, он сам пробует валидировать сессию через Mojang. А Velocity уже это сделал. В итоге Paper отвечает "не могу проверить", и админ от безысходности открывает порт наружу или ставит prevent-proxy-connections=false без понимания.

Правило железное:

• На прокси online-mode = true
• На бэкенде в server.properties всегда online-mode=false
• На бэкенде в paper-global.yml velocity.online-mode: true плюс правильный секрет

Если оставить бэкенд в online-режиме без прокси-валидации, любой клиент с подделанным UUID может зайти под чужим ником, потому что Mojang не проверял сессию через ваш сервер. Это грубая ошибка, на которой построено большинство инцидентов с украденными игроками-операторами.

Дополнительно закрываем бэкенды файрволом. Если все на одной машине - 127.0.0.1 уже всё решает. Если бэкенды на других VPS, то iptables или ufw пускает к их портам только IP прокси:

sudo ufw default deny incoming
sudo ufw allow from <PROXY_IP> to any port 25567 proto tcp
sudo ufw allow ssh
sudo ufw enable

Синхронизация между серверами

Самостоятельная сеть состоит не только из роутинга соединений. Игрокам нужны общие права, общий чат, иногда общий баланс. Без синхронизации каждый бэкенд - изолированный мир со своими ranks и логами.

Общие права через LuckPerms

LuckPerms ставится на каждый бэкенд и на сам Velocity (отдельный jar для прокси). Хранилище переключаем с file на MySQL/MariaDB:

storage-method: mysql
data:
  address: 127.0.0.1:3306
  database: luckperms
  username: lp_user
  password: 'strong-password'
messaging-service: sql

Когда LuckPerms на всех серверах смотрит в одну БД и подписан на messaging-канал, любое изменение группы или прав мгновенно применяется на всех бэкендах. Даю игроку [VIP] через /lp user Steve parent set vip - он становится VIP и в lobby, и в survival, и в creative.

Общий баланс и экономика

Тут варианта три, и каждый имеет нюансы:

• CMI или EssentialsX с MySQL backend - простейший путь для большинства SMP-сетей. Баланс пишется в общую БД, на любом сервере /balance показывает одинаковую сумму.
• Vault мост через прокси - сложнее, требует вспомогательных плагинов вроде RedisEconomy. Подходит для сетей с большим онлайном, где MySQL не справляется.
• Изолированные экономики на каждом сервере - валидный выбор, если креатив намеренно отделён от survival по бизнес-логике.

В большинстве случаев берётся EssentialsX с настроенным economy-storage: mysql в соответствующем плагине-мосте, и этого хватает.

Кросс-серверный чат

Чтобы сообщение из survival видели в lobby, нужен плагин-агрегатор. Рабочие варианты:

• VentureChat с Velocity-частью - богатая система каналов, поддержка глобального и локального чата
• CarbonChat - современная альтернатива с тонкой настройкой каналов
• GlobalTabList - только список игроков в Tab, без чата как такового

Для нашей сети ставим VentureChat на прокси и на каждый бэкенд, настраиваем канал global который синхронизируется между всеми, и local который виден только на своём сервере. Это даёт привычное поведение: общий чат для общения, локальный для непосредственно происходящего на сервере.

Переключение между серверами для игрока

Velocity по умолчанию даёт команду /server <name>, которая работает у любого с правом velocity.command.server. Для красивого UX добавляем порталы и NPC.

В лобби обычно ставят несколько NPC от Citizens или FancyNpcs, каждому привязывают команду velocity send self <server> через VelocityPortals или PortalsPlus. Игрок подходит к NPC выбора режима, кликает - и его перебрасывает на нужный бэкенд.

Альтернатива - физические порталы из обсидиана с привязкой к команде. Multiverse-Portals на лобби умеет триггерить кросс-серверные команды, если ему скормить плагин-мост.

Минимальный сценарий без порталов: игрок просто пишет /server survival, и его кидает. Дёшево и работает.

Whitelist и анти-публичность

Если сеть приватная, whitelist надо ставить в двух местах:

1. На Velocity через плагин VelocityWhitelist или NetworkManager. Это первый барьер.
2. На каждом бэкенде - /whitelist add <ник> в server.properties или через плагин синхронизатор whitelist через MySQL.

Дублирование звучит избыточно, но защищает от ситуации, когда прокси перезапустился без whitelist-плагина, а бэкенды доступны напрямую с другой машины из доверенной сети.

Производительность и хостинг

Распределение по железу зависит от онлайна:

• до 50 игроков: один dedicated сервер с 16 GB RAM. Velocity, lobby, survival, creative, minigames - все на одной машине, разделены по портам.
• 50-200 игроков: VPS под прокси (4 GB) плюс отдельные VPS под survival (8 GB) и комбинированный (lobby + creative + minigames на 8 GB).
• 200+ игроков: каждый бэкенд на своей машине, прокси в отдельном дата-центре с хорошей сетью, между ними приватная сеть от провайдера.

Velocity сам по себе CPU-light, ему важны сеть и низкие задержки. Если прокси и бэкенды на разных хостах, разница в 2-3 ms на каждый хоп ощущается игроками как лишний лаг. По возможности держите их в одной зоне доступности.

Для DDoS-защиты прокси можно поставить за фильтр трафика вроде MineGuard. Атаки летят на публичный IP прокси, бэкенды по приватной сети остаются в тишине. Подробнее: защита Velocity-сети от DDoS.

FAQ

Velocity vs BungeeCord vs Waterfall - что выбрать?

В 2026 - однозначно Velocity. BungeeCord устарел архитектурно, Waterfall (форк Bungee от PaperMC) был промежуточным решением и сейчас в режиме поддержки. Velocity активно развивается, имеет современный API и нативно работает с новыми версиями Minecraft без задержек на адаптацию.

Можно ли запустить Velocity и сервер на одной машине?

Можно и часто это лучший вариант для небольших сетей. Velocity слушает 25565 на публичном IP, бэкенды на 127.0.0.1 с разными портами. Никто извне их не видит, latency между прокси и бэкендом измеряется микросекундами. Главное - выделить достаточно RAM с запасом на пиковый онлайн.

Как защитить бэкенд от прямого подключения?

Три уровня. Первый: бэкенды слушают только loopback (server-ip=127.0.0.1), если они на одной машине с прокси. Второй: файрвол пускает к их портам только IP прокси. Третий: правильно настроенный modern forwarding в paper-global.yml с уникальным секретом, который Paper проверяет при каждом подключении.

Как сделать общий чат между серверами?

Поставить VentureChat или CarbonChat на прокси и все бэкенды, настроить shared канал. Сообщения из чата на survival будут видны в lobby и наоборот. Локальный чат при этом остаётся, чтобы внутри одного сервера общение не смешивалось с глобалкой.

Что делать если игрока кикает с "If you wish to use IP forwarding, please enable it in your BungeeCord config"?

Эту ошибку выдаёт бэкенд, который не понимает, что прокси отправляет данные. Проверьте paper-global.yml: должно быть velocity.enabled: true, правильный секрет, и server.properties обязательно с online-mode=false. Перезапустите бэкенд после правок.

Нужен ли отдельный VPS под прокси?

Не обязательно. Для сетей до 50 онлайн нормально держать всё на одной машине. Для крупных сетей отдельный прокси-сервер удобен, потому что его проще защитить от DDoS и держать в зоне с хорошим сетевым стеком, не таская туда же тяжёлые игровые серверы.

Velocity тянет модовые сборки Forge или Fabric?

Да, через announce-forge и плагины-мосты. Forge-серверы за Velocity работают, но требуют чуть более тонкой настройки и совместимых версий клиента. Для смешанных сетей (vanilla + modded) проще держать модовые серверы в отдельной "ветке" сети с переключением через /server.

Что дальше

Когда сеть запущена, добавляйте по одному. Сначала убедитесь что lobby + survival связаны и переключение работает. Потом подключайте creative и minigames. LuckPerms, чат и экономику настраивайте после базового роутинга, иначе утонете в дебаге того, что отвалилось.

Заведите бэкап velocity.toml, forwarding.secret и paper-global.yml всех бэкендов в одном месте - при миграции на новое железо это сэкономит часы. И не забудьте про мониторинг: tps на каждом бэкенде плюс пинг между прокси и серверами должны быть видны на одном дашборде.