XML-RPC в WordPress часто отключают не «на всякий случай», а после конкретной проблемы: брутфорс по xmlrpc.php, лишний шум в логах, попытки использовать pingback или старые интеграции, которые давно не нужны. Но у этого файла есть и полезные сценарии: внешняя публикация, некоторые мобильные клиенты, интеграции со сторонними сервисами. Поэтому правильный подход — не просто закрыть доступ, а сначала понять, нужен ли он вообще на вашем сайте.
Когда XML-RPC можно отключать, а когда лучше не трогать
Если сайт работает только через стандартную админку WordPress и у вас нет старых приложений, которые публикуют записи через XML-RPC, отключение обычно безопасно. Если же вы используете внешние клиенты, синхронизацию контента или сервисы, которые до сих пор ходят в xmlrpc.php, сначала проверьте их документацию и логи запросов.
Типичный признак, что XML-RPC уже не нужен: в логах есть регулярные POST-запросы к /xmlrpc.php, но в команде никто не может назвать сервис, который его использует. В таком случае файл чаще всего только создаёт поверхность атаки.
Диагностика: как понять, что именно обращается к xmlrpc.php
Перед отключением полезно посмотреть, есть ли реальные обращения и откуда они идут. Это можно сделать на уровне веб-сервера или по логам хостинга. Ищите POST-запросы к xmlrpc.php, а также методы вроде pingback.ping и system.multicall.
Что проверить в логах
- частоту запросов к
/xmlrpc.php; - IP-адреса и User-Agent;
- есть ли успешные ответы 200 или только 403/404;
- используется ли файл внешними сервисами, а не ботами.
Если у вас включён доступ к access.log, можно быстро отфильтровать обращения так:
grep "xmlrpc.php" access.logНа общем хостинге иногда проще открыть статистику запросов в панели управления и отфильтровать путь /xmlrpc.php. Если запросы идут только от сканеров, отключение — разумный шаг.
Варианты отключения: .htaccess или PHP
Есть два рабочих пути. Первый — блокировать запросы на уровне веб-сервера. Второй — отключать XML-RPC через WordPress-хук. Для большинства сайтов достаточно одного способа, но если вы хотите защититься и на уровне приложения, и на уровне сервера, можно комбинировать оба.
| Способ | Плюсы | Минусы | Когда выбирать |
|---|---|---|---|
| .htaccess | Блокирует запрос до загрузки WordPress | Работает только на Apache/LiteSpeed | Если нужен быстрый отказ на сервере |
| PHP-хук | Простой контроль внутри WordPress | WordPress всё равно частично загружается | Если не хочется трогать правила сервера |
Пошаговое решение через .htaccess
Если сайт работает на Apache или LiteSpeed, добавьте правило в .htaccess рядом с основными правилами WordPress. Лучше делать это после резервной копии файла, потому что ошибка в синтаксисе может сломать доступ к сайту.
<Files xmlrpc.php>
Require all denied
</Files>Для старых конфигураций Apache 2.2 иногда встречается вариант с Deny from all, но на современных серверах лучше использовать Require all denied. Если у вас Nginx, этот способ не сработает — там блокировку нужно делать в конфигурации сервера.
Что делать на Nginx
В конфиге сайта добавляют отдельное правило для xmlrpc.php. Пример:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}После изменения конфигурации Nginx нужно проверить синтаксис и перезагрузить сервис. Это уже серверная задача, поэтому без доступа к конфигам хостинга такой вариант может быть недоступен.
Отключение XML-RPC через PHP в WordPress
Если серверные правила менять неудобно, можно отключить XML-RPC через фильтр xmlrpc_enabled. Это не выдуманный хук: он есть в WordPress и возвращает, включён ли XML-RPC.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Код можно добавить в functions.php дочерней темы или в собственный небольшой mu-plugin. Для production-сайта mu-plugin обычно надёжнее: он не зависит от активной темы и не исчезнет после обновления шаблона.
Если нужно оставить XML-RPC только для конкретной задачи
Иногда отключать всё целиком нельзя. Например, если один сервис ещё использует XML-RPC, а остальное вы хотите закрыть. В таком случае лучше не придумывать сложные костыли, а сначала заменить интеграцию на REST API или другой способ публикации. WordPress уже давно ориентирован на REST, и это обычно проще сопровождать.
Проверка результата после внедрения
После блокировки проверьте не только код ответа, но и побочные эффекты. Самый простой тест — открыть /xmlrpc.php в браузере или отправить запрос через curl. Если всё сделано правильно, сервер должен вернуть отказ в доступе или ошибку, а не стандартный ответ WordPress.
curl -I https://example.com/xmlrpc.phpОжидаемое поведение зависит от способа блокировки: при серверном deny это может быть 403 Forbidden, при PHP-фильтре — другой отказ или пустой ответ. Главное, чтобы XML-RPC не принимал рабочие запросы.
Дополнительно проверьте:
- не появились ли ошибки в логах веб-сервера;
- не сломались ли внешние публикации или мобильные приложения;
- не изменилось ли поведение пингбеков, если вы их вообще используете;
- не выросло ли число 404/403 на других URL после правки
.htaccess.
Частые ошибки и как их исправить
Отключили XML-RPC, а потом перестали публиковаться записи из внешнего сервиса
Значит, сервис действительно использовал XML-RPC. Решение — либо вернуть доступ, либо перевести интеграцию на REST API, если сервис это поддерживает. Не оставляйте открытым только ради «на всякий случай» без понимания, кто и зачем его использует.
Добавили правило в .htaccess, но ничего не изменилось
Чаще всего сайт работает не на Apache, а на Nginx, либо .htaccess вообще не читается на этом хостинге. В таком случае правило нужно переносить в конфигурацию сервера или использовать PHP-хук.
Сайт начал отдавать 500 после правки .htaccess
Это почти всегда синтаксическая ошибка. Верните резервную копию файла и вставляйте правило только в корректный блок. На shared-хостингах лучше сначала проверить, поддерживается ли директива Require.
Отключили XML-RPC, но в логах всё равно идут запросы
Это нормально: боты продолжают стучаться, но уже получают отказ. Важен не сам факт запроса, а то, что он больше не обрабатывается WordPress как рабочий.
Практические советы по безопасности и производительности
Отключение XML-RPC само по себе не заменяет защиту входа, фильтрацию ботов и обновления. Но оно уменьшает лишнюю поверхность атаки и может сократить шум в логах. Если у вас уже закрыты другие очевидные векторы, это хороший дополнительный слой.
- делайте резервную копию
.htaccessили конфигурации Nginx перед правками; - не отключайте XML-RPC, пока не проверили сторонние интеграции;
- если нужен только один внешний сервис, рассмотрите переход на REST API;
- после изменения правил проверьте сайт в приватном окне и через curl;
- если доступ к серверу ограничен, используйте PHP-хук вместо ручной правки конфигов.
Если вам нужно не только отключить XML-RPC, но и убрать другие технические дубли и лишние элементы, имеет смысл смотреть в сторону комплексной чистки сайта. Например, у Clearfy Pro есть инструменты для удаления дублей и технической оптимизации, но применять такие решения стоит только там, где они действительно закрывают вашу задачу, а не ради набора функций.
Короткий чек-лист перед публикацией правки
- Проверили, нужен ли XML-RPC конкретным сервисам.
- Сделали резервную копию файла или конфигурации.
- Выбрали один способ блокировки: серверный или PHP.
- Проверили ответ на
/xmlrpc.phpчерез браузер или curl. - Посмотрели логи на предмет ошибок и неожиданных отказов.
Если после отключения сайт работает штатно, а внешние интеграции не пострадали, значит, решение выбрано правильно. Если что-то сломалось, не ищите обходные пути в стиле «оставить открытым для всех» — лучше точечно восстановить нужный сценарий и закрыть остальное.