XML-RPC в WordPress до сих пор включён на многих сайтах по умолчанию, хотя далеко не всем он нужен. Чаще всего его отключают из-за лишней поверхности атаки, брутфорса через xmlrpc.php и ненужных запросов от старых приложений. Но просто «запретить файл» недостаточно: важно понять, не сломаете ли вы мобильное приложение, внешнюю публикацию или интеграции с сервисами, которые всё ещё используют XML-RPC.
Когда XML-RPC стоит отключать, а когда нет
Если вы не пользуетесь приложением WordPress для iOS/Android, не публикуете записи через сторонние клиенты и не подключали старые сервисы синхронизации, XML-RPC обычно можно закрыть без последствий. На обычном сайте с редакторами в админке он часто не нужен вообще.
Если же у вас есть внешняя автоматизация, сначала проверьте, что именно ходит в xmlrpc.php. Иногда этот endpoint нужен не для публикации, а для пингов, удалённого редактирования или интеграции с устаревшим софтом. В таком случае лучше не рубить доступ вслепую, а ограничить его на уровне сервера или заменить интеграцию на REST API.
Диагностика: как понять, используется ли XML-RPC
Начните с простого теста. Откройте /xmlrpc.php в браузере. Если файл доступен, WordPress обычно отвечает сообщением о том, что это XML-RPC server accepts POST requests only. Это не ошибка, а признак того, что endpoint жив.
Дальше проверьте логи веб-сервера. Ищите обращения к /xmlrpc.php и частые POST-запросы с одного IP. Если таких запросов много, это уже не просто «наследие старой функции», а реальная нагрузка и потенциальная точка атаки.
Что смотреть в логах
- частые POST-запросы к
/xmlrpc.php; - повторяющиеся 200/403/404 ответы на этот путь;
- подозрительно одинаковые user-agent;
- пики запросов без видимой пользы для сайта.
Если у вас есть доступ к панели хостинга или SSH, проверьте логи за последние дни. На shared-хостинге обычно достаточно статистики в панели, на VPS удобнее смотреть access.log напрямую.
Как отключить XML-RPC без плагина
Самый практичный вариант — закрыть доступ на уровне WordPress через фильтр xmlrpc_enabled. Это не убирает сам файл, но отключает функциональность на уровне ядра.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Код можно добавить в functions.php дочерней темы или в небольшой mu-plugin. Второй вариант надёжнее: он не зависит от темы и не исчезнет после обновления шаблона.
Если нужен более жёсткий запрет, можно вернуть 403 на уровне сервера. Это полезно, когда вы хотите отсечь запросы ещё до загрузки WordPress.
# Apache
<Files xmlrpc.php>
Require all denied
</Files># Nginx
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Для Nginx блок лучше размещать в конфигурации сайта, а не пытаться имитировать его через PHP. Так вы не тратите ресурсы на обработку запроса вообще.
Сравнение подходов: код, сервер, плагин
| Способ | Плюсы | Минусы | Когда использовать |
|---|---|---|---|
Фильтр xmlrpc_enabled | Просто, быстро, работает в WordPress | Файл остаётся доступным на уровне веб-сервера | Если нужен мягкий и обратимый вариант |
| Блокировка в Nginx/Apache | Режет запросы раньше PHP, экономит ресурсы | Нужен доступ к конфигу сервера | Если вы администрируете сервер или хостинг позволяет правила |
| Плагин безопасности | Удобно для неразработчика | Лишняя зависимость, иногда дублирует другие функции | Если вы уже используете security-плагин и не хотите править код |
Если у вас уже стоит комплексный плагин вроде Clearfy Pro, проверьте, не закрывает ли он XML-RPC вместе с другими SEO- и security-настройками. Но если задача точечная, код или серверное правило обычно прозрачнее и предсказуемее.
Пошаговое решение: безопасный порядок действий
- Проверьте, используются ли внешние клиенты и интеграции.
- Сделайте резервную копию конфигурации и файлов.
- Сначала отключите XML-RPC через фильтр
xmlrpc_enabled. - Проверьте логи и работу админки, публикации и API-интеграций.
- Если всё стабильно, добавьте блокировку на уровне Nginx или Apache.
- Повторно проверьте доступ к
/xmlrpc.phpизвне.
Такой порядок удобен тем, что вы не теряете рабочую диагностику. Если что-то сломается, можно быстро вернуть фильтр назад и понять, какая именно интеграция зависела от XML-RPC.
Проверка результата после внедрения
После отключения откройте /xmlrpc.php в браузере или выполните запрос через curl. В зависимости от способа блокировки вы должны увидеть либо отказ в доступе, либо пустой ответ, либо сообщение об ошибке 403.
curl -I https://example.com/xmlrpc.phpЕсли всё настроено через WordPress-фильтр, сервер может вернуть обычный ответ, но функциональность XML-RPC будет отключена. Чтобы проверить именно это, отправьте тестовый XML-RPC-запрос или воспользуйтесь внешним инструментом проверки. Важно смотреть не только на статус-код, но и на фактическую возможность выполнить метод.
Дополнительно проверьте:
- не ломается ли публикация из админки;
- работают ли REST API и мобильные сценарии, если они у вас есть;
- не выросло ли число 403/404 в логах после блокировки;
- не появились ли ошибки в журнале PHP или веб-сервера.
Частые ошибки и как их исправить
Отключили XML-RPC, а потом перестало работать приложение
Значит, у вас был реальный внешний клиент. Решение простое: либо вернуть XML-RPC, либо перевести интеграцию на REST API, если приложение это поддерживает. Не стоит держать старый протокол включённым только из-за одного устаревшего сценария, если его можно заменить.
Поставили плагин, но endpoint всё равно отвечает
Некоторые плагины отключают только часть методов или маскируют ответ. Если нужен жёсткий запрет, добавьте правило на уровне сервера. Это надёжнее и не зависит от состояния WordPress.
Сломали доступ к XML-RPC, но не проверили логи
Без логов легко пропустить полезные обращения. Перед финальной блокировкой всегда смотрите, кто и как часто ходит в xmlrpc.php. Иначе можно закрыть не только мусорный трафик, но и рабочую интеграцию.
Сделали запрет в теме, а потом потеряли его после обновления
Если код лежит в functions.php родительской темы, обновление или смена шаблона может его убрать. Для таких настроек лучше использовать mu-plugin или отдельный мини-плагин.
Что делать для безопасности и производительности дополнительно
Отключение XML-RPC само по себе не заменяет нормальную защиту входа. Если у вас идут брутфорс-атаки, проверьте ещё лимиты на логин, двухфакторную аутентификацию и правила на уровне WAF или хостинга. Но закрытый XML-RPC уже убирает один из популярных векторов нагрузки.
С точки зрения производительности это тоже полезно: сервер перестаёт тратить ресурсы на обработку лишних запросов. На небольших сайтах разница может быть незаметна, но на атакуемых проектах это часто видно в логах и по снижению шума.
Если вам нужно не только отключить XML-RPC, но и почистить сайт от лишних технических дублей, служебных страниц и мусорных настроек, имеет смысл смотреть в сторону комплексной оптимизации. В таких сценариях иногда удобнее использовать Clearfy Pro: он закрывает часть типовых SEO- и технических задач без ручного набора разрозненных решений. Ссылка: Clearfy Pro.
Главный критерий здесь простой: после изменений сайт должен работать так же, как раньше, но без лишнего публичного endpoint, который вам не нужен. Если это так, XML-RPC можно считать успешно отключённым.
