Как отключить XML-RPC, закрыть лишние точки доступа и проверить, что WordPress стал безопаснее

После обновлений WordPress и плагинов часто всплывает одна и та же задача: сайт работает, но в логах остаются запросы к старым точкам входа, которые давно не нужны. Самый типичный пример — xmlrpc.php. Его продолжают сканировать боты, а на некоторых сайтах через него до сих пор пытаются дергать публикации, пингбеки и внешние клиенты, которые уже никто не использует.

Если у вас нет мобильных приложений, внешних сервисов или старого десктопного клиента, который работает именно через XML-RPC, этот интерфейс обычно проще отключить. Но делать это нужно аккуратно: сначала понять, используется ли он реально, потом закрыть доступ и только после этого проверить, что ничего не сломалось.

Когда XML-RPC действительно можно отключать

Не стоит отключать его «на всякий случай», если сайт связан с внешними сервисами, которые публикуют записи, ставят метки, отправляют комментарии или синхронизируют контент. На практике XML-RPC нужен редко, но полностью списывать его нельзя без проверки.

Сначала проверьте, есть ли зависимые сценарии

• публикация через старые приложения WordPress;
• интеграции с внешними редакторами и планировщиками;
• старые плагины автопостинга;
• сервисы, которые используют pingback.ping или metaWeblog.*.

Если ничего из этого не используется, отключение обычно безопасно. Если есть сомнения, сначала посмотрите логи веб-сервера или временно ограничьте доступ только для своих IP, а не рубите интерфейс сразу для всех.

Диагностика: как понять, что XML-RPC открыт и его дергают

Самый быстрый способ — проверить ответ сервера на запрос к /xmlrpc.php. Даже если вы не видите ошибок в админке, этот файл может быть доступен извне и принимать запросы.

curl -I https://example.com/xmlrpc.php

Если сервер отвечает не 404 и не 403, а отдает страницу с сообщением вроде XML-RPC server accepts POST requests only, значит endpoint доступен. Это еще не проблема само по себе, но точка входа открыта.

Дополнительно полезно посмотреть access log. Ищите повторяющиеся обращения к xmlrpc.php, особенно с одинаковых IP или с большим числом POST-запросов. Если таких запросов много, это уже не абстрактная «лишняя поверхность атаки», а реальный шум, который можно убрать.

Пошаговое решение: как отключить XML-RPC без лишнего риска

Есть три рабочих подхода: через плагин безопасности, через код и на уровне веб-сервера. Для большинства сайтов достаточно кода или настройки в плагине. Если у вас уже стоит решение для чистки и безопасности, например Clearfy Pro, проверьте, нет ли там отдельной опции для отключения XML-RPC и других лишних возможностей WordPress. Это удобнее, чем разносить логику по нескольким сниппетам.

Способ	Когда подходит	Компромисс
Плагин	Нужно быстро и без правки кода	Зависимость от настроек и интерфейса
Код в теме или mu-plugin	Нужен контроль и предсказуемость	Надо следить за обновлениями темы
Правило на сервере	Нужно отрезать доступ раньше WordPress	Требует доступа к конфигу Nginx/Apache

Вариант 1: отключить XML-RPC через код

Самый понятный способ — добавить фильтр в functions.php дочерней темы или, лучше, в небольшой mu-plugin. Так решение не потеряется при обновлении темы.

<?php
add_filter( 'xmlrpc_enabled', '__return_false' );

Это отключает обработку XML-RPC на уровне WordPress. Для большинства сайтов этого достаточно. Но если вы хотите не только отключить функциональность, а еще и убрать саму точку доступа из ответа сервера, дополнительно закройте URL на уровне веб-сервера.

Вариант 2: закрыть xmlrpc.php на уровне Nginx

Если сайт работает на Nginx, можно отдать 403 до передачи запроса в WordPress. Это полезно, когда ботам не нужно даже доходить до PHP.

location = /xmlrpc.php {
    deny all;
    access_log off;
    log_not_found off;
}

После правки конфигурации не забудьте проверить синтаксис и перезагрузить сервер. Для Apache логика будет другой, но смысл тот же: запретить доступ к файлу до обработки PHP.

Вариант 3: отключить через плагин безопасности

Если у вас уже установлен плагин, который управляет базовой защитой, используйте его, если в нем есть именно эта опция. Это удобно, когда вы не хотите держать отдельные сниппеты в теме. Но не ставьте новый плагин только ради одной галочки: лишний плагин ради одной функции часто хуже, чем короткий код.

Проверка результата после внедрения

После отключения важно не ограничиться «в админке ошибок нет». Проверьте несколько вещей отдельно.

• Откройте https://example.com/xmlrpc.php в браузере: доступ должен быть закрыт или не давать рабочий XML-RPC-ответ.
• Повторите проверку через curl -I и убедитесь, что сервер возвращает ожидаемый статус.
• Посмотрите access log: запросы к xmlrpc.php должны либо исчезнуть, либо получать 403/404.
• Если у вас есть внешняя интеграция, выполните ее тестовую операцию: публикацию, синхронизацию или отправку комментария.

Если вы отключали XML-RPC через код, а файл все еще отвечает как раньше, значит фильтр не подхватился. Обычно причина в том, что код положили не туда: в неактивную тему, в файл, который не загружается, или в плагин, который не успел инициализироваться.

Частые ошибки и как их исправить

Отключили XML-RPC и сломали внешнюю публикацию

Это происходит, когда сайт реально использовал старый клиент или сервис автопостинга. Исправление простое: вернуть доступ и отдельно проверить, чем именно пользуется интеграция. Иногда проще перевести ее на REST API, если сервис это поддерживает.

Закрыли файл в Nginx, но WordPress все равно отвечает

Чаще всего правило добавили не в тот server block или после более общего location, которое перехватывает запрос раньше. Проверьте порядок правил и убедитесь, что именно location = /xmlrpc.php применяется к запросу.

Поставили плагин, но нагрузка не ушла

Некоторые плагины отключают функциональность WordPress, но не блокируют сам URL на уровне веб-сервера. В итоге бот продолжает стучаться, а PHP все равно получает запросы. Если цель — снизить шум и лишние обращения, лучше закрывать точку входа раньше.

Смешали несколько способов и потеряли контроль

Если вы одновременно включили фильтр, серверное правило и опцию в плагине, потом сложно понять, что именно сработало. Для поддержки это плохой сценарий. Выберите один основной механизм и зафиксируйте его в документации проекта.

Что еще стоит проверить вместе с XML-RPC

Когда вы занимаетесь обновлением и чисткой старого WordPress-стека, имеет смысл посмотреть не только на XML-RPC. Часто рядом остаются другие лишние точки и дубли, которые создают шум для индексации и безопасности.

• неиспользуемые REST endpoints от старых плагинов;
• открытые авторские архивы, если они не дают ценности;
• лишние типы записей и таксономии, которые попадают в sitemap;
• старые плагины, которые давно не обновлялись и держат лишние хуки;
• дубли мета-тегов и каноникалов после обновления темы.

Если вы ведете сайт на обновляемой теме или регулярно меняете набор плагинов, полезно раз в несколько месяцев делать короткий аудит: что реально используется, что осталось от старой конфигурации и что можно убрать без потерь.

Практические советы по безопасности и производительности

Отключение XML-RPC само по себе не делает сайт «защищенным», но убирает лишнюю поверхность атаки и уменьшает шум в логах. Это особенно заметно на небольших проектах, где нет смысла держать старый интерфейс ради гипотетической совместимости.

Если вы управляете сайтом через код, храните такие изменения в mu-plugin или в отдельном мини-плагине, а не в основной теме. Тогда обновление темы не откатит настройку. Если используете плагин для чистки и SEO-оптимизации, держите в голове, что его задача — помогать с системными настройками, а не заменять контроль над сервером и логами.

И еще один практический момент: после обновления WordPress или плагинов повторяйте проверку. Иногда старые интеграции всплывают снова, особенно если на сайте есть автопостинг, импорт контента или внешние формы публикации.