Как отключить XML-RPC в WordPress и проверить, что он больше не доступен

Автор: Максим Комаров | Опубликовано: 16.08.2026

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

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

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

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

Но есть и исключения. Не отключайте XML-RPC, если вы точно используете:

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

Диагностика проблемы: как понять, что XML-RPC активен

Самый быстрый тест — открыть https://ваш-домен/xmlrpc.php в браузере. Если файл доступен, вы обычно увидите сообщение вроде XML-RPC server accepts POST requests only. Это не ошибка, а признак того, что endpoint жив.

Дополнительно посмотрите логи веб-сервера. Типичный признак — регулярные POST-запросы к /xmlrpc.php. Если сайт под нагрузкой, такие запросы могут создавать лишний шум и иногда влиять на производительность, особенно если их много и они идут с одного или нескольких адресов.

Что проверить перед отключением

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

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

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

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

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

После этого WordPress перестанет принимать XML-RPC-запросы на уровне ядра. Это самый чистый вариант, если вам не нужно тонкое исключение по IP или по отдельным методам.

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

Если у вас Apache и вы хотите отсечь запросы еще до WordPress, можно заблокировать сам файл xmlrpc.php через .htaccess. Это полезно, когда нужно снизить нагрузку на PHP и не отдавать обработку ядру WordPress.

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

Для Nginx логика другая: блокировку обычно добавляют в конфигурацию виртуального хоста. Пример рабочий, но его нужно вставлять именно в server-блок, а не в файл WordPress:

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

Если вы не уверены в конфигурации сервера, сначала проверьте изменения на staging-копии. Ошибка в конфиге Nginx или Apache может уронить сайт целиком, а не только XML-RPC.

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

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

Способ	Плюсы	Минусы
Фильтр `xmlrpc_enabled`	Просто, прозрачно, работает на уровне WordPress	Запрос все равно доходит до PHP
Блокировка на сервере	Режет запрос раньше, экономит ресурсы	Нужен доступ к конфигу сервера
Плагин	Быстро включить без кода	Зависимость от стороннего решения

Как проверить, что XML-RPC больше не доступен

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

Откройте /xmlrpc.php в браузере.
Проверьте ответ через curl.
Посмотрите логи веб-сервера и PHP-FPM после тестового запроса.

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

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

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

Для более точной проверки можно отправить тестовый POST-запрос. Если 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>'

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

Отключили не там, где нужно

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

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

Открытие xmlrpc.php в браузере не всегда показывает реальное состояние. Нужен именно POST-запрос, потому что XML-RPC работает через POST.

Сломали нужную интеграцию

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

Поставили плагин и забыли о нем

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

Практические советы по безопасности и производительности

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

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

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

Что должно измениться после внедрения

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

Самый надежный порядок такой: сначала проверить, нужен ли XML-RPC вообще, затем отключить его на уровне WordPress или сервера, после этого протестировать POST-запросы и только потом удалять временные меры, если они были.