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

Автор: Евгения Николаева | Опубликовано: 12.09.2026

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

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

Когда XML-RPC реально нужен

Сначала стоит проверить, есть ли у сайта зависимость от этого интерфейса. В реальных проектах XML-RPC чаще всего нужен в трёх случаях: старые мобильные клиенты WordPress, внешние сервисы публикации и некоторые плагины синхронизации. Отдельно стоит помнить про pingback и trackback — они тоже идут через этот механизм, но на большинстве сайтов их давно отключают из-за спама и лишней нагрузки.

Что обычно можно отключать безболезненно

pingback и trackback, если вы не используете их сознательно;
удалённую публикацию из старых клиентов;
доступ к xmlrpc.php для всех, кроме явно нужных сервисов;
методы, которые создают лишний шум и нагрузку на сервер.

Диагностика: кто обращается к xmlrpc.php

Перед изменениями посмотрите логи веб-сервера. Если в access log регулярно встречается /xmlrpc.php, это уже сигнал, что доступ используется. Важно не гадать, а проверить фактические запросы: IP, User-Agent, частоту и статус ответа.

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

Если логов много, полезно посмотреть, не идёт ли это от конкретного сервиса или бота. Иногда XML-RPC атакуют брутфорсом, и тогда запросы будут массовыми, с повторяющимися методами вроде system.multicall и wp.getUsersBlogs.

Ещё один практический тест — временно ограничить доступ и проверить, не сломались ли:

мобильное приложение WordPress;
Jetpack, если он у вас подключён;
внешняя автопубликация;
интеграции с CRM или планировщиками контента.

Как отключить XML-RPC в WordPress

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

Способ	Плюсы	Минусы	Когда использовать
Плагин	Быстро, без правки кода	Лишняя зависимость	Если нужен простой переключатель
Код в теме/му-плагине	Контроль, без лишних плагинов	Нужно аккуратно тестировать	Если есть доступ к коду сайта
Веб-сервер	Режет запросы раньше WordPress	Нужен доступ к конфигу	Если нужно снизить нагрузку и шум

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

Самый предсказуемый способ — добавить фильтр в functions.php дочерней темы или, лучше, в mu-plugin. Для полного отключения WordPress сам перестанет обслуживать XML-RPC.

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

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

<?php
add_filter( 'xmlrpc_methods', function( $methods ) {
    unset( $methods['pingback.ping'] );
    unset( $methods['pingback.extensions.getPingbacks'] );
    unset( $methods['wp.getUsersBlogs'] );
    return $methods;
} );

Такой вариант не всегда заменяет полный запрет, но помогает точечно убрать лишнее. Для большинства сайтов, где XML-RPC не нужен вообще, проще и надёжнее использовать первый вариант.

Вариант 2: закрыть доступ на уровне сервера

Если у вас Nginx, можно отдать 403 ещё до загрузки WordPress. Это полезно, когда XML-RPC активно атакуют и вы хотите сэкономить ресурсы PHP.

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

Для Apache обычно используют правило в .htaccess:

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

Но здесь важно понимать компромисс: если потом выяснится, что какой-то сервис всё-таки использует XML-RPC, он перестанет работать сразу. Поэтому сначала проверьте зависимости, а уже потом закрывайте файл на уровне сервера.

Вариант 3: использовать плагин

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

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

Проверьте access log и найдите обращения к xmlrpc.php.
Сверьте список интеграций: Jetpack, мобильные клиенты, внешняя публикация, CRM.
Если XML-RPC не нужен, добавьте add_filter( 'xmlrpc_enabled', '__return_false' ); в mu-plugin.
Если нужен только частично, отключите лишние методы через xmlrpc_methods.
При высокой нагрузке дополнительно закройте xmlrpc.php на уровне Nginx или Apache.
После изменений проверьте ответ /xmlrpc.php и работу всех интеграций.

Для mu-plugin достаточно создать файл, например wp-content/mu-plugins/disable-xmlrpc.php. Это удобнее, чем править тему: код не потеряется при обновлении и не зависит от шаблона.

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

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

Проверка должна быть не формальной, а прикладной. Откройте https://example.com/xmlrpc.php в браузере или через curl. Если XML-RPC отключён на уровне WordPress, обычно вы увидите сообщение о том, что XML-RPC отключён, либо получите отказ в доступе, если блокировка идёт на сервере.

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

Дальше проверьте три вещи:

нет ли новых ошибок в логах после отключения;
не перестали ли отправляться записи из внешнего сервиса;
не появились ли 403/404 в местах, где их быть не должно.

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

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

Отключили XML-RPC, но забыли про внешнюю публикацию

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

Закрыли файл на сервере, но не проверили логи

Если запросы продолжаются, вы не поймёте, кто ломится в xmlrpc.php. Сначала посмотрите источник запросов, потом решайте, нужен ли rate limit, WAF или полная блокировка.

Добавили код в активную тему

При смене темы защита исчезнет. Для технических ограничений лучше использовать mu-plugin или отдельный мини-плагин.

Отключили pingback, но оставили XML-RPC открытым

Это не ошибка, если вам нужен сам интерфейс. Но если цель — снизить поверхность атаки, одного отключения pingback недостаточно. Брутфорс и перебор методов всё равно возможны.

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

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

не включены ли pingback и trackback в настройках обсуждения;
не используются ли старые интеграции, которые можно перевести на REST API;
не стоит ли ограничить частоту запросов к чувствительным точкам входа;
не дублируют ли друг друга серверные правила и плагины безопасности.

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

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