Как отключить XML-RPC в WordPress через .htaccess и PHP

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

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

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

Не надо отключать его «на всякий случай», если вы не понимаете, кто им пользуется. Но если сайт обычный: публикации идут из админки, мобильное приложение не используется, внешние клиенты не подключены, а в логах регулярно видны запросы к /xmlrpc.php, отключение имеет смысл.

Типичные признаки, что XML-RPC не нужен

• вы не используете приложение WordPress на телефоне;
• нет интеграций с внешними CMS или редакторами через XML-RPC;
• в логах много запросов к xmlrpc.php с разных IP;
• плагин безопасности уже показывает попытки перебора через XML-RPC;
• сайт работает только как классический блог или корпоративный сайт.

Диагностика проблемы перед отключением

Сначала проверьте, не завязан ли на XML-RPC какой-то рабочий процесс. Это можно сделать без правок кода. Откройте https://ваш-домен/xmlrpc.php в браузере. Если интерфейс отвечает сообщением о том, что XML-RPC server accepts POST requests only, это нормально: сам файл доступен.

Дальше посмотрите логи веб-сервера или отчёты плагина безопасности. Если там идут частые обращения к xmlrpc.php, это не всегда атака, но часто именно так и выглядит автоматический перебор. Если у вас включён Cloudflare или другой WAF, проверьте, не блокирует ли он уже эти запросы — тогда отключение на уровне WordPress может быть избыточным.

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

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

Способ 1: отключить XML-RPC через .htaccess

Если сайт работает на Apache или LiteSpeed и у вас есть доступ к .htaccess, это самый прямой способ. Он блокирует запросы ещё до загрузки WordPress, что полезно для производительности и уменьшения лишнего трафика.

Добавьте правило выше стандартного блока WordPress, чтобы оно сработало раньше:

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

Если сервер старый и использует Apache 2.2, иногда встречается вариант с Deny from all, но на современных конфигурациях лучше использовать Require all denied. После сохранения файла запросы к /xmlrpc.php должны получать 403 Forbidden.

Когда этот способ удобнее всего

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

Способ 2: отключить XML-RPC через PHP

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

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

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

Почему mu-plugin часто лучше, чем functions.php

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

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

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

Сравнение подходов: .htaccess, PHP и плагин

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

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

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

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

Если вы блокировали через .htaccess, ожидайте 403 Forbidden. Если использовали фильтр WordPress, поведение может отличаться в зависимости от сервера и кэша, но XML-RPC-запросы должны перестать работать.

Дополнительно проверьте:

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

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

Правило добавили не туда

Если вы вставили блок в конец .htaccess после правил WordPress, он может сработать не так, как ожидается. Перенесите его выше стандартного блока # BEGIN WordPress.

Сайт на Nginx, а инструкция про .htaccess

На Nginx файл .htaccess не используется. В этом случае блокировку нужно делать в конфигурации сервера, например через location = /xmlrpc.php с возвратом 403. Если доступа к конфигу нет, используйте PHP-фильтр.

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

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

Кэш мешает увидеть результат

Иногда CDN или серверный кэш продолжает отдавать старый ответ. Очистите кэш на уровне хостинга, CDN и плагина кэширования, затем повторите проверку curl.

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

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

Если вы ведёте несколько сайтов и регулярно чистите технический мусор, имеет смысл держать такие ограничения в виде небольших mu-plugin-ов. Это проще сопровождать, чем разбрасывать код по темам. Для сайтов с активной SEO- и технической поддержкой полезно также проверять дубли, индексацию и лишние системные endpoints — именно такие мелочи часто дают непропорционально много шума в логах и в отчётах безопасности.

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