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

Автор: Константин Кузнецов | Опубликовано: 24.08.2026

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

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

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

Но есть сценарии, где отключение ломает рабочий процесс:

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

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

Перед блокировкой посмотрите логи веб-сервера. Если endpoint уже активно дергают боты, это видно по частым POST-запросам к /xmlrpc.php. Для Nginx и Apache логика одинаковая: ищем сам путь и смотрим, есть ли реальные клиенты или только мусорный трафик.

# Nginx: быстрый поиск обращений к XML-RPC
grep "xmlrpc.php" /var/log/nginx/access.log | tail -n 50

# Apache
grep "xmlrpc.php" /var/log/apache2/access.log | tail -n 50

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

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

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

Как отключить XML-RPC: сравнение подходов

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

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

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

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

Такой вариант отключает сам механизм WordPress, но файл xmlrpc.php по-прежнему может отвечать на запросы. Для большинства сайтов этого уже достаточно, если цель — убрать функциональность, а не строить жёсткий firewall-барьер.

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

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

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

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

nginx -t
systemctl reload nginx

Вариант 3: блокировка в Apache

Для Apache можно использовать правила в .htaccess или конфигурации виртуального хоста. Если у вас shared-хостинг, чаще доступен только .htaccess.

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

Если сервер старый и использует Apache 2.2, синтаксис будет другим, но на современных установках лучше ориентироваться на Require all denied.

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

Проверьте, используется ли XML-RPC внешними сервисами: Jetpack, мобильные клиенты, автопостинг.
Посмотрите access log и убедитесь, что запросы к /xmlrpc.php не идут от легитимных источников.
Сначала отключите XML-RPC через xmlrpc_enabled на тестовой копии сайта.
Проверьте публикацию, вход в админку, REST API и все интеграции.
Если нужен более жёсткий барьер, добавьте блокировку на уровне Nginx или Apache.
После выката снова проверьте логи и убедитесь, что endpoint больше не используется.

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

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

Откройте https://example.com/xmlrpc.php — доступ должен быть закрыт или функция должна быть недоступна.
Попробуйте отправить тестовый XML-RPC запрос из внешнего клиента, если он у вас есть.
Проверьте, что REST API продолжает отвечать: /wp-json/ должен открываться как раньше.
Убедитесь, что форма входа, публикация записей и медиа-загрузка не изменились.
Посмотрите access log через 10–15 минут после изменения: новых успешных обращений к xmlrpc.php быть не должно.

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

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

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

Отключили XML-RPC, а Jetpack перестал синхронизироваться

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

Добавили правило в .htaccess, но сайт начал отдавать 500

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

Отключили XML-RPC через плагин, но endpoint всё равно отвечает

Так бывает, если плагин только частично ограничивает функциональность. Для жёсткого запрета нужен серверный уровень или фильтр xmlrpc_enabled. Если цель — безопасность, лучше не полагаться на «мягкое» отключение без проверки.

Сломали внешнюю интеграцию и не поняли какую

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

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

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

С точки зрения производительности выгода обычно небольшая, но заметная на шумных сайтах: меньше бесполезных POST-запросов, меньше нагрузки на PHP-FPM и базу. Если у вас высокий трафик ботов, закрытие endpoint может заметно разгрузить сервер в логах и по числу 4xx/5xx.

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

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