XML-RPC в WordPress часто отключают «на всякий случай», а потом внезапно перестают работать мобильное приложение, внешняя публикация через старые клиенты или интеграции, которые всё ещё ходят в /xmlrpc.php. Поэтому правильный вопрос не «как выключить», а «что именно у вас использует XML-RPC и чем это заменить».
Если сайт не использует удалённую публикацию, pingback/trackback и старые интеграции, XML-RPC обычно можно отключить. Но делать это лучше после проверки логов и списка подключённых сервисов, а не по шаблону из статьи пятилетней давности.
Когда XML-RPC действительно мешает
На практике у этой точки входа две проблемы. Первая — лишняя поверхность атаки: по /xmlrpc.php часто идут переборы паролей и запросы на мультизапросы. Вторая — технический мусор: если сайт не использует pingback и удалённую публикацию, этот файл просто остаётся открытым без пользы.
Но есть и обратная сторона. Некоторые клиенты и сервисы до сих пор используют XML-RPC для публикации, синхронизации или проверки доступности сайта. Поэтому отключение без диагностики может сломать рабочий процесс редакции.
Что обычно завязано на XML-RPC
- старые мобильные приложения WordPress;
- клиенты для удалённой публикации;
- pingback и trackback;
- часть внешних сервисов, которые давно не обновлялись;
- некоторые интеграции с автопостингом.
Диагностика: есть ли у вас реальный трафик на xmlrpc.php
Перед отключением посмотрите, обращается ли кто-то к /xmlrpc.php. Если у вас есть доступ к логам веб-сервера, это самый надёжный способ. Ищите запросы вида POST /xmlrpc.php и оцените, это ваши сервисы или мусорный трафик.
Если логов нет, проверьте хотя бы косвенные признаки: используются ли мобильные приложения WordPress, есть ли внешняя публикация через сторонние инструменты, включены ли pingback/trackback в обсуждениях. Если сайт — обычный корпоративный блог без удалённой публикации, шанс, что XML-RPC нужен, невелик.
Быстрая проверка через curl
Можно проверить, отвечает ли endpoint вообще. Это не доказывает, что он нужен, но помогает понять, открыт ли он наружу.
curl -I https://example.com/xmlrpc.phpЕсли сервер отдаёт 200 или 405, файл доступен. Если 403 или 404, доступ уже ограничен на уровне сервера или сайта.
Пошаговое решение: как отключить XML-RPC в WordPress
Есть три рабочих подхода: через плагин, через код и на уровне веб-сервера. Для большинства сайтов достаточно кода в теме или mu-plugin. Если нужен быстрый и обратимый вариант без правки кода — подойдёт плагин.
| Способ | Плюсы | Минусы |
|---|---|---|
| Плагин безопасности | Быстро, без кода | Лишняя зависимость, иногда отключает больше, чем нужно |
| Код в mu-plugin | Контролируемо, не зависит от темы | Нужен доступ к файлам |
| Правило на сервере | Режет запросы раньше WordPress | Нужно аккуратно тестировать, чтобы не сломать другие правила |
Вариант 1: отключить XML-RPC через код
Самый предсказуемый способ — добавить фильтр xmlrpc_enabled. Лучше положить код в небольшой mu-plugin, чтобы он не зависел от активной темы.
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Если хотите не просто отключить протокол, а ещё и закрыть сам файл от прямого доступа, можно добавить отдельную проверку на раннем этапе загрузки:
<?php
/**
* Plugin Name: Block XML-RPC requests
*/
add_action( 'init', function () {
if ( defined( 'XMLRPC_REQUEST' ) && XMLRPC_REQUEST ) {
status_header( 403 );
exit;
}
}, 0 );Первый вариант обычно достаточно безопасен. Второй жёстче и полезен, если нужно гарантированно прервать обработку запроса.
Вариант 2: отключить pingback и trackback
Если вы не используете pingback, имеет смысл убрать и связанные механизмы. Это не равно полному отключению XML-RPC, но снижает шум и часть нежелательных запросов.
<?php
add_filter( 'xmlrpc_methods', function( $methods ) {
unset( $methods['pingback.ping'] );
return $methods;
} );
add_filter( 'pings_open', '__return_false' );Этот вариант полезен, если вам нужно оставить XML-RPC для редкой интеграции, но убрать pingback как источник мусора.
Вариант 3: закрыть xmlrpc.php на уровне сервера
Если вы уверены, что endpoint не нужен вообще, можно блокировать его до WordPress. Для Apache это обычно делают через .htaccess, для Nginx — через location.
<Files xmlrpc.php>
Require all denied
</Files>Для Nginx правило выглядит так:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Серверный блок даёт лучший эффект по производительности и безопасности, но его нужно вносить аккуратно, особенно если на сайте уже есть сложные правила для кэша, REST API или защиты админки.
Как проверить, что отключение сработало
Проверка должна быть не только «страница не открывается», но и «ничего лишнего не сломалось». Сначала убедитесь, что endpoint больше не принимает запросы. Затем проверьте сценарии, которые могли использовать XML-RPC.
- откройте
/xmlrpc.phpв браузере или черезcurl; - проверьте, что мобильное приложение WordPress не используется для публикации;
- если есть внешние сервисы автопостинга, сделайте тестовый запуск;
- посмотрите логи на предмет ошибок 401/403/404 по
xmlrpc.php; - убедитесь, что редакторы могут публиковать записи обычным способом через админку.
Хороший признак — в логах остаются только заблокированные попытки доступа, а рабочие процессы редакции не меняются.
Частые ошибки и как их исправить
Отключили XML-RPC, а сломалась публикация из внешнего сервиса
Значит, сервис действительно использовал XML-RPC. Решение простое: либо вернуть доступ, либо перевести интеграцию на REST API, если сервис это поддерживает. Не стоит держать endpoint открытым только ради старого инструмента, если есть нормальная замена.
Поставили плагин, но xmlrpc.php всё равно отвечает
Некоторые плагины отключают только методы XML-RPC, но не блокируют сам файл. Это не всегда ошибка, но если вам нужен именно запрет доступа, используйте серверное правило или mu-plugin с ранним завершением запроса.
Сломались pingback-уведомления на старом сайте
Это ожидаемо, если вы отключили связанные методы. Если pingback вам нужен, не рубите всё целиком. Оставьте XML-RPC включённым и точечно отключите только лишние методы, либо ограничьте доступ по IP.
Добавили правило в .htaccess и получили 500
Обычно причина в неверном синтаксисе или конфликте с уже существующими директивами. Сначала откатите правило, затем проверьте конфигурацию на тестовом стенде. На сайтах с нестандартной структурой лучше начинать с кода в mu-plugin, а не с веб-сервера.
Безопасность и производительность: что ещё стоит сделать рядом
Отключение XML-RPC — не замена нормальной защите входа. Если у вас есть атаки на авторизацию, проверьте ещё и другие точки:
- ограничение попыток входа;
- двухфакторную аутентификацию для админов;
- обновления ядра, тем и плагинов;
- отключение неиспользуемых плагинов;
- проверку прав на файлы и доступов к админке.
Если нужен более широкий набор инструментов для чистки дублей, отключения лишнего и технической оптимизации, можно посмотреть Clearfy Pro. Но даже с таким плагином важно понимать, какие именно функции вы выключаете и зачем.
Когда XML-RPC лучше не трогать
Не отключайте его вслепую, если сайт живёт за счёт внешней публикации, старых мобильных клиентов или интеграций, которые вы не контролируете. В таких случаях сначала найдите зависимость, потом решайте, можно ли перевести её на REST API или другой канал.
Если же сайт обычный, а в логах видны только массовые запросы к /xmlrpc.php, отключение обычно оправдано. Главное — делать это контролируемо: сначала диагностика, потом точечное ограничение, затем проверка рабочих сценариев.