Настройка прокси-сети для нескольких серверов

MAATRIX GAMES

У вас несколько игровых режимов или карт, и хочется, чтобы игрок заходил по одному адресу, а дальше сам выбирал, куда попасть — вместо того чтобы объяснять в Discord «для лобби один IP, для survival другой, для PvP третий». Это ровно та задача, которую решает прокси-сеть — но работает она далеко не в каждой игре, и прежде чем городить эту схему, стоит понять, что это такое и когда оно вообще применимо.

Что такое прокси-сеть в игровом контексте

Прокси-сервер в этом смысле — не тот прокси, что скрывает ваш IP в браузере. Это отдельный лёгкий процесс, который сам по себе не хранит игровой мир и не считает игровую логику, а только принимает подключения игроков и перенаправляет их трафик на один из нескольких бэкенд-серверов, стоящих за ним. Игрок видит один адрес и один порт — play.example.com:25565 — а физически за этим адресом может стоять хаб-лобби, отдельный сервер для survival-режима, отдельный для мини-игр и отдельный для PvP-арены, каждый со своим процессом, своим миром и часто своими настройками.

Смысл в том, чтобы разделить логику на уровни: прокси занимается только приёмом соединений, авторизацией и маршрутизацией, а вся тяжёлая работа (генерация мира, тик игровой логики, физика) остаётся на бэкендах. Игрок переключается между режимами командой внутри игры или через портал/NPC, оставаясь подключённым к тому же прокси — без ручного переподключения к другому IP.

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

Как работает маршрутизация трафика

Общий принцип одинаков вне зависимости от конкретной реализации: прокси слушает публичный порт, принимает входящее соединение, читает первые пакеты рукопожатия (handshake), чтобы понять, к какому серверу игрок хочет подключиться, и дальше либо сразу пробрасывает TCP-соединение на нужный бэкенд, либо сначала обрабатывает часть логики сам (лимит по IP, бан-лист, whitelist) и только потом передаёт эстафету.

Ключевые компоненты типичной прокси-сети:

• Точка входа (edge) — единственный публичный IP и порт, на который резолвится домен игроков.
• Таблица маршрутов — конфиг, где прописано, какой внутренний адрес и порт соответствуют каждому логическому серверу («lobby» → 10.0.0.2:25566, «survival» → 10.0.0.3:25566).
• Бэкенды — сами игровые серверы, которые обычно вообще не имеют публичного IP, а слушают только внутреннюю сеть и принимают соединения исключительно от прокси.
• Механизм переключения — команда игрока (/server survival) или внутриигровой портал, который на уровне протокола говорит прокси «переподключи этого игрока к другому бэкенду», не разрывая сессию с точки зрения пользователя.

Часто прокси и бэкенды физически стоят на одном хосте и общаются через localhost или внутреннюю подсеть — тогда порты бэкендов вообще не открывают наружу, фаервол на хосте пропускает снаружи только порт прокси, а всё остальное закрыто. Если серверы разнесены по разным машинам (например, для распределения нагрузки), между прокси и бэкендами обычно поднимают приватный канал — VPN или частную сеть хостера — именно поэтому защищённый канал между админскими узлами актуален не только для доступа админа, но и для связи компонентов сети.

Для каких игр это вообще применимо

Здесь важно быть честным: прокси-сеть в описанном виде — это не универсальный инструмент, а фича конкретных игровых экосистем, где сам клиент или протокол игры умеет работать через прокси-слой. У абсолютного большинства игр каталога — Rust, ARK: Survival, CS2, DayZ, Palworld, 7 Days to Die и десятков других — такой концепции просто нет: игровой клиент подключается напрямую к конкретному серверу по конкретному адресу, никакого механизма «зайти на прокси и переключиться на бэкенд без реконнекта» в протоколе не предусмотрено.

Прежде чем проектировать прокси-сеть под свой проект, стоит проверить: поддерживает ли конкретная игра multi-server-архитектуру на уровне протокола, или это просто ваша идея «было бы удобно». Если в официальной документации игры или в её серверном ПО нет отдельного компонента с названием вроде «proxy», «gateway» или «hub server» — скорее всего, штатной поддержки просто нет, и городить самодельное проксирование TCP-трафика для игры, которая этого не ожидает, обычно приводит к рассинхрону состояния, лагам на реконнекте или вовсе к отказу подключения.

Экосистема, где прокси-концепция реализована штатно и массово — Minecraft: там прокси-сервер (BungeeCord, Waterfall или более новый Velocity) — это отдельный, отлично документированный класс серверного ПО, специально спроектированный для связки нескольких Spigot/Paper/Fabric-бэкендов за одной точкой входа. Если ваша задача — именно Minecraft-сеть из нескольких режимов, разумнее сразу разбираться с конкретной реализацией под конкретную версию прокси-софта, а не с общими принципами — там есть специфичные нюансы (проброс UUID и IP игрока через protocol extension, синхронизация прав между бэкендами, общий белый список), которые в общей статье не покрыть.

Общий принцип реализации на своей инфраструктуре

Если игра (или мод/фреймворк поверх неё) в принципе поддерживает прокси-архитектуру, порядок действий на любом хостинге примерно такой:

1. Поднимаете прокси-процесс на выделенном порте — обычно это отдельный процесс/сервер, а не часть игрового сервера.
2. Поднимаете бэкенд-серверы на внутренних адресах — если всё на одной машине, это может быть 127.0.0.1 с разными портами; если на разных нодах, потребуется приватная сеть.
3. Прописываете таблицу маршрутов в конфиге прокси — соответствие имени сервера (то, что видит игрок в меню/команде) и реального адреса:порта бэкенда.
4. Закрываете порты бэкендов от внешнего мира в фаерволе, оставляя открытым только порт прокси — принцип тот же, что при обычной настройке портов и фаервола, просто теперь публично торчит одна точка вместо нескольких.
5. Настраиваете единый домен на IP прокси (не на бэкенды) — с этого момента у вас один адрес для всей сети режимов вместо набора разрозненных IP.
6. Синхронизируете общие данные между бэкендами, если это требуется логикой проекта — права доступа, экономика, инвентарь между режимами — это либо задача самого прокси-софта (плагины синхронизации), либо внешней базы данных, к которой обращаются все бэкенды.

Важный практический момент: прокси-слой сам по себе лёгкий по ресурсам — он не считает физику и не хранит мир, поэтому под него не нужно закладывать много RAM или CPU. Основная нагрузка остаётся на бэкендах, и именно их стоит разносить по разным серверам заказа, если один режим ощутимо тяжелее других — план под prokси можно брать минимальный, а под самый нагруженный бэкенд — с запасом.

Альтернатива: несколько независимых серверов вместо единой точки входа

Если игра прокси-концепцию не поддерживает (а таких — большинство), это не тупик — это просто значит, что единой точки входа не будет, и вместо неё вы поднимаете несколько полностью независимых серверов с собственными IP и портами. Игроки просто получают несколько адресов вместо одного: pvp.example.com:28015 для одного режима, pve.example.com:28016 — для другого.

Из минусов по сравнению с настоящей прокси-сетью: нет бесшовного переключения между режимами (игрок выходит из игры и подключается заново к другому адресу), нет общей точки для антибот-фильтрации на входе, каждый сервер администрируется и мониторится отдельно. Из плюсов: настройка кардинально проще, нет дополнительного слоя, который может стать точкой отказа (если прокси упал — недоступны все бэкенды разом, а независимые серверы падают по отдельности и не тянут друг друга за собой), и подходит вообще для любой игры без ограничений по протоколу.

На практике это рабочая и распространённая схема даже для проектов с несколькими режимами: сделать один кастомный домен с несколькими поддоменами под каждый сервер (pvp.example.com, pve.example.com, creative.example.com) — адреса всё равно получаются короткими и запоминающимися, просто без единой точки входа и без бесшовного переключения. Для большинства игр каталога, где прокси в принципе не предусмотрен, это и есть штатный способ организовать несколько режимов под одним проектом.

Мониторинг и обслуживание сети из нескольких серверов

Независимо от того, стоит у вас настоящая прокси-сеть или набор отдельных серверов, с ростом числа компонентов растёт и объём рутинной админской работы: нужно следить за состоянием каждого бэкенда отдельно, вовремя замечать, если один из режимов начал лагать или упал, и не пропустить момент, когда конкретный сервер упёрся в лимит по игрокам при общей аудитории проекта.

Практические моменты, которые стоит заложить сразу:

• Отдельный мониторинг на каждый бэкенд — TPS и задержки считаются по каждому серверу независимо, общая метрика по всей сети мало что скажет о том, где именно проблема.
• Лимиты игроков считаются раздельно — расчёт максимального онлайна под конкретное железо и RAM делается для каждого бэкенда исходя из его собственной нагрузки, а не от суммарной аудитории проекта.
• Логи разнесены физически, если бэкенды на разных нодах — при разборе инцидента на одном режиме не забывайте, что интересующий лог лежит именно на том хосте, где стоит нужный сервер, а не на прокси.
• План на случай падения одного из компонентов — если это настоящая прокси-сеть, падение прокси кладёт вход для всех сразу, поэтому имеет смысл держать её на максимально стабильном и лёгком по нагрузке узле, а не совмещать с самым тяжёлым бэкендом.

Табличное сравнение подходов для наглядности:

Частые вопросы