TeaHostПиратский сервер майнкрафт — это обычный сервер с выключенной проверкой лицензии. Технически всё сводится к одной строчке в конфиге. Проблема в том, что после этой строчки сервер становится дырявым: любой человек заходит под любым ником, включая ваш. Поэтому реальная работа начинается не с переключения флага, а с того, что делать дальше — пароли, whitelist, права и грамотная миграция, если сервер уже жил в лицензионном режиме.
Сразу оговорка по терминологии: официально это называется офлайн-режим (offline mode). «Пиратский» — жаргон рунета. Дальше буду использовать оба слова как синонимы.
Шаг первый: переключаем online-mode
Останавливаете сервер. Открываете server.properties в корне и находите строку:
online-mode=trueМеняете на:
online-mode=falseЗапускаете. Всё, сервер больше не спрашивает у Mojang, настоящий ли это игрок. Пиратские лаунчеры заходят, лицензионные тоже заходят.
Важно: править файл лучше при остановленном сервере. Сервер читает server.properties только при запуске и тогда же перезаписывает его, поэтому правка на живую не применится до перезапуска (так это описано на странице server.properties в Minecraft Wiki). Это классическая причина «я всё поменял, а ничего не поменялось». Остальные параметры этого файла разобраны в вики: настройка server.properties.
Пиратский сервер майнкрафт: почему одного флага мало
Пока online-mode=true, ник намертво привязан к аккаунту Mojang. Как только флаг снят, ник — это просто строка, которую клиент присылает серверу. Никакой проверки.
Практический вывод: через минуту после публикации адреса на ваш сервер зайдёт человек с ником вашего администратора и с вашими же правами. Не «может зайти» — зайдёт. Это происходит на каждом втором новом офлайн-сервере.
Значит, нужен плагин авторизации по паролю. Без него офлайн-сервер можно держать только за whitelist и только для знакомых.
Шаг второй: ставим AuthMe
AuthMe Reloaded — стандарт для офлайн-серверов уже много лет. Он заставляет игрока зарегистрироваться командой /register пароль пароль и логиниться через /login пароль при каждом входе. До логина игрок обездвижен, чат ему недоступен, инвентарь скрыт.
Кидаете jar в plugins/, перезапускаете, правите plugins/AuthMe/config.yml. Минимальный набор, который стоит поменять сразу:
settings:
restrictions:
maxRegPerIp: 2
timeout: 60
allowChat: false
ForceSingleSession: true
security:
minPasswordLength: 6
passwordHash: BCRYPT| Параметр | Значение | Что делает |
|---|---|---|
maxRegPerIp | 2 | Мешает одному человеку наплодить сотню аккаунтов |
timeout | 60 | Кикает тех, кто зашёл и не залогинился за минуту |
allowChat | false | Незалогиненный игрок не пишет в чат |
ForceSingleSession | true | Не даёт двум клиентам сидеть под одним ником одновременно — на офлайн-серверах это реальная проблема |
minPasswordLength | 6 | Минимальная длина пароля |
passwordHash | BCRYPT | Стойкий алгоритм хеширования паролей |
Пошаговая установка с разбором конфига есть в отдельном материале: как настроить авторизацию AuthMe.
Есть и альтернативы. nLogin умеет автоматически пропускать лицензионных игроков без пароля (режим premium autologin) — приятно, если аудитория смешанная. FastLogin делает то же самое в связке с AuthMe, а в свежих сборках AuthMe Reloaded есть и встроенный premium bypass (settings.enablePremium, команда /premium, при прямом подключении нужен PacketEvents). Для маленького сервера разницы почти нет, берите AuthMe.
Шаг третий: закрываем дыры вокруг авторизации
Плагин на месте — но есть детали, которые ломают защиту, если о них не подумать.
Права оператора. Не выдавайте OP через op ник, если сервер офлайновый. В офлайн-режиме OP привязывается к сгенерированному UUID, а не к аккаунту. Лучше раздавать права через группы в LuckPerms — так их проще отзывать и сложнее случайно продублировать. Как это устроено, разобрано в статье про настройку LuckPerms.
Whitelist для админов. Даже с AuthMe полезно держать список тех, кто вообще имеет право на админские ники. Настраивается через whitelist и права операторов.
Логирование. CoreProtect на офлайн-сервере не роскошь, а необходимость. Когда кто-то всё-таки пролезет, откат по логам будет единственным способом восстановить постройки.
Резервные копии. Ежедневный автобэкап хотя бы на неделю назад. На офлайн-сервере вероятность влететь заметно выше, чем на лицензионном.
Проблема UUID: почему это болит
Самая недооценённая часть перехода. В лицензионном режиме UUID игрока выдаёт Mojang, он глобальный и постоянный. В офлайн-режиме сервер генерирует UUID сам — из ника, по алгоритму MD5 от строки OfflinePlayer:<ник>.
Что из этого следует.
Первое: при переключении online-mode с true на false у всех игроков сменятся UUID. Их дома в EssentialsX, балансы в экономике, регионы в WorldGuard, права в LuckPerms — всё это привязано к старому UUID и после переключения просто не найдётся. Игрок зайдёт как совершенно новый человек на пустое место.
Второе: обратный переход ломает уже офлайновые данные тем же способом.
Третье: если у вас сеть серверов за прокси, UUID должны генерироваться одинаково на всех узлах, иначе игрок будет терять инвентарь при переходе между серверами.
Если сервер уже пожил в лицензионном режиме и вы хотите переехать — есть два пути. Честный: экспортировать данные плагинов, пересчитать UUID и импортировать обратно (LuckPerms и Essentials умеют миграцию, но руками придётся повозиться). Быстрый и честный по-другому: начать новый мир и сказать игрокам прямо. Второй вариант чаще оказывается дешевле по нервам.
Смешанный сервер: и пираты, и лицензия
Многим хочется пускать всех, но чтобы лицензионные игроки не вводили пароль и сохраняли свои настоящие UUID. Это делается через комбинацию:
online-mode=falseна сервере- nLogin или AuthMe + FastLogin
- Плагин сам проверяет через API Mojang, существует ли такой лицензионный аккаунт, и если да — требует, чтобы человек подтвердился как владелец
Схема рабочая, но настраивается заметно сложнее и требует, чтобы сервер имел доступ к api.mojang.com. Если доступа нет, проверка ломается, и все становятся «пиратами». Проверить связь можно так:
curl -s https://api.mojang.com/users/profiles/minecraft/NotchОтвет с JSON и UUID означает, что связь есть.
Что перестаёт работать в офлайн-режиме
Полезно знать заранее, чтобы не удивляться.
Скины. Клиент не получает скин с серверов Mojang — все выглядят как Стив или Алекс. Лечится плагинами вроде SkinsRestorer, которые подтягивают скины по нику.
Достижения и статистика Realms. Не относится к своему серверу, но иногда путают.
Античит-интеграции, завязанные на лицензию. Некоторые проверки просто не работают.
Мониторинги. Часть публичных мониторингов серверов не принимает офлайн-проекты или помечает их отдельно.
Частые вопросы
Пиратский сервер майнкрафт можно поднять на любом хостинге?
Технически да — это просто параметр в конфиге, и никакого особого софта не требуется. Разница только в том, разрешает ли конкретный хостинг такие проекты правилами. У большинства российских игровых хостингов вопросов нет.
Будет ли пиратский сервер работать медленнее?
Наоборот, чуть быстрее на входе: сервер не ждёт ответа Mojang при подключении. На производительность в игре это не влияет никак — за TPS отвечают совсем другие вещи, разобранные в статье как поднять низкий TPS.
Смогут ли лицензионные игроки зайти на офлайн-сервер?
Да, официальный лаунчер спокойно подключается к серверу с online-mode=false. Но UUID у такого игрока будет офлайновый, то есть его лицензионный аккаунт для сервера ничего не значит.
Нужен ли AuthMe, если сервер только для друзей?
Если сервер закрыт whitelist'ом и адрес нигде не публиковался — можно обойтись. Как только адрес попадает в чат Discord с сотней людей или в мониторинг, AuthMe становится обязательным.
Итог по шагам
Меняете online-mode на false при остановленном сервере. Ставите AuthMe и приводите в порядок его конфиг. Раздаёте права через LuckPerms, а не через op. Включаете CoreProtect и автобэкапы. Если сервер уже жил в лицензионном режиме — заранее решаете, что делать с UUID: мигрировать или начинать с чистого листа.
Если поднимаете первый сервер вообще, начните с базового гайда как запустить сервер Minecraft, а готовую площадку с панелью и бэкапами можно взять в тарифах.
