XML-RPC в WordPress часто отключают по одной причине: на сайт идет лишний шум, а в логах появляются запросы к /xmlrpc.php. Но на практике этот файл может быть нужен не только для старых клиентов, а и для конкретных интеграций. Поэтому правильный подход здесь не «рубить всё подряд», а сначала понять, кто именно его использует, и только потом отключать точечно.
Когда отключение XML-RPC действительно уместно
Если сайт не использует удаленную публикацию, старые мобильные клиенты и сторонние сервисы, XML-RPC можно отключить без заметных последствий. Чаще всего это оправдано на обычных корпоративных сайтах, блогах и лендингах, где публикация идет только из админки WordPress.
Но если у вас подключены Jetpack, внешние редакторы, сервисы автопостинга или мобильное приложение WordPress, отключение может сломать часть сценариев. Именно поэтому сначала нужна диагностика.
Диагностика: кто обращается к xmlrpc.php
Начните с логов веб-сервера. На уровне Nginx или Apache видно, есть ли регулярные обращения к /xmlrpc.php и с каких IP они приходят. Если запросы идут только от ботов, это один сценарий. Если в логах видны обращения от ваших сервисов или пользователей, отключать файл без проверки нельзя.
Что проверить перед изменением
- используется ли Jetpack и какие его модули активны;
- есть ли мобильное приложение WordPress у редакторов;
- подключены ли внешние интеграции для публикации или синхронизации;
- есть ли в логах частые POST-запросы к
/xmlrpc.php; - не завязан ли на XML-RPC какой-то старый плагин.
Если доступа к логам нет, можно временно посмотреть запросы через серверный мониторинг или включить логирование на короткий период. Важно не гадать, а проверить фактическое использование.
Пошаговое решение: как отключить XML-RPC безопасно
Есть два рабочих подхода: отключить обработку на уровне WordPress или заблокировать сам файл на уровне веб-сервера. Для большинства сайтов достаточно первого варианта. Второй полезен, если нужно отрезать доступ еще до загрузки WordPress.
| Способ | Плюсы | Минусы | Когда использовать |
|---|---|---|---|
Код в functions.php или плагине | Легко откатить, не трогает серверную конфигурацию | WordPress все равно загружается | Если нужен быстрый и обратимый вариант |
| Блокировка в Nginx/Apache | Отсекает запросы раньше, снижает шум | Нужно править конфиг сервера | Если XML-RPC точно не нужен |
Вариант 1: отключить XML-RPC через код
Добавьте фильтр в functions.php дочерней темы или, что лучше, в небольшой mu-plugin. Так вы не потеряете настройку при обновлении темы.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Это простой и прозрачный способ. WordPress перестанет отвечать на XML-RPC-запросы, но сам сайт продолжит работать как обычно.
Вариант 2: заблокировать xmlrpc.php на уровне Nginx
Если у вас Nginx, можно вернуть 403 еще до запуска WordPress:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Для Apache аналогичный эффект обычно делают через .htaccess:
<Files xmlrpc.php>
Require all denied
</Files>Этот вариант жестче. Он хорош, когда вы уверены, что XML-RPC не нужен вообще. Если есть сомнения, начните с фильтра в WordPress и проверьте интеграции.
Как проверить, что решение сработало
Проверка должна быть не только визуальной. Откройте https://ваш-домен/xmlrpc.php в браузере: при отключении через код вы обычно увидите сообщение о недоступности метода или 403 в зависимости от способа блокировки. Но этого мало.
Сделайте еще три проверки:
- посмотрите логи сервера и убедитесь, что запросы к
/xmlrpc.phpбольше не проходят успешно; - проверьте Jetpack и другие подключенные сервисы, если они есть;
- попробуйте опубликовать запись из того инструмента, который раньше использовал XML-RPC.
Если после отключения перестала работать синхронизация, значит, зависимость была реальной. В таком случае возвращайте XML-RPC и ищите альтернативный способ защиты, а не ломайте рабочий сценарий.
Частые ошибки и как их исправить
Отключили XML-RPC в коде, но забыли про интеграции
Самая частая ошибка — выключить файл «на всякий случай», а потом обнаружить, что мобильное приложение больше не публикует записи. Решение простое: сначала инвентаризация зависимостей, потом блокировка.
Правят functions.php родительской темы
После обновления темы изменение исчезает. Для таких правок используйте дочернюю тему или mu-plugin. Это не вопрос удобства, а вопрос сохранности настройки.
Блокируют файл, но не смотрят на логи
Если на сайт идет много запросов к XML-RPC, полезно понять источник. Иногда это просто боты, иногда — легитимный сервис. Без логов вы не отличите одно от другого.
Путают отключение XML-RPC с защитой от всех атак
Отключение этого интерфейса уменьшает поверхность атаки, но не заменяет базовую защиту: обновления, сильные пароли, ограничение попыток входа, нормальный хостинг и контроль плагинов.
Практические советы по безопасности и производительности
Если XML-RPC вам не нужен, блокировка на уровне сервера действительно снижает лишний трафик. Но не стоит ожидать от этого магического ускорения. Основной выигрыш здесь — в сокращении бесполезных запросов и уменьшении площади атаки.
- проверьте, нет ли в логах постоянного перебора
xmlrpc.php; - обновите WordPress, тему и плагины до актуальных версий;
- не храните правки только в теме, если они должны переживать обновления;
- если нужен быстрый аудит дублей и технических настроек, посмотрите на инструменты вроде Clearfy Pro, но внедряйте только то, что понимаете и можете проверить.
Для небольших сайтов обычно достаточно кода и проверки логов. Для более строгих конфигураций лучше перенести блокировку на веб-сервер и зафиксировать это в документации проекта, чтобы через полгода не искать, почему интеграция перестала отвечать.
Что делать, если XML-RPC нужен только частично
Иногда отключать его полностью не стоит. Например, Jetpack может использовать отдельные функции, а остальной XML-RPC вам не нужен. В таких случаях лучше сначала понять, можно ли заменить конкретную интеграцию REST API или другим способом подключения. Если замены нет, оставляйте рабочий сценарий и усиливайте защиту другими методами.
Практика здесь простая: не отключайте то, что не успели проверить. Для WordPress это особенно важно, потому что один и тот же файл может быть одновременно и лишним, и критичным — в зависимости от того, как именно собран сайт.