XML-RPC в WordPress часто отключают не «на всякий случай», а по конкретной причине: его используют для перебора паролей, лишних запросов к серверу или старых интеграций, которые давно не нужны. Но у этого механизма есть нюанс: если просто закрыть доступ без проверки, можно сломать удалённую публикацию, мобильные клиенты или внешние сервисы, которые ещё работают через xmlrpc.php.
Ниже — рабочий сценарий: как понять, нужен ли XML-RPC именно вам, чем отличается отключение через сервер и через код, и как проверить, что после изменений сайт не потерял нужную функциональность.
Когда XML-RPC действительно стоит отключать
Не каждый сайт обязан держать XML-RPC открытым. Если вы не используете старые приложения WordPress для публикации, внешние сервисы синхронизации и удалённое управление через XML-RPC, этот интерфейс чаще создаёт лишнюю поверхность атаки, чем пользу.
Типичные признаки, что XML-RPC не нужен
- в админке никто не публикует записи из внешнего клиента;
- нет интеграций с сервисами, которые явно требуют
xmlrpc.php; - в логах видно много запросов к
/xmlrpc.phpс ошибками авторизации; - хостинг или WAF уже отмечает попытки перебора через XML-RPC;
- сайт работает только через браузер и REST API.
Если хотя бы один из пунктов про интеграции под вопросом, сначала проверьте, кто именно обращается к XML-RPC. Иногда его используют старые мобильные клиенты, интеграции с публикацией в соцсети или сервисы резервного копирования.
Диагностика: как понять, что именно ломается
Перед отключением полезно проверить, есть ли реальные обращения к xmlrpc.php. Самый простой способ — посмотреть access log на сервере или логи в панели хостинга. Ищите запросы к файлу /xmlrpc.php и статус ответа.
Если доступа к логам нет, можно временно добавить простой логирующий фильтр и посмотреть, кто стучится в XML-RPC. Это не решение на постоянной основе, а только способ диагностики.
<?php
add_filter( 'xmlrpc_enabled', function( $enabled ) {
error_log( 'XML-RPC check: ' . ( $enabled ? 'enabled' : 'disabled' ) . ' | ' . $_SERVER['REMOTE_ADDR'] );
return $enabled;
} );Этот вариант не блокирует запросы, а только помогает понять, используется ли механизм вообще. После проверки код нужно убрать.
Как отключить XML-RPC: сравнение подходов
| Способ | Когда подходит | Плюсы | Минусы |
|---|---|---|---|
| Через плагин | Нужно быстро и без правок кода | Просто включить и выключить | Добавляет ещё один плагин, зависит от его качества |
Через .htaccess | Apache/LiteSpeed, нужен жёсткий запрет на уровне сервера | Блокирует запрос до загрузки WordPress | Не подходит для Nginx без аналогичной настройки |
| Через PHP-фильтр | Нужен управляемый вариант внутри темы или mu-plugin | Легко контролировать в коде | WordPress всё равно стартует, это не самый ранний блок |
Если задача именно в безопасности и у вас Apache, самый практичный вариант — запретить доступ к xmlrpc.php на уровне веб-сервера. Если нужен быстрый откат без правки конфигов, можно использовать код в functions.php или отдельном mu-plugin.
Пошаговое решение через .htaccess
Этот способ подходит для Apache и LiteSpeed. Он блокирует прямые запросы к файлу ещё до запуска WordPress. Перед правкой сделайте копию .htaccess, потому что ошибка в синтаксисе может сломать сайт целиком.
<Files xmlrpc.php>
Require all denied
</Files>Если сервер старый и не поддерживает синтаксис Require all denied, встречается вариант для Apache 2.2:
<Files xmlrpc.php>
Order Deny,Allow
Deny from all
</Files>После сохранения проверьте, что при открытии https://ваш-домен.ru/xmlrpc.php сервер отдаёт 403 Forbidden, а не страницу WordPress с сообщением об ошибке.
Пошаговое решение через код WordPress
Если вы не хотите трогать конфиг веб-сервера, можно отключить XML-RPC через фильтр. Это удобно, когда доступ к .htaccess ограничен или сайт работает на окружении, где править серверные правила неудобно.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Такой код можно добавить в functions.php дочерней темы, но на практике надёжнее вынести его в небольшой mu-plugin, чтобы он не зависел от темы.
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Mu-plugin удобен тем, что он не отключится случайно при смене темы и не требует активации в админке. Файл достаточно положить в wp-content/mu-plugins/.
Что проверить после отключения
Не ограничивайтесь открытием главной страницы. XML-RPC может быть отключён, а сайт при этом внешне работать нормально, поэтому нужна точечная проверка.
- откройте
/xmlrpc.phpв браузере или черезcurlи убедитесь, что доступ закрыт; - проверьте, не используются ли внешние клиенты для публикации;
- посмотрите логи сервера: запросы к
xmlrpc.phpдолжны либо исчезнуть, либо получать 403; - если у вас есть мобильное приложение WordPress, попробуйте авторизацию и публикацию тестовой записи;
- проверьте интеграции резервного копирования и автопостинга, если они были настроены давно.
Для быстрой проверки из консоли можно использовать:
curl -I https://example.com/xmlrpc.phpЕсли всё настроено корректно, вы увидите 403 или другой запрет на уровне сервера. Если приходит 200 и страница WordPress отвечает, блокировка не сработала.
Частые ошибки и как их исправить
Отключили XML-RPC, а сломалась публикация из внешнего сервиса
Значит, сервис реально использовал XML-RPC. В этом случае не стоит держать файл открытым ради одного старого сценария: лучше перевести интеграцию на REST API или заменить инструмент. Если сервис без XML-RPC не работает, это уже ограничение самого сервиса, а не WordPress.
Добавили правило в .htaccess, и сайт перестал открываться
Чаще всего причина в неверном синтаксисе или в том, что правило вставили не туда. На Apache блок для xmlrpc.php лучше добавлять отдельно и без лишних директив. Если сайт упал, сразу верните резервную копию файла.
Использовали плагин, но защита не сработала
Некоторые плагины только отключают функциональность внутри WordPress, но не блокируют сам файл на уровне веб-сервера. В результате запросы всё равно доходят до PHP. Для защиты от брутфорса это слабее, чем серверный запрет.
Безопасность и производительность: что ещё имеет смысл сделать
Отключение XML-RPC — не замена нормальной защите входа. Если у вас идут атаки на авторизацию, проверьте ещё и ограничение попыток входа, двухфакторную аутентификацию и актуальность паролей у администраторов.
Если задача шире и вы чистите сайт от лишнего технического мусора, можно посмотреть в сторону Clearfy Pro. Он помогает централизованно отключать часть ненужных функций WordPress, но всё равно стоит понимать, что именно вы выключаете и зачем.
Для серверной безопасности полезно держать под контролем не только XML-RPC, но и логи запросов, 403-ответы и подозрительные обращения к wp-login.php. Если атака идёт массово, отключение одного интерфейса не решит проблему полностью, но уменьшит шум и нагрузку.
Короткий чек-лист перед публикацией изменений
- Проверили, нужен ли XML-RPC конкретным интеграциям.
- Сделали резервную копию
.htaccessили файла с кодом. - Выбрали один способ отключения, а не несколько сразу.
- Проверили ответ
/xmlrpc.phpчерез браузер илиcurl. - Тестировали внешние клиенты и сервисы, если они были подключены.
- Посмотрели логи сервера после изменения.
Если после отключения всё работает как раньше, а запросы к xmlrpc.php больше не проходят, значит задача решена правильно: вы убрали лишнюю точку входа, не затронув остальной сайт.