Если в логах постоянно всплывают запросы к xmlrpc.php, а сайт получает лишнюю нагрузку или брутфорс по старому интерфейсу, чаще всего проблема не в самом файле, а в том, что через XML-RPC вам уже ничего не нужно, кроме редких интеграций. Важно не рубить всё подряд: на некоторых сайтах через XML-RPC до сих пор работают мобильные приложения, Jetpack и отдельные внешние сервисы.
Когда отключать XML-RPC pingback, а когда не трогать
XML-RPC в WordPress исторически нужен для удалённой публикации и обмена данными. На практике чаще всего мешает именно pingback и старые сценарии авторизации, которые создают лишний шум в логах и открывают поверхность для атак. Если сайт не использует внешнюю публикацию, а редакторы заходят только в админку или через современный REST API, отключение обычно оправдано.
Но есть исключения. Не отключайте XML-RPC без проверки, если:
- используется Jetpack и он завязан на XML-RPC в вашей конфигурации;
- редакторы публикуют через мобильное приложение WordPress;
- есть интеграции старых CMS, CRM или сервисов, которые ходят именно в
xmlrpc.php; - на сайте включены внешние инструменты автопостинга, и вы не уверены, как они подключаются.
Диагностика: что именно ломает XML-RPC
Перед изменениями проверьте, кто и как обращается к xmlrpc.php. Если это только сканеры и боты, отключение безопаснее. Если в логах есть запросы от ваших сервисов, сначала замените интеграцию или убедитесь, что она умеет работать через REST API.
Что смотреть в логах
- частые POST-запросы к
/xmlrpc.phpс разных IP; - ошибки авторизации с одинаковыми логинами;
- повторяющиеся вызовы
system.multicall; - запросы от Jetpack, мобильного приложения или внешнего плагина, который вы реально используете.
Если у вас есть доступ к access log, можно быстро отфильтровать обращения:
grep "xmlrpc.php" /var/log/nginx/access.log | tail -n 50Для Apache логика та же, меняется только путь к файлу. Смысл проверки простой: сначала понять источник, потом резать доступ.
Пошаговое решение: как отключить pingback и при необходимости весь XML-RPC
Есть три рабочих варианта: через плагин, через код в теме или через серверную блокировку. Для большинства сайтов безопаснее начать с кода, если вы контролируете тему и не хотите лишних плагинов.
| Способ | Плюсы | Минусы | Когда выбирать |
|---|---|---|---|
| Код в теме или mu-plugin | Прозрачно, без лишних зависимостей | Нужно не забыть при смене темы | Если нужен точечный контроль |
| Плагин безопасности | Быстро включается | Добавляет ещё один слой логики | Если админка уже управляется через плагин |
| Блокировка на сервере | Жёстко режет запросы до PHP | Можно сломать нужные интеграции | Если XML-RPC точно не нужен |
Вариант 1. Отключить только pingback
Если вам нужны редкие XML-RPC-сценарии, но не нужны pingback и trackback, уберите именно их. Это мягкий вариант: он снижает шум и часть злоупотреблений, но не ломает весь канал.
add_filter('xmlrpc_methods', function ($methods) {
unset($methods['pingback.ping']);
unset($methods['pingback.extensions.getPingbacks']);
return $methods;
});Такой код можно добавить в functions.php дочерней темы или, что надёжнее, в небольшой mu-plugin. Для production-сайта mu-plugin предпочтительнее: он не зависит от активной темы.
Вариант 2. Полностью отключить XML-RPC
Если интеграций нет, можно выключить весь механизм. В WordPress есть штатный фильтр xmlrpc_enabled, который позволяет вернуть false.
add_filter('xmlrpc_enabled', '__return_false');Это самый понятный способ на уровне WordPress. Он не требует правок сервера и не создаёт побочных эффектов для остального сайта, если XML-RPC действительно не используется.
Вариант 3. Закрыть доступ на уровне веб-сервера
Если задача — не только отключить функциональность, но и снизить нагрузку от ботов, можно заблокировать сам файл xmlrpc.php на уровне Nginx или Apache. Это полезно, когда запросов очень много и вы хотите отрезать их до запуска PHP.
Пример для Nginx:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Для Apache используйте правила в .htaccess или конфигурации виртуального хоста, если это допустимо в вашей инфраструктуре. Но перед этим убедитесь, что ни один сервис не обращается к XML-RPC.
Как проверить, что решение сработало
Проверка должна быть не только визуальной. Нужно убедиться, что:
xmlrpc.phpперестал отвечать или вернул ожидаемый код;- сайт не потерял нужные интеграции;
- в логах стало меньше мусора;
- не появились ошибки в админке или у редакторов.
Проверить ответ можно через curl:
curl -I https://example.com/xmlrpc.phpЕсли вы отключили XML-RPC полностью, ожидаемое поведение зависит от способа блокировки: это может быть 403 Forbidden, 404 Not Found или ответ WordPress с сообщением об отключении. Главное — убедиться, что файл больше не принимает рабочие XML-RPC-запросы.
Если вы оставили XML-RPC включённым, проверьте конкретно pingback. После удаления метода запросы на pingback должны перестать проходить, а обычные сценарии, если они есть, должны продолжить работать.
Частые ошибки и как их исправить
Отключили всё, а потом перестал работать Jetpack
Значит, XML-RPC был нужен. В такой ситуации не стоит возвращать всё назад без разбора. Сначала проверьте, какие именно функции Jetpack используются, и можно ли обойтись без XML-RPC в вашей связке. Если нет — оставьте XML-RPC включённым и отключите только pingback, либо закройте доступ точечно по IP/правилам безопасности.
Поставили блокировку на сервере и сломали внешнюю интеграцию
Это типичная ошибка, когда правило добавляют без инвентаризации сервисов. Исправление простое: временно снимите блок, посмотрите, кто обращается к xmlrpc.php, и переведите этот сервис на другой способ интеграции, если он доступен.
Добавили код в активную тему и забыли про обновление
Если код лежит в functions.php родительской темы, он может потеряться при замене темы. Для технических ограничений лучше использовать mu-plugin. Это особенно важно для сайтов, где безопасность и техподдержка важнее удобства редактирования.
Безопасность и производительность: что ещё стоит сделать рядом
Отключение XML-RPC не закрывает все векторы атак, но убирает один из самых шумных. Если на сайте уже есть проблемы с брутфорсом, имеет смысл дополнительно:
- ограничить попытки входа в админку;
- включить двухфакторную аутентификацию для редакторов и администраторов;
- проверить, не открыт ли лишний REST endpoint для публичных данных;
- посмотреть, не создаёт ли тема или плагин лишние запросы к внешним ресурсам;
- убрать старые плагины, которые давно не обновлялись и не нужны в работе.
Если вам нужен инструмент для чистки технических дублей, управления SEO-деталями и отключения лишнего мусора в WordPress, можно посмотреть Clearfy Pro. Но даже с плагином всё равно стоит понимать, что именно вы отключаете и почему.
Когда лучше не отключать XML-RPC полностью
Если сайт живёт за счёт внешних публикаций, автоматизации или старых интеграций, полный запрет может создать больше проблем, чем пользы. В таких случаях разумнее:
- оставить XML-RPC включённым, но отключить pingback;
- ограничить доступ по IP, если это возможно;
- вынести публикацию на REST API или другой современный канал;
- проверить, можно ли заменить старый сервис без потери функциональности.
Практический ориентир простой: если вы не можете назвать ни одного легитимного клиента, который должен ходить в xmlrpc.php, его можно отключать. Если такой клиент есть, сначала тестируйте на staging, а уже потом переносите изменения на боевой сайт.