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