Как настроить BungeeCord и Velocity: сеть серверов Minecraft

BungeeCord настройка нужна, когда вы хотите слить несколько серверов Minecraft в одну сеть — лобби, выживание, мини-игры — под общим IP и с переходами между мирами без переподключения. Сегодня для новых проектов вместо BungeeCord берут Velocity: он быстрее и безопаснее. В этом гайде разберём оба прокси, конфиги и пошагово поднимем сеть.

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

Один сервер Minecraft — это один мир и один тип игры. Как только хочется лобби с порталами в режимы, отдельный сервер под выживание и набор мини-игр, начинаются проблемы: у каждого свой IP, игрок при переходе вылетает и заходит заново, инвентари и сессии не связаны.

Прокси решает это. Он становится единой точкой входа: игрок коннектится к одному адресу, а прокси молча держит соединение и перебрасывает его между бэкенд-серверами командой /server или через порталы. Со стороны игрока это выглядит как мгновенный телепорт между мирами одной сети — без релога, без повторного ввода IP.

• Лобби — хаб, куда попадают все при входе.
• Выживание / анархия — отдельный тяжёлый мир со своей экономикой.
• Мини-игры — BedWars, SkyWars и прочее, часто по серверу на режим.
• Единый вход — один IP, общий бан-лист и базовая защита на уровне прокси.

Важно понимать: прокси не объединяет мощность серверов и не делает «один большой сервер». Каждый бэкенд по-прежнему отдельная JVM со своим TPS. Прокси лишь маршрутизирует игроков. Поэтому если вам нужен просто большой survival на 40 человек, сеть не нужна — хватит одного сервера; о выборе ядра под него читайте в разборе Paper vs Purpur vs Vanilla.

BungeeCord (Waterfall) или Velocity

BungeeCord — исторический стандарт, проверенный годами. Waterfall — его форк от PaperMC с оптимизациями, но в 2023 году команда Paper объявила Waterfall в режиме поддержки и сместила фокус на Velocity. Velocity написан с нуля: он легче по ресурсам, лучше держит крупные сети и предлагает современный механизм передачи данных игрока.

Установка и базовый конфиг

Оба прокси — это обычный JAR, который запускается отдельной JVM. Скачайте свежий билд (Velocity — с сайта PaperMC, BungeeCord — с SpigotMC), положите в отдельную папку и запустите один раз — сгенерируется конфиг.

velocity.toml

Главный файл Velocity. Ключевые секции:

bind = "0.0.0.0:25565"
motd = "&3Моя сеть"
player-info-forwarding-mode = "modern"
forwarding-secret-file = "forwarding.secret"

[servers]
lobby = "127.0.0.1:30066"
survival = "127.0.0.1:30067"
try = ["lobby"]

[forced-hosts]
"play.example.com" = ["lobby"]

Здесь bind — адрес и порт, который слушает прокси (его и открывают наружу). В [servers] перечислены бэкенды по внутренним адресам. try — список серверов, куда кидать игрока при входе (первое лобби, в которое удалось зайти). forced-hosts позволяет привязать домен к конкретному серверу.

config.yml (BungeeCord)

У BungeeCord та же логика, но в YAML и с одним важным отличием — ip_forward:

ip_forward: true
listeners:
- host: 0.0.0.0:25565
  priority:
  - lobby
servers:
  lobby:
    address: 127.0.0.1:30066
    restricted: false
  survival:
    address: 127.0.0.1:30067

Параметр ip_forward: true включает передачу реального IP и UUID игрока на бэкенд — без него у всех будет один адрес и сломается авторизация. Это и есть «forwarding» в терминах Bungee.

Связка с бэкендами — где все ошибаются

Самая частая ошибка новичков. Бэкенд-серверы (лобби, выживание) не должны сами проверять лицензию — это делает прокси. Поэтому на каждом бэкенде в server.properties ставим:

online-mode=false

Если оставить online-mode=true, бэкенд попытается заново авторизовать игрока в Microsoft и выкинет его с ошибкой Bad login. Но просто выключить online-mode мало — нужно «склеить» прокси и бэкенд через форвардинг.

Velocity + Paper (modern forwarding)

Это правильный, безопасный способ. На бэкенде должно стоять ядро Paper или Purpur. Открываем config/paper-global.yml и в секции прокси:

proxies:
  velocity:
    enabled: true
    online-mode: true
    secret: "вставьте_сюда_содержимое_forwarding.secret"

Значение secret — это содержимое файла forwarding.secret, который Velocity создал у себя в папке. Параметр online-mode в paper-global.yml должен совпадать с online-mode прокси (в velocity.toml): если прокси проверяет лицензию — ставим true, для пиратского/оффлайн-режима — false. Именно этот секрет не даёт подделать вход.

BungeeCord + Paper

У BungeeCord форвардинг проще и менее защищён. На бэкенде в config/paper-global.yml включаем proxies.bungee-cord.online-mode по вкусу, а в spigot.yml ставим:

settings:
  bungeecord: true

Никакого секрета здесь нет — бэкенд верит любым данным, пришедшим «как от Bungee». Отсюда вытекает главное требование безопасности.

Пошагово: поднимаем сеть на Velocity

Соберём минимальную сеть «лобби + выживание». Те же шаги дублируются в FAQ-блоке ниже.

1. Создать прокси-сервер. Поднимите отдельный сервер под Velocity и скачайте свежий билд с PaperMC. Запустите один раз — сгенерируются velocity.toml и forwarding.secret.
2. Настроить velocity.toml. Задайте bind = "0.0.0.0:25565", player-info-forwarding-mode = "modern" и в [servers] пропишите бэкенды (lobby, survival) по внутренним IP и портам плюс try = ["lobby"].
3. Подготовить бэкенды. На каждом поставьте Paper или Purpur, в server.properties выставьте online-mode=false. Сервер должен слушать внутренний адрес, а не публичный интернет.
4. Прокинуть forwarding secret. В config/paper-global.yml каждого бэкенда включите proxies.velocity.enabled: true, вставьте в secret содержимое forwarding.secret, а online-mode выставьте как у прокси.
5. Закрыть бэкенды файрволом. Наружу открыт только порт прокси (25565). Порты бэкендов закройте, чтобы к ним нельзя было подключиться напрямую.
6. Запустить и проверить. Стартуйте сначала бэкенды, потом прокси. Зайдите по адресу прокси — вас кинет в лобби. Командой /server survival проверьте переход без релога.

Как это устроено на хостинге

На VPS вы поднимаете всё руками; на игровом хостинге Elysium схема проще — каждый элемент сети это отдельный сервер в панели Pterodactyl, который ставится в один клик. Создаёте сервер под Velocity, по серверу под каждый бэкенд, и связываете их по внутренней сети одной локации (Москва, Франкфурт, Амстердам или Хельсинки — по пингу). Наружу торчит только прокси, бэкенды защищены изолированно.

Главное для прокси-сети — низкий пинг между узлами и сильное одно ядро: Minecraft почти не параллелится, и TPS бэкенда упирается в частоту ядра. На Ryzen 9 с бустом 5.0+ ГГц и NVMe Gen4 (чтение ~7 ГБ/с) переходы и подгрузка чанков не просаживают тик. Для сети из 2-3 бэкендов обычно берут тарифы уровня Nexus (8 ГБ) или Apex (12 ГБ) — но сколько именно RAM закладывать на каждый узел, прикиньте заранее.

Если вы только начинаете и сеть пока избыточна — сначала запустите один сервер по нашему большому гайду по созданию сервера Minecraft, а прокси добавите, когда проект дорастёт до нескольких режимов.