XML-RPC в WordPress часто отключают «на всякий случай», а потом удивляются, почему перестало работать мобильное приложение, удалённая публикация или старый сервис синхронизации. На живом сайте правильный вопрос не «как вырубить файл», а «что именно использует XML-RPC и можно ли это заменить».
Если у вас нет внешних клиентов, которые публикуют записи через XML-RPC, и вы не используете старые интеграции, отключение этого интерфейса обычно упрощает поверхность атаки. Но делать это лучше после проверки зависимостей, а не по шаблону из чужой статьи.
Когда XML-RPC действительно мешает
Чаще всего проблема не в самом протоколе, а в том, что он остаётся открытым без необходимости. На практике это видно по трём сценариям: в логах много запросов к /xmlrpc.php, сайт получает брутфорс по этому адресу, либо вы нашли старую интеграцию, которая использует удалённую публикацию постов.
Что стоит проверить до отключения
Сначала убедитесь, что XML-RPC не нужен вашему стеку. Проверьте:
- мобильное приложение WordPress на телефоне или планшете;
- старые сервисы автопостинга и кросспостинга;
- клиенты для удалённой публикации, которые работают не через REST API;
- плагины синхронизации с внешними системами, если они были установлены давно;
- пингбэки и трекбэки, если вы всё ещё их используете.
Если сайт небольшой и публикации идут только через админку, чаще всего XML-RPC можно убрать без последствий. Но если есть сомнения, сначала проверьте доступ к нему, а уже потом меняйте конфигурацию.
Диагностика: как понять, используется ли xmlrpc.php
Самый простой способ — посмотреть логи веб-сервера или запросы в панели хостинга. Ищите обращения к /xmlrpc.php. Если их много и они идут с разных IP, это может быть и легитимный клиент, и атака перебором.
Ещё один практичный тест — временно ограничить доступ и проверить, не сломались ли внешние сценарии. Но лучше делать это не на боевом сайте вслепую, а через короткий список проверок.
curl -I https://example.com/xmlrpc.phpЕсли файл доступен, сервер обычно отвечает не 404, а 405 или 200 с сообщением WordPress. Это нормально: сам факт ответа ещё не означает, что интерфейс нужен. Важнее понять, кто им пользуется.
Как отключить XML-RPC: три рабочих варианта
Выбор зависит от того, насколько жёстко вы хотите закрыть доступ и есть ли у вас доступ к конфигурации сервера. Для большинства сайтов достаточно решения на уровне WordPress. Если нужен более строгий контроль, можно закрыть доступ на уровне веб-сервера или через WAF.
| Способ | Где применять | Плюс | Минус |
|---|---|---|---|
| Фильтр в WordPress | Когда нужен быстрый и обратимый вариант | Легко откатить | Файл остаётся доступным на уровне сервера |
| Правило в nginx/Apache | Когда нужен жёсткий запрет | Запросы не доходят до PHP | Нужен доступ к конфигу сервера |
| WAF/плагин безопасности | Когда уже используется защитный слой | Удобно централизовать правила | Зависимость от стороннего решения |
Вариант 1: отключение через functions.php или mu-plugin
Если вам нужно быстро убрать XML-RPC, добавьте фильтр. Лучше делать это в mu-plugin, чтобы правило не потерялось при смене темы.
<?php
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;
}После этого запросы к /xmlrpc.php должны получать отказ ещё на уровне веб-сервера. Такой способ особенно полезен, если на сайт регулярно идут автоматические попытки подбора паролей через XML-RPC.
Вариант 3: блокировка через Apache
Если сайт работает на Apache, используйте правило в .htaccess или в конфигурации виртуального хоста. Для .htaccess подойдёт такой вариант:
<Files xmlrpc.php>
Require all denied
</Files>Это не самый изящный способ, но он рабочий и понятный. Главное — не смешивать его с другими правилами без проверки, особенно если у вас уже есть сложный набор редиректов и ограничений доступа.
Что делать с пингбэками и трекбэками
Отключение XML-RPC часто путают с отключением пингбэков. Это не одно и то же, но на практике они связаны. Если вы не используете обратные уведомления о ссылках, их лучше отключить отдельно.
В админке WordPress это делается в настройках обсуждения. Если нужен кодовый вариант, можно убрать поддержку пингбэков для новых записей:
<?php
add_action( 'init', function () {
remove_post_type_support( 'post', 'trackbacks' );
remove_post_type_support( 'page', 'trackbacks' );
} );Но здесь важно не путать интерфейс и транспорт. XML-RPC может быть закрыт, а пингбэки как функция обсуждений — всё ещё включены в настройках записи.
Проверка результата после внедрения
После отключения не ограничивайтесь открытием главной страницы. Проверьте именно тот путь, который вы закрывали.
- Откройте
/xmlrpc.phpв браузере или черезcurl. - Убедитесь, что внешние интеграции не потеряли доступ.
- Посмотрите логи на предмет повторяющихся ошибок авторизации.
- Если использовали плагин безопасности, проверьте, не дублирует ли он ваше правило.
Хороший признак — запросы к /xmlrpc.php больше не проходят в PHP-слой, а в логах нет новых попыток авторизации через этот endpoint. Если вы отключали XML-RPC через фильтр, убедитесь, что после обновления темы или плагинов правило не исчезло.
Частые ошибки и как их исправить
Отключили XML-RPC, но сломали мобильное приложение
Значит, приложение использовало именно XML-RPC, а не REST API. Решение простое: либо вернуть доступ, либо перевести сценарий на современный способ работы с сайтом. Для старых интеграций это часто означает ручную перенастройку, а не «магическую» замену.
Поставили плагин безопасности и добавили ещё одно правило вручную
В итоге непонятно, что именно блокирует запросы. Если доступ закрыт несколькими слоями, диагностика становится сложнее. Лучше оставить один основной механизм и документировать, где именно стоит правило.
Закрыли файл, но не посмотрели логи
Это типичная ошибка. Если на /xmlrpc.php идёт много запросов, полезно понять источник. Иногда это просто шум ботов, а иногда — реальная интеграция, которую забыли учесть.
Использовали редирект вместо запрета
Редирект не решает задачу безопасности. Запрос всё равно доходит до сайта, а иногда ещё и создаёт лишнюю нагрузку. Для XML-RPC нужен именно отказ в доступе или отключение интерфейса.
Практика безопасности и производительности
Если сайт регулярно получает брутфорс по XML-RPC, отключение этого интерфейса полезно не только для безопасности, но и для снижения лишних запросов к PHP. Это не заменяет нормальную защиту входа в админку, но убирает один из популярных векторов атаки.
Если вы уже используете комплексную чистку сайта и SEO-оптимизацию, например Clearfy Pro, проверьте, не дублирует ли он ваши ручные правила для XML-RPC и пингбэков. Дублирующие меры сами по себе не вредны, но они усложняют поддержку и мешают понять, что именно сработало.
Для сайтов с высокой нагрузкой полезно держать короткий чек-лист:
- закрыт ли
/xmlrpc.phpна нужном уровне; - нет ли внешних клиентов, которым нужен старый протокол;
- не дублируется ли блокировка в плагине и на сервере;
- проверены ли логи после изменения;
- не остались ли включёнными ненужные пингбэки.
Если после отключения XML-RPC сайт работает штатно, а внешние сценарии не пострадали, значит решение выбрано правильно. Если что-то сломалось, возвращайте доступ точечно и уже потом решайте, чем заменить конкретную интеграцию.