Почему WordPress XML-RPC возвращает 403 или 404 и как безопасно отключить или ограничить доступ

XML-RPC в WordPress до сих пор встречается на живых сайтах чаще, чем кажется: мобильное приложение, внешние сервисы публикации, старые интеграции, мониторинг. Проблема обычно всплывает не в момент настройки, а когда кто-то видит в логах массовые запросы к /xmlrpc.php, получает 403/404 или после ужесточения безопасности внезапно перестаёт работать интеграция.

Ниже — не общая теория, а рабочий разбор: как понять, кто именно блокирует XML-RPC, когда его лучше отключить полностью, а когда достаточно ограничить доступ на уровне сервера или WordPress.

Когда XML-RPC действительно проблема

Сам по себе файл xmlrpc.php не является уязвимостью, но он часто становится точкой входа для брутфорса и перебора логинов. Если сайт не использует внешние клиенты, а в логах есть сотни одинаковых запросов к этому endpoint, держать его открытым без нужды — плохая идея.

Типичные сценарии:

• в логах веб-сервера много запросов к /xmlrpc.php с разных IP;
• плагин безопасности или WAF отдаёт 403 только на XML-RPC;
• после переноса сайта на новый сервер endpoint стал отдавать 404, хотя файл физически есть;
• мобильное приложение WordPress или внешняя публикация перестали авторизоваться;
• нужно оставить только один метод, например pingback.ping или наоборот запретить его отдельно.

Диагностика: кто именно отдаёт 403 или 404

Перед изменениями важно понять, где именно возникает запрет. В WordPress 403 может вернуть сам сайт, плагин безопасности, nginx, Apache или облачный WAF. 404 тоже бывает разным: реальный отсутствующий файл, переписанный маршрут или правило, которое маскирует блокировку под «не найдено».

Проверка ответа напрямую

Сначала проверьте endpoint без браузера:

curl -i https://example.com/xmlrpc.php

Ожидаемый ответ WordPress на простой GET обычно не 200, но сам факт ответа важен. Если вы видите:

• 403 Forbidden — доступ режется на уровне сервера, WAF или плагина;
• 404 Not Found — файл скрыт, переписан или физически недоступен;
• 405 Method Not Allowed — сервер ограничивает метод, что тоже может быть нормальным решением;
• HTML-страницу блокировки от хостинга — значит, запрет не в WordPress.

Проверка изнутри WordPress

Если есть доступ к коду, можно временно проверить, существует ли файл и не подменяется ли он правилами маршрутизации:

<?php
$path = ABSPATH . 'xmlrpc.php';
if ( file_exists( $path ) ) {
    error_log( 'xmlrpc.php exists: ' . $path );
} else {
    error_log( 'xmlrpc.php missing' );
}

Этот код не решает проблему, но помогает исключить банальную ситуацию, когда файл удалили при миграции или очистке.

Как безопасно отключить XML-RPC полностью

Если сайт не использует внешние клиенты, самый надёжный вариант — отключить endpoint на уровне WordPress и дополнительно закрыть его на сервере. Одного метода часто недостаточно: плагин можно деактивировать, а правило на сервере останется.

Вариант 1: отключение через фильтр WordPress

Добавьте в functions.php дочерней темы или в небольшой mu-plugin:

<?php
add_filter( 'xmlrpc_enabled', '__return_false' );

Это самый простой способ, но он не защищает от прямых запросов к файлу на уровне веб-сервера. Поэтому его лучше использовать вместе с серверным ограничением.

Вариант 2: блокировка на nginx

Если у вас nginx, можно закрыть доступ к файлу на уровне конфигурации сайта:

location = /xmlrpc.php {
    deny all;
    access_log off;
    log_not_found off;
}

Такой вариант хорош тем, что запросы даже не доходят до PHP. Это снижает нагрузку и убирает шум в логах.

Вариант 3: блокировка на Apache

Для Apache можно использовать правило в .htaccess:

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

Если сайт работает через старую конфигурацию Apache 2.2, синтаксис будет другим, но на современных хостингах обычно используется именно Require all denied.

Когда лучше не отключать, а ограничить доступ

Полное отключение не подходит, если вы реально используете:

• мобильное приложение WordPress;
• Jetpack или похожие внешние сервисы, которым нужен XML-RPC;
• старые интеграции публикации через сторонний софт;
• отдельные сценарии pingback, если вы их осознанно оставили.

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

Ограничение по IP

Если доступ нужен только с конкретного адреса, можно разрешить его на уровне сервера. Для nginx это делается через allow и deny:

location = /xmlrpc.php {
    allow 203.0.113.10;
    deny all;
}

Для Apache логика та же, но реализация зависит от версии и общей конфигурации виртуального хоста. Важно не пытаться решать это только через WordPress: если endpoint нужен внешнему сервису, серверный уровень надёжнее.

Отключение pingback, но сохранение других методов

Если цель — убрать именно pingback-атаки, можно фильтровать методы XML-RPC в WordPress:

<?php
add_filter( 'xmlrpc_methods', function( $methods ) {
    unset( $methods['pingback.ping'] );
    unset( $methods['pingback.extensions.getPingbacks'] );
    return $methods;
} );

Это не выключает XML-RPC целиком, но уменьшает поверхность атаки. Подходит, если интеграция нужна, а pingback не используется.

Сравнение подходов

Пошаговое решение без лишнего риска

1. Проверьте, используется ли XML-RPC вообще: мобильное приложение, внешние публикации, старые интеграции.
2. Посмотрите логи веб-сервера и определите, кто отдаёт 403/404.
3. Если endpoint не нужен — закройте его на сервере и дополнительно отключите фильтром WordPress.
4. Если нужен только частично — оставьте доступ по IP или отключите опасные методы.
5. После изменений протестируйте endpoint и убедитесь, что нужные сервисы продолжают работать.

Как проверить, что всё сработало

Проверка должна быть не только визуальной. Нужны три уровня контроля: ответ endpoint, логи и работа интеграции.

1. Проверка ответа

Повторите запрос:

curl -i https://example.com/xmlrpc.php

Если вы закрывали endpoint, ожидайте 403, 404 или 405 в зависимости от выбранного способа. Главное — чтобы ответ был предсказуемым и соответствовал вашей схеме блокировки.

2. Проверка логов

После серверной блокировки в логах не должно быть обращений к PHP-обработчику WordPress для этого файла. Если запросы всё ещё доходят до PHP, значит правило стоит не там, где нужно.

3. Проверка внешнего клиента

Если XML-RPC нужен, протестируйте реальный сценарий: публикацию, авторизацию или синхронизацию. Не ограничивайтесь тем, что «страница открывается» — это не доказывает работоспособность метода.

Частые ошибки и как их исправить

• Отключили XML-RPC в WordPress, но забыли про сервер. В итоге endpoint всё ещё отвечает и продолжает нагружать сайт. Решение: закрыть файл на nginx/Apache.
• Сразу поставили жёсткий deny, не проверив интеграции. После этого перестало работать мобильное приложение или внешний сервис. Решение: сначала инвентаризация, потом блокировка.
• Путают 404 от маскировки с реальным отсутствием файла. Решение: проверить конфиг сервера и правила WAF, а не только наличие xmlrpc.php в файловой системе.
• Отключают pingback, но оставляют открытый endpoint без ограничений. Это снижает риск частично, но не убирает брутфорс. Решение: комбинировать с серверной блокировкой или IP allowlist.
• Делают правки в родительской теме. После обновления изменения теряются. Решение: использовать дочернюю тему или mu-plugin.

Практика безопасности и производительности

Если XML-RPC вам не нужен, его лучше не просто «спрятать», а убрать из доступной поверхности атаки. Это уменьшает шум в логах, снижает количество лишних запросов и делает поведение сайта понятнее при аудите безопасности.

Для сайтов с высокой нагрузкой полезно дополнительно:

• ограничить частоту запросов на уровне WAF или сервера;
• проверить, не генерирует ли XML-RPC лишние записи в логах мониторинга;
• не полагаться на один плагин безопасности как на единственный барьер;
• после изменений пересмотреть правила кэширования и исключения для админских запросов, если интеграция всё же остаётся.

Если вам нужно не только закрыть XML-RPC, но и убрать другие лишние точки входа, имеет смысл смотреть на комплексную чистку WordPress: отключение ненужных REST-маршрутов, скрытие служебных эндпоинтов, удаление дублей и технического мусора. Для этого часто используют плагины уровня Clearfy Pro, если нужен набор готовых переключателей без ручной сборки правил.

В итоге правильный выбор простой: если XML-RPC не нужен — закрывайте его на сервере и в WordPress; если нужен частично — ограничивайте доступ и режьте опасные методы; если видите 403 или 404, сначала выясните источник блокировки, а уже потом меняйте конфигурацию.