XML-RPC в WordPress часто отключают «на всякий случай», а потом внезапно перестают работать мобильное приложение, внешняя публикация записей или отдельные интеграции. Проблема в том, что этот механизм одновременно используется и легитимными клиентами, и ботами для перебора паролей. Поэтому задача не в том, чтобы просто закрыть /xmlrpc.php, а в том, чтобы сначала понять, нужен ли он вообще вашему сайту.
Ниже — рабочий сценарий: как диагностировать использование XML-RPC, чем его отключать, как не сломать нужные подключения и как проверить результат после внедрения.
Когда XML-RPC действительно можно отключать
Если вы публикуете контент только через админку WordPress, не используете старые десктопные клиенты, Jetpack-связку, внешние сервисы автопостинга и не подключаете сайт к сторонним редакторам через XML-RPC, этот интерфейс обычно не нужен. На большинстве современных проектов REST API уже закрывает часть задач, а XML-RPC остаётся только как наследие.
Но есть важная оговорка: некоторые плагины и сервисы до сих пор обращаются именно к xmlrpc.php. Поэтому перед отключением стоит проверить реальные запросы, а не ориентироваться на предположения.
Диагностика проблемы: используется ли XML-RPC на вашем сайте
Самый простой способ — посмотреть логи веб-сервера и обращения к /xmlrpc.php. Если у вас есть доступ к access log, ищите строки с этим путём. Повторяющиеся запросы с разных IP, особенно с методами system.multicall и pingback.ping, обычно указывают на автоматизированные попытки перебора или сканирование.
Если доступа к логам нет, можно временно включить логирование на уровне сервера или использовать плагин безопасности, который показывает частые обращения к файлам сайта. Но не делайте вывод только по одному запросу: иногда это может быть ваш же сервис публикации или мобильное приложение.
Что проверить перед отключением
- Используется ли Jetpack и включена ли синхронизация через WordPress.com.
- Есть ли внешние сервисы автопостинга, которые публикуют записи через XML-RPC.
- Используется ли мобильное приложение WordPress для публикации.
- Есть ли старые интеграции с редакторами или CRM, которые не переведены на REST API.
- Есть ли на сайте пингбэки и комментарии, завязанные на старую логику WordPress.
Как отключить XML-RPC: сравнение подходов
| Способ | Когда подходит | Плюсы | Минусы |
|---|---|---|---|
| Через код в теме или mu-plugin | Нужен контроль без лишних плагинов | Прозрачно, легко проверить, не зависит от стороннего плагина | Нужно не забыть про обновления и место подключения кода |
| Через security-плагин | Если уже используете плагин для защиты | Быстро включается, часто есть дополнительные фильтры | Лишняя зависимость, иногда отключает больше, чем нужно |
| На уровне сервера | Если нужен жёсткий запрет | Запросы не доходят до WordPress | Можно случайно сломать интеграции, сложнее отлаживать |
Если задача точечная, обычно достаточно кода. Если нужен более жёсткий барьер против брутфорса, можно добавить серверное правило, но только после проверки зависимостей.
Пошаговое решение через код
Самый безопасный вариант — отключить XML-RPC через фильтр xmlrpc_enabled. Его удобно положить в mu-plugin, чтобы код не потерялся при смене темы.
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Если нужно не просто отключить сам протокол, а ещё и убрать возможность пингбэков, можно дополнительно запретить соответствующий хук. Это полезно, когда сайт получает много мусорных уведомлений о ссылках.
<?php
add_filter( 'xmlrpc_methods', function( $methods ) {
unset( $methods['pingback.ping'] );
unset( $methods['pingback.extensions.getPingbacks'] );
return $methods;
} );Такой подход не ломает весь сайт сразу и даёт более тонкий контроль. Но если у вас есть внешние клиенты, которые используют XML-RPC для публикации, они перестанут работать. Это нормально только в том случае, если вы заранее подтвердили, что они не нужны.
Если нужен жёсткий запрет на уровне сервера
На Apache можно закрыть доступ к файлу xmlrpc.php через .htaccess. Это полезно, если боты активно долбят именно этот endpoint и вы хотите отсечь их до загрузки WordPress.
<Files xmlrpc.php>
Require all denied
</Files>Для Nginx правило выглядит иначе и добавляется в конфигурацию сайта:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Серверный вариант хорош, но его стоит применять только после проверки, что вам не нужен XML-RPC вообще. Иначе вы получите не «защиту», а сломанную интеграцию.
Проверка результата после внедрения
После отключения откройте https://ваш-домен/xmlrpc.php. В норме вы не должны видеть рабочий endpoint. В зависимости от способа блокировки это может быть 403, 404 или сообщение о том, что XML-RPC отключён. Главное — не должно быть успешного ответа с доступными методами.
Дальше проверьте реальные сценарии:
- попробуйте войти в мобильное приложение WordPress, если вы им пользовались;
- проверьте внешнюю публикацию из сервисов, которые были подключены к сайту;
- посмотрите логи сервера: обращения к
/xmlrpc.phpдолжны либо исчезнуть, либо получать отказ; - убедитесь, что обычная авторизация в админке и публикация записей работают как раньше.
Если у вас есть мониторинг безопасности, полезно сравнить количество неудачных запросов до и после. Но даже без цифр видно, что endpoint перестаёт отвечать на автоматические попытки перебора.
Частые ошибки и как их исправить
Отключили XML-RPC в теме
Если код лежит в functions.php, он пропадёт при смене темы. Для технической настройки лучше использовать mu-plugin или отдельный мини-плагин. Тогда отключение не зависит от дизайна.
Сломали Jetpack или внешнюю публикацию
Это типичный сценарий, когда XML-RPC закрыли без проверки зависимостей. Решение простое: временно верните доступ, проверьте, какой сервис обращается к endpoint, и решите, можно ли перевести его на другой способ интеграции.
Закрыли только через плагин, но endpoint всё равно отвечает
Некоторые плагины отключают функциональность на уровне WordPress, но сам файл xmlrpc.php остаётся доступным. Если боты продолжают стучаться, добавьте серверное правило или фильтр xmlrpc_enabled.
Ожидали, что это ускорит сайт
Отключение XML-RPC само по себе не является оптимизацией производительности в прямом смысле. Оно убирает лишний вектор атак и шум в логах, но не заменяет кеширование, оптимизацию запросов и нормальную настройку PHP-FPM.
Практические советы по безопасности
Если на сайте много мусорных запросов к XML-RPC, отключение — только один слой защиты. Дополнительно проверьте:
- сильные пароли и 2FA для админов;
- ограничение попыток входа;
- актуальность ядра, тем и плагинов;
- отсутствие лишних публичных пользователей с правами редактора или администратора;
- наличие резервных копий перед изменением серверной конфигурации.
Если вы используете плагин для чистки и SEO-настроек, например Clearfy Pro, проверьте, не дублирует ли он часть защитных правил с вашим серверным конфигом. Дублирование настроек само по себе не ошибка, но иногда приводит к путанице, когда непонятно, какой слой реально блокирует endpoint.
Для проектов, где важна минимизация поверхности атаки, лучше идти по схеме: сначала диагностика, потом точечное отключение через код, и только затем — серверный запрет. Так проще понять, что именно сломалось, если интеграция перестала отвечать.
Если после отключения XML-RPC сайт ведёт себя штатно, а в логах больше нет лишних обращений, значит решение сработало. Если что-то перестало публиковаться или синхронизироваться, возвращайтесь к списку зависимостей и ищите конкретный сервис, а не отключайте защиту целиком.