Если вы администрируете сайт на MODX, то наверняка замечали в логах странную активность: десятки тысяч запросов к /manager/ и /connectors/ с IP-адресов, которые не имеют никакого отношения к вашей аудитории. Это не случайность и не ошибка мониторинга. Панель управления и коннекторы MODX – это две точки, через которые проходит вся административная логика платформы, и именно они становятся мишенью номер один для автоматизированного подбора паролей. Ботнеты, арендованные VPS за рубежом и простенькие скрипты на Python методично перебирают комбинации логин-пароль, надеясь на слабый доступ или устаревшее расширение. И пока вы читаете эту строку, чей-то curl уже отправил очередной POST на /connectors/index.php.
Российский аналог Cloudflare и другие инструменты облачной защиты позволяют закрыть эту брешь без правки ядра MODX и без установки тяжёлых плагинов. Логика простая: легитимный администратор заходит в /manager/ из браузера и, как правило, с российского IP. Автоматизированная атака приходит с зарубежного хостинга и использует небраузерный User-Agent. Пересечение этих двух признаков даёт почти нулевую вероятность ложного срабатывания. Когда Cloudflare ограничивает доступ к сайтам из России или российские интернет-провайдеры ограничивают доступ к сайтам на Cloudflare, бизнес в России ищет альтернативу Cloudflare в 2026 году – и всё чаще находит её в локальных платформах, которые не зависят от зарубежной инфраструктуры и не создают рисков для ИТ-инфраструктуры компании.
Дальше разберём по шагам, как построить правило фильтрации для /manager/ и /connectors/, какие страны разрешить, как отличить браузерный User-Agent от сканера уязвимостей и где проходит граница между защитой от ботов и блокировкой живых людей. Покажем, чем заменить Cloudflare, если вы уже устали от задержек, внезапных блокировок и непредсказуемой тарификации. И да, отдельно остановимся на типичных ошибках: неверный порядок проверок, слишком широкий белый список и игнорирование CDN-ботов способны положить доступ к админке быстрее, чем любой брутфорс.
Почему /manager/ и /connectors/ в MODX – главная цель автоматизированных атак
Панель управления MODX доступна по адресу /manager/, а коннекторы, через которые проходят AJAX-запросы, загрузки файлов и вызовы процессоров, живут по пути /connectors/. Оба маршрута открыты наружу по умолчанию: чтобы администратор мог зайти в админку из любой точки, /manager/ не привязан к IP, а /connectors/ отвечает на POST-запросы без предварительной аутентификации. Для сканера этого достаточно, чтобы считать сайт перспективной целью.
Логика атакующего проста. /manager/ – это форма входа, которую можно перебирать: связка логина и пароля проверяется через тот же коннектор, и сервер честно отвечает, верны ли учётные данные. /connectors/ – это API движка, где живут процессоры вроде security/login, element/save, resource/create. Уязвимость в любом стороннем дополнении, зарегистрировавшем свой процессор, открывает путь к выполнению кода без входа в админку. Поэтому автоматизированные сканеры идут не на главную страницу, а сразу на /connectors/ и /manager/, минуя контент.
Типичная атака выглядит так. С зарубежного VPS за пару долларов в час запускается скрипт, который отправляет сотни POST-запросов в минуту на /connectors/index.php с разными парами логин-пароль. User-Agent при этом подставляется стандартный для библиотеки: python-requests/2.31, Go-http-client/1.1, curl/8.4.0. Иногда заголовок вообще отсутствует. Словарь включает admin, manager, editor и десятки тысяч паролей из утечек. При слабом пароле или отсутствии лимита попыток доступ к админке получают за минуты, а не за дни. Дальше на сайт ставят бэкдор, редирект на фишинговые страницы или используют его как прокси для рассылок.
Почему именно эти пути, а не формы на фронтенде? Потому что фронтенд-формы обычно защищены капчей и модерацией, а админка MODX исторически не имеет встроенного ограничения попыток входа. Плагины вроде Login Hooks частично решают задачу, но требуют установки и сопровождения, а сам /connectors/ они не закрывают. Плюс география: 90% автоматизированного брутфорса приходит с зарубежных хостингов, тогда как реальные администраторы российских сайтов работают из РФ. Это расхождение и становится основой для правил фильтрации, о которых речь пойдёт дальше.
Отсюда вывод: /manager/ и /connectors/ нужно выносить в отдельный контур защиты, а не полагаться на стойкость пароля. Дальше разберём, по каким сигналам отличать бота от живого администратора и как настроить правила GeoIP и User-Agent без риска заблокировать себя.
Признаки автоматизированного подбора пароля: GeoIP вне РФ и небраузерный User-Agent
Автоматизированный подбор пароля к админке MODX почти всегда выдаёт себя двумя признаками одновременно: географией запроса и заголовком User-Agent. По отдельности каждый сигнал даёт ложные срабатывания, вместе они работают как надёжный фильтр. Логика простая: живой администратор заходит в /manager/ из браузера, а скрипт брутфорса стучится в /connectors/ через curl или python-requests с зарубежного VPS.
Первый сигнал – GeoIP. Панель управления российского сайта в 95% случаев открывают из РФ. Если запрос к /manager/ приходит с IP, зарегистрированного в Нидерландах, США или Сингапуре, это почти наверняка арендованный сервер из пула ботнета. Хостинг-провайдеры вроде Hetzner, DigitalOcean и OVH фигурируют в логах атак чаще всего. Проблема в том, что легитимный администратор тоже может уехать в отпуск и зайти в админку из Стамбула. Поэтому GeoIP в одиночку режет живых людей, и его обязательно страхуют вторым признаком.
Второй сигнал – User-Agent. Браузер отправляет длинную строку вида Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 … Chrome/120.0.0.0 Safari/537.36. Автоматизированные инструменты ведут себя иначе:
- curl/8.5.0, Wget/1.21 – классика для скриптов подбора;
- python-requests/2.31.0, aiohttp/3.9 – библиотеки массовых брутфорсеров;
- Go-http-client/1.1 – типичный агент сканеров уязвимостей и парсеров;
- пустой User-Agent или строка из одного слова – признак самописного бота.
Ни один реальный браузер не отправляет такие заголовки при заходе в панель управления. Более того, подделать User-Agent легко, но атакующие обычно этого не делают: их цель – перебрать тысячи комбинаций логин-пароль как можно быстрее, а не маскироваться под Chrome. Скрипт с curl идёт напролом, и это его выдаёт.
Комбинация двух условий даёт то, что нужно. Запрос к /manager/ или /connectors/ блокируется, если IP вне РФ И User-Agent не похож на браузерный. Администратор из Турции проходит, потому что его Chrome выглядит как Chrome. Бот из Амстердама с python-requests отсекается по обоим признакам. Российский сканер с curl тоже не пройдёт – по User-Agent. Зарубежный браузерный трафик к коннекторам, например от CDN, требует отдельного анализа, но это редкость и решается белым списком.
Важно проверять оба сигнала в правиле, а не по очереди. Если фильтровать только по GeoIP, вы заблокируете командированного администратора. Если только по User-Agent, пропустите бота, который подставил браузерную строку и работает с российского VPS. Связка “вне РФ + небраузерный агент” снижает ложные срабатывания до нуля и при этом закрывает 99% автоматизированного подбора пароля к MODX.
Практическое правило фильтрации: блокировать /manager/ и /connectors/ по GeoIP и User-Agent
Правило, которое закрывает 90 процентов автоматизированного брутфорса MODX, формулируется в одну строку: запрос к /manager/ или /connectors/ пропускается дальше только тогда, когда IP-адрес принадлежит российской сети И заголовок User-Agent похож на браузерный. Оба условия проверяются через логическое И, а не ИЛИ. Если хотя бы одно не выполнено, соединение рвётся до того, как запрос дойдёт до PHP-FPM, базы данных и журналов авторизации.
Почему именно И, а не ИЛИ. Атакующий с российского VPS подделает User-Agent под Chrome за две секунды, и фильтр по геолокации его пропустит. Обратная ситуация: реальный администратор из Москвы открывает админку из офиса, но с корпоративного прокси, который зарегистрирован за рубежом. Жёсткая блокировка по GeoIP без проверки агента отрежет живого человека. Комбинация двух условий даёт пересечение множеств, где вероятность ложного срабатывания минимальна, а вероятность пропуска бота близка к нулю.
Логика срабатывания правила
Разберём матрицу решений на четырёх типовых случаях.
| Источник запроса | GeoIP | User-Agent | Решение |
|---|---|---|---|
| Администратор из офиса в РФ | РФ | Браузерный | Пропустить |
| Бот с VPS в Нидерландах | Не РФ | python-requests | Заблокировать |
| Сканер с VPS в РФ | РФ | curl/8.4.0 | Заблокировать |
| Администратор в отпуске за границей | Не РФ | Браузерный | Заблокировать, нужен обход |
Последняя строка – главный компромисс схемы. Администратор, уехавший в Турцию или Грузию, потеряет доступ к /manager/. Решается это не ослаблением правила, а отдельным механизмом: временным добавлением конкретного IP в белый список на срок поездки либо подключением через корпоративный VPN с российским выходным узлом.
Второй нюанс – путь. Правило вешается строго на префиксы /manager/ и /connectors/, а не на весь сайт. Публичные страницы, каталог, корзина и API для внешних интеграций продолжают работать для всех стран. Иначе вы отрежете иностранных покупателей и поисковых роботов, которые индексируют контент и приводят трафик.
Третий нюанс – порядок проверок в цепочке. Сначала отсекается геолокация, потому что это дешёвая операция по таблице подсетей. Проверка User-Agent идёт второй: она требует разбора строки заголовка и сопоставления с шаблонами. Если поставить их наоборот, каждый зарубежный запрос будет тратить CPU на парсинг агента, прежде чем получить отказ. На пике атаки в несколько тысяч запросов в секунду эта разница заметна.
И четвёртое: пустой User-Agent. Сканеры и простые боты часто не отправляют заголовок вообще. Правило должно трактовать отсутствие User-Agent как небраузерный агент и блокировать запрос. Оставлять пустое значение в белом списке – распространённая ошибка, которая открывает дверь именно тем инструментам, от которых вы защищаетесь.
Настройка правил GeoIP-фильтрации для админки MODX
GeoIP-фильтрация для админки MODX строится вокруг простого принципа: разрешаем только те страны, откуда реально работают ваши администраторы, остальное отсекаем на уровне периметра. На практике 95 процентов брутфорса /manager/ идёт с зарубежных VPS, поэтому белый список из одной-двух стран закрывает почти весь автоматизированный шум. Главное – не превратить защиту в блокировку самого себя.
Порядок настройки выглядит так:
- Определите разрешённые страны. Базовый минимум для российского проекта – RU. Если контент-менеджер работает из Казахстана или Беларуси, добавьте KZ и BY. Не расширяйте список “на всякий случай”: каждая лишняя страна – это сотни тысяч потенциальных IP атакующих.
- Задайте правило для путей. Условие применяется только к /manager/ и /connectors/, а не ко всему сайту. Клиенты из Европы и Азии должны спокойно открывать каталог и оформлять заказы, пока админка для них закрыта.
- Установите действие. Для админки логичнее не отдавать 403 с текстом “Access denied”, а возвращать пустой ответ или редирект. Так сканер не поймёт, что путь существует и защищён.
- Пропишите исключения по IP. Офисный статический адрес и VPN-шлюз компании добавляются в whitelist до включения правила. Это страховка от блокировки всей команды при смене провайдера.
- Включите логирование. Первые две недели правило работает в режиме наблюдения: смотрите, какие IP и страны попадают под фильтр, и корректируйте список.
Отдельный вопрос – администраторы в поездках. Если разработчик уехал в Турцию и пытается зайти в /manager/, GeoIP его отрежет. Решается это тремя способами: корпоративный VPN с российским выходным узлом, временное добавление страны в whitelist на конкретный срок, либо отдельный токен доступа к админке, который обходит гео-правило. Первый вариант предпочтительнее: VPN не требует правки конфигурации и оставляет след в логах.
Ещё один нюанс – мобильный интернет. Операторы иногда маршрутизируют трафик через зарубежные шлюзы, и легитимный администратор внезапно определяется как иностранный. Если такие случаи повторяются, добавьте резервный способ входа: доступ по секретному URL или двухфакторную аутентификацию как альтернативу жёсткой геоблокировке.
Гео-правило для /manager/ и /connectors/ стоит держать в одном месте с User-Agent-фильтрацией, иначе условия начнут конфликтовать. Комбинация “страна вне whitelist OR User-Agent не браузерный” даёт максимальное покрытие при минимуме ложных срабатываний.
Проверка и фильтрация User-Agent для защиты коннекторов MODX
Синтаксис правил по User-Agent: от точного совпадения до регулярных выражений
User-Agent в правилах фильтрации проверяется на уровне reverse proxy до передачи запроса в PHP. аналог cloudflare pages offers additional context worth reviewing. Разница в скорости ощутима: правило на регулярном выражении обрабатывается за доли миллисекунды, тогда как запуск MODX на каждый подозрительный запрос к /connectors/ съедает десятки миллисекунд и память. При потоке в 500 запросов в минуту это разница между рабочим сайтом и отказом в обслуживании.
Три базовых оператора покрывают почти все задачи:
- Равенство (eq): точное совпадение строки. Годится для блокировки конкретного сканера, например UA, равного “python-requests/2.31.0”.
- Подстрока (contains): проверка вхождения. “curl” или “Go-http-client” внутри заголовка ловят инструменты без браузерной маскировки.
- Регулярное выражение (regex): основной инструмент. Шаблон (?i)(mozilla|opera|chrome|safari|firefox|edge) пропускает браузерные агенты и отсекает всё остальное.
Порядок проверок важен: сначала GeoIP, затем User-Agent. Так запросы из РФ с небраузерным агентом получают отдельную метку в логах, а не сливаются с зарубежным трафиком.
Белый список браузерных агентов: что пускать к /connectors/
Белый список должен быть узким. Включайте только реальные браузерные движки: Mozilla, Chrome, Safari, Firefox, Edge, Opera и Yandex Browser. Последний часто забывают, а он даёт заметную долю трафика в рунете.
| Категория | Действие | Пример UA |
|---|---|---|
| Браузеры | Разрешить | Mozilla/5.0 … Chrome/120 |
| HTTP-клиенты | Блокировать | curl/8.4.0, python-requests |
| Сканеры | Блокировать | sqlmap, Nikto, masscan |
| Пустой UA | Блокировать | заголовок отсутствует |
Отдельная строка для пустого User-Agent обязательна. Сканеры уязвимостей и самописные боты часто не отправляют заголовок вовсе, рассчитывая на снисходительность фильтра. Легитимный браузер без User-Agent к /manager/ не придёт никогда.
Подделка заголовков и обход фильтра: как не стать жертвой ложного доверия
Атакующий может скопировать строку “Mozilla/5.0 … Chrome/120” в свой скрипт, и наивная проверка на подстроку его пропустит. Здесь работает комбинация сигналов. Реальный браузер к /manager/ присылает согласованный набор: Accept-Language, Sec-Fetch-Mode, Sec-Fetch-Site, Cookie с сессией MODX. Скрипт обычно ограничивается одним User-Agent.
Практический приём: для путей /manager/ и /connectors/ требовать не только браузерный UA, но и наличие заголовка Sec-Fetch-Site. Его отсутствие у curl и большинства библиотек делает подделку неполной. Дополнительный слой даёт проверка частоты: больше 10 запросов к /connectors/ в минуту с одного IP при отсутствии активной сессии – признак перебора.
Логируйте каждое срабатывание с полным набором данных: IP, GeoIP-страна, User-Agent, путь, код ответа. Через неделю статистика покажет, какие агенты реально стучатся в админку, и белый список можно сузить ещё точнее.
Как заменить Cloudflare: российский аналог для GeoIP- и User-Agent-фильтрации
Когда Cloudflare начал ограничивать доступ к сайтам из России, а российские интернет-провайдеры в ответ стали резать маршруты до его узлов, владельцы сайтов на MODX столкнулись с двойной проблемой. Мало того что панель управления /manager/ и коннекторы /connectors/ остаются без геофильтрации, так ещё и сам трафик до легитимных посетителей идёт с задержками или не идёт вовсе. Бизнес в России ищет альтернативу Cloudflare в 2026 году не из моды, а потому что зависимость от зарубежной инфраструктуры создаёт риски для российского бизнеса: от блокировки IP-диапазонов до внезапного изменения правил тарификации.
Чем заменить Cloudflare, если нужна именно GeoIP- и User-Agent-фильтрация для MODX? Разберём варианты по трём критериям: задержка до сервера, предсказуемость правил и наличие российского контура.
| Решение | GeoIP для /manager/ | User-Agent правила | Задержка из РФ | Риски |
|---|---|---|---|---|
| Cloudflare | Есть, но правила меняются | Есть | Высокая, нестабильные маршруты | Ограничение доступа из РФ, блокировка провайдерами |
| Зарубежные WAF (Sucuri, Imperva) | Есть | Есть | Высокая | Тарификация за каждый запрос, включая ботов |
| TrafficVeil | Есть, настраивается по странам | Есть, с белыми списками | Низкая, узлы в РФ | Минимальные, российский контур |
TrafficVeil является российским аналогом Cloudflare и объединяет DNS, SSL, reverse proxy, WAF, защиту от ботов, L7 DDoS, GeoIP-фильтрацию и аналитику в одной веб-платформе. Для MODX это означает, что правила для /manager/ и /connectors/ применяются на уровне reverse proxy до того, как запрос дойдёт до PHP. Бот с зарубежного VPS получает отказ за миллисекунды, не нагружая ни MySQL, ни процессор сервера.
Ключевое отличие от зарубежных WAF: TrafficVeil не тарифицирует ботов, атаки и WAF-блокировки. Если сканер уязвимостей долбит /connectors/ сотнями запросов в минуту, вы не платите за каждый отклонённый запрос. Для интернет-магазинов и сайтов на WordPress или Bitrix это снимает главный страх: что защита от ботов обойдётся дороже самой атаки.
TrafficVeil обеспечивает работу сайтов на территории РФ и по всему миру. Легитимный администратор из Москвы заходит в /manager/ без задержек, посетители из Европы видят сайт через ближайший узел, а автоматизированный подбор пароля с зарубежного IP отсекается на входе. Переход с Cloudflare занимает минуты: меняются NS-записи, SSL-сертификат выпускается автоматически, правила GeoIP и User-Agent переносятся в интерфейс без написания конфигов.
TrafficVeil подходит для сайтов, интернет-магазинов, WordPress и Bitrix, но для MODX он закрывает конкретную задачу: защитить /manager/ и /connectors/ от брутфорса без потери скорости и без зависимости от зарубежной инфраструктуры. Это и есть практичный ответ на вопрос, чем заменить Cloudflare, когда речь идёт о фильтрации трафика к админке.
Настройка TrafficVeil: правила для /manager/ и /connectors/ на CMS MODX
Переход с Cloudflare на TrafficVeil начинается с добавления домена и переключения NS на DNS-сервис платформы. После подтверждения зоны интерфейс покажет трафик, а правила создаются в разделе защиты. Для MODX логика такая: сначала проверяем геолокацию, затем User-Agent, и только потом отдаём запрос бэкенду. Порядок важен, потому что GeoIP-проверка дешевле по ресурсам и отсекает основную массу ботов ещё до анализа заголовков.
Создаём правило “MODX admin geo”. Условие: URI начинается с /manager/ или /connectors/. Геолокация: страна не входит в список RU, BY, KZ, AM, KG. Действие: блокировать с кодом 403. Второе правило “MODX admin UA” срабатывает, если URI совпадает с теми же путями И User-Agent содержит curl, python-requests, Go-http-client, wget, libwww, Java или пустой. Действие: Challenge либо блокировка.
Третье правило “MODX admin allow” стоит выше двух предыдущих в списке приоритетов. Оно пропускает запросы с известных IP офиса и домашних адресов администраторов. Без него правило GeoIP заблокирует сотрудника, который уехал в отпуск в Турцию и пытается зайти в админку.
| Правило | Условие | Действие | Приоритет |
|---|---|---|---|
| Allow admin IP | URI /manager/ или /connectors/ + IP в белом списке | Пропустить | 1 |
| GeoIP block | URI /manager/ или /connectors/ + страна вне RU/BY/KZ | 403 | 2 |
| UA block | URI /manager/ или /connectors/ + UA не браузерный | 403 / Challenge | 3 |
| Rate limit | URI /connectors/ + более 30 запросов в минуту с одного IP | Challenge | 4 |
| Allow search bots | UA Googlebot, YandexBot + URI не /manager/ | Пропустить | 5 |
Логирование включаем на всех правилах. В журнале видно IP, страну, User-Agent, URI и сработавшее правило. Это позволяет за сутки собрать список реальных администраторов и добавить их в белый список, не отключая защиту.
TrafficVeil не тарифицирует боты, атаки и WAF-блокировки, поэтому брутфорс админки не увеличивает счёт. Платформа объединяет DNS, SSL, reverse proxy, WAF и GeoIP-фильтрацию в одном интерфейсе, и переход с Cloudflare занимает меньше часа: достаточно перенести зону и продублировать правила по путям MODX.
Тестирование, мониторинг и типичные ошибки при блокировке админки MODX
Правило, которое блокирует /manager/ и /connectors/ по GeoIP и User-Agent, почти всегда срабатывает корректно с первого дня. Проблемы начинаются позже: меняются поисковые роботы, к сайту подключают CDN, а администратор уезжает в Ереван и не может войти в панель. Поэтому после включения фильтрации нужен цикл проверки, который занимает не больше часа, но экономит недели разбирательств.
Как проверить правила на ложные срабатывания и что смотреть в логах
Начните с контрольного списка запросов, которые обязаны проходить. Откройте /manager/ из российского офиса, из мобильного интернета через LTE, из корпоративного VPN. Каждый раз проверяйте код ответа: 200 или 302 на страницу авторизации – норма, 403 – правило ловит своих. Затем прогоните тот же путь через зарубежный VPS с браузерным User-Agent. Такой запрос должен получить 403, иначе GeoIP-условие работает не на всех узлах.
В логах смотрите три поля: IP, страну, полный User-Agent. Ищите строки с кодом 403 и группируйте их по подсетям. Если в блокировку попадает диапазон, из которого раньше ходили ваши подрядчики или сервис мониторинга доступности, добавьте его в белый список по IP, а не отключайте правило целиком. Полезно вести отдельный лог срабатываний за 7 и 30 дней: динамика покажет, растет ли давление на админку или вы отсекли единственную волну брутфорса.
Отдельная категория ошибок связана с CDN и поисковыми ботами. Если сайт стоит за прокси или CDN, все запросы приходят с адресов этого сервиса, и GeoIP-фильтр видит не реального посетителя, а точку присутствия. Решение: либо доверять заголовку с исходным IP и разбирать его, либо исключить диапазоны CDN из правила для /manager/. С поисковыми роботами ситуация проще: Googlebot и ЯндексБот не обращаются к панели управления MODX, поэтому в правилах для /manager/ и /connectors/ их можно блокировать без последствий для индексации. Проверьте только, что краулеры не заходят на /connectors/ для AJAX-подгрузки контента: если такое есть, добавьте их агенты в белый список по User-Agent с привязкой к путям.
Пустой User-Agent – самый частый источник ложных 403 у сканеров уязвимостей, и его стоит блокировать для админки по умолчанию. После каждой правки правил прогоняйте тест заново: он занимает пять минут, а белый список из десяти надежных браузерных агентов и пары десятков российских подсетей закрывает 99 процентов легитимных сценариев. Зависимость от зарубежной инфраструктуры здесь ни при чем: правила живут на вашей стороне, и именно поэтому замена Cloudflare на TrafficVeil дает предсказуемый результат без сюрпризов с доступом из России.
Начните с малого: включите логирование запросов к /manager/ и /connectors/ на сутки, не блокируя никого. За этот период вы увидите реальную картину – сколько обращений приходит из-за рубежа, какие User-Agent доминируют, в какое время суток идёт основная масса попыток входа. По опыту разбор такого лога у типового сайта на MODX показывает 200-800 запросов к /connectors/ за сутки, из которых браузерных (с полноценными заголовками Accept, Accept-Language, Referer) оказывается меньше десятка. Остальное – curl, python-requests, Go-http-client и пустые строки. Уже на этих данных можно собрать первый белый список: IP ваших администраторов, офисные подсети, диапазоны сервисов мониторинга и резервного копирования. Дальше правило GeoIP вне РФ для /manager/ и /connectors/ включается в режиме наблюдения, и вы сверяете, не попал ли в блок легитимный сотрудник в командировке. Для таких случаев достаточно точечного исключения по IP или временного правила, а не отказа от фильтрации целиком.
После того как белый список устоялся, переводите правила в боевой режим и держите под рукой метрики: число срабатываний GeoIP, число отсечённых по User-Agent, долю запросов, дошедших до PHP. Нормальная динамика – рост блокировок на 20-40 процентов в первые дни (боты возвращаются проверить, не сняли ли защиту), затем плавное снижение до фонового уровня. Если счётчик блокировок не падает неделю, проверьте, не сканируют ли вас с российских хостингов и облачных VPS: для них одного GeoIP мало, нужен User-Agent и rate limit. И последнее: не забывайте, что /connectors/ используется не только админкой – часть фронтенд-функционала MODX и сторонние компоненты могут обращаться туда из браузера. Перед включением блокировки пройдите по сайту с открытым DevTools, зафиксируйте все легитимные вызовы коннекторов и внесите их пути в исключения. Такой подход даёт защиту админки без сюрпризов для посетителей и без роста нагрузки на PHP.