XML-RPC в WordPress до сих пор встречается на живых сайтах, хотя большинству проектов он уже не нужен. Проблема в том, что его часто отключают «на всякий случай» и потом удивляются: перестала работать публикация из мобильного приложения, сломалась синхронизация с внешним сервисом или появились странные 403/405 в логах. Поэтому здесь важен не сам факт отключения, а проверка, нужен ли вам этот интерфейс вообще.
Если коротко: XML-RPC стоит отключать только после диагностики. На типичном сайте без Jetpack, старых мобильных клиентов и сторонних интеграций это обычно безопасно. Но если у вас есть внешняя публикация, автопостинг или сервисы, которые ходят в /xmlrpc.php, сначала надо понять, чем их заменить.
Когда XML-RPC действительно можно отключить
XML-RPC — это старый удалённый интерфейс WordPress. Его используют не все, но он может быть нужен для конкретных сценариев. Если вы не уверены, проверьте, есть ли у вас хотя бы один из этих признаков:
- подключён Jetpack и используются функции, завязанные на удалённый доступ;
- публикация идёт из стороннего клиента, а не из админки WordPress;
- есть интеграция с внешним сервисом, который отправляет записи через XML-RPC;
- в логах регулярно появляются запросы к
xmlrpc.phpот неизвестных IP; - сайт часто получает брутфорс по XML-RPC, а не только по
wp-login.php.
Если ничего из этого нет, отключение обычно оправдано. Но если у вас есть хотя бы одна интеграция, сначала проверьте её в тестовой среде или на staging-копии.
Диагностика: как понять, используется ли xmlrpc.php
Самый практичный способ — посмотреть логи веб-сервера. Ищите обращения к /xmlrpc.php. Если логов нет под рукой, можно временно добавить простой мониторинг через error_log() и посмотреть, кто и когда обращается к файлу. Для продакшена это не постоянное решение, а именно короткая проверка.
Проверка по логам сервера
grep "xmlrpc.php" /var/log/nginx/access.log | tail -n 50Если у вас Apache, путь к логам будет другим, но логика та же: ищите частые POST-запросы к xmlrpc.php, особенно с повторяющимися IP и одинаковыми user-agent.
Быстрая проверка из браузера и через curl
Откройте https://ваш-домен.ru/xmlrpc.php. Если файл доступен, WordPress обычно отвечает сообщением о том, что XML-RPC сервер принимает только POST-запросы. Это не значит, что интерфейс нужен, но подтверждает, что он активен.
curl -I https://example.com/xmlrpc.phpЕсли после отключения вы видите 403 или 404, это ожидаемо. Если же ваш внешний сервис перестал публиковать записи, значит, XML-RPC ему был нужен.
Как отключить XML-RPC: кодом или плагином
Есть два нормальных пути: отключить через код или через плагин безопасности/оптимизации. Код надёжнее и прозрачнее, плагин удобнее, если вы не хотите лезть в тему или mu-plugins.
| Способ | Плюсы | Минусы |
|---|---|---|
| Код в mu-plugin | Не зависит от темы, легко контролировать в Git | Нужен доступ к файлам |
| Плагин безопасности | Быстро включить без разработки | Лишняя зависимость, иногда дублирует функции |
| .htaccess / nginx | Блокирует запросы на уровне сервера | Надо аккуратно править конфиг, легко ошибиться |
Вариант 1: отключение через код
Самый безопасный вариант — положить небольшой файл в wp-content/mu-plugins/. Тогда отключение не потеряется после смены темы и не зависит от активного шаблона.
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Если хотите не просто отключить функциональность, а ещё и убрать сам доступ к файлу, можно дополнительно вернуть 403 для прямых запросов. Но делайте это только если уверены, что XML-RPC нигде не используется.
<?php
add_action( 'init', function () {
if ( defined( 'XMLRPC_REQUEST' ) && XMLRPC_REQUEST ) {
status_header( 403 );
exit;
}
} );На практике первого варианта часто достаточно: WordPress перестаёт обрабатывать XML-RPC как рабочий интерфейс, а внешние запросы получают отказ.
Вариант 2: через плагин
Если у вас уже стоит плагин безопасности, проверьте, есть ли в нём настройка отключения XML-RPC. У некоторых решений она спрятана в разделе hardening или защите от брутфорса. Не ставьте отдельный плагин только ради одной галочки, если ту же задачу можно решить кодом.
Если вы используете комплексный набор для чистки и технической оптимизации сайта, например Clearfy Pro, проверьте, нет ли там уже функции отключения XML-RPC и других технических эндпоинтов. В таком случае лучше не дублировать логику в нескольких местах.
Пошаговое решение без лишнего риска
- Проверьте логи и убедитесь, что
xmlrpc.phpне нужен интеграциям. - Сделайте бэкап файлов и базы, даже если меняете только один фильтр.
- Добавьте код в
mu-pluginsили включите настройку в существующем плагине. - Очистите кеш страницы и серверный кеш, если он есть.
- Проверьте ответ
/xmlrpc.phpчерез браузер иcurl. - Посмотрите логи 24–48 часов после изменения, чтобы убедиться, что ничего не сломалось.
Как проверить результат после внедрения
Проверка должна быть не только визуальной. Нужны минимум три теста: ответ сервера, отсутствие ошибок в логах и работоспособность тех функций, которые вы считали не зависящими от XML-RPC.
Что именно проверять
curl -I https://example.com/xmlrpc.php— ожидаемый код ответа после отключения;- журнал ошибок веб-сервера — нет ли новых 500/403 по связанным запросам;
- публикацию из админки WordPress — обычный редактор должен работать как раньше;
- Jetpack или внешние сервисы — если они были, убедитесь, что не потеряли связь;
- кеширование — очистите кеш, чтобы не смотреть на старую версию страницы.
Если вы отключали XML-RPC ради безопасности, полезно ещё раз посмотреть access log через несколько дней. Боты обычно продолжают стучаться в этот файл, и это нормально: важно, чтобы сервер отвечал быстро и предсказуемо.
Частые ошибки и как их исправить
Отключили XML-RPC, а перестал работать Jetpack
Это самый частый сценарий. Решение простое: либо возвращаете XML-RPC, либо переводите нужные функции Jetpack на другой способ связи, если он доступен в вашей конфигурации. Не отключайте интерфейс вслепую на боевом сайте с подключёнными внешними сервисами.
Поставили два разных способа отключения сразу
Например, фильтр в коде плюс правило в nginx плюс настройка в плагине. В результате потом сложно понять, что именно дало 403. Оставьте один источник истины: либо код, либо серверный уровень, либо плагин.
Сломали доступ к xmlrpc.php, но не очистили кеш
Если у вас есть CDN или серверный кеш, старый ответ может ещё какое-то время отдаваться как будто ничего не изменилось. После правки обязательно очищайте кеш на всех уровнях.
Отключили через .htaccess без проверки конфигурации сервера
На nginx файл .htaccess не поможет. Если сайт работает на nginx, правило нужно писать в конфиге сервера. Иначе вы будете думать, что защита включена, хотя на деле файл по-прежнему доступен.
Практические советы по безопасности и производительности
Отключение XML-RPC — не универсальная защита, а один из слоёв. Если цель — снизить поверхность атаки, проверьте ещё и другие технические точки входа: wp-login.php, REST API, слабые пароли, устаревшие плагины. Не стоит рассчитывать, что один фильтр решит все проблемы безопасности.
Если вам нужно регулярно чистить сайт от технического мусора, дубликатов и лишних эндпоинтов, удобнее держать такие настройки в одном месте, а не размазывать по теме и нескольким плагинам. Для этого часто используют наборы оптимизации вроде Clearfy Pro — но только если вам действительно нужен такой комбайн, а не одна отдельная функция.
И ещё момент по производительности: сам по себе XML-RPC обычно не является главным тормозом сайта. Но если по нему идёт постоянный поток ботов, он создаёт лишнюю нагрузку на PHP и логи. В этом случае отключение или жёсткое ограничение доступа имеет смысл.
После внедрения не ограничивайтесь одной проверкой в браузере. Посмотрите логи, протестируйте интеграции и убедитесь, что сайт отвечает так, как вы ожидаете. Тогда отключение XML-RPC будет не «магической настройкой», а контролируемым изменением.