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