XML-RPC в WordPress часто отключают «в лоб», а потом удивляются, что перестали работать мобильные клиенты, внешние публикации или старые интеграции. На практике задача обычно не в полном запрете, а в том, чтобы закрыть лишнее и оставить только то, что реально используется.
Ниже разберём, как понять, нужен ли вам XML-RPC, чем его лучше ограничивать и как проверить, что сайт не потерял нужную функциональность.
Когда XML-RPC действительно стоит трогать
Если сайт не использует внешние приложения для публикации, старые интеграции с Jetpack, удалённое управление постами или pingback/trackback, XML-RPC чаще всего только расширяет поверхность атаки. Но если у вас есть мобильное приложение, сторонний сервис автопостинга или старая связка с CMS/скриптом, полное отключение может сломать рабочий сценарий.
Поэтому сначала полезно ответить на простой вопрос: кто именно обращается к /xmlrpc.php и зачем. Если ответа нет, не надо сразу ставить жёсткий запрет на уровне сервера без проверки.
Диагностика: кто использует XML-RPC
Самый надёжный способ — посмотреть логи веб-сервера. Если у вас Nginx или Apache, ищите запросы к /xmlrpc.php и оцените частоту обращений. Отдельно смотрите на коды ответа: массовые POST-запросы с ошибками могут быть признаком перебора паролей, а не легитимной интеграции.
Что проверить перед изменениями
- Есть ли у вас Jetpack или другое приложение, которое подключается к сайту удалённо.
- Используются ли мобильные клиенты WordPress для публикации.
- Есть ли старые внешние скрипты, которые вызывают
xmlrpc.php. - Нужны ли pingback и trackback на сайте вообще.
- Есть ли в логах регулярные обращения к
/xmlrpc.phpс неизвестных IP.
Если вы не уверены, начните не с полного отключения, а с блокировки только опасных сценариев. Это безопаснее для сайта с живыми интеграциями.
Пошаговое решение: отключить XML-RPC выборочно
Ниже два рабочих подхода: через код в теме или мини-плагин, и через веб-сервер. Для большинства сайтов удобнее начать с кода: проще откатить и легче понять, что именно сломалось.
Вариант 1: отключить XML-RPC через код
Добавьте код в functions.php дочерней темы или в собственный плагин. Этот вариант полностью отключает XML-RPC и при этом даёт понятную точку управления.
<?php
add_filter('xmlrpc_enabled', '__return_false');
Если вам нужно не отключать всё целиком, а убрать только pingback, можно оставить XML-RPC включённым и заблокировать конкретный метод:
<?php
add_filter('xmlrpc_methods', function ($methods) {
unset($methods['pingback.ping']);
return $methods;
});
Это полезно, когда вы хотите сохранить удалённую публикацию, но убрать один из самых шумных и бесполезных для большинства сайтов механизмов.
Вариант 2: закрыть доступ на уровне Nginx
Если у вас есть доступ к конфигу Nginx, можно отдать 403 только для этого файла. Такой способ быстрее и не зависит от WordPress-кода, но требует аккуратности: после изменения конфигурации проверьте, что сайт продолжает отдавать обычные страницы.
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}
Для Apache аналогичный эффект обычно делают через .htaccess, но это уже зависит от конфигурации хостинга. Если правила переписывания у вас нестандартные, сначала протестируйте на staging-копии.
Вариант 3: оставить XML-RPC, но убрать лишнее
Это компромиссный сценарий. Он подходит, если вы не хотите ломать внешние подключения, но хотите снизить риск злоупотреблений. В таком случае имеет смысл:
- убрать
pingback.ping; - ограничить доступ по IP, если интеграция идёт с фиксированного адреса;
- добавить базовую защиту на уровне WAF или fail2ban;
- отключить trackback/pingback в настройках обсуждения, если они не нужны.
Сравнение подходов
| Способ | Что делает | Плюс | Минус |
|---|---|---|---|
Фильтр xmlrpc_enabled | Отключает XML-RPC в WordPress | Просто откатить, не требует доступа к серверу | Запрос всё равно доходит до PHP |
| Блокировка в Nginx/Apache | Режет доступ к xmlrpc.php на входе | Меньше нагрузки и шума в логах | Нужен доступ к конфигу сервера |
| Удаление отдельных методов | Оставляет XML-RPC частично | Сохраняет нужные интеграции | Требует понимания, какие методы используются |
Как проверить, что решение сработало
Проверка должна быть не формальной, а практической. После изменения откройте /xmlrpc.php в браузере — вы не увидите «красивую» страницу, но важен сам факт ответа сервера. Если доступ закрыт на уровне веб-сервера, обычно это 403 Forbidden. Если XML-RPC отключён на уровне WordPress, поведение может отличаться в зависимости от окружения, но сам метод должен перестать работать.
Дальше проверьте реальные сценарии:
- если есть Jetpack — переподключите его и убедитесь, что синхронизация не сломалась;
- если используете мобильное приложение — попробуйте создать черновик или обновить запись;
- посмотрите логи на повторяющиеся обращения к
/xmlrpc.php; - проверьте, исчезли ли запросы к
pingback.ping.
Для быстрой проверки можно отправить тестовый запрос из консоли, если у вас есть доступ к серверу:
curl -I https://example.com/xmlrpc.phpЕсли вы закрывали файл на уровне Nginx, ожидайте 403. Если меняли только фильтр WordPress, результат зависит от того, как именно сервер и PHP обрабатывают запрос.
Частые ошибки и как их исправить
Отключили XML-RPC, а потом перестал работать Jetpack
Это типичная ситуация, если не проверили зависимости заранее. Решение простое: либо возвращаете XML-RPC, либо переходите на частичное ограничение и убираете только опасные методы.
Закрыли доступ в Nginx, но забыли про staging
На тестовой копии всё могло быть нормально, а на боевом сервере — другая конфигурация. Всегда проверяйте именно тот виртуальный хост, который обслуживает домен.
Отключили pingback, но комментарии-спам не исчезли
Pingback — не единственный источник спама. Если у вас открыты обычные комментарии, нужны дополнительные меры: модерация, антиспам и ограничение ссылок в комментариях.
Поставили плагин, который «всё отключает», но не поняли, что он меняет
С такими решениями осторожнее: некоторые плагины отключают не только XML-RPC, но и другие функции, которые потом сложно диагностировать. Если нужен точечный контроль, код в дочерней теме или маленький собственный плагин обычно надёжнее.
Практические советы по безопасности и производительности
Если XML-RPC вам не нужен, лучше закрыть его на уровне сервера. Это уменьшает лишние обращения и упрощает логи. Если нужен частично — оставляйте только то, что реально используется, и ограничивайте доступ по IP или через WAF.
Для сайтов с регулярными атаками на xmlrpc.php полезно ещё и убрать pingback, потому что он часто становится источником бессмысленного трафика. А если вы ведёте сайт без внешних интеграций, проверьте вместе с этим и другие старые точки входа: trackback, неиспользуемые REST-эндпоинты, слабые пароли админов.
Если вам нужен более широкий набор мер по чистке и технической оптимизации WordPress, можно посмотреть и на инструменты вроде Clearfy Pro: он закрывает часть типовых задач по удалению дублей и лишних функций, но такие решения всё равно стоит внедрять осознанно, а не «включить всё сразу».