Настройка BungeeCord: безопасное соединение серверов Minecraft

BungeeCord объединяет несколько серверов Minecraft Java Edition под одним общим адресом. Прокси аутентифицирует игрока и перенаправляет его в лобби, на выживание или на другие бэкенды. Сам он не хостит мир. Поэтому минимальной сети требуется как минимум два отдельных процесса или хостинговых инстанса: один прокси BungeeCord и один бэкенд Minecraft.

Самое важное правило безопасности: бэкенды работают за BungeeCord в offline-режиме. Поэтому они никогда не должны быть свободно доступны из интернета. ip_forward: true передаёт идентификацию, но не является контролем доступа. Настрой защиту через файрвол или приватную сеть, прежде чем считать сеть готовой.

Как выглядит сеть BungeeCord

Minecraft Java Client
        |
        | публичный адрес прокси
        v
 BungeeCord (online_mode=true, ip_forward=true)
        |
        | только разрешённый путь прокси
        +---------------------+
        v                     v
 Lobby / Paper          Survival / Paper
 online-mode=false      online-mode=false
 bungeecord=true        bungeecord=true

Прокси берёт на себя логин, публичный адрес, маршрутизацию и команды прокси. Бэкенды хранят миры, инвентари и данные плагинов Bukkit/Paper. BungeeCord не синхронизирует эти данные автоматически. Для сетевых рангов, банов или инвентарей нужны соответствующие плагины и, как правило, общая база данных.

Какая топология подходит?

Конфигурация BungeeCord во всех вариантах выглядит похоже, а вот безопасный сетевой путь — нет. Определись с топологией, прежде чем вносить адреса в config.yml.

Прокси и бэкенд на одном узле

Два хостинговых инстанса на одном узле всё равно остаются отдельными контейнерами. Прокси может обращаться к бэкенду через предназначенный для этого внутренний адрес; чужой инстанс на том же мосту (bridge) — не должен. Поэтому открытие доступа для всей подсети Docker было бы слишком широким. Защита должна оставаться привязанной к конкретному источнику прокси и заново определяться после перезапуска контейнера.

Прокси и бэкенд на разных узлах

Здесь путь проходит через сеть узлов. Разреши на бэкенде именно источник соответствующего прокси и конкретный TCP-порт. Не открывай случайно UDP, диапазон портов или весь IP узла для других клиентских инстансов. Проверь положительный путь от прокси и отрицательный путь от независимого источника в том же временном окне.

Внешний бэкенд

Бэкенду за пределами хостинговой платформы нужен маршрут, который сможет достичь прокси BungeeCord. За файрвол внешней системы отвечает её оператор. Обратный туннель или VPN могут обеспечить транспорт, но безопасны только тогда, когда бэкенд остаётся привязанным локально и пропускается исключительно авторизованный путь прокси. Продуктовые тексты могут называть этот вариант безопасным только после проверки положительного и отрицательного пути для конкретной настройки.

Несколько прокси

Несколько прокси для высокой доступности — это отдельная архитектура. Каждый допустимый путь источника, общее хранение плагинов/данных и обработку сессий нужно спланировать явно. Не просто добавляй ещё один IP в широкий allowlist. Это руководство сознательно описывает один выделенный прокси на путь к бэкенду.

Требования и модель стоимости

Тебе понадобится:

• инстанс BungeeCord;
• как минимум один отдельный сервер Paper/Spigot в качестве бэкенда;
• уникальный TCP-порт для каждого процесса;
• доступный путь от прокси к бэкенду;
• файрвол, приватная сеть или аналогично проверенный контроль доступа;
• протестированный бэкап перед переустройством существующего сервера.

На game-serverhosting BungeeCord — это отдельное серверное ПО. Планируй прокси и бэкенды как отдельные инстансы. Если у тебя ещё нет инстансов, начни с заказа Minecraft-сервера. Актуальная кодовая база BungeeCord компилируется под Java 17; предлагаемый Egg работает на Java 21. Не полагайся на старые общие утверждения вроде «512 МБ на 500 игроков»: плагины, скорость подключений, сжатие и атаки существенно меняют потребности.

Шаг 1: зафиксируй архитектуру и порты

Дай каждому инстансу имя и роль. Простой пример:

127.0.0.1 работает только тогда, когда прокси и бэкенд используют один и тот же сетевой namespace. Два контейнера Pterodactyl на одном хосте не соединены через loopback автоматически. Используй именно тот адрес бэкенда, до которого может достучаться твой прокси, и никогда не открывай заранее целую подсеть контейнеров.

Шаг 2: сделай бэкап существующих серверов

Перед изменением online-режима или форвардинга сделай бэкап миров, playerdata, баз данных плагинов и файлов конфигурации. Выполни как минимум одно тестовое восстановление. При переходе с offline- на online-UUID игроки могут выглядеть как новые аккаунты, хотя их старые файлы всё ещё существуют. Руководство по безопасной смене версии объясняет путь бэкапа, копирования и отката, который стоит использовать и для этой миграции.

Шаг 3: запусти прокси и отредактируй config.yml

Запусти BungeeCord один раз и затем корректно останови прокси. Так появится config.yml, соответствующая установленной версии. Полное описание полей ты найдёшь в статье BungeeCord config.yml — объяснение.

Минимальная сокращённая модель выглядит так:

online_mode: true
ip_forward: true
player_limit: -1

servers:
  lobby:
    address: <LOBBY-ADRESSE>:<LOBBY-PORT>
    motd: '&aLobby'
    restricted: false
  survival:
    address: <SURVIVAL-ADRESSE>:<SURVIVAL-PORT>
    motd: '&aSurvival'
    restricted: false

listeners:
  - host: 0.0.0.0:<PROXY-PORT>
    priorities:
      - lobby
      - survival
    force_default_server: true
    max_players: 100

max_players влияет на отображаемое количество слотов. Глобальный жёсткий лимит задаётся через player_limit; значения ноль или меньше означают там неограниченное количество. Имена бэкендов под priorities должны точно совпадать с ключами под servers.

Шаг 4: настрой бэкенды для форвардинга

На каждом бэкенде Paper/Spigot:

# server.properties
online-mode=false

# spigot.yml
settings:
  bungeecord: true

В актуальном Paper дополнительно проверь config/paper-global.yml:

proxies:
  bungee-cord:
    online-mode: true

Это значение Paper описывает online-режим прокси и должно ему соответствовать. Оно не противоречит online-mode=false в server.properties. Все четыре значения и последствия для UUID/бэкапов подробно объясняются в статье Безопасная настройка BungeeCord IP Forwarding.

Шаг 5: защити доступ к бэкенду

Теперь наступает шаг, которого не хватает во многих старых туториалах. Разреши доступ к TCP-порту бэкенда исключительно от соответствующего прокси или привяжи его к действительно общей приватной сети. Обычный внутренний IP, restricted: true или bungeecord: true не являются доказательством безопасности.

На game-serverhosting допустимый путь прокси для поддерживаемых топологий BungeeCord выводится активным Backend-Guard из конкретного инстанса прокси. Если источник отсутствует или останавливается, путь остаётся исключительно drop-режимом. Для внешне работающего бэкенда тебе нужно самостоятельно настроить его файрвол так, чтобы разрешён был только проверенный путь прокси.

BungeeGuard может обеспечить дополнительную защиту токеном на shared-хостинге. Используй версию не ниже 1.4.0; затронутые более старые установки должны быть обновлены с ротацией токена. Токен никогда не должен попадать в тикеты, скриншоты или логи. BungeeGuard дополняет сетевую защиту, но не делает доступную поверхность атаки автоматически невидимой.

Шаг 6: порядок запуска и реальные тесты

Сначала запусти бэкенды, а затем прокси. Проверь больше, чем просто открытый порт:

1. Процесс прокси запущен и слушает на назначенной аллокации.
2. Прокси достигает адреса лобби по TCP.
3. Minecraft-пинг через публичный адрес прокси работает.
4. Реальный тестовый аккаунт попадает в лобби и может переключить сервер.
5. IP и online-UUID корректно приходят на бэкенд.
6. Независимый прямой доступ к порту бэкенда терпит неудачу.

Именно пункт 6 превращает работающий путь форвардинга в защищённый результат. Если вход не удаётся, пройди дерево диагностики для «Could not connect to a default or fallback server», не открывая при этом файрвол огульно.

Планирование маршрутизации, fallback и обслуживания

priorities — это не просто список для первого подключения. Он также определяет, какие цели BungeeCord пробует по очереди, если сервер выходит из строя. Поставь на первое место небольшой, надёжно совместимый бэкенд. Survival-сервер с тяжёлым модпаком редко бывает лучшим техническим fallback.

forced_hosts может направлять разные домены на разные стартовые цели. Пример: creative.example.net запускается на creative, а play.example.net начинается в лобби. Оба DNS-имени указывают на один и тот же прокси. Тестируй каждое имя хоста отдельно, потому что работающий default ничего не говорит об опечатке в маппинге forced-host.

restricted: true полезен для серверов обслуживания или команды. Соответствующее право bungeecord.server.<name> должно проверяться на уровне прокси. Оно предотвращает переключение обычного игрока через BungeeCord, но не защищает от прямого TCP-доступа к бэкенду.

Для обслуживания рекомендуется такой порядок действий:

1. Убери целевой сервер из публично используемого приоритета или заблокируй его через право доступа.
2. Контролируемо перемести подключённых игроков на исправный бэкенд.
3. Сделай бэкап бэкенда и проведи обслуживание.
4. Проверь TCP-соединение прокси-бэкенд и реальный тестовый вход.
5. Только после этого снова открой маршрутизацию.

Перезапуск прокси отключает всех подключённых через него игроков. Миры на бэкендах продолжают работать, но перезапуск всё равно является заметным прерыванием и должен проводиться в окне обслуживания.

Проверка безопасности перед вводом в эксплуатацию

Пройди эту границу один раз с точки зрения атакующего:

• Задокументирован ли только прокси как публичный адрес Minecraft?
• Заблокирован ли каждый порт бэкенда с независимой рабочей станции?
• Может ли другой инстанс на том же shared-узле/мосту достичь порта?
• Переоценивается ли актуальный источник прокси после stop/start?
• Остаётся ли остановленный или неоднозначно разрешаемый прокси в состоянии fail-closed?
• Удалены ли токены, полные IP-адреса и key.pem из скриншотов и логов поддержки?
• Есть ли права вроде /ip, /send, /alert и /end только у небольшого круга лиц?
• Все ли зарегистрированные бэкенды заслуживают доверия? Бэкенды могут влиять на сеть через Plugin Messaging.

Если ты не можешь ответить на вопрос тестом или конкретным правилом, состояние — unverified, а не «вероятно безопасно». Это особенно важно на shared-хостинге: адрес, выглядящий внутренним, ещё не доказывает разделение арендаторов.

Бэкапы, обновления и мониторинг

У BungeeCord нет мира, но его состояние всё равно важно для восстановления. Перед обновлениями сделай бэкап:

• config.yml и modules.yml;
• каталога plugins/ прокси вместе с конфигурациями;
• локальных или внешних баз данных плагинов в согласованном виде;
• используемой сборки BungeeCord и версии Java;
• отредактированной документации по именам бэкендов, портам и правилам защиты.

Миры, playerdata и данные плагинов Bukkit/Paper бэкапятся отдельно на бэкендах. Бэкап прокси не заменяет бэкап мира. После восстановления проверяй не только наличие файлов, но и то, что вход в лобби, UUID, права доступа и переключение сервера снова работают корректно.

Для обновления корректно останови прокси, замени только JAR-файл либо воспользуйся предусмотренным инсталлятором и сначала проверь лог запуска. Затем следуют Minecraft-пинг, реальный вход, идентификация, fallback и по-прежнему заблокированный прямой путь. Держи наготове последний рабочий JAR вместе с подходящей конфигурацией для отката.

Дополнительно отслеживай Heap/GC, блокировки event loop, исключения плагинов, таймауты бэкенда и необычную частоту подключений. Зелёное поле в дашборде не должно сводить несколько этих состояний к общему «онлайн».

Избегай типичных ошибок настройки

• Перепутаны порт прокси и порт бэкенда: игроки попадают напрямую на бэкенд в offline-режиме, либо BungeeCord подключается сам к себе.
• Публичный домен в качестве адреса бэкенда: прокси попадает в DNS-/маршрутную петлю. Используй конкретный внутренний целевой адрес.
• max_players воспринимается как жёсткий лимит: список серверов показывает это значение, хотя player_limit при этом всё ещё может быть неограниченным.
• Проведён только один TCP-тест: листенер открыт, но лобби, форвардинг или протокол не работают.
• Файрвол отключён для отладки: положительный вход проходит, но при этом одновременно остаётся открытым обход идентификации.
• На прокси установлен Bukkit-плагин: платформа или зависимости не подходят; читай дескриптор и страницу проекта.
• /greload после серьёзных изменений: часть конфигурации или плагинов остаётся в старом состоянии. Используй полный перезапуск.
• Бэкап без теста восстановления: только в случае сбоя выясняется, что база данных, миры или состояние плагинов были сохранены не согласованно.

Направь домен и SRV на прокси

DNS всегда указывает на публичный прокси. При нестандартном порте Java запись SRV _minecraft._tcp может отображать порт. Целью (target) SRV должно быть имя хоста, а не IP. Точные шаги для A/CNAME/SRV описаны в руководстве Подключение собственного домена к игровому серверу.

Forced Hosts ничего в этом не меняют: они используют запрошенное клиентом имя хоста только как информацию для маршрутизации. survival.example.net тоже сначала указывает на прокси; только BungeeCord перенаправляет внутри на survival.

Правильно распредели плагины и права доступа

• Плагины BungeeCord должны находиться в plugins/ прокси.
• Плагины Bukkit/Paper должны находиться на соответствующем бэкенде.
• Некоторым сетевым плагинам нужны компоненты на обоих уровнях.
• Права прокси не появляются автоматически в чисто бэкендовом плагине прав доступа.
• После изменения плагинов полный запланированный перезапуск надёжнее, чем /greload.

Используй только плагины из надёжных источников и проверяй платформу, версию, зависимости и указания по безопасности. Руководство по плагинам показывает путь в панели для плагинов Paper/Spigot; плагины для прокси ты должен явно опознавать как совместимые с BungeeCord.

Кроссплей с Bedrock через Geyser

В сети BungeeCord ты устанавливаешь Geyser на прокси, а не на каждом бэкенде. Java использует TCP, листенер Bedrock — UDP. Floodgate достаточно установить на прокси, если плагины бэкенда не нуждаются ни в его API, ни в дополнительной поддержке скинов. key.pem — это секрет аутентификации.

Проверка портов и входа остаётся раздельной для TCP и UDP. Используй руководство по кроссплею Geyser/Floodgate после того, как чисто Java-путь надёжно заработает.

BungeeCord или Velocity?

В 2026 году BungeeCord по-прежнему активно разрабатывается. Waterfall, бывший форк PaperMC, напротив, достиг end of life. PaperMC рекомендует Velocity для новых сетей и сам отмечает, что собственное сравнение может быть предвзятым в пользу собственного продукта.

Для уже существующей сети с важными плагинами BungeeCord BungeeCord может быть менее рискованным выбором. Для новой сети на актуальных версиях Paper Velocity предлагает Modern Forwarding с защищённым секретом и MAC-форматом. Принимай решение не на основе общих цифр производительности, а исходя из версий, plugin API, форвардинга и миграции. В статье BungeeCord vs Velocity 2026 есть матрица принятия решения.

FAQ

Является ли BungeeCord сервером Minecraft?

Нет. BungeeCord — это прокси. Миры, чанки, мобы и игровые режимы работают на отдельных бэкендах.

Сколько серверов мне нужно?

Минимум два процесса или инстанса: прокси и один бэкенд. Для лобби плюс игрового режима разумны три инстанса.

Должен ли прокси работать в online-режиме?

Для обычной аутентифицированной сети — да: online_mode: true на прокси. Бэкенды используют online-mode=false, потому что прокси уже выполнил аутентификацию.

Безопасен ли ip_forward?

Он нужен для реальных IP и online-UUID, но сам по себе не безопасен. Legacy-форвардинг не имеет специфичного для прокси секрета подписи. Порт бэкенда должен быть защищён от недоверенных источников.

Перезапускает ли перезапуск прокси мои миры?

Нет. Бэкенды продолжают работать, но игроки, подключённые через прокси, будут отключены.

Нужно ли мне лобби?

Не обязательно. Нужна как минимум одна доступная цель в priorities; отдельное лобби обычно делает fallback и обслуживание более наглядными.

Какие порты нужны BungeeCord?

Публичный листенер Java использует TCP. Каждому бэкенду нужен собственный TCP-порт, доступный только для прокси. Query и Geyser/Bedrock при активации используют отдельные UDP-порты; не открывай их, если функция не используется.

Могу ли я установить плагины Paper на BungeeCord?

Нет, не в общем случае. Плагины Paper/Bukkit должны находиться на бэкендах. Прокси нужны плагины, специально созданные для BungeeCord. Сетевые плагины могут поставлять два отдельных компонента.

Почему мой бэкенд видит только IP прокси?

Обычно ip_forward на прокси или settings.bungeecord на бэкенде отключены. Проверь обе стороны и выполни полный перезапуск. Меняй значения, влияющие на UUID, только после бэкапа.

Могу ли я использовать несколько доменов?

Да. Все домены указывают на прокси. forced_hosts может затем сопоставить запрошенное имя хоста со стартовым бэкендом.

Работает ли кроссплей автоматически на каждом бэкенде?

Geyser преобразует Bedrock на прокси. Бэкенды должны принимать версию протокола Java, эмулируемую Geyser; при расхождении версий может понадобиться осознанно проверенная настройка ViaVersion. Доступность UDP тестируется отдельно от Java-TCP.

Финальная проверка

Сеть готова только тогда, когда реальный вход через прокси проходит успешно и независимый прямой вход на бэкенд в offline-режиме заблокирован. Документируй адреса и правила в отредактированном виде, сохраняй конфигурацию и данные мира отдельно и назначь следующий профессиональный review до указанного срока, если BungeeCord, Java, BungeeGuard, Paper, Velocity или Geyser выпустят значимый релиз.

Для будущих случаев поддержки сохраняй также время и часовой пояс теста, версии прокси/бэкенда и первое конкретное сообщение об ошибке. При этом маскируй IP-адреса игроков и полностью удаляй секреты. Так позже можно будет проследить разницу между ошибками процесса, сети, протокола, идентификации и плагинов, не перенося чувствительные клиентские данные в постоянную базу знаний.

Первоисточники

• BungeeCord: установка
• BungeeCord: руководство по конфигурации
• BungeeCord: IP Forwarding
• BungeeCord: репозиторий и предупреждение о безопасности
• Paper: глобальная конфигурация
• BungeeGuard: безопасность