На Java-сервере список разрешённых игроков отвечает за вход, а статус оператора — за команды внутри игры. Доступ к консоли, панели, SSH и RCON относится к отдельным учётным записям. Если смешать эти уровни, можно случайно дать игроку больше полномочий, чем планировали.
Ниже — порядок для Java Edition на vanilla-совместимом сервере, включая Paper. Команды управления вводите в консоль того самого экземпляра сервера; там начальный / не нужен. В игровом чате перед командой ставьте /. Bedrock использует отдельную систему allowlist и здесь не рассматривается.
Сначала ограничьте вход на сервер#
Перед изменениями убедитесь, что у вас останется доступ к консоли или панели. Если это удалённый сервер, не закрывайте текущую административную сессию, пока не проверите новое правило.
Добавьте игроков, которым разрешён вход, затем включите whitelist и проверьте список:
whitelist add PlayerOne
whitelist add PlayerTwo
whitelist list
whitelist on
Удалить игрока можно командой whitelist remove PlayerOne, а состояние проверить командой whitelist list. В server.properties настройка называется white-list; файл whitelist.json хранит имена и UUID разрешённых игроков. Документация Paper советует менять этот список командой /whitelist, а не редактировать JSON вручную.
Если команда выполнена в консоли, не добавляйте перед ней /. Если выполняете её от имени игрока в чате, нужен слэш и соответствующие права. В обсуждениях администраторы часто упираются именно в эту путаницу: например, в вопросе про добавление игрока редактированием файла решение свелось к использованию консольной команды. Это пример отдельной ситуации, а не статистика проблем.
Выдавайте OP только тем, кому нужны игровые команды#
Добавление в whitelist не делает игрока оператором. И наоборот, операторский статус не должен быть способом описать, кому вы доверяете вход на сервер. Не полагайтесь на возможные исключения для операторов в проверке whitelist: явно задайте список игроков и проверьте поведение на выбранной сборке.
Выдать и отозвать статус оператора можно из консоли:
op PlayerOne
deop PlayerOne
Файл ops.json хранит операторский статус и уровень разрешений. В Paper уровни описаны от 0 до 4; общий параметр op-permission-level задаёт уровень по умолчанию для новых операторов. Команда /op может дать широкие игровые полномочия, поэтому не назначайте OP для обычного входа или каждой административной мелочи. На Paper 1.21 и новее уже встроен Spark; отдельные разрешения spark позволяют пользоваться конкретными диагностическими командами без выдачи полного OP, если права сервера настроены соответствующим образом.
Если модератору нужны только отдельные команды, используйте совместимую систему permissions и выдайте минимальный набор прав. Названия permission-узлов зависят от плагина и команды; сверяйтесь с документацией установленных версий. Не копируйте вслепую список прав с другого сервера.
Отделите игровой доступ от доступа к машине#
Консоль сервера может выполнять команды от имени самого сервера и обычно не требует игрового OP. Поэтому доступ к ней выдавайте только доверенным администраторам. Учётная запись панели, системный пользователь SSH и пароль RCON — самостоятельные способы управления; отзовите их отдельно, когда человек перестаёт обслуживать сервер. Если вы управляете собственной инфраструктурой через Nexardo, права панели всё равно следует проверять отдельно от списка игроков и операторов Minecraft.
RCON выключен по умолчанию в документированной конфигурации Paper. Если он действительно нужен, задайте уникальный сильный пароль и ограничьте сетевую доступность firewall или приватной сетью. Не открывайте RCON всему интернету и не вставляйте пароль в скриншоты, команды оболочки или публичные логи. Если RCON не используется, оставьте enable-rcon=false.
Если человек не может войти или выполнить команду#
Сообщение о whitelist при подключении. Убедитесь, что проверяете правильный сервер и мир; посмотрите whitelist list, проверьте имя/профиль игрока и включён ли white-list. Именно он ограничивает новые подключения. enforce-whitelist относится к отключению уже вошедших игроков, которые не прошли whitelist; это отдельный сценарий, а не переключатель для отказа новому игроку. Не добавляйте игрока в OP «на всякий случай» — это не замена проверке списка доступа.
Игрок вошёл, но команда запрещена. Проверьте, вводит ли он команду в чате, какой уровень OP ему выдан, и не управляет ли командой плагин permissions. Сначала выдайте узкое право на нужную команду, если это поддерживает установленный плагин; не повышайте уровень всем операторам автоматически.
Не работает панель, SSH или RCON. Это отдельная учётная запись и сетевой путь. Проверьте её роль и адрес/фильтр доступа независимо от whitelist.json и ops.json. Не включайте RCON только ради исправления ошибки входа игрока.
Не редактируйте ops.json или whitelist.json, пока сервер работает: Paper описывает их как файлы состояния и рекомендует управлять ими командами. После изменений перепроверьте список, разрешения и отдельные административные учётные записи. Когда игроку больше не нужен доступ, удалите его из whitelist и отдельно снимите OP, если он был оператором.
