Как отключить XML-RPC.php в WordPress и не сломать нужные интеграции

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

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

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

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

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

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

Быстрая диагностика проблемы

Перед изменениями посмотрите, есть ли обращения к /xmlrpc.php в логах веб-сервера или в журнале безопасности. Если сайт под нагрузкой или его регулярно сканируют, этот файл часто фигурирует в запросах с попытками перебора логинов.

Проверить наличие endpoint можно и вручную:

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

Ответ 405 Method Not Allowed или похожий не означает, что всё уже отключено. Это лишь показывает, что файл существует и отвечает. Для реальной проверки важнее понять, принимает ли он XML-RPC-запросы.

Если у вас есть доступ к логам, ищите повторяющиеся POST-запросы к xmlrpc.php. Это полезно ещё и потому, что после отключения можно сравнить картину до и после.

Как отключить XML-RPC.php: сравнение подходов

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

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

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

Самый аккуратный вариант — отключить XML-RPC через фильтр xmlrpc_enabled. Это не выдуманный хук, он есть в WordPress и используется именно для такого сценария.

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

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

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

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

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

После этого WordPress перестанет принимать XML-RPC-запросы на уровне ядра. Это удобно, если вы не хотите зависеть от настроек сервера или стороннего плагина.

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

На Apache можно закрыть доступ к файлу через .htaccess. Это полезно, когда вы хотите отсечь запросы ещё до запуска PHP.

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

Для Nginx правило обычно добавляют в конфигурацию сайта:

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

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

Что проверить после отключения

После внедрения важно не ограничиваться «код добавили — значит всё хорошо». Проверьте три вещи: ответ endpoint, работу интеграций и отсутствие лишних ошибок в логах.

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

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

Пример запроса через curl:

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

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

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

Отключили XML-RPC, а автопостинг перестал работать

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

Добавили правило в .htaccess, но endpoint всё равно отвечает

Часто причина в том, что сайт работает на Nginx, а .htaccess вообще не используется. Ещё один вариант — правило добавили не в тот блок или его перезаписывает другой конфиг. В таком случае проверяйте именно конфигурацию веб-сервера, а не только файлы WordPress.

Плагин безопасности уже блокирует XML-RPC, а вы добавили ещё одно правило

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

Отключили endpoint, но в логах остались запросы

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

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

Отключение XML-RPC — не панацея, но это хороший шаг в сторону уменьшения поверхности атаки. На сайтах с большим количеством мусорных запросов это ещё и помогает убрать лишнюю работу PHP.

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

Если вам нужен более широкий набор технических чисток — отключение эмодзи, лишних эмбедов, REST-эндпоинтов, дублей и служебных скриптов — это уже лучше собирать осознанно, а не через случайные сниппеты. Для таких задач иногда используют Clearfy Pro, но и там важно проверять, что именно выключается на конкретном сайте, а не включать всё подряд.

Короткий чек-лист перед публикацией изменений

• Проверили, что XML-RPC реально не используется внешними сервисами.
• Выбрали один способ блокировки: код или сервер.
• Добавили правило в mu-plugin, плагин или конфиг сервера.
• Протестировали /xmlrpc.php через браузер и curl.
• Посмотрели логи на предмет ошибок и старых интеграций.
• Убедились, что REST API и админка работают как раньше.

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