Файл xmlrpc.php до сих пор встречается на большинстве WordPress-сайтов и часто становится точкой входа для перебора паролей и лишней нагрузки. Если вы не используете мобильное приложение WordPress, внешние публикации через XML-RPC или старые интеграции, этот интерфейс обычно проще закрыть, чем оставлять открытым без необходимости.
Ниже — рабочие способы отключения, что именно ломается после этого, как проверить, что всё действительно закрыто, и какие ошибки чаще всего допускают на живом сайте.
Когда отключение xmlrpc.php действительно уместно
Не стоит закрывать XML-RPC «на всякий случай», если у вас есть зависимые сценарии. Сначала проверьте, используется ли он вообще. На практике этот файл нужен реже, чем кажется.
Типичные сценарии, где xmlrpc.php можно отключить
- сайт не синхронизируется с мобильным приложением WordPress;
- нет внешних сервисов, которые публикуют записи через XML-RPC;
- не используется Jetpack в режиме, где ему нужен XML-RPC для связи со старым стеком;
- нет старых интеграций с приложениями и скриптами, которые отправляют
metaWeblog.newPostилиpingback.ping.
Когда отключать не стоит
Если у вас есть рабочая интеграция, которая уже завязана на XML-RPC, сначала перенесите её на REST API или другой способ авторизации. Иначе после блокировки получите тихую поломку: публикации не создаются, синхронизация не работает, а ошибка может всплыть не сразу.
Диагностика: как понять, что xmlrpc.php открыт и используется
Самый простой признак — файл отвечает на запросы извне. Проверить это можно без доступа к админке. Если сервер возвращает 200 OK или хотя бы страницу с сообщением WordPress, значит endpoint доступен.
curl -I https://example.com/xmlrpc.phpДля более точной проверки можно отправить тестовый POST-запрос. Если XML-RPC включён, сервер обычно отвечает не пустым статусом, а сообщением об ошибке метода или формата запроса.
curl -s -X POST https://example.com/xmlrpc.php \
-H 'Content-Type: text/xml' \
--data '<?xml version="1.0"?><methodCall><methodName>system.listMethods</methodName></methodCall>'Если вы видите ответ WordPress, а не блокировку на уровне сервера, значит endpoint доступен для перебора и сканирования.
Как отключить xmlrpc.php: рабочие способы
Есть три нормальных подхода: через код, через сервер и через плагин безопасности. Выбор зависит от того, где у вас есть контроль и насколько часто вы меняете конфигурацию.
| Способ | Плюсы | Минусы | Когда выбирать |
|---|---|---|---|
| Код в WordPress | Быстро, не зависит от панели хостинга | Файл всё равно доступен на уровне веб-сервера | Если нужен простой и обратимый вариант |
| Правило в сервере | Режет запросы раньше WordPress | Нужно править Nginx/Apache | Если есть доступ к конфигу сервера |
| Плагин безопасности | Без кода, удобно для админов | Лишняя зависимость от плагина | Если уже используете security-плагин |
Способ 1. Отключение через functions.php или mu-plugin
Если нужен быстрый и обратимый вариант, можно заблокировать XML-RPC на уровне WordPress. Лучше делать это через mu-plugin, а не в теме: так настройка не сломается после смены темы.
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Этот вариант отключает сам механизм XML-RPC, но не всегда убирает сам файл из доступности. Для большинства сайтов этого достаточно, если цель — остановить использование метода изнутри WordPress.
Способ 2. Блокировка на уровне Nginx
Если у вас Nginx, лучше отрезать запросы до передачи в PHP. Это уменьшает лишнюю нагрузку и делает сканирование менее полезным для атакующего.
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}После изменения конфигурации проверьте reload Nginx и убедитесь, что правило не конфликтует с другими location-блоками.
Способ 3. Блокировка в Apache через .htaccess
Если сайт работает на Apache, можно закрыть доступ через .htaccess. Это особенно удобно, когда нет доступа к глобальной конфигурации.
<Files "xmlrpc.php">
Require all denied
</Files>Для старых конфигураций Apache иногда встречается синтаксис Deny from all, но на современных серверах лучше использовать Require all denied.
Что ломается после отключения xmlrpc.php
После блокировки могут перестать работать старые интеграции. Это не баг, а ожидаемое поведение. Важно заранее понимать, что именно вы отключаете.
- мобильное приложение WordPress может потерять возможность публиковать контент;
- Jetpack и похожие сервисы могут запросить альтернативный канал связи;
- внешние клиенты для публикации записей перестанут отправлять посты;
- pingback и trackback через XML-RPC будут недоступны.
Если вам нужен только запрет на bruteforce, но интеграция должна остаться, тогда вместо полного отключения лучше ограничить доступ по IP или закрыть только опасные методы. Это уже более тонкая настройка и требует аккуратности.
Проверка результата после внедрения
После внесения изменений не ограничивайтесь открытием страницы в браузере. Нужна проверка именно на уровне HTTP и логики WordPress.
- выполните
curl -I https://example.com/xmlrpc.phpи проверьте, что ответ не выглядит как обычный доступный endpoint; - отправьте тестовый XML-RPC POST-запрос и убедитесь, что он не проходит;
- посмотрите логи веб-сервера: запросы к
/xmlrpc.phpдолжны получать отказ; - проверьте, не сломались ли внешние интеграции, если они у вас были.
Если вы закрывали файл через WordPress-фильтр, а не на уровне сервера, полезно проверить и фронт, и админку: иногда сайт продолжает отвечать на запрос, но методы уже не работают. Для безопасности это лучше, чем ничего, но не равно полноценной блокировке.
Частые ошибки и как их исправить
Ошибка: отключили XML-RPC в теме
Если правило лежит в functions.php активной темы, оно исчезнет после смены темы или обновления кастомной сборки. Для системной настройки используйте mu-plugin или конфиг сервера.
Ошибка: закрыли файл, но оставили старые интеграции
Сайт начинает «молчать» не сразу: публикации не уходят, а причина всплывает только в логах стороннего сервиса. Перед отключением проверьте, кто обращается к XML-RPC, и зафиксируйте это в списке зависимостей.
Ошибка: блокируют только через WordPress, но не на сервере
Если цель — снизить нагрузку и шум от сканеров, лучше резать запрос раньше PHP. Иначе бот всё равно будет стучаться в xmlrpc.php, а сервер будет тратить ресурсы на загрузку WordPress.
Ошибка: путают XML-RPC и REST API
Отключение xmlrpc.php не выключает REST API. Это разные механизмы. Если у вас проблемы с API, не ищите их в XML-RPC без проверки фактов.
Практические советы по безопасности и производительности
Если сайт регулярно атакуют перебором, одного отключения XML-RPC может быть мало. Имеет смысл дополнительно ограничить частоту запросов к wp-login.php, включить нормальный WAF на уровне хостинга и проверить, не торчит ли наружу лишняя админка.
Для сайтов, где техническая чистка и отключение лишнего функционала идут пакетом, удобно держать это в одном регламенте: убрать ненужные endpoints, закрыть технические страницы от индексации, отключить лишние фиды и ревизии. Если нужен инструмент для системной чистки WordPress, можно посмотреть Clearfy Pro: https://wpshop.ru/plugins/clearfy.
Но даже с плагином не стоит полагаться только на галочки в интерфейсе. После любой настройки проверяйте реальный HTTP-ответ и логи сервера — это единственный способ понять, что блокировка сработала так, как вы ожидали.