XML-RPC в WordPress часто отключают «на всякий случай», а потом внезапно перестают работать мобильное приложение, Jetpack, публикация через сторонние сервисы и некоторые интеграции для автопостинга. Проблема в том, что это не просто лишний файл xmlrpc.php, а отдельный интерфейс удалённого доступа. Его можно закрыть, но только после проверки, что он реально не нужен.
Ниже — рабочая схема: как понять, используется ли XML-RPC, чем его отключить, как проверить результат и какие ошибки встречаются чаще всего.
Когда XML-RPC действительно стоит отключать
Если сайт не использует старые внешние клиенты, публикацию по API через XML-RPC и интеграции, завязанные именно на этот протокол, его лучше закрыть. На практике это полезно для сайтов, где:
- не используется Jetpack;
- не публикуют записи из старых десктопных клиентов;
- не подключены сервисы, которым нужен XML-RPC, а не REST API;
- нужно уменьшить поверхность атаки, особенно если в логах есть запросы к
/xmlrpc.php.
Но если у вас есть мобильное приложение WordPress, старые интеграции или автоматизация через внешние сервисы, сначала проверьте, что именно они используют. Удалять доступ без диагностики — частая причина «сломалось после усиления безопасности».
Диагностика: используется ли XML-RPC на сайте
Самый простой способ — проверить логи веб-сервера и попытки обращения к xmlrpc.php. Если запросы идут регулярно, это не всегда атака: иногда так стучатся легитимные сервисы. Сначала нужно понять источник.
Что смотреть в логах
Ищите запросы вида POST /xmlrpc.php. Если у вас Nginx, полезно проверить access.log. Пример фильтра:
grep "xmlrpc.php" /var/log/nginx/access.log | tail -n 50Если видите много однотипных запросов с разных IP, это похоже на перебор или сканирование. Если запросы идут с одного знакомого адреса, проверьте, не ваш ли это сервис, плагин или приложение.
Проверка зависимостей в админке
Пройдитесь по списку подключенных сервисов:
- Jetpack;
- мобильное приложение WordPress;
- плагины автопостинга;
- интеграции с внешними CRM и публикацией по API;
- старые клиенты для публикации записей.
Если сомневаетесь, временно ограничьтесь проверкой на staging-копии. Это быстрее, чем потом откатывать неудачную правку на боевом сайте.
Как отключить XML-RPC: три рабочих варианта
Лучший способ зависит от того, как у вас устроен сайт. Если нужен быстрый и обратимый вариант — используйте фильтр в теме или мини-плагине. Если хотите закрыть запросы раньше, можно добавить правило на уровне сервера. А если нужен компромисс, иногда достаточно не полного отключения, а точечного ограничения.
| Подход | Плюсы | Минусы |
|---|---|---|
| Код в мини-плагине | Контроль, легко отключить, не зависит от темы | Нужно следить за обновлениями и местом подключения |
| Правило на сервере | Быстро режет лишние запросы до WordPress | Нужен доступ к конфигу Nginx/Apache |
| Плагин безопасности | Удобно для админов без доступа к коду | Лишняя зависимость, не всегда прозрачная логика |
Вариант 1: отключить через PHP-фильтр
Этот способ подходит, если вы хотите управляемое решение без правок ядра. Добавьте код в мини-плагин или в functions.php дочерней темы, но лучше именно в мини-плагин, чтобы не потерять настройку при смене темы.
<?php
/**
* Disable XML-RPC.
*/
add_filter( 'xmlrpc_enabled', '__return_false' );После этого WordPress перестанет принимать XML-RPC-запросы, но сам файл xmlrpc.php может по-прежнему отвечать на запросы на уровне веб-сервера. Это нормально: важно, что WordPress не будет их обрабатывать.
Вариант 2: закрыть доступ на уровне Nginx
Если сервер у вас под управлением и вы хотите отсечь запросы раньше, можно добавить отдельное правило. Это особенно полезно, когда к сайту идёт много мусорных обращений.
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}После изменения конфигурации не забудьте проверить синтаксис и перезагрузить веб-сервер. Для Nginx это обычно выглядит так:
nginx -t
systemctl reload nginxЕсли у вас Apache, логика та же, но синтаксис будет другой. Не копируйте правило Nginx в .htaccess без адаптации.
Вариант 3: не отключать полностью, а ограничить
Иногда полный запрет не нужен. Например, если XML-RPC используется только одним сервисом, а остальное вы хотите отсечь. Тогда лучше не ломать всё подряд, а сначала проверить, можно ли перевести интеграцию на REST API. В WordPress это обычно более современный и предсказуемый путь.
Пошаговое решение без сюрпризов
- Проверьте логи и список подключенных сервисов.
- Убедитесь, что Jetpack, мобильное приложение и сторонние публикации через XML-RPC не используются.
- Сделайте резервную копию конфигурации и базы.
- Выберите способ отключения: код или серверное правило.
- Внесите изменение сначала на staging, если он есть.
- Проверьте ответ
/xmlrpc.phpи работу критичных интеграций.
Если нужен быстрый и несложный путь, начните с фильтра xmlrpc_enabled. Если атаки идут массово, дополнительно закройте доступ на сервере.
Как проверить, что отключение сработало
Проверка должна быть не «страница открывается», а именно тест на обработку XML-RPC. Есть несколько способов.
Проверка через curl
Отправьте простой запрос к xmlrpc.php. Если XML-RPC отключён, WordPress обычно вернёт ошибку доступа или другой неуспешный ответ в зависимости от способа блокировки.
curl -i https://example.com/xmlrpc.phpЕсли вы закрыли доступ на уровне сервера, можно увидеть 403 Forbidden. Если отключили через WordPress-фильтр, поведение может отличаться, но главное — метод не должен работать как раньше.
Проверка в админке и у сервисов
- попробуйте синхронизацию Jetpack, если он у вас был подключён;
- проверьте публикацию из мобильного приложения WordPress;
- посмотрите, не появились ли ошибки в логах интеграций;
- убедитесь, что REST API работает, если он нужен для других задач.
Если после отключения перестала работать конкретная интеграция, значит она действительно зависела от XML-RPC. В таком случае лучше искать замену на REST API или другой способ подключения, а не возвращать всё назад без разбора.
Частые ошибки и как их исправить
Отключили XML-RPC, не проверив Jetpack
Это одна из самых частых проблем. Jetpack в некоторых сценариях использует XML-RPC для связи с сайтом. Если он нужен, сначала проверьте, можно ли перевести нужную функцию на другой механизм, или не отключайте XML-RPC полностью.
Добавили код в активную тему
Если правка лежит в functions.php основной темы, она исчезнет при смене темы. Для технических ограничений лучше использовать мини-плагин или mu-plugin. Это проще сопровождать и безопаснее при обновлениях.
Смешали серверное правило и плагин без понимания приоритета
Если xmlrpc.php закрыт на уровне Nginx, а в WordPress стоит фильтр, вы можете получить неочевидное поведение при диагностике. Сначала проверьте, где именно блокируется запрос, и только потом делайте выводы.
Сломали интеграцию, которая давно не использовалась
Иногда сервис не трогали месяцами, но он всё ещё нужен для редких задач. Перед отключением полезно не только смотреть код, но и спросить у команды, какие внешние подключения вообще живы.
Безопасность и производительность: что ещё имеет смысл сделать
Отключение XML-RPC само по себе не закрывает все проблемы безопасности. Но это хороший повод проверить соседние настройки:
- обновления ядра, тем и плагинов;
- ограничение попыток входа;
- наличие двухфакторной аутентификации для админов;
- чистоту списка активных плагинов;
- логи ошибок и подозрительных запросов.
Если у вас много мусорных обращений к xmlrpc.php, закрытие на уровне сервера может немного разгрузить PHP-FPM. Это не «ускорение сайта» в рекламном смысле, но лишнюю нагрузку убирает.
Для сайтов, где важна техническая чистота и SEO-гигиена, удобно держать такие ограничения в одном месте. Если нужен инструмент без ручной сборки из десятка мелких правок, можно посмотреть в сторону Clearfy Pro: у него есть функции для чистки сайта и отключения лишнего, но применять его стоит только там, где вы понимаете, что именно выключаете.
Когда лучше не отключать XML-RPC полностью
Полный запрет не всегда лучший вариант. Если сайт живёт на старой интеграции, а перевод на REST API сейчас невозможен, лучше оставить XML-RPC включённым и ограничить доступ по IP, логике сервера или через WAF. Это менее «чистое» решение, но иногда оно безопаснее для бизнеса, чем резкий обрыв связи.
Практический критерий простой: если после отключения у вас ломается рабочий сценарий публикации или синхронизации, значит сначала нужно заменить интеграцию, а не просто закрывать endpoint.
