BungeeCord IP Forwarding нужен для того, чтобы бэкенд получал настоящий IP игрока, Online-UUID и данные профиля, хотя TCP-соединение приходит от прокси. Для этого должны совпасть четыре значения — а порт бэкенда должен быть защищен от прямых подключений.
ip_forward: trueне является Firewall. Классический формат BungeeCord не имеет прокси-специфичного секретного ключа подписи. Тот, кто доберется до незащищенного Offline-Mode-бэкенда, может подделать Forwarding-данные и выдать себя за другого игрока.
Четыре значения
| Место | Файл/поле | Обычное значение |
|---|---|---|
| BungeeCord | config.yml → online_mode |
true |
| BungeeCord | config.yml → ip_forward |
true |
| Бэкенд | server.properties → online-mode |
false |
| Бэкенд | spigot.yml → settings.bungeecord |
true |
Для актуального Paper дополнительно нужно:
# config/paper-global.yml
proxies:
bungee-cord:
online-mode: true
Это значение Paper соответствует Online-Mode прокси. Оно остается true, даже если в server.properties на бэкенде используется online-mode=false.
Почему перед изменением нужен Backup
Без Forwarding Offline-Mode-бэкенд создает UUID из имени игрока. При корректном Forwarding он получает UUID из онлайн-аутентификации. Эти значения не совпадают. Инвентарь, Enderchest, ранги или данные экономики после этого могут выглядеть пропавшими, хотя они сохранены под старым UUID.
Перед изменением:
- сохрани миры,
playerdata, базы данных прав и плагинов; - проверь восстановление из Backup;
- задокументируй старый и ожидаемый UUID для тестового игрока;
- проверь инструменты миграции конкретных плагинов;
- никогда не меняй имена файлов вслепую, не зная ссылок и формата данных.
Существующий гайд по смене версии описывает подходящий путь Backup, копии и отката.
Шаг 1: настроить прокси
Корректно останови BungeeCord и отредактируй текущий config.yml:
online_mode: true
ip_forward: true
Оставь публичную аутентификацию активной на прокси. Параллельно проверь Listener, servers и priorities по справочнику полей config.yml.
Шаг 2: настроить бэкенд
Полностью останови каждый бэкенд и измени:
# server.properties
online-mode=false
# spigot.yml
settings:
bungeecord: true
При Paper дополнительно задай показанное значение proxies.bungee-cord.online-mode. Сначала перезапусти бэкенды, затем BungeeCord. Частичного reload для такого изменения идентичности недостаточно.
Шаг 3: закрыть путь к бэкенду
Разреши Backend-TCP-порт только из проверенного пути прокси. В зависимости от твоей инфраструктуры это может быть Loopback, настоящая приватная сеть/VPN или строгая Firewall-правило. В контейнерных окружениях одной внутренней IP недостаточно: чужой инстанс на том же Bridge не должен проходить как прокси.
На game-serverhosting активный Guard привязывает поддерживаемые BungeeCord-бэкенды к конкретному прокси-инстансу и заново определяет его текущий контейнерный источник. Stop, отсутствующий или неоднозначный источник остаются в режиме Drop-only. Пути Same-Node, Cross-Node и External-Backend были проверены настоящим входом через прокси; независимый прямой доступ оставался заблокированным. Это утверждение относится к этим доказанным путям, а не является гарантией для любых внешних сетей провайдеров.
Полный Setup-гайд объясняет эти сетевые варианты.
Как правильно понимать BungeeGuard
BungeeGuard дополняет Legacy-формат общим токеном. Используй минимум 1.4.0. Страница безопасности проекта документирует раскрытие токена для старых BungeeCord-установок; после Upgrade потенциально затронутый токен нужно ротировать на прокси и бэкендах.
- создавай токен локально с достаточной энтропией;
- никогда не копируй его в тикеты, логи, скриншоты или Git;
- обновляй прокси и все бэкенды согласованно;
- удаляй старый токен только после успешного теста;
- при неизвестной/старой версии считай состояние unverified.
BungeeGuard особенно полезен на Shared Hosting, но не заменяет доступное Firewall-/приватное сетевое решение как первый уровень защиты.
Проверка: четыре отдельных сигнала
- Процесс: прокси и бэкенд полностью запущены.
- TCP: прокси достигает Backendlistener.
- Вход в лобби: настоящий аутентифицированный игрок попадает через прокси на бэкенд.
- Идентичность: бэкенд видит ожидаемые Online-UUID и Client-IP, а не Offline-UUID или только Proxy-IP.
Затем идет негативный тест: независимый источник не должен достигать порта бэкенда. Открытый Listener или успешный Ping сами по себе не доказывают вход.
Типичные ошибки
| Симптом | Причина | Следующий шаг |
|---|---|---|
| у всех игроков Proxy-IP | ip_forward или bungeecord выключен |
проверить обе стороны, полностью перезапустить |
| у игрока новый инвентарь | изменился режим UUID | сохранить Backup, сравнить UUID, мигрировать с учетом конкретного плагина |
If you wish to use IP forwarding... |
бэкенд ожидает Forwarding, прокси его не отправляет | проверить значение прокси и точный запущенный config |
| возможен прямой вход под чужим именем | бэкенд публично доступен | немедленно исправить Firewall/приватную сеть |
| прокси тоже не достигает бэкенда | разрешение имеет неверный/stale источник | заново оценить конкретную привязку прокси, не открывать широко |
| после BungeeGuard-Update вход невозможен | токен несогласован | проверить отредактированные версии, согласованно ротировать |
Если нет стартовой цели, поможет руководство по fallback-ошибкам. Домены по-прежнему указывают на прокси; для этого используй гайд по Domain-/SRV.
Плагины и Crossplay
Плагины прав, банов и экономики особенно чувствительны к UUID. Сохрани их данные и проверь, требуется ли компонент для прокси и бэкенда. Гайд по плагинам объясняет разделение платформ.
Geyser в прокси-сети устанавливается только на прокси. Bedrock-UDP и Java-TCP остаются отдельными путями; key.pem является секретным. Настраивай Geyser/Floodgate только после того, как Java-Forwarding и негативный путь стали зелеными.
FAQ
Является ли ip_forward: true защитой?
Нет. Он только передает IP, UUID и профиль на бэкенд. У классического формата нет прокси-специфичного секретного ключа подписи: тот, кто напрямую доберется до незащищенного Offline-Mode-бэкенда, может подделать эти данные. Защита — это сетевая граница, а не настройка.
Почему на бэкенде стоит online-mode=false?
Потому что аутентификация через Mojang уже происходит на прокси — иначе бэкенд потребовал бы ее второй раз и отклонил бы каждого игрока. В Paper proxies.bungee-cord.online-mode все равно остается true: это значение отражает Online-Mode прокси, а не бэкенда.
Почему после переключения у игроков пустой инвентарь?
Потому что изменился UUID. Без Forwarding Offline-Mode-бэкенд создает UUID из имени игрока, а с Forwarding приходит настоящий Online-UUID. Старые данные не потеряны, они лежат под старым UUID — поэтому перед изменением нужен проверенный Backup.
Нужен ли мне BungeeGuard?
Он дополняет Legacy-формат общим токеном и особенно полезен на Shared Hosting, где ты не можешь задать собственное Firewall-правило. Используй минимум версию 1.4.0 и ротируй токен после Upgrade. Доступное Firewall- или приватное сетевое решение он не заменяет.
Куда ставить Geyser в прокси-сети?
Только на прокси, не дополнительно на бэкенды. Bedrock работает через UDP, Java через TCP — оба пути проверяются отдельно, а key.pem является секретным. Настраивай Crossplay только тогда, когда Forwarding и негативный тест на стороне Java зеленые.