Если на сайте не используются старые мобильные клиенты, внешние публикации через сторонние сервисы или Jetpack-функции, XML-RPC чаще всего только расширяет поверхность атаки. Но отключать его нужно аккуратно: на части сайтов этот интерфейс всё ещё нужен, а грубая блокировка может задеть полезные сценарии.
Ниже разберём два рабочих способа: через PHP и через серверную блокировку. Сразу покажу, как проверить результат и где чаще всего ошибаются.
Когда XML-RPC действительно стоит отключать
XML-RPC — это не «лишний плагин», а отдельный механизм удалённого доступа к WordPress. Через него можно отправлять публикации, управлять комментариями и выполнять другие действия, которые исторически были полезны для внешних клиентов. Сейчас в большинстве проектов он не нужен.
Отключение обычно оправдано, если:
- сайт не использует Jetpack или другие сервисы, которым нужен XML-RPC;
- нет старых приложений для публикации в WordPress;
- нужно уменьшить число точек для брутфорса и pingback-атак;
- на сервере есть доступ к настройкам веб-сервера или к
.htaccess.
Диагностика: как понять, что XML-RPC открыт
Перед изменениями проверьте текущую ситуацию. Самый простой тест — запрос к /xmlrpc.php. Если файл доступен, сервер обычно отвечает не HTML-страницей сайта, а сообщением WordPress или HTTP-ошибкой, если доступ уже ограничен.
Проверка через curl
curl -I https://example.com/xmlrpc.phpЧто смотреть в ответе:
200 OKили405 Method Not Allowed— файл доступен;403 Forbidden— доступ уже закрыт на уровне сервера;404 Not Found— файл скрыт или заблокирован нестандартно.
Можно проверить и POST-запросом, потому что именно он важен для XML-RPC:
curl -s -X POST https://example.com/xmlrpc.php -d '<?xml version="1.0"?><methodCall><methodName>system.listMethods</methodName></methodCall>'Если интерфейс открыт, WordPress обычно вернёт XML-ответ, а не обычную страницу ошибки.
Пошаговое решение через PHP
Этот вариант удобен, если вы хотите отключить XML-RPC на уровне WordPress, не трогая конфигурацию сервера. Подходит для большинства сайтов, где достаточно убрать функциональность из самого ядра.
Код для functions.php или mu-plugin
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Лучше не вставлять это в активную тему, если проект живёт долго. Надёжнее создать небольшой mu-plugin, чтобы блокировка не исчезла после смены темы.
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Файл положите в wp-content/mu-plugins/disable-xmlrpc.php. Если папки mu-plugins нет, создайте её вручную.
Что делает этот способ
Фильтр xmlrpc_enabled отключает сам механизм на уровне WordPress. Это безопаснее, чем удалять файл xmlrpc.php из ядра или править системные файлы вручную. При обновлении WordPress решение не сломается.
Пошаговое решение через .htaccess
Если нужен более жёсткий барьер, можно закрыть доступ к xmlrpc.php на уровне Apache. Это полезно, когда вы хотите отрезать запросы ещё до загрузки WordPress.
Правило для .htaccess
<Files xmlrpc.php>
Require all denied
</Files>Если сервер старый и использует Apache 2.2, иногда встречается вариант:
<Files xmlrpc.php>
Order Deny,Allow
Deny from all
</Files>Но на современных конфигурациях лучше использовать Require all denied. Не смешивайте оба варианта в одном блоке без необходимости.
Когда выбирать серверную блокировку
- на сайте идёт постоянный перебор запросов к
xmlrpc.php; - нужно снизить нагрузку до запуска WordPress;
- вы точно знаете, что XML-RPC не нужен ни одному сервису.
| Способ | Плюс | Минус |
|---|---|---|
| PHP-фильтр | Просто внедрить, не зависит от веб-сервера | WordPress всё равно загружается |
| .htaccess | Блокирует запрос раньше, экономит ресурсы | Работает только на Apache/Nginx с аналогичной настройкой |
| Оба способа | Максимально жёсткая защита | Нужно следить, чтобы не сломать нужные интеграции |
Как проверить, что отключение сработало
После внедрения повторите те же проверки, что и до изменений.
- Откройте
https://example.com/xmlrpc.phpв браузере. - Проверьте ответ через
curl -I. - Сделайте POST-запрос к XML-RPC и убедитесь, что он не проходит.
Если вы отключали через PHP, а файл всё ещё отвечает, проверьте, не переопределяет ли код другой плагин или тема фильтр xmlrpc_enabled. Если блокировали через .htaccess, убедитесь, что правило стоит в правильном месте и сервер вообще читает этот файл.
Частые ошибки и как их исправить
Сломали Jetpack или внешнюю публикацию
Некоторые сервисы используют XML-RPC для связи с сайтом. Если после отключения перестала работать синхронизация, сначала проверьте, действительно ли она нужна. Если нужна — не блокируйте интерфейс полностью, а ограничьте доступ по IP или пересмотрите схему интеграции.
Добавили правило не в тот файл
На Apache правило должно быть в корневом .htaccess сайта. Если WordPress стоит в подкаталоге, блокировку нужно ставить именно там, где обрабатывается запрос к xmlrpc.php.
Ожидали, что исчезнут все запросы к сайту
Отключение XML-RPC не решает все проблемы безопасности. Если у вас брутфорсят wp-login.php, это отдельная задача: нужны ограничение попыток входа, двухфакторная аутентификация и нормальная защита админки.
Удалили файл xmlrpc.php вручную
Так делать не стоит. Обновление WordPress может восстановить файл, а ручные правки ядра усложняют поддержку. Лучше использовать фильтр, серверное правило или специализированный плагин безопасности.
Практические советы по безопасности и производительности
Если вы отключаете XML-RPC как часть общей чистки сайта, не ограничивайтесь одной настройкой. Проверьте ещё несколько вещей:
- закрыт ли доступ к
wp-login.phpдля подозрительных IP; - есть ли двухфакторная аутентификация для админов;
- не включены ли лишние внешние сервисы, которые держат старые API-интеграции;
- не дублируются ли функции безопасности несколькими плагинами одновременно.
Если нужен более широкий набор технических настроек для чистки WordPress, иногда удобнее собрать это в одном решении, чем держать несколько разрозненных плагинов. Например, Clearfy Pro закрывает часть типовых задач по оптимизации и удалению лишнего функционала, но использовать его стоит только там, где его набор реально нужен: Clearfy Pro.
Что делать, если XML-RPC нужен частично
Иногда полностью отключать интерфейс нельзя. Тогда лучше не рубить с плеча, а ограничить сценарий использования. Например, оставить доступ только для конкретного сервиса через серверные правила или вынести интеграцию на другой механизм, если он поддерживается.
В таких случаях сначала составьте список реальных потребителей XML-RPC. Если список пустой — отключайте без сомнений. Если там есть один-единственный сервис, проверьте, есть ли у него современная альтернатива через REST API или прямую интеграцию с WordPress.
Главная проверка здесь простая: после отключения не должно быть ни одного легитимного сценария, который перестал работать без объяснения причин. Если такой сценарий есть, значит, блокировку нужно пересмотреть, а не просто «дожать» её до конца.