Как отключить XML-RPC в WordPress через настройки сервера и плагин без поломки интеграций

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

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

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

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

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

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

Самый простой способ — посмотреть, кто обращается к /xmlrpc.php в логах веб-сервера или в аналитике безопасности. Если доступа к логам нет, можно проверить endpoint вручную. В ответе WordPress на этот URL обычно возвращает служебную страницу или ошибку, а не 404.

Быстрая проверка через curl

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

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

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

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

Способы отключения: что выбрать на практике

Есть три нормальных варианта: через плагин, через код и через серверную блокировку. Для большинства проектов самый безопасный путь — плагин или небольшой сниппет, потому что их проще откатить. Серверная блокировка полезна, если нужно отсечь запросы раньше, чем они дойдут до PHP.

Пошаговое решение через код

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

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

Этот способ отключает сам механизм XML-RPC на уровне WordPress. Запросы на /xmlrpc.php будут получать отказ, но файл останется доступен как точка входа. Для большинства сайтов этого достаточно.

Вариант для mu-plugin

Если вы ведёте несколько правок и не хотите привязываться к теме, создайте файл wp-content/mu-plugins/disable-xmlrpc.php. Mu-plugin загружается автоматически и не зависит от активной темы.

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

Это удобнее, чем править functions.php, если сайт часто обновляется или тема меняется.

Пошаговое решение через плагин

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

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

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

Если нужен жёсткий запрет на уровне сервера

Серверная блокировка полезна, когда бот-активность на /xmlrpc.php высокая и вы хотите отрезать запросы раньше, чем они попадут в WordPress. Это снижает нагрузку на PHP, но требует аккуратности: если у вас есть легитимные интеграции, они перестанут работать сразу.

Nginx

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

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

Apache

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

Проверка результата после внедрения

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

• Откройте https://example.com/xmlrpc.php в браузере или через curl.
• Убедитесь, что ответ не позволяет использовать XML-RPC как раньше.
• Проверьте публикацию из тех сервисов, которые были подключены раньше.
• Посмотрите логи на предмет повторяющихся ошибок от внешних клиентов.
• Если используете мониторинг безопасности, убедитесь, что он не считает блокировку ошибкой сервера.

Для быстрой проверки можно отправить POST-запрос и посмотреть, что сервер больше не принимает XML-RPC-методы:

curl -X POST https://example.com/xmlrpc.php \
  -H 'Content-Type: text/xml' \
  --data '<?xml version="1.0"?><methodCall><methodName>system.listMethods</methodName></methodCall>'

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

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

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

Причина почти всегда одна: приложение или сервис всё ещё использует XML-RPC, а не REST API. Решение — либо перевести интеграцию на REST, либо оставить XML-RPC включённым для этого сценария и закрыть его другими способами защиты.

Поставили плагин и забыли, что он конфликтует с другим плагином безопасности

Некоторые security-плагины дублируют одни и те же ограничения. В итоге вы видите неочевидные ошибки, хотя проблема не в WordPress, а в двух правилах, которые одновременно блокируют один и тот же URL. Проверяйте, кто именно отвечает за блокировку: плагин, сервер или WAF.

Спрятали проблему за 403, но не проверили логи

Если endpoint просто стал отдавать 403, это ещё не финальная проверка. Нужно понять, не идут ли на него постоянные запросы от легитимного клиента. Иначе вы получите тихую поломку, о которой узнаете только от редактора или заказчика.

Правили functions.php в родительской теме

Это частая ошибка на живых проектах. После обновления темы изменение исчезнет. Для таких правок лучше использовать mu-plugin или отдельный мини-плагин.

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

Отключение XML-RPC не заменяет нормальную защиту входа в админку. Если у вас слабые пароли, открыт /wp-login.php без ограничений и нет 2FA, один только запрет XML-RPC мало что даст. Но как часть общей гигиены это полезная правка.

Для производительности эффект обычно небольшой на спокойных сайтах, но заметнее на проектах, которые регулярно получают мусорные запросы. Если боты массово стучатся в xmlrpc.php, сервер перестаёт тратить ресурсы на обработку этих запросов в PHP.

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

Что делать, если XML-RPC всё-таки нужен частично

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

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