xmlrpc.php до сих пор встречается в атаках на WordPress чаще, чем хотелось бы: перебор паролей, pingback-спам, лишняя поверхность для сканеров. Но просто заблокировать файл «в лоб» — плохая идея, если сайт использует Jetpack, старые мобильные клиенты, внешнюю публикацию или какие-то интеграции через XML-RPC.
Ниже — рабочая схема: сначала понять, используется ли XML-RPC вообще, затем закрыть его безопасным способом и проверить, что ничего не сломалось.
Когда xmlrpc.php действительно нужно отключать
Если сайт не использует сторонние сервисы, которые ходят в XML-RPC, отключение обычно оправдано. На практике это полезно, когда:
- в логах много запросов к
/xmlrpc.php; - идут попытки подбора пароля через метод
system.multicall; - вам не нужен pingback/trackback;
- публикация из внешних клиентов не используется;
- Jetpack и похожие интеграции либо не установлены, либо переведены на другие каналы связи.
Если хотя бы один сервис зависит от XML-RPC, сначала проверьте его поведение на тестовой копии сайта. Иначе можно получить «тихий» отказ: сайт открывается, но публикации из внешнего приложения не проходят.
Диагностика: используется ли XML-RPC сейчас
Самый простой способ — посмотреть, есть ли обращения к файлу и кто их делает. В access-логах веб-сервера обычно видно путь /xmlrpc.php. Если доступа к логам нет, можно временно добавить проверку на уровне WordPress и записать факт обращения в debug.log.
Проверка через лог запросов
Если у вас есть доступ к Nginx или Apache-логам, ищите запросы к xmlrpc.php и частые POST-запросы с одного IP. Это уже повод закрывать доступ хотя бы на уровне веб-сервера.
Проверка через WordPress
Можно временно включить логирование и посмотреть, приходят ли запросы вообще. Для этого в wp-config.php должны быть включены отладочные настройки:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);Дальше добавьте небольшой сниппет в mu-plugin или в functions.php темы, если это временная диагностика:
add_action('xmlrpc_call', function ($method) {
error_log('XML-RPC call: ' . $method);
});Если в wp-content/debug.log ничего не появляется, это не доказывает, что XML-RPC не нужен, но помогает понять, что активных вызовов сейчас нет.
Как отключить xmlrpc.php без лишнего риска
Есть три нормальных подхода: блокировка на уровне сервера, отключение через WordPress-фильтр и точечное ограничение только опасных методов. Выбор зависит от того, нужен ли файл полностью или только частично.
| Способ | Когда подходит | Минус |
|---|---|---|
| Блокировка на сервере | XML-RPC не нужен вообще | Может сломать внешние интеграции |
| Фильтр WordPress | Нужно быстро отключить доступ изнутри CMS | Запрос всё равно доходит до WordPress |
| Ограничение методов | Нужны отдельные функции XML-RPC | Требует аккуратной настройки |
Вариант 1: закрыть файл на уровне Nginx
Если XML-RPC не нужен, это самый прямой вариант. Для Nginx добавьте правило в конфигурацию сайта:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
return 444;
}Код 444 просто рвёт соединение без ответа. Это снижает шум от сканеров и экономит ресурсы. После изменения конфигурации не забудьте проверить синтаксис и перезагрузить сервер.
Вариант 2: закрыть через .htaccess в Apache
Если сайт работает на Apache, можно добавить правило в .htaccess:
<Files xmlrpc.php>
Require all denied
</Files>Это хороший вариант для shared-хостинга, где нет доступа к конфигу виртуального хоста. Но если у вас есть интеграции, сначала убедитесь, что они не используют XML-RPC.
Вариант 3: отключить XML-RPC через WordPress
Если удобнее управлять логикой из кода WordPress, используйте фильтр xmlrpc_enabled:
add_filter('xmlrpc_enabled', '__return_false');Это короткое и рабочее решение. Оно не заменяет серверную блокировку, но подходит как быстрый способ отключить XML-RPC на уровне приложения. Если у вас есть доступ к серверу, лучше сочетать оба уровня: WordPress + веб-сервер.
Вариант 4: оставить XML-RPC, но убрать опасные методы
Иногда нужен только ограниченный набор методов. Например, если вы не хотите полностью ломать старую интеграцию, но хотите убрать pingback. Тогда можно фильтровать список методов:
add_filter('xmlrpc_methods', function ($methods) {
unset($methods['pingback.ping']);
unset($methods['pingback.extensions.getPingbacks']);
return $methods;
});Этот вариант не делает XML-RPC безопасным сам по себе, но уменьшает поверхность атаки. Для сайтов с историческим наследием это часто промежуточный шаг перед полным отключением.
Пошаговое решение для боевого сайта
Если нужен практический порядок действий, делайте так:
- Проверьте, используются ли Jetpack, мобильные приложения WordPress, внешняя публикация или старые интеграции.
- На staging-копии временно отключите XML-RPC через
xmlrpc_enabled. - Протестируйте входящие публикации, синхронизацию и любые внешние сервисы.
- Если всё работает без XML-RPC, закройте
xmlrpc.phpна уровне сервера. - Проверьте логи на 403/444 и убедитесь, что нет легитимных ошибок.
Если сайт большой, лучше сначала закрыть доступ только для подозрительных IP через WAF или fail2ban, а не рубить файл сразу для всех. Это особенно полезно, когда вы ещё не до конца понимаете, кто именно обращается к XML-RPC.
Как проверить, что решение сработало
После внедрения нужно проверить не только «открывается ли сайт», но и сам факт блокировки.
- Откройте
https://example.com/xmlrpc.phpв браузере: при правильной блокировке вы не должны получить рабочий XML-RPC-ответ. - Проверьте access-лог: запрос должен завершаться 403, 444 или другим ожидаемым кодом отказа.
- Если использовали фильтр WordPress, попробуйте отправить тестовый XML-RPC-запрос из внешнего клиента.
- Проверьте Jetpack, если он установлен: некоторые функции могут зависеть от связи через XML-RPC.
- Посмотрите error.log и debug.log на предмет новых ошибок после изменения.
Если вы закрывали файл на уровне сервера, а WordPress всё ещё отвечает на запросы, значит правило не применилось или конфиг перезаписан другим include-файлом.
Частые ошибки и как их исправить
Сразу блокируют xmlrpc.php, не проверив интеграции
Это самая частая проблема. Пользователь видит, что сайт живой, но внешняя публикация перестаёт работать. Решение простое: сначала staging и только потом боевой сайт.
Путают XML-RPC и REST API
Это разные механизмы. Отключение xmlrpc.php не должно ломать REST API, но если после изменений «отвалились» мобильные приложения или редактор, проверьте, что вы не блокировали лишние маршруты на уровне WAF или плагина безопасности.
Блокируют только через WordPress, но не на сервере
Такой вариант оставляет лишнюю нагрузку: запрос всё равно доходит до PHP и WordPress. Если атаки массовые, лучше закрыть файл раньше — на уровне Nginx или Apache.
Оставляют pingback включённым
Pingback редко нужен на современных сайтах, но часто используется для спама и лишних запросов. Если XML-RPC нужен частично, хотя бы уберите pingback-методы.
Безопасность и производительность: что ещё стоит сделать
Если вы уже трогаете XML-RPC, имеет смысл посмотреть на соседние точки входа. На практике полезно:
- ограничить попытки входа в админку;
- включить нормальный WAF или хотя бы rate limiting;
- убрать ненужные pingback/trackback, если они не используются;
- проверить, не открыт ли лишний доступ к
wp-login.phpиwp-admin; - следить за логами после изменений хотя бы несколько дней.
Если вам нужен более широкий набор настроек для чистки сайта, отключения дублей и технической оптимизации, часть задач удобно закрывать через Clearfy Pro: https://wpshop.ru/plugins/clearfy?utm_source=wptavern.ru&utm_medium=article&utm_campaign=kak-zakryt-xmlrpc-i-ostavit-rabochimi-nuzhnye-integracii
Но саму блокировку XML-RPC лучше делать осознанно, а не «по кнопке». В этом вопросе важнее не скорость, а понимание, кто и зачем ходит в ваш сайт.