XML-RPC в WordPress нужен не всем, но на живых сайтах он часто остаётся включённым по умолчанию. Если вы не используете мобильное приложение WordPress, внешние публикации или старые интеграции, этот интерфейс только расширяет поверхность атаки и создаёт лишний шум в логах. Ниже — рабочие способы отключения, проверка результата и разбор того, что ломается чаще всего.
Когда XML-RPC действительно стоит отключить
Сначала полезно понять, есть ли у сайта реальная зависимость от xmlrpc.php. Если вы не уверены, проверьте сценарии, которые обычно завязаны на XML-RPC:
- публикация через старые десктопные клиенты и мобильные приложения WordPress;
- удалённые вызовы для некоторых внешних сервисов и интеграций;
- плагины, которые до сих пор используют XML-RPC вместо REST API;
- пингбэки и трекбэки, если они вам вообще нужны.
Если ничего из этого не используется, отключение обычно безопасно. На практике это полезно ещё и для снижения количества попыток брутфорса, потому что xmlrpc.php часто атакуют отдельно от обычной формы входа.
Диагностика: как понять, что XML-RPC открыт
Самый простой тест — обратиться к /xmlrpc.php напрямую. Если файл доступен, WordPress обычно отвечает сообщением о том, что XML-RPC сервер принимает только POST-запросы. Это ещё не означает, что он нужен, но означает, что точка входа жива.
Проверить можно и из консоли:
curl -I https://example.com/xmlrpc.phpЕсли сервер отдаёт 200, 405 или похожий ответ, файл доступен. После блокировки вы можете увидеть 403, 404 или ответ веб-сервера с запретом доступа — это зависит от способа отключения.
Ещё один практический признак — записи в логах безопасности или в access.log с частыми запросами к xmlrpc.php. Если такие обращения есть, а интеграций нет, отключение имеет смысл.
Способы отключения: что выбрать на практике
| Способ | Когда подходит | Плюсы | Минусы |
|---|---|---|---|
| Код в теме или mu-plugin | Нужен контроль на уровне WordPress | Прозрачно, можно быстро откатить | Не защищает до загрузки WordPress |
| Правило в веб-сервере | Нужна жёсткая блокировка | Режет запрос раньше PHP | Нужно править конфиг сервера |
| Плагин безопасности | Нужна настройка без кода | Удобно для админов | Лишняя зависимость от плагина |
Вариант 1: отключить XML-RPC через код
Если вам достаточно блокировки на уровне WordPress, добавьте фильтр в functions.php дочерней темы или, лучше, в небольшой mu-plugin. Так решение не потеряется после обновления темы.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Это самый короткий и понятный вариант. WordPress перестанет обслуживать XML-RPC-запросы, но сам файл xmlrpc.php может по-прежнему отвечать на уровне веб-сервера.
Вариант 2: заблокировать доступ на уровне веб-сервера
Если нужен более жёсткий запрет, блокируйте файл в конфигурации сервера. Для Apache это обычно делается через .htaccess:
<Files xmlrpc.php>
Require all denied
</Files>Для Nginx правило обычно добавляют в конфиг сайта:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Такой подход полезен, если вы хотите отсечь запросы до запуска PHP. Это снижает нагрузку и делает блокировку более предсказуемой.
Вариант 3: использовать плагин безопасности
Если на проекте уже стоит плагин безопасности, проверьте, умеет ли он отключать XML-RPC без дополнительных костылей. Это удобно, когда доступ к серверной конфигурации ограничен. Но если плагин нужен только ради одной галочки, код или серверное правило обычно проще сопровождать.
Пошаговое решение без лишних рисков
- Проверьте, не используют ли сайт и интеграции XML-RPC.
- Сделайте резервную копию конфигурации и файлов, если правите сервер.
- Выберите способ блокировки: код, веб-сервер или плагин.
- Внедрите правило на тестовом стенде или в окне низкой нагрузки.
- Проверьте ответ
/xmlrpc.phpи логи сервера. - Убедитесь, что вход в админку, REST API и публикация записей не пострадали.
Если у вас есть staging-копия, сначала проверьте блокировку там. Это особенно важно, когда сайт использует сторонние сервисы публикации или старый мобильный клиент.
Как проверить, что блокировка сработала
После внедрения не ограничивайтесь визуальной проверкой. Нужна именно техническая валидация:
- откройте
https://ваш-домен/xmlrpc.phpв браузере; - выполните
curl -I https://ваш-домен/xmlrpc.php; - проверьте access.log и error.log на отсутствие успешных ответов по этому пути;
- если стоит плагин безопасности, убедитесь, что он не только скрывает файл, но и реально блокирует запросы.
Хороший признак — сервер отвечает отказом до выполнения WordPress. Если вы видите обычный ответ WordPress, значит блокировка на уровне PHP не сработала или правило подключено не там, где нужно.
Частые ошибки и как их исправить
Отключили XML-RPC, но забыли про старые интеграции
Иногда после блокировки перестаёт работать публикация через внешний клиент или синхронизация с сервисом, который до сих пор использует XML-RPC. Решение простое: либо вернуть доступ, либо перевести интеграцию на REST API, если она это поддерживает.
Правило добавили не в тот уровень конфигурации
Для Nginx правило в .htaccess не сработает, потому что Nginx его не читает. Для Apache, наоборот, правка nginx.conf ничего не изменит. Если после правки ответ не поменялся, проверьте, какой веб-сервер реально обслуживает сайт.
Сделали блокировку только в WordPress, но запросы всё равно грузят сервер
Фильтр xmlrpc_enabled отключает функциональность внутри WordPress, но не всегда отсекает сам HTTP-запрос на раннем этапе. Если сайт под атакой или есть заметная нагрузка, лучше блокировать на уровне веб-сервера.
Сломали доступ к админке из-за слишком широкого правила
Редко, но бывает, когда в конфиге сервера случайно блокируют не только xmlrpc.php, а целый каталог или соседние правила. Если после правки начались странные 403 на других URL, откатите изменение и проверьте область действия директивы.
Безопасность и производительность: что ещё имеет смысл сделать
Отключение XML-RPC — не замена нормальной защите входа. Если цель — снизить риск перебора паролей, дополнительно проверьте:
- ограничение попыток входа;
- двухфакторную аутентификацию для админов;
- актуальность ядра, темы и плагинов;
- отсутствие лишних публичных endpoint'ов;
- логи на предмет повторяющихся запросов к
xmlrpc.phpи/wp-login.php.
Если на сайте уже используется плагин для чистки дублей, SEO-правил и технической оптимизации, например Clearfy Pro, проверьте, не дублируете ли вы его функции ручными правилами. Лишние пересечения в безопасности и SEO обычно только усложняют поддержку.
На проектах с высокой посещаемостью полезно переносить такие блокировки на уровень веб-сервера или CDN, чтобы не тратить ресурсы PHP на заведомо нежелательные запросы.