XML-RPC в WordPress часто оставляют включённым «на всякий случай», а потом удивляются лишним запросам, брутфорсу по xmlrpc.php и странным обращениям в логах. Проблема в том, что этот файл нужен не всем, но отключать его вслепую тоже нельзя: некоторые мобильные клиенты, внешние сервисы публикации и старые интеграции до сих пор используют именно его.
Ниже — практический сценарий: как понять, нужен ли XML-RPC именно вашему сайту, как отключить его безопасно и как проверить, что ничего не отвалилось.
Когда XML-RPC действительно стоит отключать
Если вы не пользуетесь внешними приложениями для публикации, не подключали старые сервисы автопостинга и не видите в логах легитимных обращений к xmlrpc.php, отключение обычно оправдано. На практике это снижает поверхность атаки: именно этот файл часто используют для перебора паролей и массовых запросов.
Но есть и обратная сторона. XML-RPC может быть нужен:
- мобильному приложению WordPress для публикации и редактирования;
- Jetpack и похожим сервисам, если они у вас завязаны на старый механизм связи;
- внешним редакторам и интеграциям, которые не перешли на REST API;
- некоторым сервисам отложенного постинга и мониторинга.
Быстрая диагностика: нужен ли файл xmlrpc.php
Проверьте логи веб-сервера или защитного плагина. Если запросы к /xmlrpc.php идут только от сканеров и ботов, это хороший кандидат на отключение. Если же вы видите обращения от ваших устройств, сервисов публикации или интеграций, сначала разберитесь с ними.
Ещё один простой тест — открыть https://ваш-домен/xmlrpc.php в браузере. Нормальный ответ WordPress обычно выглядит как сообщение о том, что XML-RPC сервер принимает только POST-запросы. Это не доказывает, что файл нужен, но подтверждает, что он доступен извне.
Как отключить XML-RPC: сравнение подходов
Есть три рабочих варианта: через плагин безопасности, через код в теме или mu-plugin, и на уровне веб-сервера. У каждого свой компромисс.
| Способ | Плюсы | Минусы |
|---|---|---|
| Плагин | Быстро, без правки кода, удобно для админов | Дополнительная зависимость, не всегда нужен ещё один плагин |
| Код | Прозрачно, переносимо, легко откатить | Нужно понимать, куда вставлять код |
| Веб-сервер | Режет запросы раньше WordPress, меньше нагрузки | Зависит от конфигурации хостинга, не всегда доступно |
Если у вас уже есть плагин безопасности, проще использовать его. Если хотите минимальное и контролируемое решение, лучше добавить код в mu-plugin или в собственный мини-плагин.
Вариант 1: отключить XML-RPC через код
Самый понятный способ — вернуть false в фильтре xmlrpc_enabled. Это отключит сам механизм обработки XML-RPC в WordPress.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Если вы хотите не просто отключить обработку, а ещё и явно блокировать доступ к файлу на уровне WordPress, можно добавить проверку в init. Такой вариант полезен, когда нужно вернуть понятный статус ответа и не отдавать лишнюю информацию.
<?php
add_action( 'init', function () {
if ( defined( 'XMLRPC_REQUEST' ) && XMLRPC_REQUEST ) {
status_header( 403 );
nocache_headers();
wp_die( 'XML-RPC disabled.', 'Forbidden', array( 'response' => 403 ) );
}
} );Код лучше размещать не в functions.php активной темы, а в небольшом плагине или mu-plugin. Тогда он не исчезнет после смены темы.
Вариант 2: закрыть xmlrpc.php на уровне сервера
Если у вас Apache и доступен .htaccess, можно заблокировать прямые обращения к файлу до загрузки WordPress. Это полезно, когда сайт получает много мусорных запросов и вы хотите сэкономить ресурсы.
<Files xmlrpc.php>
Require all denied
</Files>Для Nginx обычно используют отдельное правило в конфигурации виртуального хоста:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Если у вас нет доступа к конфигу сервера, не пытайтесь имитировать это через произвольные плагины редиректов. Для такого кейса лучше код или плагин безопасности.
Пошаговое решение без лишнего риска
- Проверьте, используются ли внешние клиенты, Jetpack или старые интеграции.
- Посмотрите логи обращений к
xmlrpc.phpза последние дни. - Выберите способ отключения: код, плагин или серверное правило.
- Внесите изменение сначала на staging, если он есть.
- Проверьте, не сломалась ли публикация из внешних приложений и не появились ли ошибки в админке.
Если сайт большой или на нём много сторонних интеграций, начните с временной блокировки на уровне WordPress, а не сервера. Так проще откатиться, если что-то перестанет работать.
Как проверить, что решение сработало
Проверка должна быть не только визуальной. После отключения откройте /xmlrpc.php напрямую. В зависимости от способа вы должны увидеть либо 403 Forbidden, либо сообщение о том, что XML-RPC отключён, либо другой отказ в доступе от сервера.
Дальше проверьте практические сценарии:
- вход в админку и обычную публикацию записей;
- работу мобильного приложения WordPress, если вы им пользуетесь;
- связанные сервисы автопостинга и мониторинга;
- логи сервера на предмет повторяющихся ошибок после изменения.
Если после отключения в логах продолжаются обращения к xmlrpc.php, это нормально: сканеры не исчезнут. Важно, чтобы они получали отказ быстро и без лишней нагрузки на PHP.
Частые ошибки и как их исправить
Отключили XML-RPC, а потом перестал работать мобильный клиент
Значит, у вас был реальный зависимый сценарий. Верните доступ и замените его на REST API или другой поддерживаемый способ интеграции. Не стоит держать XML-RPC включённым только ради одного старого приложения, если есть современная альтернатива.
Добавили код в тему, а после обновления он пропал
Это типичная ошибка. Для таких правок используйте mu-plugin или отдельный мини-плагин. Тогда отключение не зависит от темы и не потеряется при обновлении.
Поставили плагин безопасности и одновременно закрыли файл на сервере
Двойная блокировка обычно не ломает сайт, но усложняет диагностику. Если потом что-то перестанет работать, вы не поймёте, где именно сработало ограничение. Лучше оставить один основной способ и документировать его.
Сделали редирект вместо запрета
Редирект для xmlrpc.php — плохая идея. Сканеры всё равно будут стучаться, а вы получите лишние ответы и путаницу в логах. Для этого сценария нужен именно отказ в доступе, а не переадресация.
Что ещё стоит проверить после отключения
Если вы закрываете XML-RPC ради безопасности, не ограничивайтесь только этим файлом. Посмотрите, нет ли у сайта других лишних точек входа: устаревших плагинов, неиспользуемых REST-маршрутов, открытых тестовых страниц и слабых паролей админов. Одна точечная мера не заменяет базовую гигиену.
Для сайтов, где важна техническая чистота, полезно держать под рукой инструменты, которые помогают убирать лишнее из WordPress без ручной правки каждого шаблона. Например, если вам нужно одновременно чистить сайт от мусорных элементов, дублей и лишних технических хвостов, можно посмотреть на Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но даже в этом случае сначала проверьте, что именно вы отключаете и зачем.
Мини-чек-лист перед отключением
- Проверены внешние клиенты и интеграции.
- Посмотрены логи запросов к
xmlrpc.php. - Выбран один способ блокировки, без дублирования на всех уровнях сразу.
- Есть план отката на случай, если что-то перестанет работать.
- После изменения проверен прямой доступ к
/xmlrpc.phpи рабочие сценарии публикации.
Если у вас обычный сайт без внешних редакторов и старых интеграций, отключение XML-RPC — это не «жёсткая оптимизация», а нормальная техническая уборка. Главное — не делать её вслепую и не путать безопасность с поломкой нужного функционала.