Руководство 🛡️ Руководство | Полная защита Майнкрафт-серверов от всех видов Лаг-Машин (1.8 - 1.21.11)

Всем привет народ, в этом новом руководстве я хочу поговорить и ответить на вопрос « Как реально защитить свой сервер от всех возможных Лаг-Машин в 2026 году? »

---

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

В этом подробном руководстве я разберу самую эффективную и рабочую систему защиты именно для Paper/Purpur для версий от 1.16 до 1.21.11 включительно

Способов защиты существует несколько, и самое главное — стоит использовать комбинированный подход, который не ломает обычные редстоун-схемы, но жёстко режет именно проблему лаг-машин. Я прошерстил кучу форумов, где обсуждали нашу тему, посмотрел все возможные плагины, которые решают проблему, добавляя умные системы, и реальные примеры машин 2024–2026 годов. Так, что предлагаю начать

---

1. Почему обычные настройки ядра не спасают полностью?

Ванильные механики Майнкрафта просто не рассчитаны на такие « злоупотребления » редстоун-механизмами. Даже если ты включишь все возможные лимиты в paper-global.yml или, например, purpur.yml, лаг-машина всё равно может проскочить, ну и сломать сервер. Вопрос, почему?

• Ядро ограничивает общие вещи (к примеру, чанки, пакеты, сущности и тд.), но не умеет правильно определять именно опасные редстоун-механизмы, то есть лаг-машины
  
  
• Если поставить слишком жёсткие лимиты — сломаются нормальные фермы и всякие обычные редстоун-механизмы
  
  
• Без дополнительных плагинов сервер всё равно может просесть до 10-15 тпс, если в мире уже есть лаг-машина, а при грамотно построенной многослойной машине из куча разных редстоун-схем, сервер просто ляжет

Именно поэтому ядро — это только самая база (около 30–40 % защиты), реальную защиту могут дать определённые плагины, которые на это нацелены

---

2. Реальная защита — комбинированный подход:

Сейчас я расскажу о трёх уровнях защиты, которые сейчас я буду делать:

• Шаг #1: Настройка ядер (Paper + Purpur)
• Шаг #2: You must be logged in to see this link. + You must be logged in to see this link. + You must be logged in to see this link.
• Шаг #3: You must be logged in to see this link.
• Шаг #4: You must be logged in to see this link.

Все эти плагины бесплатные, лёгкие в настройке, не конфликтуют друг с другом и работают на наших нужных версиях версиях 1.16–1.21.11

Шаг #1: Изменения в paper-global.yml:

Сначала настроим параметр chunk-loading и packet-limiter — это два очень важных места в файле paper-global.yml, которые почти напрямую убивают лаг-машины


Сначала давайте я разберу каждую строку по порядку, чтобы вы поняли, зачем мы это делаем и как это помогает против лаг-машин, но при этом не ломает обычные вещи:

• player-max-chunk-load-rate: 60.0 — Эта настройка ограничивает, сколько чанков игрок может загружать в секунду (по умолчанию было 100). Многие лаг-машины специально заставляют сервер быстро грузить и выгружать чанки через редстоун. Здесь мы снижаем до 60 — сервер перестаёт « захлёбываться », но обычное хождение по миру, например, и фермы почти не замечают разницы
  
  
• player-max-chunk-send-rate: 40.0 — Почти то же самое, но уже про отправку чанков игроку. Лаг-машины часто создают огромный поток данных. Ограничиваем до 40, что сильно снижает нагрузку на сеть и на CPU, при этом обычная игра остаётся плавная
  
  
• max-packet-rate: 400.0 — Ограничивает количество пакетов, которые игрок может отправлять серверу в секунду. Некоторые лаг-машины используют packet-флуд вместе с редстоуном. 400 — прям самая золотая середина, она защищает от спама, но и не трогает нормальные действия многих игроков

Шаг #1: Изменения в purpur.yml:

Теперь переходим к Purpur, здесь мы работаем точечно с блоками, сущностями и механиками, которые чаще всего используют в лаг-машинах


Всё также, давайте разберём каждый параметр:

• disable-drops-on-cramming-death: true — Когда сущность умирает от « крамминга » (это переполнение чанка), она не дропает выпавшие с неё лут. Лаг-машины часто спамят стойками для брони или другими сущностями — а эта настройка убирает лишние дропы и сильно снижает нагрузку на сервер
  
  
• can-movement-tick: false — Запрещает стойкам для брони обрабатывать движение каждый тик. Многие лаг-машины именно через стойки для брони создают энтити-спам. Эта строчка их мгновенно убирает, но и обычные статичные стойки для брони работают как раньше
  
  
• transfer-cooldown: 8 — Замедляет скорость передачи предметов между воронками (по умолчанию было 4). Это сильно ослабляет различные петли воронок и бесконечные циклы воронок — достаточно популярные лаг-машины 2025–2026 годов. Обычные механизмы по сортировке предметов и фермы продолжают работать, просто чуть медленнее (разница почти незаметна для игроков), но самое печальное, что могут сильно сломаться кулдаун-механизмы, связанные с тем, что механизм будет активироваться только тогда, когда пройдут из одной воронки в другой все предметы
  
  
• entity: 50 — Если какая-то сущность (моб, предмет, вагонетка и тд.) тратит больше 50 миллисекунд на один тик, сервер автоматически её убивает. Это жёстко режет энтити-спам и сложные машины, которые заставляют сервер захлёбываться от слишком тяжёлых сущностей, которые находятся в одном месте в огромном количестве. При этом неопасные мобы и фермы почти не пострадают

Эти изменения в purpur.yml — это та самая « тонкая » защита, которая не ломает ничего полезного, но реально « душит » большинство лаг-машин ещё на уровне ядра

Шаг #1: Изменения в paper-world-defaults.yml:


Это ключевой параметр, который многие пропускают. Он меняет саму реализацию редстоуна на более эффективную. Если более подробно, это альтернативная реализация редстоуна от разработчика SpaceWalker, она умнее считает обновления блоков, особенно при работе с редстоун-механизмами: редстоуном, наблюдателями, повторителями и поршнями. На практике классические лаг-машины, созданные при помощи редстоун-механизмов теряют 50-80% своей эффективности, а обычные механизмы продолжают работать корректно

Шаг #2: You must be logged in to see this link., You must be logged in to see this link. и You must be logged in to see this link. — Тройная точечная защита

Все эти плагины очень важны в нашей связке, но есть небольшая проблема, что один из них, а именно AntiRedStoneLag, доступен только с версии 1.21, а форк LagAssist и CoreDefender уже доступны с 1.16 по 1.21. Так что у нас могут быть два варианта событий для разных версий: если у вас версия сервера 1.21 и выше, то однозначно стоит поставить и AntiRedstoneLag, и CoreDefender, а если ниже, то лучше оставить только LagAssist с CoreDefender. Вообще эти плагины специально созданы для того, чтобы отслеживать и останавливать редстоун лаг-машины, так что они идеально нам помогут

Поэтому, если ваш сервер стоит на версии ниже, чем 1.21, то для вас я подготовил настроенные некоторые параметры файла server.yml плагина LagAssist для лучшей работы:


Но, если ваш сервер использует, версию выше, чем 1.21, то вот вам подготовленные и настроенные части параметров конфигураций плагинов LagAssist, AntiRedStoneLag и CoreDefender:

Файл server.yml плагина LagAssist:


Конфиг плагина AntiRedstoneLag целиком:


Изменённые части параметров конфига плагина CoreDefender:


* Но не забывайте, что если у вас крупный сервер с большим онлайном, который при этом стоит на 1.21, то я советую оставить только AntiRedStoneLag с CoreDefender, так как LagAssist и AntiRedStoneLag и так хорошо бьют по лаг-машинам, но вместе они дают небольшую избыточную нагрузку. Так что лучше именно оставить и AntiRedStoneLag, и CoreDefender, так как они вместе намного мощнее работают, чем тот же LagAssist с CoreDefender. А что именно выбирать — это уже ваше дело, своё мнение я сказал

Шаг #3: You must be logged in to see this link. — Всесторонний оптимизатор + встроенный редстоун-лимитер

Теперь давайте поговорим про второй очень важный плагин в нашей связке — LagFixer. Если AntiRedstoneLag работает как точечный снайпер по редстоуну, разрушающий лаг-машины, то LagFixer — это настоящий тяжёлый плагин-оптимизатор, который берёт на себя сразу несколько задач. Он ограничивает сущности в чанках, чистит мир от мусора, включает умную систему LagShield и имеет свой встроенный лимитер редстоуна

Плагин полностью бесплатный, очень лёгкий и уже давно стоит на тысячах серверов. Самое удобное в нём то, что почти всё можно настраивать прямо в игре, не заходя ни в какие конфиги. После установки плагина можно просто прописать команду /lagfixer menu, и откроется красивая менюшка со всеми настройками. Там можно увидеть переключатели для каждого модуля, можно сразу включать или выключать нужные части, менять лимиты с помощью кнопок

Шаг #4: Spark — главный инструмент мониторинга

Чтобы вся эта защита работала максимально точно, стоит поставить дополнительный очень мощный плагин Spark. Он не блокирует лаг-машины сам по себе, но именно он помогает их быстро находить и понимать, где именно прячется проблема. Я думаю, что многие и так знают или хотя бы слышали о нём, но всё равно расскажу как с ним работать и находить лаг-машины
Самая полезная команда для этого — /spark profiler. Запускаем её на 15–30 секунд в момент просадки Тпс сервера или когда подозреваешь наличие лаг-машины. Spark записывает нагрузку и выдаёт максимально подробный отчёт, жаль только на английском, который можно открыть прямо в браузере по ссылке. В этом отчёте сразу видно самые « горячие » чанки, а именно те, где происходит наибольшее количество, например, обновлений редстоуна, ну или других блоков. Ты можешь увидеть точные координаты чанка, где расположена возможная лаг-машина, сколько обновлений редстоуна там происходит и какие именно блоки или механизмы создают наибольшую нагрузку. То есть сам по себе плагин, идёт как дополнительный, чтобы точно не пропустить никакую лаг-машину

---

3. Почему именно эта связка, а не другие плагины?

Это важный момент, который я хочу прояснить. Многие владельцы серверов, узнав и увидив проблему с лаг-машинами, сразу начинают ставить много, прям очень много разных анти-лаг плагинов, например, ClearLagg, RedstoneLimiter, FarmLimiter, EntityStacker, NoLag и куча других похожих. На первый взгляд кажется, что чем больше защиты — тем лучше, но на практике это почти всегда приводит, к сожалению, к обратному результату

Вот почему не стоит набирать кучу похожих и однообразных плагинов плагинов:

• Каждый дополнительный плагин добавляет свою нагрузку на сервер. Они все отслеживают одни и те же события (обновления блоков, тики сущностей, редстоун-схемы, механизмы и тд.), и из-за этого сервер начинает тратить лишние силы впустую, нагружая самого себя
  
  
• Разные плагины могут реагировать на одну и ту же ситуацию по-разному: один отключит редстоун, второй сломает блок, третий попробует что-то заспавнить. В итоге вместо стабильности получаешь новые проблемы и нестабильности
  
  
• Слишком агрессивные плагины часто ломают обычные фермы, там, автоматические какие-то двери, сортировщики и другие полезные механизмы, которые игроки используют у себя. В результате этого игроки начинают жаловаться, что всё перестало работать. А звучит это так себе
  
  
• Чем больше плагинов, тем сложнее понять, какой именно из них виноват, когда Тпс всё-таки просел. Приходится отключать их по одному и каждый раз перезагружать сервер для теста — на это уходит много времени и сил

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

---

4. Вывод и конец

Думаю, можно прийти к следующему: для защиты сервера, конечно, можно поставить специальные плагины, но ещё и без настройки конфигурации ядра не обойтись

---

Итак, я думаю, что можно на этом можно закончить руководство. Честно, пока я сам всё писал и изучал, я для себя столько нового узнал, да и надеюсь, прочтя руководство, вы для себя может быть тоже что-то новое и интересное нашли. Как вам руководство? Критикуйте, говорите что хотите, так как в некоторых местах я могу ошибаться, ну и в целом буду частенько дополнять его, например, настройками плагинов и ядер