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

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

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

Когда XML-RPC действительно стоит отключать

Сначала важно понять, не сломаете ли вы нужную интеграцию. XML-RPC может использоваться для:

• старых мобильных приложений WordPress;
• публикации через внешние клиенты и сервисы;
• pingback и trackback;
• некоторых автоматизаций, которые до сих пор не переведены на REST API.

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

Диагностика: как понять, что XML-RPC открыт

Проверка нужна до изменений и после них. Самый простой тест — открыть файл /xmlrpc.php в браузере или через curl. Если endpoint доступен, WordPress обычно отвечает сообщением о том, что XML-RPC сервер принимает только POST-запросы.

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

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

Что проверить перед отключением

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

Способ 1: отключить XML-RPC через код в functions.php

Если нужен быстрый и понятный вариант, можно добавить фильтр в functions.php дочерней темы или в собственный мини-плагин. Этот способ блокирует обработку XML-RPC на уровне WordPress.

add_filter( 'xmlrpc_enabled', '__return_false' );

Это самый короткий вариант, но он не всегда закрывает сам файл на уровне веб-сервера. Обычно этого достаточно, чтобы WordPress перестал принимать XML-RPC-запросы, однако сам endpoint может продолжать отвечать HTTP-статусом сервера.

Когда этого достаточно

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

Способ 2: закрыть доступ через .htaccess или nginx

Если нужен более жёсткий вариант, лучше блокировать доступ на уровне веб-сервера. Так вы уменьшаете лишнюю нагрузку и не даёте запросам доходить до WordPress.

Для Apache (.htaccess)

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

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

Для nginx

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

Такой блок лучше добавлять в конфигурацию сайта, а не в общий шаблон без проверки. После правки конфигурации не забудьте перезагрузить nginx.

Что выбрать: код, сервер или оба варианта

Подход	Плюсы	Минусы	Когда использовать
Фильтр xmlrpc_enabled	Быстро, без доступа к серверу	Файл может оставаться доступным	Если нет доступа к конфигам
Блокировка в Apache/nginx	Режет запросы раньше WordPress	Нужен доступ к серверу	Если нужен жёсткий контроль
Оба варианта	Максимально надёжно	Нужно проверить, не мешает ли это интеграциям	Для публичных сайтов без XML-RPC

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

После отключения важно убедиться, что защита реально сработала. Проверять лучше не только в браузере, но и через HTTP-запрос.

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

Ожидаемый результат зависит от способа блокировки:

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

Дополнительно проверьте логи безопасности и логи веб-сервера: если бот продолжает долбить /xmlrpc.php, это хороший сигнал, что блокировка стоит на правильном месте.

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

Отключили XML-RPC, но атаки в логах остались

Это нормально, если вы закрыли только WordPress-обработку. Боты всё равно будут стучаться в файл. Чтобы сократить шум и нагрузку, блокируйте endpoint на уровне nginx или Apache.

Сломалась публикация через мобильное приложение

Значит, сайт реально использовал XML-RPC. В этом случае либо оставьте доступ, либо переведите интеграцию на REST API, если сервис это поддерживает.

Добавили правило не в тот файл

Частая проблема на Apache — правило кладут в functions.php, ожидая серверной блокировки. Это разные уровни. Если нужен отказ до WordPress, правьте именно конфиг веб-сервера или .htaccess.

Конфликт с кэшем или CDN

Иногда кажется, что правило не работает, потому что CDN отдаёт старый ответ. После изменений очистите кэш на стороне сайта, прокси и CDN, затем повторите проверку.

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

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

• закрыт ли доступ к /wp-login.php для брутфорса;
• не включены ли лишние pingback'и и trackback'и;
• не торчит ли сайт с устаревшими плагинами, которые тоже принимают внешние запросы;
• не создаёт ли тема или плагин лишние публичные endpoint'ы без необходимости.

Если вы регулярно чистите сайт от дублей, технических страниц и мусорных endpoint'ов, удобно держать это в одном регламенте. В таких задачах полезны и ручные правки, и инструменты для SEO- и технической чистки вроде Clearfy Pro, если вам нужен набор готовых настроек без постоянного редактирования кода.

Мини-чек-лист перед публикацией изменений

• Проверил, использует ли сайт XML-RPC.
• Добавил отключение в functions.php или в мини-плагин.
• При необходимости закрыл xmlrpc.php на уровне nginx/Apache.
• Очистил кэш сайта, CDN и браузера.
• Проверил ответ /xmlrpc.php через curl.
• Убедился, что нужные интеграции не сломались.

Если после проверки endpoint всё ещё доступен, не ограничивайтесь одним фильтром в WordPress. В реальных условиях надёжнее закрывать XML-RPC на сервере и отдельно отключать его в самом WordPress.