Как отключить XML-RPC в WordPress без поломки сайта и лишних рисков

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

Ниже — рабочая схема: как понять, нужен ли XML-RPC именно вашему сайту, как отключить его безопасно, чем проверить результат и какие ошибки встречаются чаще всего.

Когда XML-RPC действительно стоит отключать

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

Но отключение имеет смысл только после проверки зависимостей. Если у вас есть:

• мобильное приложение WordPress для публикации;
• Jetpack или похожий сервис, который использует XML-RPC;
• внешняя CMS/скрипт, отправляющий записи через XML-RPC;
• старые пингбеки и трекбеки, которые ещё где-то используются;

— сначала убедитесь, что это не сломает рабочий процесс.

Быстрая диагностика: нужен ли вам xmlrpc.php

Самый простой способ — посмотреть, есть ли обращения к /xmlrpc.php в логах веб-сервера или в журнале безопасности. Если запросы есть, это ещё не значит, что интерфейс нужен: часто это сканеры и попытки перебора.

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

# Пример поиска обращений в access.log
# путь зависит от конфигурации сервера
grep "xmlrpc.php" /var/log/nginx/access.log | tail -n 20

Как отключить XML-RPC: три рабочих варианта

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

Вариант 1: отключить через код

Если у вас есть доступ к теме или, лучше, к mu-plugin, можно отключить XML-RPC через фильтр xmlrpc_enabled. Это понятный и обратимый способ.

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

Такой код можно положить в отдельный файл в wp-content/mu-plugins/disable-xmlrpc.php. Плюс mu-plugin в том, что он не зависит от активной темы и не исчезнет после обновления шаблона.

Вариант 2: блокировка на уровне nginx

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

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

После изменения конфигурации проверьте синтаксис и перезагрузите nginx. Это уже серверная задача, поэтому на общем хостинге такой вариант может быть недоступен.

Вариант 3: через плагин безопасности или чистки

Если вы уже используете плагин для технической оптимизации, проверьте, есть ли в нём отключение XML-RPC. Например, в Clearfy Pro есть набор функций для чистки WordPress и отключения лишнего технического мусора; это удобно, если вы хотите управлять такими настройками из одной панели. Ссылка: https://wpshop.ru/plugins/clearfy

Но даже в этом случае не стоит включать всё подряд. Сначала отключайте только то, что действительно не используется, и проверяйте сайт после каждого изменения.

Пошаговое решение без сюрпризов

Ниже — порядок, который я бы использовал на рабочем проекте.

1. Проверить, есть ли реальные зависимости от XML-RPC.
2. Сделать резервную копию конфигурации и файлов.
3. Отключить XML-RPC одним способом, а не несколькими сразу.
4. Проверить ответ xmlrpc.php и рабочие сценарии публикации.
5. Посмотреть логи на предмет ошибок и неожиданных 403/500.

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

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

После этого зайдите на https://example.com/xmlrpc.php. В зависимости от конфигурации сервера и кода вы увидите либо сообщение о том, что XML-RPC отключён, либо 403/404. Сам по себе код ответа не так важен, как отсутствие доступа к методам XML-RPC.

Как проверить, что решение сработало

Проверка должна быть не только технической, но и прикладной. Сайт может отдавать 403 на xmlrpc.php, но при этом какой-то внешний сервис всё ещё будет пытаться публиковать записи и падать с ошибкой.

Что проверить вручную

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

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

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

Можно быстро посмотреть, как отвечает endpoint:

curl -I https://example.com/xmlrpc.php

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

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

Самая распространённая ошибка — отключить XML-RPC и не проверить зависимости. Вторая по частоте — сделать это одновременно в плагине, в теме и на сервере, а потом не понимать, какой именно слой блокирует запрос.

• Ошибка: отключили XML-RPC, а мобильное приложение перестало публиковать.
  Причина: приложение использовало XML-RPC, а альтернативу не настроили.
  Что делать: вернуть доступ или перевести публикацию на REST API/админку.
• Ошибка: сайт отдаёт 403 на xmlrpc.php, но атаки в логах не исчезли.
  Причина: сканеры продолжают стучаться, а блокировка происходит уже после входа в PHP.
  Что делать: добавить серверный запрет и ограничение на уровне WAF/фаервола.
• Ошибка: после правки functions.php сайт стал падать.
  Причина: синтаксическая ошибка или правка в активной теме, которая обновилась.
  Что делать: перенести код в mu-plugin и проверить файл на синтаксис.

Безопасность и производительность: что ещё имеет смысл сделать

Отключение XML-RPC само по себе не решает все проблемы безопасности, но убирает один из популярных векторов атак. Если сайт часто сканируют, дополнительно стоит:

• ограничить частоту запросов к /wp-login.php;
• использовать сложные пароли и двухфакторную аутентификацию для админов;
• проверить, не включены ли лишние pingback/trackback;
• убрать неиспользуемые плагины и темы;
• следить за логами 403 и 404, чтобы видеть аномалии.

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

Когда XML-RPC лучше не трогать

Если у вас есть рабочая интеграция, завязанная на XML-RPC, и перевести её быстро не получится, не ломайте процесс ради формальной «безопасности». В таком случае лучше ограничить доступ на уровне IP, добавить защиту от перебора и оставить интерфейс только для доверенных источников.

Практический подход здесь простой: сначала понять, кто и зачем обращается к xmlrpc.php, потом отключать или ограничивать доступ. Это надёжнее, чем ставить запрет вслепую и потом искать, почему перестала работать публикация.