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

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

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

Когда XML-RPC можно отключать, а когда нет

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

Типичные признаки, что XML-RPC не используется

• в логах нет обращений к /xmlrpc.php от ваших сервисов;
• мобильное приложение WordPress не используется;
• публикация и обновление контента идут через админку или REST API;
• нет старых интеграций, которые требуют metaWeblog или pingback.

Диагностика: как понять, что XML-RPC вообще активен

Самый простой способ — открыть https://ваш-домен/xmlrpc.php. Если файл доступен, WordPress обычно отвечает не HTML-страницей, а коротким сообщением о том, что запросы XML-RPC принимаются только через POST. Это не ошибка, а признак того, что endpoint жив.

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

Что проверить перед изменениями

• используются ли внешние приложения для публикации;
• есть ли интеграции с сервисами, которые не умеют REST API;
• не завязаны ли на XML-RPC старые плагины синхронизации;
• есть ли на сервере правила, которые уже блокируют xmlrpc.php на уровне nginx, Apache или WAF.

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

Если нужен быстрый и контролируемый вариант, добавьте фильтр в functions.php дочерней темы или лучше в отдельный mu-plugin. Для production mu-plugin удобнее: он не зависит от темы и не исчезнет после её обновления.

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

Этого достаточно, чтобы WordPress перестал принимать XML-RPC-запросы. На большинстве сайтов это самый чистый вариант: без правок ядра и без лишних плагинов.

Вариант через mu-plugin

Создайте файл wp-content/mu-plugins/disable-xmlrpc.php. Если папки mu-plugins нет, её можно создать вручную.

<?php
/**
 * Plugin Name: Disable XML-RPC
 */
add_filter( 'xmlrpc_enabled', '__return_false' );

После этого WordPress загрузит код автоматически. Это удобно, если вы ведёте несколько сайтов и хотите одинаковую политику безопасности без зависимости от темы.

Способ 2: заблокировать xmlrpc.php на уровне сервера

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

Apache: правило в .htaccess

Для Apache можно добавить отдельное правило в корень сайта. Оно вернёт 403 для запросов к xmlrpc.php.

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

Если у вас старый синтаксис Apache 2.2, может использоваться Deny from all, но на современных установках лучше ориентироваться на Require all denied.

nginx: блокировка в конфигурации

Для nginx правило обычно добавляют в конфиг сайта:

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

Такой вариант особенно полезен, если вы хотите снизить лишнюю нагрузку от постоянных обращений к этому endpoint.

Сравнение подходов: код, сервер, плагин

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

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

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

Проверка через браузер

Откройте /xmlrpc.php. Если блокировка сделана на сервере, вы должны увидеть 403 Forbidden или аналогичный ответ. Если использован только фильтр WordPress, поведение может отличаться в зависимости от конфигурации сервера, но XML-RPC-запросы должны перестать работать.

Проверка через curl

Можно отправить простой POST-запрос и посмотреть ответ сервера:

curl -i -X POST https://example.com/xmlrpc.php \
  -H 'Content-Type: text/xml' \
  --data '<?xml version="1.0"?><methodCall><methodName>system.listMethods</methodName><params></params></methodCall>'

Если всё закрыто корректно, вы увидите отказ в доступе или ответ, который не позволяет использовать XML-RPC как раньше. Важно: не ориентируйтесь только на статус страницы в браузере, потому что GET и POST ведут себя по-разному.

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

Сломали мобильное приложение или внешнюю публикацию

Это значит, что XML-RPC всё-таки использовался. Не возвращайте всё назад вслепую: сначала найдите конкретный сервис, который зависит от этого endpoint, и проверьте, есть ли у него поддержка REST API или другого способа авторизации.

Добавили правило в .htaccess, но оно не сработало

Причина обычно в том, что сайт работает не на Apache, а на nginx, либо правило стоит не в том месте. Для nginx .htaccess не используется вообще. Если у вас связка nginx + Apache, блокировать лучше на уровне nginx.

Отключили XML-RPC через фильтр, но запросы всё равно видны в логах

Фильтр WordPress отключает функциональность, но не всегда убирает сам факт обращения к файлу. Если цель — уменьшить шум и нагрузку, блокируйте xmlrpc.php на сервере или через WAF.

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

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

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

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

• закрывайте xmlrpc.php на сервере, если он не нужен;
• не держите одновременно несколько плагинов, которые решают одну и ту же задачу;
• после изменений проверьте логи на 403 и 404, чтобы понять, кто обращается к endpoint;
• если используете CDN или WAF, добавьте правило и там, чтобы не пропускать лишние запросы до origin-сервера.

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