Как закрыть доступ к xmlrpc.php в WordPress без поломки сайта

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

Ниже — практический разбор: как понять, нужен ли вам xmlrpc.php, как закрыть к нему доступ безопасно и как проверить, что после изменения ничего не сломалось.

Когда xmlrpc.php действительно стоит отключить

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

Типичный сценарий: в логах появляются повторяющиеся POST /xmlrpc.php, а в панели безопасности — попытки подбора паролей или pingback-атаки. В таком случае отключение доступа к файлу даёт понятный эффект: запросы перестают доходить до WordPress, а сервер перестаёт тратить ресурсы на обработку мусора.

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

Перед изменениями проверьте три вещи:

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

Если доступ к админке есть, откройте журнал безопасности или access log на хостинге. Если видите много запросов к /xmlrpc.php без полезной нагрузки, это хороший кандидат на отключение.

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

Есть несколько рабочих вариантов. Выбор зависит от того, есть ли у вас доступ к конфигурации сервера и нужен ли вам полный запрет или только ограничение на уровне WordPress.

Способ	Когда подходит	Плюс	Минус
Правило на сервере	Есть доступ к Nginx/Apache	Запросы режутся до WordPress	Нужно аккуратно править конфиг
Код в теме или MU-плагине	Нет доступа к серверу	Просто внедрить	WordPress всё равно загрузится
Плагин безопасности	Нужна настройка без кода	Удобно для админов	Лишняя зависимость от плагина

Вариант 1: закрыть xmlrpc.php на уровне Nginx

Если сайт работает на Nginx, самый прямой способ — вернуть 403 для этого файла. Так запрос даже не попадёт в WordPress.

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

После правки конфигурации проверьте синтаксис и перезагрузите сервер. На практике это самый чистый вариант, если XML-RPC вам не нужен вообще.

Вариант 2: закрыть xmlrpc.php в .htaccess на Apache

Для Apache можно добавить правило в .htaccess в корне сайта:

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

Если у вас старый стек с Apache 2.2, синтаксис может отличаться, но на современных хостингах обычно используется именно Require all denied.

Вариант 3: отключить XML-RPC через код

Если серверный доступ ограничен, можно заблокировать XML-RPC на уровне WordPress. Для этого лучше использовать mu-plugin, чтобы правило не зависело от активной темы.

<?php
/**
 * Plugin Name: Disable XML-RPC
 */

add_filter( 'xmlrpc_enabled', '__return_false' );

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

Что проверить после внедрения

Недостаточно просто добавить правило и забыть. Нужно убедиться, что доступ действительно закрыт, а нужные интеграции не пострадали.

• Откройте /xmlrpc.php в браузере или через curl — сервер должен вернуть 403 или другой отказ в доступе.
• Проверьте логи: запросы к файлу должны исчезнуть или перестать доходить до PHP.
• Если у вас был внешний сервис публикации, попробуйте выполнить тестовое соединение.
• Проверьте, не появились ли ошибки в журнале безопасности или в логах веб-сервера.

Простой тест через консоль:

curl -I https://example.com/xmlrpc.php

Ожидаемый результат — 403 Forbidden или аналогичный отказ. Если вы видите 200 OK, правило не сработало или было добавлено не в тот уровень конфигурации.

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

Отключили XML-RPC, а потом перестал работать Jetpack

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

Добавили правило в .htaccess, но файл всё равно открывается

Частая причина — сайт работает не на Apache, а на Nginx, где .htaccess не используется. В этом случае правило нужно добавлять в конфигурацию Nginx или блокировать доступ другим способом.

Использовали плагин, но запросы продолжают идти

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

Сломали редиректы или кэш после правки конфигурации

Такое бывает, если правило вставили в неправильный блок или нарушили структуру конфига. Всегда делайте резервную копию файла конфигурации и проверяйте синтаксис до перезапуска сервера.

Практические советы по безопасности и производительности

Если XML-RPC вам не нужен, лучше закрыть его именно на сервере. Это уменьшает количество лишних запросов к PHP и делает сайт чуть устойчивее к шуму в логах и попыткам перебора паролей.

Если вы управляете несколькими сайтами, удобно держать такой запрет в шаблоне конфигурации хоста или в mu-plugin, чтобы не повторять настройку вручную. Для сайтов, где важна дополнительная чистка технических дублей и лишних сущностей, полезно параллельно проверить и другие элементы технического мусора. Например, в Clearfy Pro есть инструменты для SEO- и технической гигиены сайта: https://wpshop.ru/plugins/clearfy?utm_source=wpstart.ru&utm_medium=article&utm_campaign=zakryt-dostup-k-xmlrpc-php-v-wordpress

Но не стоит смешивать всё в одну правку. Сначала закройте xmlrpc.php, затем отдельно проверьте, не нужны ли вам старые интеграции, и только после этого двигайтесь дальше по списку технической оптимизации.

Короткий чек-лист перед публикацией изменения

• Проверил, используется ли XML-RPC внешними сервисами.
• Сделал резервную копию конфигурации или файла с кодом.
• Добавил правило на уровне сервера или в mu-plugin.
• Проверил ответ /xmlrpc.php через браузер или curl.
• Убедился, что Jetpack и другие интеграции не сломались.
• Посмотрел логи после изменения.

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