Как отключить XML-RPC в WordPress и не сломать REST API и мобильные приложения

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

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

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

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

Отключение особенно уместно, если вы видите:

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

Диагностика: что именно использует XML-RPC

Перед отключением проверьте не только плагины, но и реальные запросы. Самый простой способ — посмотреть access log веб-сервера и поискать обращения к xmlrpc.php. Если у вас есть SSH-доступ, это можно сделать так:

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

Если логов нет под рукой, проверьте установленные интеграции:

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

Чем XML-RPC отличается от REST API

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

Пошаговое решение: как отключить XML-RPC безопасно

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

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

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

Этот вариант отключает сам механизм XML-RPC, но не трогает REST API. Для большинства сайтов этого достаточно.

Вариант 2. Закрыть доступ к файлу на уровне сервера

Если вы точно знаете, что XML-RPC не нужен, можно заблокировать прямой доступ к xmlrpc.php. Для Nginx это обычно делают отдельным правилом:

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

Для Apache можно использовать правило в .htaccess:

<Files xmlrpc.php>
    Require all denied
</Files>

Этот способ жёстче, чем фильтр WordPress. Он полезен, если на сайт идёт много мусорных запросов и вы хотите отрезать их ещё до загрузки WordPress.

Вариант 3. Использовать плагин безопасности

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

Проверка результата после внедрения

После отключения нужно проверить не только факт блокировки, но и побочные эффекты.

• Откройте /xmlrpc.php в браузере или через curl — доступ должен быть закрыт или возвращать ожидаемый ответ.
• Проверьте, что REST API отвечает: /wp-json/ должен открываться без ошибок.
• Если используете мобильное приложение WordPress, попробуйте авторизацию и публикацию тестовой записи.
• Посмотрите логи сервера: количество запросов к xmlrpc.php должно снизиться или исчезнуть.

Пример проверки через curl:

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

Если xmlrpc.php закрыт, а /wp-json/ отвечает нормально, базовая настройка сделана правильно.

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

Отключили XML-RPC и сломали мобильное приложение

Такое бывает, если сайт всё ещё использует старый клиент WordPress или сторонний сервис публикации через XML-RPC. Решение простое: верните доступ, найдите конкретную интеграцию и переведите её на REST API или другой способ авторизации.

Поставили сразу несколько блокировок

Когда XML-RPC отключают и фильтром WordPress, и правилом сервера, и ещё плагином, потом сложно понять, что именно сломало интеграцию. Начинайте с одного способа. Если нужен быстрый откат — фильтр в мини-плагине удобнее всего.

Перепутали XML-RPC и REST API

Это самая частая ошибка. REST API не отключается автоматически вместе с XML-RPC. Если после правки перестал работать редактор блоков или интеграция плагина, ищите проблему в другом месте: авторизация, кэш, CORS, права доступа или отдельные ограничения безопасности.

Закрыли файл, но не убрали лишние запросы

Если сайт постоянно получает атаки на xmlrpc.php, полезно не только закрыть файл, но и проверить WAF, rate limiting и правила на уровне CDN или веб-сервера. Иначе вы просто будете получать много 403 в логах без реального снижения нагрузки.

Что ещё стоит проверить для безопасности и производительности

Если вы уже занимаетесь этой частью сайта, имеет смысл посмотреть и соседние настройки:

• отключение pingback и trackback, если они не нужны;
• ограничение попыток входа в админку;
• защита wp-login.php через дополнительную авторизацию или WAF;
• проверка, не генерирует ли сайт лишние ответы 404 и 301 на технические URL.

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

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

• Проверить, используется ли мобильное приложение WordPress.
• Посмотреть логи на обращения к xmlrpc.php.
• Убедиться, что внешние интеграции не завязаны на XML-RPC.
• Выбрать один способ отключения: код, сервер или плагин.
• После правки протестировать /wp-json/ и основные сценарии входа/публикации.

Если сайт небольшой и интеграций немного, обычно хватает фильтра xmlrpc_enabled. Если на сервер идёт заметный поток мусорных запросов, лучше закрывать доступ ещё и на уровне веб-сервера. Главное — не отключать вслепую и не путать XML-RPC с REST API.