Как отключить xmlrpc.php в WordPress без ломки REST API и планировщика

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

Ниже — рабочий сценарий: как понять, нужен ли вам xmlrpc.php, чем его лучше отключать, как не задеть REST API и как проверить, что после изменения сайт ведёт себя нормально.

Когда проблема действительно есть

Отключать XML-RPC имеет смысл не потому, что это «модно», а когда вы видите конкретные признаки:

• в логах много запросов к /xmlrpc.php с перебором логинов и паролей;
• хостинг показывает всплески POST-запросов к этому файлу;
• сайт не использует удалённую публикацию, старые приложения WordPress и интеграции через XML-RPC;
• нужно сократить лишнюю поверхность атаки без вмешательства в REST API и админку.

Важно не путать XML-RPC и REST API. Это разные механизмы. Если вам нужен Gutenberg, мобильные приложения, внешние сервисы на REST — отключение xmlrpc.php их не затрагивает.

Что проверить до изменений

Сначала убедитесь, что XML-RPC реально не нужен. Для этого проверьте:

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

Если сомневаетесь, временно ограничьте доступ к файлу на уровне сервера и посмотрите логи. Это безопаснее, чем сразу удалять или бездумно ставить плагин, который блокирует всё подряд.

Как отключить xmlrpc.php без побочных эффектов

Есть три нормальных подхода: через плагин, через код и через веб-сервер. Для большинства сайтов самый предсказуемый вариант — код в functions.php дочерней темы или в небольшом mu-plugin. Так вы контролируете поведение и не зависите от лишнего плагина.

Вариант через код

Если XML-RPC не нужен, можно полностью отключить его фильтром xmlrpc_enabled:

add_filter( 'xmlrpc_enabled', '__return_false' );

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

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

Вариант через mu-plugin

Если не хотите зависеть от темы, создайте файл wp-content/mu-plugins/disable-xmlrpc.php:

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

mu-plugin удобен тем, что он не отключится случайно при смене темы или обновлении обычных плагинов. Для технической чистки сайта это часто лучший компромисс.

Вариант через nginx

Если сайт работает на nginx, можно отрезать запросы к xmlrpc.php ещё до запуска PHP:

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

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

Диагностика: как понять, что отключение не сломало сайт

После изменения не ограничивайтесь открытием главной страницы. Проверьте именно те точки, которые обычно страдают при неаккуратной чистке:

• вход в админку и создание/редактирование записей;
• REST API, если его использует тема, редактор или внешние сервисы;
• Jetpack, если он установлен;
• отложенные задачи WordPress и публикацию по расписанию;
• логи веб-сервера на предмет 403/404/500 по /xmlrpc.php.

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

Минимальный чек-лист проверки

• Открывается ли админка без ошибок.
• Сохраняются ли записи и страницы.
• Работает ли публикация по расписанию.
• Не ругается ли Jetpack, если он используется.
• Нет ли всплеска 500-ошибок в логах после изменения.

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

Ошибка 1: блокируют не только XML-RPC, но и REST API. Это часто происходит, когда ставят слишком агрессивный security-плагин или правила в nginx копируют без проверки. Симптом: ломается редактор, интеграции и часть админки. Решение — убрать правило, которое режет /wp-json/, и оставить блокировку только для /xmlrpc.php.

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

Ошибка 3: правят functions.php родительской темы. После обновления тема перезапишется, и защита исчезнет. Решение — использовать дочернюю тему или mu-plugin.

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

Когда лучше не отключать xmlrpc.php полностью

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

• ограничить доступ по IP на уровне сервера;
• оставить endpoint, но закрыть его дополнительной защитой;
• проверить, можно ли перевести интеграцию на REST API.

Если задача — не просто «убрать лишнее», а сделать сайт чище и безопаснее, иногда полезно смотреть на это как на часть общей технической уборки. В таких задачах удобно сочетать точечные правки кода с инструментами вроде Clearfy Pro, если вам нужен набор именно для удаления дублей и чистки типовых WordPress-излишков: https://wpshop.ru/plugins/clearfy.

Что делать после внедрения

Когда убедились, что сайт не сломался, не оставляйте проверку на уровне «всё открывается». Через 1–2 дня посмотрите логи и убедитесь, что:

• запросы к /xmlrpc.php больше не создают нагрузку;
• нет ошибок в cron-задачах;
• не появились жалобы на публикацию или синхронизацию контента;
• внешние сервисы, если они есть, переведены на рабочий способ интеграции.

Если на сайте есть мониторинг, добавьте отдельную проверку на доступность /xmlrpc.php. Это поможет быстро заметить, если правило на сервере случайно исчезнет после деплоя или миграции.