XML-RPC в WordPress часто отключают ради безопасности, но делают это грубо: ставят плагин, который режет всё подряд, и потом внезапно перестают работать мобильные клиенты, внешние публикации и часть интеграций. Если задача именно в том, чтобы убрать старый вектор атак и при этом не сломать REST API, лучше действовать точечно.
Ниже разберём, как понять, нужен ли вам XML-RPC вообще, чем его безопасно отключить и как проверить, что сайт после изменений не потерял рабочие сценарии.
Когда XML-RPC действительно стоит отключать
XML-RPC нужен в основном для старых сценариев: удалённая публикация, некоторые внешние клиенты, pingback и trackback. В современных установках WordPress большая часть задач уже решается через REST API, админку или прямую интеграцию плагинов. Поэтому если вы не используете старые приложения и не публикуете записи через XML-RPC, его можно убрать без заметного ущерба.
Но есть важная оговорка: не путайте XML-RPC и REST API. Это разные механизмы. Отключение XML-RPC не должно ломать /wp-json/, редактор блоков, мобильное приложение WordPress и интеграции, которые работают через REST.
Диагностика: что именно у вас использует XML-RPC
Перед отключением проверьте, есть ли реальные обращения к xmlrpc.php. На живом сайте это можно увидеть в логах веб-сервера, в панели хостинга или в WAF/Cloudflare, если он у вас подключён. Если в логах регулярно встречаются запросы к /xmlrpc.php с ошибками авторизации, это не обязательно значит, что XML-RPC нужен вам. Часто это просто перебор паролей.
Что проверить вручную
- Используете ли вы мобильное приложение WordPress для публикации и редактирования.
- Есть ли внешние сервисы, которые отправляют записи через XML-RPC.
- Нужны ли pingback и trackback на сайте вообще.
- Не завязаны ли на XML-RPC старые интеграции с CMS, CRM или скриптами публикации.
Если ответ на все пункты отрицательный, отключение XML-RPC обычно безопасно. Если хотя бы один сценарий нужен, лучше сначала перевести его на REST API или другой способ интеграции.
Как отключить XML-RPC без блокировки REST API
Самый надёжный вариант — отключить именно обработку XML-RPC на уровне WordPress, а не резать весь трафик по шаблону в .htaccess или nginx без понимания последствий. Для этого достаточно небольшого кода в плагине или в functions.php дочерней темы. Но для боевого сайта я бы всё же вынес это в мини-плагин, чтобы не зависеть от темы.
Вариант 1: отключить XML-RPC через фильтр
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );
Этот вариант отключает сам XML-RPC, но не трогает REST API. Если у вас нет других ограничений на уровне сервера, /wp-json/ продолжит работать как обычно.
Вариант 2: заблокировать только xmlrpc.php на уровне сервера
Если вам нужно именно отрезать доступ к файлу xmlrpc.php, можно сделать это на уровне веб-сервера. Такой способ полезен, когда на сайт идёт много мусорных запросов и вы хотите отсеять их ещё до загрузки WordPress.
Для Apache это может выглядеть так:
<Files xmlrpc.php>
Require all denied
</Files>
Для nginx обычно используют отдельное правило в конфигурации сайта:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}
Этот способ тоже не должен затрагивать REST API, потому что он работает по другому URL. Но если у вас нестандартная конфигурация, проверьте, не проксируется ли /wp-json/ через отдельные правила безопасности.
Сравнение подходов: плагин, код или сервер
| Способ | Что делает | Плюсы | Минусы |
|---|---|---|---|
Фильтр xmlrpc_enabled | Отключает XML-RPC внутри WordPress | Просто, не ломает REST API | Запрос до WordPress всё равно доходит |
| Правило в nginx/Apache | Блокирует xmlrpc.php на уровне сервера | Снимает нагрузку раньше, чем загрузится WP | Нужен доступ к конфигу сервера |
| Плагин безопасности | Отключает XML-RPC и/или pingback | Удобно для админов без доступа к серверу | Лишняя зависимость, иногда больше функций, чем нужно |
Если у вас есть доступ к конфигу сервера, блокировка на уровне nginx или Apache обычно предпочтительнее. Если доступа нет, используйте фильтр в WordPress. Плагин имеет смысл только тогда, когда вам нужно централизованно управлять несколькими настройками безопасности и вы доверяете его логике.
Пошаговое решение для боевого сайта
- Проверьте, не используется ли XML-RPC внешними сервисами или мобильным приложением.
- Сделайте резервную копию конфигурации сайта и, если возможно, тест на staging.
- Выберите один способ отключения: фильтр WordPress или правило сервера.
- После внедрения проверьте, что
/xmlrpc.phpнедоступен, а/wp-json/открывается. - Посмотрите логи на предмет новых ошибок и убедитесь, что интеграции продолжают работать.
Если вы ведёте несколько сайтов, удобно сначала применить изменение на одном проекте и проверить типовые сценарии: вход в админку, публикацию записи, работу редактора блоков, REST-запросы от плагинов и внешних сервисов.
Как проверить, что решение сработало
Проверка должна быть не только визуальной. Откройте /xmlrpc.php в браузере или через curl. В зависимости от способа блокировки вы увидите либо запрет доступа, либо стандартный ответ WordPress о том, что XML-RPC сервер принимает только POST-запросы. Главное — убедиться, что метод, который вы выбрали, действительно сработал.
curl -I https://example.com/xmlrpc.php
curl -I https://example.com/wp-json/
Если REST API жив, а XML-RPC закрыт, значит базовая цель достигнута. Дополнительно проверьте:
- открывается ли редактор блоков в админке;
- работают ли формы и плагины, которые используют REST API;
- не появились ли ошибки 403/404 в логах для других маршрутов;
- не сломалась ли авторизация в стороннем приложении, если оно у вас есть.
Частые ошибки и как их исправить
Блокируют не только XML-RPC, но и весь REST API
Такое бывает, когда в правилах безопасности режут запросы по слову api или по слишком широкому шаблону. Исправление простое: ограничьте правило только /xmlrpc.php и не трогайте /wp-json/.
Отключили XML-RPC, а атаки в логах остались
Это нормально, если сканеры продолжают стучаться в файл по старым спискам. Они не опасны сами по себе, если сервер отвечает быстро и без загрузки WordPress. Чтобы снизить шум, блокируйте запросы на уровне nginx/Apache или через WAF.
Сломалось мобильное приложение WordPress
Значит, оно всё ещё использовало XML-RPC в вашем сценарии. В этом случае либо возвращайте доступ, либо переводите процесс публикации на REST API и другой клиент. Не оставляйте отключение в проде, пока не проверите рабочий процесс редакции.
Использовали плагин, который отключил больше, чем нужно
Некоторые плагины безопасности умеют выключать pingback, REST API, авторизацию по XML-RPC и ещё несколько функций сразу. Если после установки начались побочные эффекты, уберите плагин и замените его точечным кодом или серверным правилом.
Практические советы по безопасности и производительности
Если цель — снизить поверхность атаки, одного отключения XML-RPC мало. Проверьте ещё несколько вещей: не оставлены ли открытыми лишние endpoints, не включён ли pingback без необходимости, не светится ли админка через слабые пароли и нет ли старых плагинов с известными уязвимостями.
Для сайтов с повышенной нагрузкой серверная блокировка xmlrpc.php полезнее, чем обработка запроса внутри WordPress: так вы экономите PHP-процессы и уменьшаете мусорный трафик. Если у вас уже стоит комплексный плагин для чистки сайта и удаления дублей, например Clearfy Pro, проверьте, не дублирует ли он ваши ручные правила безопасности. Лишние пересечения только усложняют диагностику.
И ещё один практический момент: если вы отключаете XML-RPC на staging, не забудьте повторить проверку на production отдельно. На тестовом стенде часто нет тех внешних интеграций, которые реально используются на боевом сайте.