XML-RPC в WordPress часто отключают «на всякий случай», а потом внезапно перестают работать мобильное приложение, внешняя публикация через сторонний сервис или старый клиент для удалённой записи. Проблема в том, что это не просто лишний endpoint, а точка, через которую до сих пор ходят некоторые интеграции.
Если задача — убрать лишнюю поверхность атаки и снизить шум от брутфорса, отключать XML-RPC можно. Но делать это лучше после проверки, что сайт не использует /xmlrpc.php ни напрямую, ни через плагины и сервисы. Ниже — рабочая схема: как диагностировать зависимость, как отключить endpoint, как проверить результат и что делать, если что-то сломалось.
Когда XML-RPC действительно мешает
На практике XML-RPC обычно отключают в трёх сценариях:
- сайт не использует внешнюю публикацию и мобильные клиенты WordPress;
- в логах много запросов к
/xmlrpc.phpс попытками перебора паролей; - нужно сократить лишние точки входа на сайте без изменения основной логики WordPress.
Но если у вас подключены Jetpack, старое мобильное приложение WordPress, сервисы автопостинга или интеграции с удалённой публикацией, отключение может дать побочный эффект. Поэтому сначала нужна диагностика.
Диагностика: используется ли XML-RPC сейчас
Самый простой способ — посмотреть, кто обращается к /xmlrpc.php в логах веб-сервера. Если у вас есть доступ к access.log, ищите запросы к этому файлу:
grep "xmlrpc.php" /var/log/nginx/access.logЕсли видите только мусорные попытки авторизации, а легитимных запросов нет, отключение обычно безопасно. Если же в логах есть запросы с нормальным user-agent или с понятной периодичностью от ваших сервисов, сначала проверьте, что это за интеграция.
Ещё один практический тест — временно заблокировать XML-RPC на staging и проверить:
- вход через мобильное приложение WordPress;
- публикацию через внешние сервисы;
- работу Jetpack, если он установлен;
- любые плагины, которые умеют отправлять записи удалённо.
Если staging нет, хотя бы проверьте список активных плагинов и интеграций. Особенно внимательно смотрите на плагины для автопостинга, синхронизации контента и удалённого управления сайтом.
Как отключить XML-RPC в WordPress
Есть несколько рабочих вариантов. Выбор зависит от того, хотите ли вы просто закрыть endpoint, оставить его доступным для отдельных методов или сделать это через плагин.
Вариант 1: отключить через код в теме или mu-plugin
Если нужен контролируемый и прозрачный вариант, добавьте фильтр в functions.php дочерней темы или, лучше, в mu-plugin. Так настройка не потеряется при обновлении темы.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Это отключает XML-RPC целиком. Для большинства сайтов этого достаточно.
Если хотите не просто отключить функциональность, а ещё и убрать сам endpoint, можно дополнительно отдать 403 на запросы к xmlrpc.php на уровне веб-сервера или WordPress. В WordPress это можно сделать так:
<?php
add_action( 'init', function () {
if ( defined( 'XMLRPC_REQUEST' ) && XMLRPC_REQUEST ) {
status_header( 403 );
exit;
}
} );Этот вариант не заменяет серверную блокировку, но помогает, если запрос всё же дошёл до WordPress.
Вариант 2: закрыть на уровне Nginx или Apache
Если у вас есть доступ к конфигурации веб-сервера, это самый жёсткий и предсказуемый способ. Для Nginx можно добавить отдельное правило:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Для Apache можно использовать правило в .htaccess:
<Files "xmlrpc.php">
Require all denied
</Files>Серверная блокировка полезна тем, что запросы не доходят до PHP вообще. Это снижает нагрузку и убирает лишний шум в логах.
Вариант 3: отключить через плагин
Если код трогать не хочется, можно использовать плагин для hardening. Но здесь важен состав функций: некоторые плагины отключают XML-RPC вместе с другими настройками безопасности, и это не всегда удобно для точечной задачи.
В контексте комплексной чистки сайта и SEO-оптимизации часто удобнее использовать Clearfy Pro: он помогает централизованно отключать лишние функции WordPress, не разбрасывая настройки по теме и отдельным сниппетам. Это не магия, а просто более управляемый способ держать технические переключатели в одном месте.
| Способ | Плюсы | Минусы |
|---|---|---|
| Код в mu-plugin | Прозрачно, переносимо, без лишних зависимостей | Нужно не забыть про обновления и контроль изменений |
| Конфиг веб-сервера | Самый жёсткий и быстрый вариант | Нужен доступ к серверу и аккуратность с правилами |
| Плагин безопасности | Удобно для админов без доступа к серверу | Дополнительный слой, возможны лишние функции |
Пошаговое решение без сюрпризов
- Проверьте логи и убедитесь, что XML-RPC не используется легитимно.
- Если есть сомнения, сначала протестируйте отключение на staging.
- Выберите один способ: код, серверное правило или плагин. Не смешивайте сразу несколько без необходимости.
- После внедрения откройте
https://ваш-домен.ru/xmlrpc.phpв браузере или черезcurlи проверьте ответ. - Проверьте внешние сервисы, которые могут публиковать записи или синхронизировать контент.
Для быстрой проверки через консоль можно использовать такой запрос:
curl -I https://example.com/xmlrpc.phpЕсли всё отключено корректно, вы должны увидеть отказ в доступе на уровне сервера или пустой/заблокированный ответ в зависимости от выбранного метода. Главное — не получить рабочий XML-RPC-ответ с возможностью авторизации.
Как проверить, что решение сработало
Проверка должна быть не только технической, но и функциональной. Смотрите на три вещи:
- endpoint недоступен — запрос к
/xmlrpc.phpне проходит; - нет ошибок в логах — после отключения не появляются новые фатальные ошибки или предупреждения;
- интеграции работают — ничего важного не сломалось в публикации и синхронизации.
Если у вас есть мониторинг, добавьте отдельную проверку на доступность /xmlrpc.php. Это полезно, если endpoint закрыт на уровне сервера: так вы сразу увидите, если правило случайно удалили при деплое.
Частые ошибки и как их исправить
Отключили XML-RPC, а потом перестал работать Jetpack
Это ожидаемо: часть функций Jetpack исторически завязана на XML-RPC или связанные механизмы связи с WordPress.com. Решение простое — либо не отключать XML-RPC, либо пересмотреть набор функций Jetpack и оставить только то, что реально нужно.
Поставили плагин безопасности и забыли, что он уже блокирует endpoint
В итоге админ видит «двойную защиту», а на деле не понимает, какой слой что делает. Если используете плагин, проверьте, не дублируется ли правило в .htaccess, Nginx-конфиге или в другом security-плагине. Дублирование не всегда ломает сайт, но сильно усложняет диагностику.
Закрыли XML-RPC, но оставили старые интеграции без проверки
Самая неприятная ошибка — считать задачу решённой сразу после добавления фильтра. На практике нужно проверить не только сам endpoint, но и сценарии публикации, которые были настроены раньше. Особенно это касается сайтов, где контент отправляется из внешней CRM, редактора или мобильного приложения.
Использовали код в активной теме
После обновления темы настройка исчезает. Для таких переключателей лучше использовать mu-plugin или отдельный мини-плагин. Это надёжнее, чем держать техническую защиту в шаблоне.
Что ещё стоит сделать для безопасности и производительности
Отключение XML-RPC само по себе не делает сайт защищённым, но убирает одну лишнюю точку входа. Если вы уже занимаетесь технической чисткой, имеет смысл проверить и другие вещи:
- неиспользуемые REST-маршруты от старых плагинов;
- лишние ревизии и автосохранения, если сайт сильно разросся;
- дублирующиеся скрипты и стили в теме;
- тяжёлые плагины, которые создают лишнюю нагрузку на админку;
- наличие кеширования страниц и объекта, если сайт посещаемый.
Если вам нужен не разовый харднинг, а системная чистка WordPress с отключением лишних функций, удобнее держать такие настройки в одном месте. Для этого и полезны инструменты вроде Clearfy Pro: они помогают не расползаться по десятку сниппетов и не терять контроль над тем, что именно отключено на сайте.
Важный практический момент: не отключайте XML-RPC только потому, что «так советуют в интернете». Сначала проверьте зависимости, потом закрывайте endpoint, потом фиксируйте результат в логах и мониторинге. Тогда решение будет не декоративным, а рабочим.