Файл xmlrpc.php до сих пор встречается на многих сайтах WordPress, и чаще всего его отключают по одной причине: он становится лишней точкой атаки. Но у этого решения есть нюанс — через XML-RPC работают некоторые внешние сервисы, мобильные клиенты и старые интеграции. Если просто «отрезать» доступ на уровне сервера, можно неожиданно сломать публикацию через сторонний клиент или синхронизацию с приложением.
Ниже — практический сценарий: как понять, нужен ли вам xmlrpc.php, как отключить его без лишнего риска и как проверить, что сайт после изменения ведёт себя нормально.
Когда xmlrpc.php действительно стоит отключать
Если сайт не использует удалённую публикацию, pingback/trackback и старые внешние клиенты, отключение XML-RPC обычно оправдано. На практике это полезно для типовых корпоративных сайтов, блогов с обычной админкой и магазинов WooCommerce, где весь контент и заказы обрабатываются внутри WordPress.
Но если у вас есть мобильное приложение, интеграция с внешним редактором, старый плагин для автопостинга или сервис, который публикует записи через XML-RPC, отключение нужно планировать отдельно. Иначе проблема проявится не в админке, а в стороннем сервисе: публикация начнёт падать с ошибкой авторизации или недоступности метода.
Быстрая диагностика: используется ли XML-RPC сейчас
Проверить это можно без догадок. Сначала посмотрите логи доступа веб-сервера: если /xmlrpc.php регулярно вызывается извне, там будут заметные запросы. Затем проверьте, нет ли в проекте плагинов или интеграций, которые упоминают XML-RPC в настройках или документации.
Ещё один практичный тест — открыть URL https://example.com/xmlrpc.php в браузере. Если файл доступен, WordPress обычно отвечает сообщением о том, что XML-RPC сервер принимает только POST-запросы. Это не доказывает, что он нужен, но подтверждает, что точка входа открыта.
| Подход | Что делает | Когда выбирать |
|---|---|---|
| Плагин безопасности | Блокирует доступ к XML-RPC на уровне WordPress | Если нужен быстрый способ без правок сервера |
| Код в теме или mu-plugin | Отключает XML-RPC через фильтр WordPress | Если нужен контролируемый и прозрачный вариант |
| Правило на сервере | Отсекает запросы до загрузки WordPress | Если важна минимальная нагрузка и есть доступ к конфигу сервера |
Как отключить xmlrpc.php через код
Если вы хотите решение без лишних зависимостей, используйте фильтр xmlrpc_enabled. Это штатный способ WordPress, он не ломает ядро и легко откатывается. Лучше добавлять такой код не в активную тему, а в mu-plugin или в собственный мини-плагин, чтобы он не исчез при смене шаблона.
<?php
/**
* Plugin Name: Disable XML-RPC
* Description: Отключает XML-RPC на сайте WordPress.
*/
add_filter( 'xmlrpc_enabled', '__return_false' );
Если у вас нет mu-plugins, создайте файл, например wp-content/mu-plugins/disable-xmlrpc.php. Папка mu-plugins может отсутствовать — это нормально, её можно создать вручную. Такой файл WordPress подхватит автоматически.
Что делать, если нужен не полный запрет, а частичное ограничение
Иногда XML-RPC нужен только для одного сценария, например для подключения одного внешнего клиента. Тогда лучше не отключать всё подряд, а точечно ограничить доступ на уровне сервера или дополнительно фильтровать запросы по IP, если источник статичный. Это уже не универсальное решение, но оно безопаснее, чем оставлять открытым весь интерфейс.
Если вы не уверены, что именно использует XML-RPC, сначала соберите список интеграций и только потом принимайте решение. Отключение «на всякий случай» часто приводит к тому, что проблему замечают уже после сбоя публикации или синхронизации.
Как заблокировать xmlrpc.php на уровне сервера
Если у вас Apache и сайт работает через .htaccess, можно закрыть доступ к файлу до загрузки WordPress. Это снижает лишнюю нагрузку и не даёт скрипту даже стартовать. Для Nginx логика будет другой, но смысл тот же: отдать отказ на уровне веб-сервера.
<Files xmlrpc.php>
Require all denied
</Files>
Для Nginx обычно используют правило в конфигурации сайта:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}
После изменения конфигурации не забудьте проверить синтаксис и перезагрузить веб-сервер. Для Apache это зависит от окружения, для Nginx обычно используют проверку конфигурации перед reload. Если доступа к серверу нет, остаётся вариант с кодом или плагином.
Проверка результата после внедрения
После отключения важно не ограничиться «страница открывается». Проверьте именно те точки, которые могли пострадать.
- Откройте
/xmlrpc.phpв браузере — доступ должен быть закрыт или возвращать отказ. - Проверьте публикацию записи из админки — обычный редактор WordPress должен работать без изменений.
- Если есть внешние сервисы, попробуйте выполнить тестовую отправку или синхронизацию.
- Посмотрите логи сервера: запросы к
xmlrpc.phpдолжны либо исчезнуть, либо получать отказ.
Если вы отключали XML-RPC через код, а файл всё ещё отвечает, значит фильтр не загрузился. Обычно причина в том, что код добавили не туда: в неактивную тему, в файл, который не подключается, или с синтаксической ошибкой. Если блокировка на сервере не сработала, проверьте, что правило стоит в нужном виртуальном хосте, а не в глобальном конфиге, который не применяется к сайту.
Частые ошибки и как их исправить
Отключили XML-RPC, а потом перестала работать внешняя публикация
Это типичный сценарий, когда заранее не проверили интеграции. Решение простое: верните доступ, если сервис действительно нужен, или переведите его на другой способ подключения. Если сервис старый и работает только через XML-RPC, лучше оставить доступ ограниченным, чем ломать рабочий процесс без замены.
Добавили код в functions.php и потеряли его после обновления темы
Это не ошибка WordPress, а ошибка размещения. Для таких задач используйте mu-plugin или отдельный мини-плагин. Тогда отключение не зависит от темы и не исчезнет после обновления.
Закрыли xmlrpc.php, но атаки в логах не исчезли
Так бывает, если боты продолжают стучаться по старым URL. Это нормально: сама попытка запроса ещё не означает, что защита не работает. Смотрите не на факт обращений, а на код ответа и отсутствие выполнения PHP-скрипта. Если блокировка сделана на сервере, нагрузка на WordPress при этом минимальна.
Безопасность и производительность: что ещё проверить рядом
Если вы уже занимаетесь защитой сайта, имеет смысл проверить и другие точки, которые часто оставляют открытыми без необходимости. Например, доступ к wp-login.php, лимиты на попытки входа, актуальность плагинов и наличие лишних REST-эндпоинтов от старых расширений. Но не смешивайте всё в одну правку: сначала отключите XML-RPC, затем отдельно проверьте, не сломались ли нужные сценарии.
Для сайтов, где нужен быстрый и аккуратный аудит типовых проблем безопасности и дублей, иногда удобнее использовать набор инструментов вроде Clearfy Pro: он не заменяет ручную проверку, но помогает закрыть часть рутинных настроек без разрозненных правок по файлам. Если хотите посмотреть продукт, ссылка такая: Clearfy Pro.
Главный критерий здесь простой: после отключения XML-RPC сайт должен продолжать работать в тех сценариях, которые реально используются. Если интеграций нет — закрывайте доступ смело. Если они есть — сначала найдите замену или ограничьте доступ точечно.