XML-RPC в WordPress часто отключают ради безопасности, но на живом сайте это не всегда безболезненно. Через этот интерфейс работают старые мобильные клиенты, внешние сервисы публикации, некоторые интеграции и пингбеки. Если просто закрыть файл на уровне сервера, можно неожиданно сломать автопостинг, удалённое редактирование и часть мониторинга.
Ниже — рабочий сценарий: как понять, нужен ли XML-RPC именно вашему сайту, как отключить его аккуратно и как проверить, что ничего лишнего не отвалилось.
Когда XML-RPC действительно стоит отключать
Если сайт управляется только через wp-admin и не использует внешние приложения, XML-RPC обычно не нужен. На практике его оставляют включённым по инерции, а потом получают лишнюю поверхность атаки. Особенно это заметно на сайтах, где нет мобильного приложения WordPress, нет интеграций с Zapier-подобными сервисами и не используются удалённые публикации.
Но есть и обратная сторона: если вы отключите XML-RPC наугад, можно сломать:
- публикацию через внешние клиенты и приложения;
- интеграции с сервисами автопостинга;
- пингбеки и трекбеки, если они ещё используются;
- некоторые старые плагины, которые до сих пор обращаются к
xmlrpc.php.
Диагностика: используется ли XML-RPC сейчас
Сначала проверьте, есть ли реальные обращения к /xmlrpc.php. Самый простой способ — посмотреть логи веб-сервера или статистику в панели хостинга. Если там есть регулярные запросы не только от ботов, значит интерфейс, скорее всего, задействован.
Что искать в логах
В access.log обычно видны запросы к xmlrpc.php с разными методами, например POST. Если запросы идут от известных сервисов или ваших собственных IP, это повод не рубить доступ сразу, а сначала понять источник.
Если доступа к логам нет, можно временно включить простую проверку через браузер: откройте /xmlrpc.php. В ответе WordPress обычно возвращает сообщение о том, что XML-RPC сервер принимает только POST-запросы. Это не доказывает использование, но подтверждает, что файл доступен извне.
Быстрый чек-лист перед отключением
- Проверьте, публикуете ли вы записи из мобильного приложения WordPress.
- Посмотрите, есть ли интеграции с внешними сервисами публикации.
- Проверьте логи на обращения к
xmlrpc.php. - Убедитесь, что на сайте не используются старые плагины с удалённым API.
- Сделайте резервную копию файлов и базы перед изменениями.
Как отключить XML-RPC: три рабочих варианта
Выбор зависит от того, где вам удобнее контролировать доступ: в коде, на уровне плагина или на сервере. Для большинства сайтов достаточно одного аккуратного способа. Не стоит включать сразу несколько блокировок, если потом будет сложно понять, что именно сломало интеграцию.
| Способ | Плюсы | Минусы |
|---|---|---|
| Код в теме или mu-plugin | Прозрачно, легко откатить | Нужно не забыть про обновления и место размещения |
| Плагин безопасности | Быстро без правки кода | Может добавлять лишнюю логику и зависеть от настроек |
| Серверная блокировка | Режет запросы раньше WordPress | Нужно аккуратно настроить, чтобы не блокировать лишнее |
Вариант 1: отключить XML-RPC через код
Если нужен контролируемый и обратимый способ, добавьте фильтр в functions.php дочерней темы или, лучше, в небольшой mu-plugin. Для mu-plugin код переживёт смену темы и не потеряется при обновлении.
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );
Этот вариант отключает сам XML-RPC на уровне WordPress. При обращении к xmlrpc.php сервер файл отдаст, но WordPress не будет принимать запросы как рабочий XML-RPC endpoint.
Вариант 2: закрыть доступ на уровне сервера
Если задача — не просто отключить функцию, а ещё и уменьшить лишние запросы, можно заблокировать сам файл. Для Apache это обычно делают через .htaccess, для Nginx — через конфигурацию сайта.
Для Apache:
<Files xmlrpc.php>
Require all denied
</Files>
Для Nginx логика обычно выносится в конфиг виртуального хоста:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}
Серверная блокировка полезна, если вы хотите отсечь массовые обращения ещё до загрузки WordPress. Но если позже понадобится внешний клиент, придётся править конфиг снова.
Вариант 3: использовать плагин безопасности
Если на сайте уже стоит плагин безопасности, проверьте, есть ли у него отдельная опция отключения XML-RPC. Это удобно, когда вы управляете сайтом не только как разработчик, но и как администратор без доступа к коду. Минус в том, что в плагинах названия опций и поведение отличаются, поэтому перед включением блокировки стоит прочитать, что именно делает настройка: отключает ли она только XML-RPC или ещё и pingbacks.
Пошаговое решение без лишнего риска
Ниже — последовательность, которая обычно даёт предсказуемый результат и позволяет быстро откатиться, если что-то пошло не так.
- Проверьте логи и список интеграций.
- Сделайте резервную копию.
- Выберите один способ блокировки: код или сервер.
- Внедрите изменение на staging, если он есть.
- Проверьте доступ к сайту и внешние сценарии публикации.
- Только после этого переносите на production.
Если вы работаете через код, лучше вынести отключение в mu-plugin. Это минимизирует риск случайно потерять правку при смене темы. Пример файла wp-content/mu-plugins/disable-xmlrpc.php:
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );
Если нужен более жёсткий вариант, можно дополнительно закрыть xmlrpc.php на сервере. Но делайте это только после проверки, что сайт не использует удалённые публикации и сторонние клиенты.
Как проверить, что отключение сработало
Проверка должна быть не только визуальной. Откройте /xmlrpc.php в браузере и отправьте тестовый POST-запрос любым удобным способом, например через curl. Если XML-RPC отключён корректно, вы не должны получить рабочий ответ метода.
curl -i -X POST https://example.com/xmlrpc.php \
-H 'Content-Type: text/xml' \
--data '<?xml version="1.0"?><methodCall><methodName>system.listMethods</methodName></methodCall>'
Что считать нормальным результатом:
- методы XML-RPC больше не выполняются;
- в логах нет успешных обращений к endpoint;
- основной сайт и wp-admin работают без ошибок;
- внешние интеграции, если они были, либо переведены на другой способ, либо осознанно отключены.
Если после блокировки сайт продолжает отвечать на XML-RPC-запросы, значит вы отключили не тот слой. Частая причина — код добавили в неактивную тему или в файл, который не загружается.
Частые ошибки и как их исправить
Отключили XML-RPC, но забыли про интеграцию
Симптом: перестала работать публикация из внешнего сервиса или мобильного приложения. Решение простое — либо вернуть доступ, либо перенести интеграцию на другой API, если сервис это поддерживает. Не пытайтесь “починить” проблему повторным включением случайных плагинов безопасности, если причина уже понятна.
Заблокировали файл на сервере и получили 403 в неожиданных местах
Иногда хостинг или прокси-кеш добавляют свои правила, и в результате блокируется не только XML-RPC, но и соседние маршруты. Проверьте, что правило применяется именно к /xmlrpc.php, а не к каталогу или всему сайту.
Использовали несколько способов сразу
Если вы одновременно включили настройку в плагине, добавили фильтр в код и закрыли файл через сервер, потом трудно понять, что именно мешает. Для диагностики оставляйте один активный слой блокировки и документируйте его в репозитории или в заметке для команды.
Сломали обновление или деплой
Если правка была внесена прямо в родительскую тему, она может исчезнуть после обновления. Для таких задач лучше использовать mu-plugin или отдельный мини-плагин в репозитории проекта.
Безопасность и производительность: что ещё имеет смысл проверить
Отключение XML-RPC — не универсальная защита, а один из шагов. Если цель — уменьшить лишние запросы и поверхность атаки, проверьте ещё:
- не включён ли REST API без ограничений там, где он не нужен;
- нет ли открытых форм входа с простыми паролями;
- не генерирует ли сайт лишние запросы к внешним сервисам на каждом хите;
- не раздута ли база мусорными ревизиями и автосохранениями;
- не стоит ли кеш-плагин, который конфликтует с серверными правилами.
Если на сайте уже используется Clearfy Pro, у него есть инструменты для чистки технического мусора и управления частью SEO/служебных настроек. Но даже с плагином лучше понимать, что именно вы отключаете и почему, а не полагаться на одну кнопку без проверки последствий.
Практика здесь простая: сначала выясняете, нужен ли XML-RPC, потом отключаете одним способом, затем проверяете реальные сценарии. Такой порядок экономит время на откате и помогает не сломать то, что ещё используется в проекте.