Как отключить XML-RPC в WordPress без сбоев и лишних 404

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

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

Сам по себе xmlrpc.php не нужен большинству сайтов. Но есть сценарии, где его всё ещё используют: старые клиенты для публикации, некоторые внешние сервисы, приложения для удалённого управления контентом, отдельные интеграции с Jetpack и похожими инструментами. Если у вас есть хотя бы один такой сценарий, отключать нужно не «вслепую», а после проверки.

Быстрая диагностика перед изменениями

Начните с простых проверок. Откройте /xmlrpc.php в браузере: если endpoint доступен, WordPress обычно отвечает сообщением о том, что XML-RPC сервер принимает только POST-запросы. Это не ошибка. Важнее посмотреть логи веб-сервера и понять, есть ли реальные обращения.

• Проверьте access log на запросы к /xmlrpc.php.
• Посмотрите, нет ли в них регулярных POST-запросов от ваших сервисов.
• Если используется Jetpack, мобильное приложение WordPress или внешняя публикация, сначала протестируйте их на копии сайта.
• Проверьте, не завязана ли на XML-RPC синхронизация с CRM, редактором или планировщиком публикаций.

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

Пошаговое отключение XML-RPC

Самый надёжный способ — отключить обработку XML-RPC на уровне WordPress, а не только прятать файл на уровне сервера. Так вы не оставляете лишнюю поверхность атаки и не зависите от конкретной конфигурации Nginx или Apache.

Вариант через код в functions.php или mu-plugin

Если нужен быстрый и прозрачный способ, добавьте фильтр xmlrpc_enabled. Лучше делать это в mu-plugin, чтобы настройка не пропала после смены темы.

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

Это отключает XML-RPC на уровне WordPress. После этого запросы к xmlrpc.php перестанут проходить штатно, но сам файл может оставаться доступным для прямого обращения. Поэтому для защиты от лишнего шума полезно добавить и серверное правило.

Блокировка на уровне веб-сервера

Если сайт работает на Apache, можно закрыть доступ к файлу через .htaccess. Это не замена отключению в WordPress, а дополнительный слой защиты.

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

Для Nginx правило обычно добавляют в конфигурацию сайта:

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

Если у вас нет доступа к конфигу сервера, достаточно фильтра xmlrpc_enabled. Но в этом случае не забывайте, что боты всё равно будут стучаться в endpoint, и это будет видно в логах.

Что делать, если XML-RPC нужен только частично

Иногда отключать всё нельзя. Например, сайт использует только одну внешнюю интеграцию, а остальное через XML-RPC не нужно. В таком случае лучше сначала выяснить, какие именно методы используются, и уже потом принимать решение. На практике это удобнее делать на staging-копии: отключаете XML-RPC, проверяете интеграции, и только после этого переносите изменение на прод.

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

Проверка результата после внедрения

После отключения нужно убедиться, что решение сработало не только «по ощущениям», но и технически. Проверка занимает несколько минут и экономит время на поиске скрытых ошибок позже.

1. Откройте /xmlrpc.php в браузере и убедитесь, что он не отвечает как рабочий endpoint.
2. Сделайте POST-запрос к xmlrpc.php через curl или Postman и проверьте код ответа.
3. Посмотрите access log: новых успешных обращений быть не должно.
4. Проверьте мобильное приложение WordPress, если оно используется.
5. Проверьте внешние сервисы, которые публикуют записи или читают данные с сайта.

Пример проверки через curl:

curl -i -X POST https://example.com/xmlrpc.php \
  -H 'Content-Type: text/xml' \
  --data '<?xml version="1.0"?><methodCall><methodName>system.listMethods</methodName></methodCall>'

Если всё закрыто корректно, вы не должны получать нормальный ответ XML-RPC с перечнем методов. Конкретный код ответа зависит от того, где именно стоит блокировка: WordPress, Apache или Nginx.

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

Отключили только в плагине безопасности

Некоторые плагины умеют скрывать или блокировать XML-RPC, но это не всегда полноценное отключение. Если правило работает только в интерфейсе плагина, после его деактивации защита исчезнет. Для критичных сайтов лучше дублировать настройку кодом или на уровне сервера.

Сломали Jetpack или мобильное приложение

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

Поставили 404 вместо 403 и запутали диагностику

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

Забыли про кэш и CDN

После изменения правил старый ответ может продолжать отдаваться из кэша. Очистите серверный кэш, кэш плагина и, если есть, CDN. Иначе проверка покажет старое поведение, хотя настройка уже изменена.

Безопасность и производительность: что учесть дополнительно

Отключение XML-RPC само по себе не делает сайт «защищённым полностью», но убирает один из популярных векторов атак. Чтобы эффект был заметнее, проверьте ещё несколько вещей:

• ограничьте попытки входа в админку;
• включите двухфакторную аутентификацию для администраторов;
• убедитесь, что wp-login.php не открыт для массового перебора без ограничений;
• проверьте, не пишет ли сервер слишком много логов из-за постоянных обращений к xmlrpc.php;
• если сайт на shared-хостинге, уточните, можно ли закрыть endpoint на уровне панели управления.

Если у вас уже стоит плагин для технической чистки и SEO-оптимизации, например Clearfy Pro, проверьте, не дублирует ли он эту настройку. Дублирующие правила сами по себе не опасны, но усложняют поддержку: через полгода уже не видно, где именно включена блокировка.

Как выбрать подход: код, сервер или плагин

На практике лучше сочетать отключение на уровне WordPress и блокировку на сервере, если это возможно. Тогда даже при ошибке в одной из точек защита не исчезнет полностью.

Если после внедрения вы видите только ожидаемые 403/404 на xmlrpc.php, а публикация, авторизация и внешние интеграции работают как раньше, значит решение выбрано правильно. Если что-то сломалось, не пытайтесь «додавить» блокировку — сначала найдите, кто именно использовал XML-RPC, и переведите этот сценарий на более современный способ связи с сайтом.