XML-RPC в WordPress часто оставляют включённым «на всякий случай», а потом получают лишнюю поверхность атаки, шум в логах и непонятные запросы к xmlrpc.php. Если вы не используете мобильное приложение WordPress, внешние публикации через сторонние сервисы или старые интеграции, этот интерфейс обычно можно отключить без потери функциональности сайта.
Ниже — практический разбор: как понять, нужен ли XML-RPC именно вам, как отключить его безопасно, чем отличается блокировка на уровне WordPress и веб-сервера, и как проверить результат после изменений.
Когда XML-RPC действительно можно отключить
XML-RPC нужен не всем. На типовом сайте он используется редко, но продолжает быть доступной точкой входа для запросов на /xmlrpc.php. Проблема не в самом файле, а в том, что его часто сканируют боты и пытаются использовать для перебора логинов, pingback-атак и других нежелательных сценариев.
Проверьте, есть ли у вас зависимость от XML-RPC
Перед отключением ответьте на несколько конкретных вопросов:
- Используете ли вы мобильное приложение WordPress для публикации и редактирования?
- Подключён ли внешний сервис, который публикует записи через XML-RPC?
- Нужны ли старые интеграции, которые не работают через REST API?
- Есть ли у сайта pingback/trackback, и нужны ли они вообще?
Если на все вопросы ответ «нет», отключение XML-RPC обычно безопасно. Если хотя бы один сценарий нужен, лучше не рубить доступ полностью, а сначала проверить, можно ли перевести интеграцию на REST API или другой способ авторизации.
Диагностика: как понять, что XML-RPC сейчас открыт
Самый простой признак — файл xmlrpc.php отвечает на запросы. Это можно проверить вручную или через командную строку. Важно не путать «файл доступен» и «функциональность реально используется»: даже если вы не пользуетесь XML-RPC, он может быть открыт по умолчанию.
Проверка через браузер или curl
Откройте https://example.com/xmlrpc.php. Если интерфейс не закрыт, вы обычно увидите ответ WordPress вроде сообщения о том, что XML-RPC сервер принимает только POST-запросы. Это уже означает, что endpoint доступен.
Через curl проверка выглядит так:
curl -i https://example.com/xmlrpc.phpЕсли сервер отвечает, значит точка входа существует. Для более точной проверки можно отправить тестовый POST-запрос, но для задачи отключения обычно достаточно убедиться, что endpoint не отдаёт рабочий ответ после внесения изменений.
Как отключить XML-RPC: сравнение подходов
Есть три рабочих варианта: через плагин, через код в теме или mu-plugin, и на уровне веб-сервера. У каждого есть свои плюсы и ограничения.
| Способ | Когда подходит | Плюсы | Минусы |
|---|---|---|---|
| Плагин | Нужен быстрый способ без правки кода | Просто включить и отключить | Ещё один плагин в системе |
Код в functions.php или mu-plugin | Есть доступ к коду и нужен контролируемый вариант | Не зависит от интерфейса плагина | Нужно аккуратно обновлять тему |
| Блокировка на сервере | Нужна жёсткая защита от запросов к xmlrpc.php | Запросы режутся раньше WordPress | Нужно понимать конфиг Nginx/Apache |
Пошаговое решение через код
Если вам нужен предсказуемый вариант без стороннего плагина, проще всего отключить XML-RPC фильтром xmlrpc_enabled. Такой способ не ломает админку и не вмешивается в другие части сайта.
Вариант для темы или mu-plugin
Лучше добавлять это не в активную тему, а в mu-plugin или в небольшой собственный плагин. Тогда отключение не исчезнет после смены темы.
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Если вы всё же добавляете код в functions.php, убедитесь, что тема дочерняя. Иначе при обновлении родительской темы настройка пропадёт.
Дополнительная защита: закрыть pingback
Даже если XML-RPC нужен частично, pingback часто не нужен вообще. Его можно отключить отдельно, чтобы убрать один из популярных векторов злоупотребления.
<?php
add_filter( 'xmlrpc_methods', function( $methods ) {
unset( $methods['pingback.ping'] );
return $methods;
} );Этот вариант не отключает XML-RPC целиком, но убирает метод, который чаще всего используют для нежелательных запросов.
Как закрыть xmlrpc.php на уровне сервера
Если цель — не просто отключить функциональность, а ещё и сократить лишние обращения к серверу, можно заблокировать xmlrpc.php на уровне веб-сервера. Это особенно полезно, если по логам видно постоянные запросы к этому файлу.
Apache: правило в .htaccess
Для Apache можно добавить отдельное правило. Оно не зависит от WordPress и сработает раньше загрузки CMS.
<Files xmlrpc.php>
Require all denied
</Files>Если у вас старый стек с Apache 2.2, синтаксис может отличаться, но на современных установках используется именно Require all denied.
Nginx: блокировка location
Для Nginx логика похожая: запросы к xmlrpc.php лучше отрезать на уровне конфигурации сайта.
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}После изменения конфигурации не забудьте проверить синтаксис и перезагрузить сервер. Иначе правило просто не начнёт работать.
Проверка результата после внедрения
После отключения важно не ограничиваться «в админке всё открывается». Нужно проверить именно тот endpoint, который вы закрывали.
- Откройте
/xmlrpc.phpв браузере и убедитесь, что доступ запрещён или ответ не содержит рабочего XML-RPC-сервера. - Проверьте
curl -i https://example.com/xmlrpc.phpи посмотрите код ответа. - Если использовали серверную блокировку, убедитесь, что в логах больше не идут обращения к этому файлу с успешным ответом.
- Проверьте, не сломались ли внешние интеграции, если они у вас были.
Если вы отключали XML-RPC через фильтр xmlrpc_enabled, нормальным результатом будет отказ в доступе или сообщение об ошибке при попытке отправить XML-RPC-запрос. Главное — чтобы endpoint больше не выполнял команды.
Частые ошибки и как их исправить
Отключили XML-RPC, но забыли про внешнюю интеграцию
Такое случается, если сайт связан с сервисом публикации или мобильным приложением. Симптом простой: интеграция перестаёт отправлять записи, а в логах появляются ошибки авторизации или недоступности endpoint. Решение — либо вернуть XML-RPC, либо перевести интеграцию на REST API.
Добавили код в родительскую тему
После обновления тема перезаписалась, и отключение исчезло. Это типичная ошибка при правке functions.php не в дочерней теме. Надёжнее вынести код в mu-plugin.
Заблокировали файл, но WordPress всё ещё отвечает
Иногда правило добавили не в тот серверный блок или конфиг не был применён. Проверьте, что правило находится именно в конфигурации нужного виртуального хоста, а затем перезагрузите Nginx или Apache.
Поставили плагин, который отключает больше, чем нужно
Некоторые плагины не только закрывают XML-RPC, но и вмешиваются в другие настройки безопасности. Если вам нужен только один endpoint, кодовый вариант обычно прозрачнее и проще в сопровождении.
Что ещё стоит сделать для безопасности
Отключение XML-RPC — полезный шаг, но не замена базовой гигиены. Если на сайте уже есть подозрительная активность, проверьте и другие точки входа: слабые пароли, устаревшие плагины, лишние админ-аккаунты, открытый REST API там, где он не нужен, и отсутствие ограничений на попытки входа.
Если вы используете набор инструментов для технической чистки и SEO-оптимизации, имеет смысл смотреть на сайт шире: убрать лишние служебные сущности, сократить дубли и отключить ненужные функции, которые создают шум. В таких задачах полезны решения вроде Clearfy Pro, если вам нужен именно набор для технической настройки WordPress, а не точечный код.
Но в случае с XML-RPC не стоит полагаться только на плагин. Лучше понимать, где именно закрыт доступ: в WordPress, на сервере или в обоих местах. Тогда проще отлаживать сайт и не ловить неожиданные побочные эффекты после обновлений.