BungeeCord config.yml объяснена: безопасные настройки

Файл config.yml определяет, где BungeeCord слушает соединения, какие бэкенды ему известны и куда направляются новые игроки. Всегда создавай этот файл со своей установленной версией. Старые примеры из блогов могут содержать поля или значения по умолчанию, которые уже не подходят к текущей сборке.

Синтаксически корректная конфигурация ещё не значит безопасная сеть. Как только бэкенды используют online-mode=false, их TCP-порт должен быть защищён от прямых подключений. Полный процесс описан в основном руководстве по настройке BungeeCord.

Безопасная базовая структура

online_mode: true
ip_forward: true
player_limit: -1
server_connect_timeout: 5000
remote_ping_timeout: 5000

servers:
  lobby:
    address: <LOBBY-ADRESSE>:<PORT>
    motd: '&aЛобби'
    restricted: false
  survival:
    address: <SURVIVAL-ADRESSE>:<PORT>
    motd: '&aВыживание'
    restricted: false

listeners:
  - host: 0.0.0.0:<PROXY-PORT>
    motd: '&aМоя сеть'
    priorities:
      - lobby
      - survival
    force_default_server: true
    forced_hosts:
      survival.example.net: survival
    max_players: 100
    tab_list: GLOBAL_PING
    query_enabled: false
    proxy_protocol: false

Плейсхолдеры нужно заменить на адреса из панели. Публичный адрес бэкенда в примере — не разрешение оставлять порт открытым для всех.

Глобальные поля

servers: именование бэкендов

Каждый ключ под servers — это внутреннее имя. address должен быть доступен с точки зрения процесса прокси. restricted: true требует права bungeecord.server.<name>, но не предотвращает прямой сетевой доступ к порту бэкенда.

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

listeners: публичные входы

host должен соответствовать назначенному выделению прокси. priorities — упорядоченный список для старта и резервного варианта. Опечатки вроде Lobby вместо lobby достаточно, чтобы не найти цель по умолчанию.

force_default_server: true направляет новые подключения через логику приоритетов/forced-host. При false BungeeCord может попытаться восстановить ранее использованную цель.

max_players — это не player_limit

listeners.*.max_players управляет отображаемым числом игроков в списке серверов. player_limit — это глобальный жёсткий лимит. Задавай оба параметра осознанно; красивое отображение не заменяет реальное измерение нагрузки.

forced_hosts и DNS

forced_hosts сопоставляет имя хоста внутреннему имени сервера. DNS всё равно указывает на BungeeCord. Для домена и отличающегося порта используй руководство по домену/SRV.

Не путай эти поля

• proxy_protocol предназначен для подключённого перед прокси HAProxy/отправителя PROXY protocol, а не для обычного форвардинга BungeeCord.
• query_enabled при необходимости открывает отдельный UDP-сервис; не включай его заранее на всякий случай.
• ping_passthrough перенимает MOTD и статус цели, но делает сбой бэкенда более заметным.
• restricted — это право BungeeCord, а не файрвол.
• /greload не переносит надёжно каждое изменение плагинов и прав; планируй перезапуск.

Настрой бэкенд соответствующим образом

Установи online-mode=false в server.properties и settings.bungeecord: true в spigot.yml. Для Paper proxies.bungee-cord.online-mode должен соответствовать online_mode прокси. Перед изменением прочитай руководство по безопасному forwarding и создай проверенную резервную копию через путь копирования/отката, описанный в руководстве по смене версий.

Проверка

1. Используй только пробелы, не табуляцию.
2. Проверь отступы и строки со специальными символами.
3. Сравни все имена в priorities и forced_hosts со значениями в servers.
4. Полностью перезапусти бэкенд и прокси.
5. Проверь отдельно TCP, Minecraft-пинг и реальный вход в лобби.
6. Проверь из независимого источника, что порт бэкенда заблокирован.

Если BungeeCord не может достучаться до лобби, поможет руководство по ошибкам fallback-сервера. Устанавливай плагины прокси и бэкенда на правильном уровне только после этого базового теста.

FAQ

Почему не стоит копировать config.yml из руководства?

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

В чём разница между max_players и player_limit?

listeners.*.max_players — это чисто отображение: число, которое клиенты видят в списке серверов. player_limit — это жёсткий глобальный лимит, при достижении которого прокси отклоняет подключения (0 или меньше означает без ограничений). Задавай оба параметра осознанно — высокое отображаемое число не заменяет реальное измерение нагрузки.

Достаточно ли restricted: true для защиты бэкенда?

Нет. restricted — это право BungeeCord, требующее bungeecord.server.<name> для перехода через прокси. Оно никак не мешает обратиться напрямую к порту бэкенда. Защита там — это файрвол или приватная сеть, а не конфигурация прокси.

Нужно ли перезапускать после изменения, или достаточно /greload?

Планируй перезапуск. /greload заново считывает конфигурацию, но не переносит надёжно каждое изменение плагинов и прав в текущее состояние. При изменениях в listeners, серверах или forwarding полный перезапуск — единственный надёжный способ.

Почему домен прокси нельзя указывать как адрес бэкенда?

Потому что тогда прокси будет обращаться сам к себе как к цели, и возникнет петля. В servers.<name>.address должен быть адрес, по которому процесс прокси достигает бэкенд — внутренний или приватный адрес, а не публичное имя, на которое указывает DNS твоей сети.

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

• Официальный справочник по конфигурации BungeeCord
• Актуальные значения по умолчанию BungeeCord в исходном коде
• Глобальная конфигурация Paper