Whitelist: как настроить доступ на сервер

MAATRIX GAMES

Открыл сервер для друзей — а через пару дней там уже десяток незнакомых ников, кто-то ломает постройки, кто-то фармит ресурсы ботом. Знакомая история: без ограничений доступа приватный сервер быстро перестаёт быть приватным. Whitelist решает это на корню — заходят только те, кого ты явно пустил, все остальные видят сервер в списке, но подключиться не могут.

Зачем нужен whitelist

Whitelist — это белый список: сервер пускает только игроков, чьи ID или имена в нём числятся. Всем остальным — вежливый отказ при попытке подключения, часто с текстом вроде «You are not white-listed on this server».

Это закрывает сразу несколько проблем:

• Приватность. Сервер для друзей, гильдии или небольшого комьюнити не становится проходным двором, даже если IP или адрес утёк в паблик.
• Защита от части гриферов и ботов. Массовые скрипты, которые сканируют открытые порты и коннектятся куда попало, отваливаются на первом же экране входа — их ников просто нет в списке.
• Контроль по личности, а не по паролю. Пароль знают все, кому его дали, и передать его третьему лицу — секундное дело. Whitelist привязан к конкретному игровому ID, и это меняет модель угроз (подробнее — в разделе про разницу с паролем).
• Порядок в модерации. Когда список игроков конечный и известный, банить, миксовать права и разбираться в инцидентах ощутимо проще — не нужно гадать, кто из полусотни рандомных ников что натворил.

Whitelist не панацея: он не остановит игрока, который уже в списке и решил нашкодить, и не защитит от DDoS или эксплойтов протокола. Это фильтр на входе, а не система безопасности целиком.

Базовый принцип: файл со списком разрешённых ID

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

Общая логика такая:

1. В списке хранится не просто ник, а привязка к уникальному ID игрока (UUID в Minecraft, SteamID в играх на Source/Unity с интеграцией Steam и так далее) — это важно, потому что ники можно менять, а ID — нет.
2. Список читается сервером при старте и обновляется либо через перезапуск/reload, либо «на лету» командой.
3. Игрок, которого нет в списке, получает отказ при попытке подключения — обычно ещё до того, как успевает загрузиться в мир.

Дальше — конкретика по играм, где механизм называется и настраивается по-разному, но суть та же.

Whitelist в Minecraft: server.properties и whitelist.json

Minecraft — самый показательный пример, потому что здесь механизм максимально прозрачный и лежит в двух местах.

Первое — параметр в server.properties, в корне сервера:

white-list=true

Он включает саму проверку. Без него whitelist.json может быть заполнен чем угодно — сервер его игнорирует.

Второе — сам список, файл whitelist.json рядом с server.properties. Формат простой:

[
  {
    "uuid": "069a79f4-44e9-4726-a5be-fca90e38aec5",
    "name": "Notch"
  },
  {
    "uuid": "853c80ef-3c37-49fd-aa49-938b674adae6",
    "name": "jeb_"
  }
]

Обрати внимание: ключевое поле — uuid, а не name. Ник в файле обновится сам при следующем входе игрока или команде reload, если игрок сменил имя, а вот UUID неизменен — он и есть настоящий идентификатор аккаунта.

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

Через команду в игре или консоли/RCON (нужны права оператора):

/whitelist add Notch
/whitelist remove Notch
/whitelist list
/whitelist reload

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

Вручную через редактирование файла, если сервер выключен или нужно закинуть сразу большой список: правишь whitelist.json в любом текстовом редакторе и запускаешь сервер (или командой /whitelist reload, если сервер уже работает — она перечитывает файл с диска).

Важная деталь для пиратских/офлайн-серверов: если сервер запущен в офлайн-режиме (online-mode=false), UUID генерируется локально из ника и не совпадает с лицензионным аккаунтом — в этом случае привязка менее надёжна, и по сути whitelist превращается в проверку по нику, а не по личности игрока.

Для Bukkit/Spigot/Paper-сборок принцип идентичный — whitelist встроен в ядро игры, а не является функцией плагина, так что всё работает так же и с модами. Если только начинаешь разбираться с плагинами на такой сборке, у нас есть отдельный разбор: Bukkit и Spigot: плагины, с чего начать.

Аналогичный механизм в других играх

Название и детали отличаются, но принцип «список разрешённых ID» встречается почти везде, где есть закрытые серверы.

Rust. Здесь нативного whitelist в ядре игры нет — контроль доступа делают через плагины на базе Oxide/uMod, например Whitelist или похожие по функции моды, которые хранят список SteamID в отдельном конфиге плагина (обычно JSON или oxide-data файл). Логика та же: SteamID в списке — пускают, нет — кикают при коннекте. Если ещё не ставил Oxide/uMod, у нас есть гайд: Oxide и uMod: установка и первые плагины.

ARK: Survival Evolved/Ascended. Параметр AllowedCheaterSteamIDs тут ни при чём, а вот bAllowUnclaimedDinoConfiscation и другие настройки в GameUserSettings.ini не имеют отношения к доступу. Закрытие сервера по игрокам обычно делают через список PlayersJoinNoCheckList/PlayersExclusiveJoinList в GameUserSettings.ini — эксклюзивный список SteamID, которым разрешён вход, остальные получают отказ. Формат — простой список ID через запятую в соответствующей секции конфига.

Counter-Strike 2 и другие игры на Source/движках с интеграцией Steam. Тут чаще используют не whitelist, а связку sv_password (пароль на сервер) плюс список забаненных (banned_user.cfg) — то есть логика скорее обратная, «чёрный список» вместо «белого». Полноценный whitelist по SteamID делают через плагины серверных фреймворков (например, на базе Metamod/SourceMod), которые заранее сверяют SteamID подключающегося со списком в конфиге плагина.

Игры с модами вроде FiveM/RedM (ESX, QBCore). Контроль доступа обычно завязан на систему прав и идентификаторов (license, steam, discord ID) прямо в серверных ресурсах — например, ресурс whitelist или встроенная логика фреймворка, которая проверяет ID игрока против таблицы в базе перед тем, как разрешить полноценный вход в мир (до этого игрок застревает на loading screen).

Общий вывод: если в игре нет встроенного whitelist в самом ядре сервера (как в Minecraft), почти всегда есть плагин или мод, который добавляет этот функционал через список ID во внешнем конфиге.

Ручное добавление игроков по ID

Ручной способ пригождается, когда сервер выключен, когда нужно закинуть сразу большой список (например, при переезде с другого сервера) или когда команда добавления по какой-то причине недоступна.

Общий алгоритм для файловых whitelist (Minecraft и большинство плагинов на JSON/INI):

1. Останови сервер или убедись, что есть команда reload после правки (для Minecraft — /whitelist reload, работает и без остановки).
2. Узнай точный ID игрока. Для Minecraft это UUID — его можно получить через ник на сторонних сервисах проверки UUID или просто добавить по нику: если сервер в онлайн-режиме, он сам подтянет корректный UUID при первом же входе игрока (или сразу при команде /whitelist add, которая обращается к серверам авторизации). Для SteamID — берётся из профиля Steam (64-битный формат, который отображается, например, в URL профиля или через сервисы вроде SteamID.io).
3. Добавь запись в файл в правильном формате (см. пример whitelist.json выше) — обязательно валидным JSON, лишняя запятая или незакрытая скобка уронит парсинг всего файла при старте.
4. Перезапусти сервер или выполни reload, проверь командой /whitelist list (или её аналогом), что игрок появился.

Whitelist через команду в игре или RCON

Быстрее ручной правки — команда прямо из игры (если у тебя есть права оператора/админа) или через RCON, если нужно управлять сервером удалённо без прямого доступа к консоли.

Для Minecraft через RCON (например, клиентом mcrcon или встроенным в панель управления):

mcrcon -H <ip-сервера> -P 25575 -p <rcon-пароль> "whitelist add Notch"

Важно: RCON-порт и пароль настраиваются в server.properties:

enable-rcon=true
rcon.port=25575
rcon.password=<надёжный-пароль>

Держать RCON открытым на 0.0.0.0 без файрвола — плохая идея: это ещё один вход, который тоже надо защищать, иначе вся польза от whitelist обнуляется дырой в самом RCON.

Для игр с плагинами (Rust/Oxide, ARK и другие) команды обычно доступны через консоль сервера или чат-команды с префиксом плагина, конкретный синтаксис смотри в документации самого плагина — универсального стандарта тут нет.

Whitelist vs пароль на сервер: в чём разница

Оба способа закрывают сервер от посторонних, но работают на разных принципах, и путать их не стоит.

На практике многие держат оба слоя сразу: whitelist как основной фильтр по личности плюс пароль (sv_password в CS2, rcon.password для админки, а не для входа игроков) как дополнительный барьер для служебных портов. Для постоянного приватного сервера whitelist почти всегда предпочтительнее — он не «утекает» одной случайной фразой в чужом чате.

Если параллельно настраиваешь и сам сервер с нуля, у нас есть базовые гайды по подъёму: как поднять сервер Minecraft, как поднять сервер Rust и как поднять сервер ARK: Survival.

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