Как отключить XML-RPC в WordPress и не сломать нужные подключения

XML-RPC в WordPress часто отключают по одной причине: через него регулярно прилетают брутфорс-атаки и лишние запросы. Но у этого интерфейса есть и легитимные сценарии — мобильное приложение WordPress, внешние публикации, некоторые интеграции и старые сервисы. Поэтому правильный подход здесь не «выключить всё сразу», а сначала понять, используется ли endpoint /xmlrpc.php, а потом уже закрывать его точечно.

Если задача стоит именно как техническая оптимизация и снижение поверхности атаки, ниже — рабочая схема: как диагностировать использование XML-RPC, чем его отключить, как проверить, что ничего не сломалось, и какие ошибки обычно допускают на продакшене.

Когда XML-RPC действительно стоит отключать

Отключение имеет смысл, если сайт не использует:

• мобильное приложение WordPress для публикации;
• удалённую публикацию через старые клиенты и сервисы;
• pingback/trackback-сценарии, если они вам не нужны;
• внешние инструменты, которые обращаются к xmlrpc.php напрямую.

Если у вас обычный контентный сайт, а публикация идёт только из админки, XML-RPC чаще всего не нужен. Но перед отключением лучше проверить логи и фактические обращения, а не ориентироваться на предположение.

Диагностика: используется ли XML-RPC сейчас

Самый простой способ — посмотреть доступ к /xmlrpc.php в логах веб-сервера. Если у вас Nginx, ищите запросы к этому файлу по access log. Если Apache — аналогично в access.log. Важно смотреть не только 200 OK, но и 401/403/405: даже неуспешные попытки показывают, что endpoint активно сканируют.

Пример быстрой проверки через консоль на сервере:

grep "xmlrpc.php" /var/log/nginx/access.log | tail -n 20

Если доступа к логам нет, можно проверить ответ напрямую:

curl -I https://example.com/xmlrpc.php

Обычный ответ WordPress на этот файл часто выглядит как 405 Method Not Allowed или 200 с сообщением об ошибке метода — это нормально. Сам по себе такой ответ ещё не говорит, что XML-RPC используется, но подтверждает, что endpoint доступен извне.

Что ещё проверить перед отключением

• Использует ли кто-то мобильное приложение WordPress для публикации.
• Есть ли сторонние сервисы автопостинга, которые подключены к сайту.
• Нужны ли вам pingback и trackback вообще.
• Нет ли интеграций, которые завязаны на старый XML-RPC API.

Если сайт небольшой и публикация идёт только через wp-admin, обычно отключение проходит без последствий. Но на проектах с редакторами, внешними интеграциями и автоматизацией лучше сначала сделать тест на staging.

Как отключить XML-RPC: три рабочих варианта

Выбор зависит от того, как у вас устроен сайт. Если нужен быстрый и обратимый способ — используйте плагин. Если хотите минимальный overhead — добавьте фильтр в код темы или mu-plugin. Если задача только в блокировке на уровне сервера — можно закрыть доступ в конфиге веб-сервера.

Вариант 1. Отключить XML-RPC через код

Если нужен аккуратный способ без плагинов, добавьте фильтр xmlrpc_enabled. Лучше размещать его в mu-plugins или в дочерней теме, если тема у вас под контролем.

<?php
add_filter( 'xmlrpc_enabled', '__return_false' );

Этот вариант отключает сам XML-RPC API, но не мешает WordPress работать как обычно через админку и REST API. Для большинства сайтов этого достаточно.

Если хотите дополнительно убрать pingback, можно отключить соответствующий функционал отдельно:

<?php
add_filter( 'pings_open', '__return_false' );
add_filter( 'xmlrpc_methods', function( $methods ) {
    unset( $methods['pingback.ping'] );
    return $methods;
} );

Но здесь важно понимать: если вы отключаете pingback, убедитесь, что он вам действительно не нужен. Для современных сайтов это чаще всего не критично.

Вариант 2. Закрыть xmlrpc.php на уровне сервера

Если у вас Nginx, можно запретить доступ к файлу напрямую. Это полезно, когда вы хотите отрезать запросы ещё до загрузки WordPress.

location = /xmlrpc.php {
    deny all;
    access_log off;
    log_not_found off;
}

Для Apache можно использовать правило в .htaccess:

<Files "xmlrpc.php">
    Require all denied
</Files>

Серверная блокировка хороша тем, что снижает лишнюю нагрузку. Но если вы позже вспомните про внешнюю интеграцию, придётся править конфиг и перезагружать веб-сервер. Поэтому сначала проверьте зависимости.

Вариант 3. Использовать плагин

Если нужен быстрый способ без кода, можно поставить плагин, который отключает XML-RPC и связанные с ним функции. Это удобно для редакторов и администраторов, которые не хотят лезть в конфиги. Но для продакшена я бы всё равно предпочёл код или серверное правило: меньше лишней логики в админке.

Если на сайте уже используется набор утилит для технической чистки, например Clearfy Pro, проверьте, нет ли там отдельной настройки для XML-RPC и pingback. Важно не дублировать отключение в нескольких местах: потом сложно понять, что именно сработало.

Пошаговое решение без лишнего риска

1. Проверьте логи на обращения к xmlrpc.php.
2. Уточните, не используется ли мобильное приложение WordPress или внешняя публикация.
3. Выберите способ отключения: код, сервер или плагин.
4. Внесите изменение сначала на staging, если он есть.
5. Проверьте, что админка, REST API и публикация записей работают как раньше.
6. Посмотрите логи ещё раз через 1–2 дня и убедитесь, что нет ошибок у интеграций.

Как проверить, что решение сработало

После внедрения не ограничивайтесь визуальной проверкой сайта. Нужны конкретные признаки, что XML-RPC действительно закрыт.

• Запрос к /xmlrpc.php возвращает 403 Forbidden или 404 Not Found, если вы блокировали файл на сервере.
• В логах больше нет успешных обращений к этому endpoint.
• Мобильное приложение WordPress, если оно использовалось, больше не может подключиться.
• Публикация и редактирование записей через админку работают без изменений.

Проверить ответ можно так:

curl -I https://example.com/xmlrpc.php

Если вы отключали через фильтр xmlrpc_enabled, WordPress может отвечать иначе, чем при серверной блокировке. Это нормально. Важен не конкретный код ответа, а отсутствие возможности использовать XML-RPC по назначению.

Частые ошибки и как их исправить

Отключили XML-RPC, а потом перестало подключаться мобильное приложение

Это ожидаемое поведение, а не ошибка WordPress. Если приложение действительно нужно, не блокируйте endpoint полностью. Лучше ограничьте доступ на уровне IP, VPN или используйте другой сценарий публикации.

Добавили правило в .htaccess, но XML-RPC всё ещё отвечает

Частая причина — сайт работает на Nginx, а правили Apache-конфиг, который не используется. Ещё вариант — правило стоит ниже других директив и не срабатывает. Проверьте реальный стек веб-сервера и место, где он читает правила.

Отключили pingback, но не проверили внешние сервисы

Некоторые старые сервисы используют pingback как часть автоматизации. Если у вас есть интеграции, не отключайте всё вслепую. Сначала посмотрите, какие методы XML-RPC реально вызываются.

Сделали и в плагине, и в коде, и на сервере

Такой «слоёный пирог» потом трудно сопровождать. Если что-то перестало работать, вы не поймёте, какой именно уровень блокирует запрос. Выберите один основной способ и документируйте его в проекте.

Безопасность и производительность: что важно не забыть

Отключение XML-RPC не заменяет нормальную защиту входа в админку. Если у вас слабые пароли, нет ограничений по логину и не включена двухфакторная аутентификация, закрытие одного endpoint не решит проблему целиком.

С точки зрения производительности серверная блокировка предпочтительнее: запросы не доходят до WordPress, а значит, не тратятся ресурсы PHP и базы. Но если у вас нет доступа к конфигам, кодовый фильтр тоже рабочий и обычно достаточный.

Для сайтов, где важна техническая чистота, полезно держать такие отключения в одном месте — например, в mu-plugins. Тогда при смене темы вы не потеряете настройку и не забудете, где именно она была сделана.

<?php
/**
 * Plugin Name: Disable XML-RPC
 */
add_filter( 'xmlrpc_enabled', '__return_false' );

Такой мини-плагин проще сопровождать, чем правку в functions.php активной темы. Для проекта это обычно более надёжный вариант.