Это не одна настройка. XML-RPC — старый вход в PHP-файл. Application Passwords — отдельные пароли к REST API (и, если xmlrpc не закрыт, ещё и к нему же). Двухфакторка на wp-login.php вторую дверь не закрывает. Ниже — как я решаю, что оставлять, что резать на nginx, и где «плагин запретил xmlrpc» оставляет дыру, которой хватает боту.

Хосты в примерах вымышленные: shop.example. Свои пути, пользователя и префикс логов подставляйте.

Две двери, не «один API WordPress»

На живом сайте обычно торчат три способа что-то сделать «не из браузера»:

• /xmlrpc.php — XML-RPC. Методы вроде wp.getUsersBlogs, wp.newPost, pingback. Клиент шлёт логин и пароль в теле XML на каждый запрос.
• /wp-json/ — REST API. Gutenberg, приложение, ваш скрипт, куча плагинов. С WordPress 5.6 туда ходят Application Passwords через HTTP Basic Auth.
• /wp-login.php — человек в браузере. Сюда Application Password не подходит: это не замена пароля учётки для формы входа.

Путаница начинается здесь. Человек включает 2FA и считает, что «без телефона никто не войдёт». Для формы логина — да. Для xmlrpc, если он принимает основной пароль пользователя, второго фактора нет. Бот не открывает браузер и не вводит код из приложения.

Вторая путаница: «раз есть Application Passwords, xmlrpc больше не нужен, WordPress сам его выключит». Не выключит. Это разные стеки. Пароль приложения, если xmlrpc жив, подходит и туда: в документации ядра прямо сказано, что Application Password можно подставить вместо обычного пароля в XML-RPC. То есть вы завели «безопасный» токен для REST, а старый файл его тоже съест.

Третья: галочка в плагине «Disable XML-RPC». Часто это фильтр xmlrpc_enabled. Он отключает методы, которым нужна авторизация. Файл при этом открывается, PHP крутится, pingback и часть методов без логина могут отвечать. Для бота, которому нужно занять php-fpm, этого достаточно. Для меня критерий «закрыто» — nginx/apache не отдают этот URI в PHP, а не «в админке галочка зелёная».

Зачем xmlrpc вообще существует в 2026-м

Когда-то это был нормальный способ писать с телефона и цеплять Jetpack. Сейчас на большинстве витрин, которые мне отдают, в access.log по xmlrpc.php нет ни одного своего User-Agent. Есть словари паролей, system.multicall и pingback на чужие сайты.

Две атаки, из-за которых я не оставляю файл «на всякий случай»:

• Брутфорс пачкой. system.multicall в одном HTTP-запросе прогоняет десятки wp.getUsersBlogs с разными паролями. Лимитер по запросам на IP видит один POST. Лимит без закрытия multicall — полумера: словарь укладывается в один хит.
• Pingback как чужой молоток. Сайт принимает pingback.ping и сам идёт на URL, который подсунули. Либо участвует в отражённой нагрузке, либо светит внутренние адреса, если кто-то целится в SSRF. Даже без успешного логина файл уже не бесплатный.

Jetpack, официальное приложение WordPress старых версий, часть сервисов рассылки и редкие десктопные клиенты xmlrpc ещё используют. Поэтому я не ставлю deny all вслепую на проде, пока не посмотрел неделю логов. Но «вдруг пригодится» — не причина держать вход, который умеет перебирать пароль администратора без 2FA.

Что такое Application Passwords на практике

С WordPress 5.6 у пользователя в профиле появляется блок «Пароли приложений». Вы даёте имя («backup-bot», «магазин-контент», «телефон редактора»), ядро показывает 24 символа один раз, дальше пароль лежит хешем в user meta. Пробелы в отображении можно не копировать — перед проверкой их срезают.

Зачем это, если «и так есть пароль админа»:

• Основной пароль не разъезжается по скриптам, телефону и подрядчику. Сменили пароль учётки после увольнения — бот с Application Password продолжает жить, пока его явно не отозвали. Это и плюс, и минус: ротация учётки дыру не закрывает.
• Отзыв точечный. Удалили один пароль — отвалилось одно приложение, редактор в браузере не вылетел.
• 2FA на логине можно держать жёсткой. Скрипту второй фактор не нужен, человеку — нужен. Раньше из-за xmlrpc люди 2FA не включали: «приложение не зайдёт».
• В профиле видно, когда пароль последний раз использовали и с какого IP. Не в реальном времени до секунды, с задержкой примерно до суток, но «висит полгода, last used — никогда» уже повод снести.

Ходят они по HTTPS Basic Auth: логин учётки плюс этот пароль. Без HTTPS ядро по умолчанию блок даже не показывает: иначе пароль утечёт на первой же кофейне. Если сайт за прокси и WordPress думает, что он на http, в профиле пусто. Тогда сначала чинят HTTPS/X-Forwarded-Proto, а не «включают фильтр разрешить без SSL». Разрешить Application Passwords по http — сознательно оставить секрет в открытую на участке до прокси.

Права у такого пароля — права пользователя, не «только читать посты». Завели под администратором — получили администратора. Для заливки черновиков мне хватает роли автора или редактора и отдельной учётки, не «ещё один токен на admin».

Как я смотрю, кто чем пользуется

Пока нет картины за несколько дней, я ничего не отключаю на живом магазине. Сначала логи, потом решение.

Nginx, если access_log в обычном combined:

# пути к логам подставьте свои
awk '$7 ~ /xmlrpc\.php/ {print $1,$4,$9,$11}' /var/log/nginx/shop.example.access.log | tail -n 50
awk '$7 ~ /xmlrpc\.php/ {c[$1]++} END {for (i in c) print c[i], i}' /var/log/nginx/shop.example.access.log | sort -n | tail
awk '$7 ~ /wp-json\// {print $1,$9,$7}' /var/log/nginx/shop.example.access.log | awk '{print $3}' | sort | uniq -c | sort -n | tail

Что я хочу увидеть:

• По xmlrpc: либо пусто, либо одни и те же /24 из сканеров, статус 200 на POST. Свой телефон обычно один-два IP, предсказуемый интервал, не 400 запросов в минуту.
• User-Agent. Jetpack и приложение WordPress не маскируются под Mozilla/5.0 с кривой кодировкой. Сканеры часто пишут xmlrpc, пусто или «WordPress» без версии.
• По REST: Gutenberg с админки будет, это норма. Смотрю, есть ли POST/PUT с внешних IP на /wp-json/wp/v2/posts или media. Если есть — это живой клиент, его нельзя убить вместе с xmlrpc.

Проверка «файл вообще отвечает», не из лога:

curl -sS -D - -o /dev/null https://shop.example/xmlrpc.php
curl -sS https://shop.example/xmlrpc.php \
  -H 'Content-Type: text/xml' \
  -d '<?xml version="1.0"?><methodCall><methodName>system.listMethods</methodName></methodCall>' | head

200 и список методов — дверь открыта, даже если «плагин безопасности установлен». 403/404 с nginx без X-Powered-By и без тела PHP — уже похоже на правду.

REST и доступность Application Passwords:

curl -sS https://shop.example/wp-json/ | python3 -m json.tool | head
# в корне смотрю ключ authentication.application-passwords
curl -sS -u 'editor:xxxx xxxx xxxx xxxx xxxx xxxx' \
  https://shop.example/wp-json/wp/v2/users/me

Если в корне authentication пустой — либо HTTP, либо фича выключена фильтром, либо что-то по дороге срезает заголовок Authorization. Последнее на nginx с PHP-FPM встречается: CGI не пробрасывает Authorization, пока не сказать.

# внутри location ~ \.php$
fastcgi_param HTTP_AUTHORIZATION $http_authorization;

Без этой строки «пароль приложения не работает, а обычный логин в браузере живой» — не баг WordPress, а FPM не видит Basic Auth.

Если xmlrpc никому не нужен — режу на веб-сервере

Это мой дефолт для витрины без Jetpack и без старого мобильного клиента. Фильтр в теме — вторым слоем, не вместо.

# server { ... }
location = /xmlrpc.php {
    access_log /var/log/nginx/shop.example.xmlrpc.denied.log;
    return 403;
}

deny all или return 444 тоже работают. Мне удобнее 403 и отдельный лог: сразу видно, что сканеры не исчезли, просто больше не крутят PHP. На Apache в корне сайта или в конфиге хоста:

<Files xmlrpc.php>
    Require all denied
</Files>

Правило на WAF (если он есть) дублирует, не заменяет. Когда человек правит только Cloudflare и забывает origin, прямой IP сервера xmlrpc снова открыт.

После рестарта nginx проверяю тем же curl: не 200 со списком методов, а 403 без text/html от WordPress. Затем на час оставляю отдельный лог — если вдруг вылезет свой клиент, это будет видно по IP, а не «через неделю редактор звонит, что приложение молчит».

Плагины «выключить xmlrpc» я не ставлю как основную защиту. Лишний PHP на периметре, плюс половина из них делает только xmlrpc_enabled.

Почему xmlrpc_enabled я не считаю закрытием

В functions.php или mu-plugin часто копируют:

add_filter( 'xmlrpc_enabled', '__return_false' );

Это отключает авторизованные методы. Запрос всё равно доходит до WordPress: php-fpm воркер занят, плагины загрузились, объектный кеш дёрнули. Pingback на части сборок остаётся в списке. Сканер с system.multicall получает отказ, но уже после входа в PHP.

Если xmlrpc по какой-то причине оставляю, вычищаю хотя бы multicall и pingback:

<?php
// mu-plugins/disable-xmlrpc-extras.php
add_filter( 'xmlrpc_methods', function ( $methods ) {
    unset( $methods['system.multicall'], $methods['system.multitask'] );
    unset( $methods['pingback.ping'], $methods['pingback.extensions.getPingbacks'] );
    return $methods;
} );

Это не «можно не закрывать файл». Это минимум, если Jetpack реально нужен и закрыть location нельзя. Плюс лимит запросов на этот URI отдельно от admin-ajax.php — иначе снова либо дыра, либо свои ловят 429.

Когда xmlrpc оставляю

Короткий список, не «все интеграции»:

• Jetpack и связанные сервисы Automattic, если они включены сознательно, а не «поставили и забыли».
• Старое официальное приложение WordPress, которое ещё ходит в xmlrpc, а не в REST. Новые клиенты умеют Application Passwords и REST — их я перевожу.
• Редкий десктопный клиент публикации, который заказчик не готов менять сегодня.

Если оставляю, пароль приложения завожу под отдельным пользователем с нужной ролью, основной пароль этой учётки длинный и никуда не светится, 2FA на человеческих админах включена. xmlrpc тогда принимает Application Password, и утечка основного пароля админки не даёт боту этот вход. Обратное тоже верно: утечка пароля приложения — это вход в API с правами этой учётки, пока не отозвали.

Белый список IP на xmlrpc.php лучше, чем открытый мир. Для Jetpack это набор адресов Automattic, он плавает; без WAF с готовым правилом я не рисую его руками «по памяти» и не выкладываю чужие схемы. Практичнее: либо официальное правило у CDN, либо закрыть xmlrpc и жить на REST.

Application Passwords: заводить, не размножать, уметь выключить

Правила, без которых я токен не создаю:

• Одно приложение — один пароль. Не «один на все скрипты», чтобы потом не гадать, какой cron его светит.
• Имя в профиле человеческое: rsync-report bot, iPhone редактор, не test и не 1.
• Учётка с минимальной ролью. Для черновиков не нужен администратор. Для медиа — часто хватает автора.
• Пароль копирую в секрет хранилища один раз. В чат, в тикет и в тело статьи его не кладут. В логах nginx он не должен появиться: Basic Auth лучше не писать в access_log.
• Раз в квартал смотрю last used. Не использовался — удаляю, не «вдруг пригодится».

Через WP-CLI, если SSH есть:

cd /var/www/shop.example/public_html
wp user list --fields=ID,user_login,roles
wp user application-password list editor --fields=uuid,name,created,last_used,last_ip
# создать и сразу забрать только секрет, без таблицы
wp user application-password create editor 'content-bot' --porcelain
# отозвать по uuid из списка
wp user application-password delete editor 00000000-0000-4000-8000-000000000000

Если Application Passwords на сайте никто не использует (нет мобильного клиента, нет внешних скриптов, черновики пишут руками), я их выключаю. Иначе любой администратор может завести себе токен, а через дырявый плагин или XSS это делают уже не только администраторы.

<?php
// mu-plugins/disable-application-passwords.php
add_filter( 'wp_is_application_passwords_available', '__return_false' );

Точечно, только выбранным ролям:

<?php
add_filter( 'wp_is_application_passwords_available_for_user', function ( $allow, $user ) {
    if ( $user instanceof WP_User && in_array( 'administrator', (array) $user->roles, true ) ) {
        return $allow;
    }
    return false;
}, 10, 2 );

Выключить и забыть отозвать уже выданные пароли — мало. Фильтр закрывает новые и использование, но я всё равно прохожусь по списку и удаляю старые: меньше сюрпризов, когда фильтр кто-то снимет «чтобы приложение заработало».

REST я не вырубаю «за компанию»

После статьи про xmlrpc находится человек, который в плагине безопасности ставит Disable REST API. Gutenberg после этого рисует белый экран, кастомайзер полуживой, часть блоков не сохраняется. REST — не xmlrpc. Это штатный транспорт админки.

Что я ограничиваю, не выключая REST целиком:

• Публичный список пользователей. На многих сайтах GET /wp-json/wp/v2/users без авторизации отдаёт логины. Для брутфорса это подарок: не надо угадывать admin. Плагин безопасности или маленький mu-plugin, который на rest_authentication_errors закрывает users для анонимов, — нормальная гигиена. Слепой «REST off» — нет.
• Лимит на /wp-json/ на краю, отдельно от html, если вижу перебор. Не общий location ~ \.php$.
• Не торчит ли создание Application Passwords для всех ролей, если фича нужна только админу.

Проверка, светит ли сайт логины:

curl -sS 'https://shop.example/wp-json/wp/v2/users' | python3 -m json.tool | head

Если в ответе массив с slug — аноним уже знает, кого подбирать. Это не «дыра нулевого дня», это дефолт, который я закрываю в тот же вечер, что и xmlrpc.

Какие комбинации я считаю нормальными

Свожу к трём схемам, без зоопарка галочек.

1. Витрина, правки из браузера, нет Jetpack, нет внешних ботов. xmlrpc на nginx 403. Application Passwords выключены фильтром. 2FA на администраторах. REST живой, список users для гостя закрыт. Это большинство сайтов, которые мне отдают «просто посмотрите безопасность».
2. Нужен скрипт или телефон. xmlrpc всё равно 403, если клиент умеет REST. Одна учётка с ролью по задаче, один Application Password, HTTPS доведён до ядра, Authorization проброшен в FPM. Основной пароль этой учётки не совпадает с паролем приложения и никуда не записан в cron.
3. Jetpack или старый клиент, без них пока никак. xmlrpc открыт, multicall и pingback сняты, лимит на URI, по возможности ограничение по источнику на WAF. Пароли приложений для этого клиента, не основной пароль админа. Остальным пользователям Application Passwords не светятся.

Схема, которую я снимаю сразу: 2FA «для галочки», xmlrpc открыт на мир, в cron лежит основной пароль администратора, в профиле три пароля приложения с именами test/test2/asdf, REST отдаёт users. Это не «чуть-чуть не донастроили». Это три входа с одним секретом и одним без второго фактора.

Что проверить за ночь, а не сразу закрыть ноутбук

После изменений я не верю одному curl с ноутбука. За ночь видно, не отвалился ли свой клиент и не начал ли сканер долбить соседнюю дверь.

• Отдельный лог 403 по xmlrpc: есть чужие POST, нет 200 в php-fpm slowlog по этому файлу.
• В access.log нет всплеска 401/403 на /wp-json/wp/v2/ с офисного IP. Если есть — вы закрыли не то, или срезали Authorization.
• Админка открывается, запись сохраняется, медиа грузится. Gutenberg ходит в REST; если его прибили, узнаете утром от редактора, не из мониторинга.
• wp user application-password list по всем, у кого не пусто: имена понятные, last_ip свой, лишние удалены.
• Повторный curl на /wp-json/wp/v2/users без куки — не список логинов.
• Плагин безопасности не включил обратно xmlrpc своим «режимом совместимости» и не выключил REST. После обновления плагинов это проверяю отдельно.

Если за ночь в xmlrpc-логе вдруг свой IP приложения — не открываю файл обратно «как было», а перевожу клиент на REST и Application Password. Старый xmlrpc ради одного телефона на витрине с заказами я оставляю только когда перевод реально нельзя сделать сегодня, и тогда это временная схема с датой, а не новая норма.

Лимит сработал. Просто он отстрелил своих вместе с ботами. Офис сидит за одним белым IP, xmlrpc дергает приложение каждые несколько секунд, а общий php-location обслуживает и логин, и admin-ajax.php, и оформление заказа.

Ниже — как я режу именно логин и xmlrpc, оставляя сайт живым, и где limit_req бесполезен, сколько его ни крути. Без «поставьте плагин лимита логинов» и без слепого deny all на xmlrpc, пока не ясно, кто им пользуется.

Что бьют на самом деле, и почему это две разные двери

На типичном WordPress без WAF смотрят три URL:

• /wp-login.php — форма входа. GET рисует форму, POST проверяет пароль.
• /xmlrpc.php — старый API. С него удобно перебирать пароли пачками через system.multicall и дёргать pingback.
• Иногда /wp-admin/ и REST /wp-json/ — это уже другие истории, их в ту же зону, что логин, я не кладу.

GET на логин — не атака. Человек открыл форму, браузер подтянул редирект, плагин 2FA нарисовал второй шаг. Если лимитировать любой метод, первый же заход «съедает» burst, а POST с паролем уже ловит 429. Поэтому ключ зоны я завязываю на POST, не на URL целиком.

xmlrpc почти всегда POST. Закрывать его наглухо можно, если им никто не пользуется: нет официального приложения WP, нет Jetpack, нет старых клиентов публикации. Если приложение нужно — return 403 хуже брутфорса: свои отвалятся сразу, боты просто перейдут на wp-login.php.

Почему общий limit_req на php убивает нормальных людей

admin-ajax.php на живом сайте стучит постоянно: пульс админки, автосохранение записи, корзина, фильтры каталога. Один редактор за минуту легко делает десятки POST. Посадили его в зону 1r/s burst=3 вместе с логином — получите «сайт тормозит», хотя CPU спокойный, а в логе 503 на ajax.

Вторая ловушка — общий IP. Офис, коворкинг, 4G-оператор с CGNAT, гостиница. Двадцать человек за одним адресом. Лимит «один запрос в секунду на IP» для брутфорса с ботнета ещё терпим, для офиса это коллективный бан после трёх неудачных паролей подряд.

Третья — статус по умолчанию. Nginx на превышение отдаёт 503. Мониторинг орёт «сайт мёртв», человек лезет в php-fpm и диск. Это не падение бэкенда, это отказ лимитера. Ставлю limit_req_status 429 и в логах сразу видно, что именно отсекли, а не «бэкенд не отвечает».

Две зоны, не одна

Зоны объявляю в http, не в server. Размер 10m для $binary_remote_addr — десятки тысяч IP, на обычный сайт с головой. Rate считаю отдельно:

# http { ... }
limit_req_zone $limit_key_wplogin zone=wplogin:10m rate=6r/m;
limit_req_zone $limit_key_xmlrpc  zone=xmlrpc:10m  rate=1r/s;
limit_req_status 429;
limit_req_log_level warn;

Шесть POST в минуту на логин — человек с кривым паролем ещё влезет, словарь на тысячи попыток уже нет. xmlrpc чуть свободнее по частоте HTTP-запросов: живое приложение иногда стучит пачкой. Это не дыра — дыра в xmlrpc не частота, а толстое тело, про это ниже.

Ключ пустой строкой означает «этого запроса в зоне нет». Так я выключаю лимит для GET и для белого списка.

map $request_method $limit_key_wplogin {
    POST $binary_remote_addr;
    default "";
}

# xmlrpc почти весь POST; GET на него мне не жалко тоже резать
map $request_method $limit_key_xmlrpc {
    default $binary_remote_addr;
}

Если офис сидит на постоянном адресе, вычитаю его из ключа через geo. В примере — документационный диапазон, не чей-то боевой:

geo $offnet {
    default 0;
    203.0.113.0/24 1;   # офис, подставьте свой
}

map $offnet $limit_key_wplogin {
    1      "";
    default $limit_wplogin_ip;
}

map $request_method $limit_wplogin_ip {
    POST $binary_remote_addr;
    default "";
}

Два map на одну переменную nginx не даст — ключ собираю в одном месте. Рабочий вариант без сюрпризов:

geo $is_office {
    default 0;
    203.0.113.0/24 1;
}

map "$is_office:$request_method" $limit_key_wplogin {
    "1:POST" "";
    "0:POST" $binary_remote_addr;
    default  "";
}

map $is_office $limit_key_xmlrpc {
    1       "";
    default $binary_remote_addr;
}

Белый список — не «интернет офиса целиком». Только тот префикс, с которого реально заходят в админку. Домашний динамический IP туда не тащу: через месяц он уедет соседу.

location: только эти два файла, тот же php, что у остальных

location = с точным именем бьёт точнее regex. Обработчик php не выдумываю — копирую то, что уже работает для *.php. На Debian это часто snippets/fastcgi-php.conf плюс ваш fastcgi_pass. Сокет не копируйте из чужой статьи: у вас может быть другой пул.

server {
    # ...

    location = /wp-login.php {
        limit_req zone=wplogin burst=4 nodelay;
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php-fpm.sock;  # как у вас в общем php
    }

    location = /xmlrpc.php {
        limit_req zone=xmlrpc burst=8 nodelay;
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php-fpm.sock;
    }

    # общий php — БЕЗ limit_req этих зон
    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php-fpm.sock;
    }
}

burst=4 nodelay на логине: четыре лишних POST проходят сразу, дальше 429, без очереди. Без nodelay nginx начинает задерживать запросы — форма «думает» секундами, человек жмёт ещё раз, вы сами себе множите POST. Для логина я предпочитаю жёсткий отказ, не задержку.

На xmlrpc burst больше: приложение может открыть несколько соединений подряд при синхронизации. Если xmlrpc вам не нужен совсем — не лимитируйте, закройте:

location = /xmlrpc.php {
    return 403;
}

Проверяю необходимость просто: grep xmlrpc access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head и user-agent. Если неделю стучат только словари и Hello world — закрываю. Если есть wp-iphone / wp-android с адресов редакции — оставляю зону.

Настоящий IP, иначе режете Cloudflare, а не бота

$binary_remote_addr — это TCP-пир. Стоит сайт за Cloudflare, nginx-прокси или балансировщиком хостера — пир один на всех. Лимит превращается в глобальный рубильник: первый бот выжигает burst, посетители с того же эджа ловят 429.

Смотрю, откуда приходит запрос:

log_format debugip '$remote_addr cf="$http_cf_connecting_ip" xff="$http_x_forwarded_for"';

Дальше set_real_ip_from на префиксы своего прокси и real_ip_header — тот заголовок, которому вы доверяете. Не доверяю X-Forwarded-For с интернета без фильтра: его подставляет кто угодно. Для Cloudflare — их диапазоны и CF-Connecting-IP. Для своего nginx-прокси — только его адрес в set_real_ip_from.

Пока real_ip не настроен, limit_req на логин я не включаю в боевой server. Иначе «защита» — это лотерея, кто первый постучал в этот воркер.

Где лимит бесполезен: system.multicall

Брутфорс по xmlrpc часто укладывается в один HTTP POST. Внутри system.multicall — сотни wp.getUsersBlogs с разными паролями. Для nginx это один запрос. Зона 1r/s его пропускает, php-fpm честно пережёвывает пачку, в auth.log WordPress — сотни неудачных логинов, в access.log — одна строка 200.

Поэтому «я поставил rate limit, xmlrpc больше не брутфорсят» — самообман, если multicall жив. Nginx $request_body в if на практике пустой: тело ещё не прочитано в той фазе, конфиг из гугла с if ($request_body ~ multicall) просто не срабатывает. Я это не рисую как рабочую схему.

Что работает без магии:

• xmlrpc не нужен — return 403 на location, плюс фильтр в WordPress на всякий случай;
• нужен только pingback — всё равно спорно, pingback сам по себе источник шума; чаще его выключают;
• нужно приложение — оставляю xmlrpc под limit_req и отдельно отключаю multicall на стороне PHP (му-плагин на xmlrpc_methods выкидывает system.multicall), либо режу на WAF, который тело реально видит;
• Application Passwords и REST — другая дверь, xmlrpc для них не обязателен. Если мобильный вход уже через REST, xmlrpc я закрываю, не лимитирую.

Лимит по запросам и разбор методов xmlrpc — два разных слоя. Первый без второго на этой двери недоделан.

Как проверить, что своих не задело

Не тестирую с того же ноутбука, с которого админю. Иначе сам себя выкину и буду чинить по аварийной консоли. С другого адреса, лучше с маленького VPS:

# форма должна открываться сколько угодно
for i in $(seq 1 20); do curl -s -o /dev/null -w "%{http_code}\n" https://example.com/wp-login.php; done

# POST — должны пойти 429 после burst
for i in $(seq 1 20); do
  curl -s -o /dev/null -w "%{http_code}\n" -X POST \
    -d "log=nosuchuser&pwd=wrong&wp-submit=Log+In" \
    https://example.com/wp-login.php
done

# ajax и главная не в этой зоне
for i in $(seq 1 30); do
  curl -s -o /dev/null -w "%{http_code}\n" -X POST https://example.com/wp-admin/admin-ajax.php
done

Ожидание: GET логина — сплошные 200 (или 302, если уже есть редирект). POST — несколько 200/302, потом 429, не 503. ajax — без 429. Главная и карточки товара — без 429.

Потом то же с офисного IP, если он в geo: POST не должен упираться в 429, иначе белый список не попал в ключ. Частая ошибка — geo по $remote_addr до real_ip, и офис виден как адрес Cloudflare.

В логе ищу не «много 404», а явно статус и зону. С limit_req_log_level warn в error.log будет limiting requests, excess: ... zone=wplogin. Если зоны в логе нет, а 503 есть — вы смотрите не на лимитер, а на php-fpm/upstream.

Что я не кладу в эти зоны

• admin-ajax.php, async-upload.php, cron wp-cron.php — это не брутфорс логина.
• REST /wp-json/ целиком. Там и легитимный редактор, и Application Passwords. Если резать — отдельные location на конкретные маршруты, не оптом.
• wp-admin/ GET статики и admin-post.php с авторизованной сессией.
• Статику и wp-content/uploads — к логину отношения не имеет.

Отдельно: плагины «кастомной страницы входа» часто POST-ят не на /wp-login.php, а на / или на /my-account/. Тогда мой location логин не защищает, зато WooCommerce-чекаут внезапно оказывается под лимитом, если кто-то прикрутил зону на location /. Смотрю в access.log реальный URI при неудачном входе, не название плагина на коробке.

fail2ban рядом, не вместо

Nginx лимитер не помнит «этот IP вчера перебирал пароли». Он держит короткое окно. fail2ban по error.log с zone=wplogin или по auth-логу WordPress закрывает упёртых на часы. Но jail, который банит после трёх 429, снова отстрелит офис. Либо офис в ignoreip, либо порог заметно выше человеческого «забыл пароль, нажал пять раз».

Я не баняю 429 с ajax и не баняю 404 на xmlrpc.php, если сами его закрыли 403: боты будут стучать вечно, jail раздует ipset, а толку ноль — они и так получают отказ.

Что оставляю на обычном сайте

Рабочий минимум, которым я заканчиваю, если это один WordPress на VPS без приложения:

• real_ip настроен, в логе виден клиент, не эдж;
• wp-login.php — POST-only зона ~6r/m, burst 4 nodelay, статус 429;
• xmlrpc.php — 403, если за неделю нет своих клиентов;
• если клиент есть — зона 1r/s + выключенный system.multicall в PHP;
• офисный префикс в geo, не «весь провайдер»;
• общий php-location без этих зон;
• проверка циклом curl с чужого IP и глазами error.log, что падает зона, а не 503 от fpm.

Плагин лимита логинов в WordPress я не считаю заменой: он срабатывает уже внутри PHP, после того как fpm взял воркер. Под словарём это дороже, чем отказ на nginx. Плагин имеет смысл как второй слой (капча, временная блокировка учётки), не как единственный.

Если после включения 429 сыпятся на живых редакторов — не поднимаю rate «пока не пройдёт». Сначала смотрю, какой URI и какой IP. Почти всегда это либо общий php-location, либо NAT офиса, либо xmlrpc приложения, которое я забыл, что оно существует.