Velocity vs BungeeCord: сравнение и миграция

BungeeCord появился в 2012 году и на протяжении многих лет был единственным реальным выбором для тех, кому нужен прокси-сервер в Minecraft. Он делал свою работу. Но сейчас 2026 год, и ситуация кардинально изменилась.

Velocity, созданный Эндрю Штейнборном в 2018 году и перешедший под крыло PaperMC, стал де-факто стандартом для новых сетей. Waterfall (форк BungeeCord от Paper) официально заброшен. Сам BungeeCord на минимальном обслуживании от md_5.

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

Производительность: цифры говорят сами за себя

Давайте начнём с того, что волнует всех - скорость. PaperMC заявляет, что Velocity до 8 раз быстрее BungeeCord в определённых сценариях. Звучит как маркетинг? Давайте разберём, откуда берутся эти цифры.

Сжатие: libdeflate vs zlib

BungeeCord использует стандартный Java-реализованный zlib для сжатия пакетов. Velocity использует libdeflate - нативную библиотеку, которая обеспечивает примерно двукратное ускорение компрессии и декомпрессии. На сети с 500+ игроками это ощутимая разница в нагрузке на CPU.

Отсутствие Entity ID Rewriting

Вот это, пожалуй, самое важное архитектурное отличие. BungeeCord перехватывает каждый пакет и переписывает Entity ID, чтобы избежать конфликтов между серверами. Это дорогая операция, которая происходит на каждый пакет с entity.

Velocity отказался от этого подхода полностью. Вместо переписывания ID на прокси, Velocity полагается на то, что бекенд-серверы сами корректно управляют Entity ID при переключении игрока. Результат - значительно меньше CPU overhead на каждое соединение.

TCP Fast Open

Velocity поддерживает TCP Fast Open (TFO) из коробки. Эта технология позволяет отправлять данные уже в первом SYN-пакете TCP-соединения, сокращая время установки соединения на один RTT. Для игроков это означает более быстрое подключение к серверу.

Асинхронная обработка событий

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

Нативный транспорт

Velocity поддерживает нативный Epoll транспорт на Linux вместо стандартного Java NIO. Это снижает количество системных вызовов и уменьшает латентность на уровне ядра ОС. На загруженных серверах с тысячами соединений разница особенно заметна.

BungeeCord использует стандартный Netty NIO транспорт на всех платформах. Технически он тоже может работать с Epoll, но Velocity делает это из коробки, без дополнительных настроек.

Что это значит на практике

На небольшой сети с 50 игроками разница может быть незаметна. Но если у вас 200+ игроков, особенно с кастомными плагинами, переход на Velocity даст ощутимый прирост. Меньше TPS-дропов при переключении между серверами, быстрее подключение, стабильнее работа под нагрузкой.

Отдельно стоит отметить потребление памяти. Velocity в целом легче BungeeCord при одинаковом количестве подключений. За счёт отказа от Entity ID Rewriting и более оптимизированной работы с буферами пакетов, на каждое соединение тратится меньше RAM. Для серверов, где каждый мегабайт на счету, это существенно.

Безопасность: главная причина для миграции

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

IPForward: дыра размером с дверь

BungeeCord использует механизм IPForward для передачи информации об игроке на бекенд-серверы. Как это работает? Прокси добавляет IP-адрес и UUID игрока в handshake-пакет в виде обычного текста. Бекенд-сервер с включённым bungeecord: true слепо доверяет этим данным.

Проблема очевидна: если кто-то подключится к бекенд-серверу напрямую (минуя прокси), он может подставить любой UUID в handshake. Это означает полный доступ к чужому аккаунту, включая инвентарь, права, баланс.

BungeeHack и UUID Spoofing

BungeeHack - это целое семейство эксплойтов, использующих именно эту уязвимость. Атакующий подключается напрямую к бекенд-серверу и подменяет UUID в handshake-пакете. Результат - он заходит под чужим аккаунтом.

UUID Spoofing работает аналогично. Поскольку BungeeCord передаёт UUID в plain text без какой-либо верификации, подделка тривиальна. Даже файрвол не всегда спасает, если у атакующего есть доступ к внутренней сети.

Velocity Modern Forwarding: HMAC-SHA256

Velocity решает эту проблему кардинально. Modern Forwarding использует HMAC-SHA256 для подписи данных, передаваемых от прокси к бекенд-серверу. Прокси и бекенд-сервер разделяют секретный ключ, и каждый handshake подписывается этим ключом.

Если кто-то попытается подключиться к бекенд-серверу напрямую или подменить данные в handshake, подпись не совпадёт и соединение будет отклонено. Никаких UUID Spoofing, никаких BungeeHack. Криптографическая защита вместо "доверяй и не проверяй".

Конкретный сценарий атаки

Представьте: у вас сеть из BungeeCord и трёх Paper-серверов. Бекенды слушают на 25566, 25567, 25568. Вы забыли закрыть файрволом порт 25567 (survival-сервер). Атакующий узнаёт IP вашего сервера, подключается напрямую на порт 25567 с подменённым UUID администратора. Он получает полный доступ к op-правам, WorldEdit, банковскому плагину.

С Velocity Modern Forwarding этот сценарий невозможен. Даже если порт открыт, бекенд-сервер отклонит соединение без валидной HMAC-подписи. Это принципиально другой уровень защиты.

BungeeGuard - это костыль

Да, существует BungeeGuard и аналогичные плагины, которые добавляют токен-верификацию поверх BungeeCord. Но это костыль. Вы накладываете пластырь на архитектурную проблему, вместо того чтобы использовать решение, где безопасность заложена в основу. К тому же BungeeGuard нужно настраивать отдельно на каждом бекенд-сервере и не забывать обновлять токены. В Velocity это просто работает.

Waterfall мёртв, BungeeCord на аппарате ИВЛ

Если вы ещё думаете "ну, я подожду", вот факты.

Waterfall: официально EOL

Waterfall - это форк BungeeCord от команды PaperMC, который добавлял патчи производительности и исправления багов. В 2024 году PaperMC официально объявили Waterfall End of Life. Никаких обновлений, никаких патчей безопасности. Команда Paper прямо рекомендует переходить на Velocity.

BungeeCord: минимальное обслуживание

md_5 продолжает поддерживать BungeeCord, но это именно минимальное обслуживание. Крупных обновлений нет уже давно. Поддержка новых версий Minecraft добавляется, но без серьёзных улучшений в архитектуре или безопасности. Проект живёт по инерции.

Что это значит для вас

Если вы используете Waterfall, у вас уже нет выбора - проект мёртв. Если вы на BungeeCord, вопрос не "если", а "когда" вы столкнётесь с проблемой, для которой не будет патча. Лучше мигрировать на своих условиях, чем быть вынужденным.

Экосистема плагинов

Один из главных аргументов против миграции - "а плагины?". Давайте разберём.

Несовместимость API

Это факт: плагины BungeeCord не работают на Velocity. У них разные API. Если у вас кастомный плагин для BungeeCord, его придётся переписать. Это, пожалуй, самая болезненная часть миграции.

Но есть нюансы. Многие популярные плагины уже давно имеют версии для обеих платформ. LuckPerms, TAB, LimboAuth, MiniMOTD, Geyser - все они поддерживают Velocity.

Hangar: 311+ плагинов

На Hangar (платформа плагинов от PaperMC) доступно более 311 плагинов для Velocity. И это число растёт. Новые плагины часто выходят сначала для Velocity, а потом (если вообще) для BungeeCord. Тренд очевиден.

Крупные сети уже перешли

Minehut, одна из крупнейших Minecraft-хостинг платформ, использует Velocity. Большинство современных хостингов рекомендуют Velocity по умолчанию. Это не экспериментальная технология, это продакшн-стандарт.

Гайд по миграции

Хорошо, вы решили мигрировать. Вот пошаговая инструкция.

Шаг 1: Установка Velocity

Скачайте последнюю версию Velocity с PaperMC Downloads. Создайте отдельную директорию и запустите:

java -Xms512M -Xmx512M -jar velocity.jar

Velocity сгенерирует конфигурационные файлы. Остановите сервер.

Шаг 2: Настройка velocity.toml

Откройте velocity.toml и настройте основные параметры:

bind = "0.0.0.0:25565"

[servers]
lobby = "127.0.0.1:30001"
survival = "127.0.0.1:30002"
minigames = "127.0.0.1:30003"

try = ["lobby"]

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

[advanced]
tcp-fast-open = true

Шаг 3: Включение Modern Forwarding

В velocity.toml установите:

player-info-forwarding-mode = "modern"

Velocity создаст файл forwarding.secret с секретным ключом. Скопируйте содержимое этого файла.

Шаг 4: Настройка бекенд-серверов

На каждом Paper-сервере сначала отключите BungeeCord forwarding в spigot.yml:

settings:
  bungeecord: false

Затем включите Velocity в config/paper-global.yml:

proxies:
  velocity:
    enabled: true
    online-mode: false
    secret: "ВСТАВЬТЕ_СЕКРЕТ_ИЗ_forwarding.secret"

Шаг 5: Замена плагинов

Составьте список всех BungeeCord-плагинов и найдите их Velocity-аналоги:

BungeeCord плагин	Velocity аналог
BungeeTabListPlus	TAB (Velocity)
BungeeCord AuthMe	LimboAuth
ServerListPlus	MiniMOTD
BungeeGuard	Не нужен (Modern Forwarding)
Geyser-BungeeCord	Geyser-Velocity

Шаг 6: Файрвол

Убедитесь, что порты бекенд-серверов закрыты извне. Несмотря на Modern Forwarding, прямой доступ к бекендам должен быть закрыт:

# Разрешаем только локальный доступ к бекенд-серверам
iptables -A INPUT -p tcp --dport 30001:30010 -s 127.0.0.1 -j ACCEPT
iptables -A INPUT -p tcp --dport 30001:30010 -j DROP

Шаг 7: Тестирование

Запустите всё и проверьте:

Подключение через прокси работает
Переключение между серверами работает
UUID игроков корректный (проверьте через /velocity dump)
Плагины функционируют

Частые ошибки при миграции

Раз уж мы говорим о миграции, вот грабли, на которые наступают чаще всего.

Забыли отключить bungeecord: true. После перехода на Velocity нужно выставить bungeecord: false в spigot.yml. Если оставить true, бекенд-сервер будет пытаться читать IPForward данные из handshake, а Velocity отправляет данные через свой Modern Forwarding канал. Результат - сломанные IP-адреса и UUID.

Скопировали секрет с пробелами. При копировании forwarding.secret люди иногда захватывают пробел или перенос строки в конце. Подпись не совпадает, и все соединения отклоняются. Проверяйте секрет дважды.

Не обновили online-mode. В paper-global.yml секция velocity требует online-mode: false. Это не значит, что сервер станет пиратским. Верификация происходит на уровне прокси, а бекенд доверяет прокси через HMAC. Но если забыть этот параметр, ничего не заработает.

Плагины с hardcoded BungeeCord API. Некоторые плагины используют BungeeCord Plugin Messaging Channel для связи между серверами. На Velocity вам нужна Velocity API или кросс-платформенные решения вроде PluginMessage API через Velocity.

Когда BungeeCord всё ещё ок

Справедливости ради, есть сценарии, где BungeeCord пока остаётся разумным выбором.

Legacy-сети на 1.8. Если ваш сервер работает на 1.8 и вы принципиально не обновляетесь, экосистема BungeeCord для этой версии богаче. Velocity ориентирован на современные версии.

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

Во всех остальных случаях Velocity - однозначный выбор.

Сравнительная таблица

Параметр	BungeeCord	Velocity
Производительность	Базовая	До 8x быстрее
Сжатие	Java zlib	libdeflate (2x быстрее)
Entity ID Rewriting	Да (CPU overhead)	Нет
TCP Fast Open	Нет	Да
Обработка событий	Синхронная	Асинхронная
Forwarding	Plain text (IPForward)	HMAC-SHA256 (Modern)
BungeeHack защита	Требует доп. плагины	Встроена
Статус проекта	Обслуживание	Активная разработка
Waterfall (форк)	EOL	-
Плагины на Hangar	Ограничено	311+
Лицензия	Кастомная	GPLv3
Крупные сети	Устаревшие	Minehut и др.

Как это работает с DDoS-защитой

Если ваш сервер находится за DDoS-защитой вроде MineGuard, переход на Velocity не требует изменений в настройках фильтрации. Прокси-протокол работает одинаково, TCP-соединения проксируются так же. Velocity даже немного упрощает жизнь за счёт поддержки PROXY Protocol из коробки.

Вердикт

BungeeCord сделал огромную работу для Minecraft-комьюнити. Без него сетевые серверы не были бы такими, какие они сейчас. Но технологии не стоят на месте.

Velocity быстрее, безопаснее, активнее разрабатывается. Waterfall мёртв, и Paper прямо говорит: используйте Velocity. Все крупные хостинги рекомендуют Velocity. Экосистема плагинов растёт.

Единственная реальная боль при миграции - это переписывание кастомных плагинов. Но чем дольше вы ждёте, тем больше кода придётся переписать. Лучше начать сейчас.

Если вы запускаете новую сеть в 2026 году и выбираете BungeeCord - вы делаете ошибку. Если вы уже на BungeeCord, составьте план миграции. Ваши игроки скажут спасибо.

Velocity vs BungeeCord: почему пора переходить