Как отключить XML-RPC в WordPress и не сломать нужные интеграции

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

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

Когда XML-RPC можно отключать без риска

Если у вас обычный сайт на WordPress, а публикация и администрирование идут только через wp-admin или REST API, XML-RPC чаще всего не нужен. Особенно это касается сайтов, где нет старых мобильных клиентов, внешних редакторов и сервисов автопостинга, завязанных именно на xmlrpc.php.

Перед отключением проверьте три вещи:

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

Быстрая диагностика по логам

Если есть доступ к access log веб-сервера, найдите обращения к xmlrpc.php. Это самый простой способ понять, используется ли endpoint вообще.

grep "xmlrpc.php" /var/log/nginx/access.log | tail -n 20

Если видите только повторяющиеся POST-запросы с одинаковых IP и без признаков вашего сервиса — это типичный шум, а не рабочая интеграция. Если же запросы идут с понятных адресов или от известных приложений, сначала разберитесь, что именно их вызывает.

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

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

Способ	Когда подходит	Плюсы	Минусы
Код в WordPress	Нужен быстрый и обратимый вариант	Легко откатить, не требует доступа к серверу	Запрос все равно доходит до WordPress
Правило на сервере	Нужно отсечь запросы раньше PHP	Меньше нагрузки, лучше для защиты	Требует доступа к конфигу Nginx/Apache
Плагин безопасности	Нужна настройка без кода	Удобно для админов без доступа к серверу	Лишняя зависимость от плагина

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

Самый предсказуемый способ — добавить фильтр xmlrpc_enabled. Лучше делать это в небольшом mu-plugin, чтобы настройка не зависела от темы.

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

Если не хотите создавать отдельный файл, можно добавить тот же код в functions.php дочерней темы. Но для технических настроек это хуже: при смене темы правило потеряется.

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

Если сервер под вашим контролем, лучше отрезать xmlrpc.php до запуска WordPress. Для Nginx это выглядит так:

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

Такой вариант полезен, если сайт регулярно получает мусорные запросы и вы хотите снизить нагрузку на PHP-FPM. Но перед применением убедитесь, что XML-RPC действительно не нужен ни одному сервису.

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

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

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

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

1. Сделайте резервную копию файлов и базы.
2. Проверьте, есть ли реальные обращения к xmlrpc.php в логах.
3. Выберите способ отключения: код, сервер или плагин.
4. Примените изменение на staging, если он есть.
5. Проверьте, не сломались ли внешние публикации и мобильные клиенты.
6. Только после этого переносите настройку на production.

Что проверить после отключения

После внедрения откройте в браузере /xmlrpc.php. В норме вы не должны видеть рабочий endpoint. В зависимости от способа блокировки это может быть 403, 404 или сообщение о том, что XML-RPC отключен. Главное — не должен выполняться полноценный ответ WordPress на XML-RPC-запросы.

Дополнительно проверьте:

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

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

Самый надежный тест — отправить запрос вручную и посмотреть ответ. Это можно сделать через curl:

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

Если вы закрывали endpoint на уровне сервера, ответ должен быть неуспешным еще до WordPress. Если использовали фильтр xmlrpc_enabled, поведение зависит от конфигурации и дополнительных правил, но endpoint не должен работать как раньше.

Для более точной проверки можно отправить XML-RPC метод, например system.listMethods. Если endpoint отключен корректно, запрос не пройдет.

curl -i -X POST https://example.com/xmlrpc.php \
  -H 'Content-Type: text/xml' \
  --data '<?xml version="1.0"?>
<methodCall>
  <methodName>system.listMethods</methodName>
  <params></params>
</methodCall>'

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

Отключили XML-RPC, а потом перестала работать публикация из внешнего сервиса

Значит, сервис был завязан именно на XML-RPC, а не на REST API. Решение простое: либо вернуть endpoint, либо перевести интеграцию на другой способ. Не стоит держать XML-RPC включенным только ради одного старого сценария, если его можно заменить.

Закрыли только через плагин, но запросы все равно идут

Плагин может отключать функциональность WordPress, но не всегда блокирует сам файл на уровне веб-сервера. В логах вы все равно будете видеть обращения к xmlrpc.php. Если цель — снизить нагрузку и шум, лучше добавить правило в Nginx или Apache.

Сломали REST API, перепутав его с XML-RPC

Это разные механизмы. Отключение XML-RPC не должно ломать REST API. Если после правок перестали работать мобильные приложения или редактор, проверьте, что вы не добавили слишком широкое правило в веб-сервере и не заблокировали лишние endpoints.

Сделали правило в теме, а потом потеряли его после обновления

Для системных ограничений не используйте обычную тему. Лучше mu-plugin или конфиг сервера. Так настройка не исчезнет при обновлении шаблона.

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

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

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

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

Короткий чек-лист перед отключением

• Проверил логи на реальные обращения к xmlrpc.php.
• Убедился, что не использую старые XML-RPC-интеграции.
• Выбрал способ отключения: код, сервер или плагин.
• Протестировал на staging или в окне обслуживания.
• Проверил, что REST API и обычная публикация работают.
• Посмотрел ответы curl и логи после изменения.

Если нужен именно безопасный и обратимый путь, начните с mu-plugin. Если цель — убрать нагрузку еще до PHP, переносите блокировку на уровень веб-сервера. Это тот случай, когда техническое решение должно быть не просто «выключено», а еще и проверяемо.