XML-RPC в WordPress часто отключают «на всякий случай», а потом внезапно перестают работать внешние публикации, мобильные клиенты или старые интеграции. Проблема в том, что это не один переключатель, а точка входа для нескольких сценариев сразу. Поэтому правильный подход — сначала понять, нужен ли вам XML-RPC вообще, а уже потом отключать его на уровне сервера или PHP.
Когда XML-RPC действительно стоит отключать
Если сайт не использует удалённую публикацию, старые мобильные приложения WordPress и сторонние сервисы, которые ходят в /xmlrpc.php, то этот endpoint чаще всего только расширяет поверхность атаки. На практике его отключают ради снижения шума от брутфорса и лишних запросов в логах. Но если у вас подключён Jetpack, внешняя публикация из редактора, синхронизация с приложением или интеграция через старый API, сначала проверьте зависимость.
Быстрая диагностика перед изменениями
Начните с простых проверок. Они занимают пару минут и помогают не сломать то, что уже работает:
- откройте
/xmlrpc.phpв браузере — если endpoint доступен, вы увидите ответ WordPress, а не 404; - посмотрите логи веб-сервера на обращения к
xmlrpc.php; - проверьте, используется ли Jetpack или внешняя публикация;
- если есть мобильное приложение WordPress, убедитесь, что оно не используется для редактирования сайта;
- посмотрите, не завязаны ли на XML-RPC сторонние сервисы резервного копирования или автоматизации.
Если сомневаетесь, временно ограничьте доступ только для теста, а не удаляйте функциональность сразу. Это проще откатить.
Как отключить XML-RPC: сравнение подходов
Есть три рабочих варианта: через плагин, через PHP-фильтр и через веб-сервер. Для большинства сайтов достаточно PHP-решения. .htaccess подходит, если нужен быстрый запрет на уровне Apache. Плагин удобен, когда вы не хотите править код, но он добавляет ещё один слой логики.
| Способ | Когда использовать | Плюсы | Минусы |
|---|---|---|---|
| PHP-фильтр | Если есть доступ к теме или mu-plugin | Гибко, легко откатить, работает в WordPress-логике | Не блокирует запрос до загрузки WordPress |
| .htaccess | Если сайт на Apache/Nginx с аналогичной логикой на уровне сервера | Режет запрос раньше, меньше лишней нагрузки | Нужно аккуратно редактировать конфиг |
| Плагин | Если нужен быстрый вариант без кода | Просто включить/выключить | Лишняя зависимость, не всегда прозрачно работает |
Пошаговое решение через PHP
Если вам нужно именно отключить XML-RPC в WordPress, самый предсказуемый способ — добавить фильтр в functions.php дочерней темы или в небольшой mu-plugin. Так вы не потеряете настройку при обновлении темы.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Этот вариант отключает XML-RPC на уровне WordPress. После этого обращения к /xmlrpc.php обычно перестают проходить через стандартную логику.
Если вам нужно не просто выключить XML-RPC, а оставить его доступным только для части сценариев, лучше не использовать глобальное отключение. Тогда уже нужна более точная логика — например, проверка по IP на уровне сервера или отдельный промежуточный слой авторизации. Но для большинства сайтов это избыточно.
Вариант для mu-plugin
Если не хотите привязываться к теме, создайте файл wp-content/mu-plugins/disable-xmlrpc.php. Такой код загружается автоматически и не зависит от активной темы:
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Это удобно для клиентских проектов: настройка остаётся на месте даже после смены темы.
Отключение через .htaccess для Apache
Если сайт работает на Apache, можно заблокировать доступ к xmlrpc.php на уровне сервера. Это полезно, когда вы хотите отсечь запросы ещё до загрузки WordPress. Добавляйте правило аккуратно и только после резервной копии файла.
<Files xmlrpc.php>
Require all denied
</Files>Для старых конфигураций Apache 2.2 встречается другой синтаксис, но на современных серверах чаще используется именно Require all denied. Если у вас Nginx, аналогичное ограничение настраивается в конфиге сервера, а не в .htaccess.
Как проверить, что решение сработало
После изменения не ограничивайтесь «сайт открывается — значит всё нормально». Проверьте именно тот endpoint, который вы отключали.
- Откройте
/xmlrpc.phpв браузере: при серверной блокировке должен быть отказ в доступе, при фильтре WordPress — endpoint не должен вести себя как рабочий API. - Проверьте логи: новые обращения к
xmlrpc.phpдолжны либо исчезнуть, либо получать отказ. - Если у вас есть Jetpack или внешняя интеграция, протестируйте её отдельно.
- Проверьте мобильное приложение WordPress, если оно использовалось для публикации или редактирования.
Если после отключения что-то сломалось, не ищите проблему в кэше первым делом. Сначала проверьте, не был ли сервис завязан именно на XML-RPC.
Частые ошибки и как их исправить
Отключили XML-RPC и потеряли интеграцию
Самая частая причина — не было инвентаризации зависимостей. Исправление простое: временно верните доступ, проверьте, какой сервис обращается к endpoint, и решите, можно ли заменить его на REST API или другой способ авторизации.
Правило в .htaccess сломало сайт
Обычно это происходит из-за неверного синтаксиса или вставки правила не в тот блок. Если сайт начал отдавать 500, первым делом откатите последний фрагмент и проверьте файл на лишние символы. Для Apache важно не смешивать правила разных версий без понимания контекста.
Плагин отключает XML-RPC, но endpoint всё ещё отвечает
Такое бывает, если плагин только ограничивает отдельные методы, а не отключает весь механизм. В этом случае лучше перейти на фильтр xmlrpc_enabled или серверную блокировку.
Что делать, если XML-RPC нужен частично
Иногда полностью отключать XML-RPC нельзя: например, сайт использует старую интеграцию или Jetpack. Тогда задача меняется — нужно не выключить всё, а сократить риск. В таком случае полезнее:
- ограничить доступ на уровне IP, если интеграция работает с фиксированного адреса;
- оставить XML-RPC только на время миграции;
- перевести интеграцию на REST API, если сервис это поддерживает;
- проверить, не дублируется ли функциональность через другие каналы.
Если вы чистите сайт комплексно, иногда удобнее делать это вместе с другими техническими правками. Например, в Clearfy Pro есть набор инструментов для отключения лишнего и удаления технического мусора, но даже в таком случае важно понимать, что именно вы выключаете и зачем: автоматическая галочка не заменяет проверку зависимостей.
Практические советы по безопасности и производительности
Отключение XML-RPC само по себе не делает сайт «защищённым полностью», но убирает один из часто атакуемых входов. Чтобы эффект был заметнее, держите в порядке и другие точки входа:
- обновляйте WordPress, тему и плагины;
- используйте ограничение попыток входа только там, где это действительно нужно;
- не оставляйте неиспользуемые интеграции включёнными;
- проверяйте логи на повторяющиеся обращения к
xmlrpc.phpи другим служебным URL; - не смешивайте серверные блокировки и плагины без понимания приоритета правил.
Если сайт небольшой и интеграций мало, серверная блокировка обычно даёт более чистый результат. Если проект часто меняется и вы хотите управлять поведением из WordPress, удобнее PHP-фильтр в mu-plugin.
Главное здесь не сам способ, а контроль над последствиями. XML-RPC отключают не ради галочки, а чтобы убрать лишнюю поверхность атаки и не сломать рабочие сценарии. Если вы сначала проверили зависимости, а потом выбрали способ блокировки, откат почти никогда не нужен.