XML-RPC в WordPress часто отключают «на всякий случай», а потом внезапно перестают работать мобильное приложение, внешняя публикация через сервисы автопостинга или интеграция со старым клиентом. Проблема не в самом XML-RPC, а в том, что его режут без проверки зависимостей. Если у сайта нет внешних интеграций, отключение действительно имеет смысл: меньше лишних точек входа и меньше шума в логах. Если интеграции есть, нужен аккуратный сценарий, а не грубый запрет.
Ниже — практический разбор: как понять, нужен ли XML-RPC именно вашему сайту, как отключить его безопасно, чем отличается код от плагина и как проверить результат после внедрения.
Когда XML-RPC можно отключать, а когда нельзя
XML-RPC нужен не всем. На современных сайтах его часто заменяют REST API, прямой вход в админку или интеграции через отдельные плагины. Но есть сценарии, где он всё ещё используется:
- старые мобильные приложения WordPress;
- внешние сервисы автопубликации и планирования постов;
- клиенты для удалённой публикации, которые работают именно через XML-RPC;
- некоторые интеграции с Jetpack и похожими сервисами, если они настроены на XML-RPC-канал.
Если у вас обычный сайт без внешней публикации и без старых клиентов, отключение обычно безопасно. Но сначала лучше проверить, кто обращается к /xmlrpc.php.
Диагностика проблемы: есть ли реальные запросы к xmlrpc.php
Самый простой способ — посмотреть логи веб-сервера или счётчики в WAF/защите. Если в логах регулярно встречаются запросы к /xmlrpc.php, это не всегда атака, но повод разобраться. На многих сайтах этот файл сканируют боты, и из-за этого он создаёт лишний шум.
Если доступа к логам нет, проверьте хотя бы логи безопасности в плагине или в панели хостинга. Важный момент: не путайте единичные сканирования с рабочей интеграцией. Рабочая интеграция обычно даёт повторяющиеся запросы с понятным источником.
Как отключить XML-RPC в WordPress: три рабочих варианта
Есть три нормальных подхода: через код, через плагин безопасности и через веб-сервер. Для большинства сайтов лучше начинать с кода или плагина, потому что это проще откатить.
| Способ | Плюсы | Минусы | Когда выбирать |
|---|---|---|---|
| Код в теме или mu-plugin | Прозрачно, без лишних зависимостей | Нужно аккуратно обновлять | Если есть доступ к коду и нужен контроль |
| Плагин безопасности | Быстро включить и отключить | Ещё один плагин в стеке | Если код не хотите трогать |
| Правило на сервере | Отсекает запросы раньше WordPress | Зависит от конфигурации хостинга | Если умеете править nginx/apache |
Вариант 1: отключить XML-RPC через код
Самый предсказуемый способ — добавить фильтр xmlrpc_enabled. Его можно положить в functions.php дочерней темы, но для постоянной защиты лучше использовать mu-plugin, чтобы решение не зависело от темы.
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter('xmlrpc_enabled', '__return_false');
Если нужен именно запрет на сам файл, можно дополнительно убрать доступ на уровне шаблона запроса:
<?php
add_action('init', function () {
if (defined('XMLRPC_REQUEST') && XMLRPC_REQUEST) {
status_header(403);
exit;
}
});
Первый вариант предпочтительнее: он использует штатный фильтр WordPress. Второй жёстче, но его стоит применять только если вы понимаете, что делаете, и не хотите оставлять даже частично доступный endpoint.
Вариант 2: отключить через плагин
Если код трогать неудобно, используйте плагин, который умеет выключать XML-RPC и не навязывает лишние изменения. Важно не ставить случайный «security suite» только ради одной галочки: потом трудно понять, что именно сломало интеграцию.
Если у вас уже стоит плагин для технической чистки и SEO-оптимизации, проверьте, нет ли там отдельной опции для XML-RPC. Например, в Clearfy Pro есть набор настроек для технической оптимизации и отключения лишних возможностей WordPress, что удобно, когда нужно собрать такие правки в одном месте.
Вариант 3: закрыть xmlrpc.php на уровне сервера
Если у вас nginx или Apache и вы хотите отсечь запросы до загрузки WordPress, можно закрыть доступ к xmlrpc.php на уровне веб-сервера. Это полезно на высоконагруженных сайтах, где даже лишние запросы к PHP нежелательны.
Для nginx это обычно делается отдельным location-блоком. Пример зависит от общей конфигурации, поэтому вставлять его нужно аккуратно, не ломая существующие правила:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}
На Apache аналогичный запрет можно реализовать через правила в .htaccess, если хостинг это позволяет. Но если вы не уверены в конфигурации, безопаснее ограничиться фильтром WordPress.
Пошаговое решение без поломки интеграций
- Проверьте, используется ли XML-RPC внешними сервисами, старым приложением или клиентом публикации.
- Сделайте бэкап файла конфигурации или подготовьте быстрый способ отката.
- Выберите один способ отключения: код, плагин или серверное правило.
- Внесите изменение сначала на staging, если он есть.
- Проверьте доступ к сайту, вход в админку и работу публикаций.
- Только после этого переносите правку на боевой сайт.
Если у вас есть сомнения, начните с фильтра xmlrpc_enabled. Его проще всего убрать, если вдруг обнаружится зависимость.
Как проверить, что XML-RPC действительно отключён
Проверка нужна не формальная, а практическая. Откройте в браузере или через curl адрес /xmlrpc.php. Если всё отключено корректно, вы не должны получать рабочий ответ метода XML-RPC.
curl -i https://example.com/xmlrpc.phpОжидаемое поведение зависит от способа отключения: это может быть 403 Forbidden, 405 Method Not Allowed или другой отказ в доступе. Главное — не должен открываться рабочий XML-RPC-ответ.
Дополнительно проверьте:
- вход в админку WordPress;
- публикацию и обновление записей;
- работу мобильного приложения, если вы им пользуетесь;
- интеграции с внешними сервисами, которые могли работать через XML-RPC.
Если после отключения перестала работать публикация из стороннего сервиса, значит, вы нашли реальную зависимость. В этом случае либо возвращайте XML-RPC, либо переводите интеграцию на другой способ подключения.
Частые ошибки и как их исправить
Отключили XML-RPC и потеряли автопостинг
Это самая частая история. Причина простая: сервис был завязан именно на XML-RPC, а не на REST API. Решение — либо вернуть доступ, либо перенастроить интеграцию на другой механизм, если сервис его поддерживает.
Сломали сайт правилом в .htaccess или nginx
Ошибка обычно в том, что правило вставили не в тот блок или нарушили порядок директив. Если после правки сайт начал отдавать 500 ошибку, сразу откатывайте конфиг и проверяйте синтаксис перед повторным применением.
Использовали несколько способов одновременно
Когда XML-RPC отключают и плагином, и кодом, и серверным правилом сразу, потом трудно понять, что именно сработало и где искать проблему. Для диагностики лучше оставить один способ. Если нужен жёсткий запрет на уровне сервера, код в WordPress уже не обязателен.
Проверили только в браузере
Браузерный переход на /xmlrpc.php не всегда показывает реальную картину. Для точной проверки используйте curl или смотрите логи. Иначе можно пропустить ситуацию, когда файл доступен, но просто не отображает полезный ответ в браузере.
Что делать, если XML-RPC нужен частично
Иногда отключать его полностью не стоит. Например, если один старый сервис ещё не переведён на другой способ авторизации. В таком случае лучше не рубить доступ целиком, а сначала зафиксировать, кто и как использует endpoint. Дальше уже решать: оставить XML-RPC включённым, ограничить доступ по IP на сервере или перевести конкретную интеграцию на другой канал.
Если задача — не столько отключить XML-RPC, сколько уменьшить поверхность атаки, полезно сочетать его с другими мерами: актуальные обновления WordPress, ограничение попыток входа, нормальная политика паролей и базовая защита админки. Сам по себе XML-RPC — не корень всех проблем, а один из старых интерфейсов, который стоит держать под контролем.
Практический чек-лист перед отключением
- Проверить логи на обращения к
/xmlrpc.php. - Уточнить, есть ли мобильное приложение или внешний сервис публикации.
- Выбрать один способ отключения, а не несколько сразу.
- Сделать тест на staging или хотя бы подготовить откат.
- После правки проверить ответ
/xmlrpc.phpчерезcurl. - Убедиться, что публикация, редактирование и интеграции работают как раньше.
Если нужен аккуратный технический аудит сайта перед такими изменениями, имеет смысл сначала убрать лишние функции и дубли, а уже потом трогать доступы и endpoint'ы. В этом сценарии полезны инструменты, которые помогают держать WordPress в более чистом состоянии без ручного хаоса в коде и настройках.