XML-RPC в WordPress часто отключают ради безопасности и снижения лишних запросов, но на живом сайте это не всегда можно сделать «в лоб». Через него до сих пор работают некоторые мобильные клиенты, внешние сервисы публикации и старые интеграции. Если просто закрыть endpoint, можно получить неочевидные ошибки в приложениях и автоматизации.
Ниже — практический сценарий: как понять, нужен ли вам XML-RPC, как отключить его без лишнего риска и как проверить, что сайт после изменения ведёт себя нормально.
Когда XML-RPC действительно мешает
Проблема обычно не в самом файле xmlrpc.php, а в том, что он остаётся доступным для перебора логинов, pingback-атак и бессмысленных обращений. На небольших сайтах это часто просто шум в логах, на более нагруженных — лишняя нагрузка и источник подозрительных запросов.
Отключать XML-RPC имеет смысл, если вы не используете:
- мобильное приложение WordPress для публикации;
- Jetpack или похожие сервисы, которым нужен удалённый доступ;
- внешние клиенты для постинга по XML-RPC;
- старые интеграции, которые не переведены на REST API.
Как быстро понять, используется ли XML-RPC сейчас
Самый простой способ — посмотреть логи веб-сервера и проверить, есть ли обращения к /xmlrpc.php. Если запросы идут регулярно, это ещё не значит, что endpoint нужен, но это хороший повод проверить интеграции.
Дополнительно можно открыть страницу https://example.com/xmlrpc.php. Если она отвечает текстом XML-RPC server accepts POST requests only., endpoint доступен. Это нормально для стандартного WordPress, но не означает, что его обязательно нужно оставлять открытым.
Что отключать: кодом, через сервер или плагином
Есть три рабочих подхода. Выбор зависит от того, насколько жёстко вы хотите закрыть доступ и есть ли у вас контроль над конфигурацией сервера.
| Способ | Плюсы | Минусы | Когда выбирать |
|---|---|---|---|
| Код в теме или MU-плагине | Быстро, прозрачно, легко откатить | Не блокирует запрос на уровне сервера | Если нужен аккуратный и управляемый вариант |
| Правило на сервере | Жёсткая блокировка до WordPress | Нужно править конфиг Nginx/Apache | Если важна защита и есть доступ к серверу |
| Плагин безопасности | Без кода, удобно для админов | Лишняя зависимость, иногда больше настроек, чем нужно | Если на сайте уже есть security-плагин |
Пошаговое отключение XML-RPC кодом
Если вам нужен управляемый вариант без правок конфигурации сервера, используйте фильтр xmlrpc_enabled. Его удобно добавить в MU-плагин, чтобы настройка не зависела от темы.
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Такой код отключает сам XML-RPC на уровне WordPress. Для большинства сайтов этого достаточно, если нет внешних клиентов, которые используют этот протокол.
Если нужно не отключить всё, а убрать pingback
Иногда XML-RPC нужен для отдельных интеграций, но pingback-методы — нет. Тогда можно точечно вырезать только опасные вызовы через фильтр xmlrpc_methods.
<?php
add_filter( 'xmlrpc_methods', function( $methods ) {
unset( $methods['pingback.ping'] );
unset( $methods['pingback.extensions.getPingbacks'] );
return $methods;
} );Это не полная защита, но уже уменьшает поверхность атаки и убирает один из самых шумных сценариев.
Жёсткая блокировка на уровне сервера
Если вы уверены, что XML-RPC не нужен вообще, лучше закрыть доступ ещё до загрузки WordPress. Это снижает лишнюю нагрузку и не даёт PHP обрабатывать запросы.
Для Nginx
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Для Apache
<Files xmlrpc.php>
Require all denied
</Files>После таких правил запросы к endpoint будут блокироваться на уровне веб-сервера. Это особенно полезно, если сайт часто получает брутфорс-запросы или мусорный трафик.
Диагностика перед отключением
Перед изменением лучше пройти короткий чек-лист. Он помогает не сломать внешние сервисы и не искать потом причину «пропавшей» публикации.
- Проверьте, используется ли Jetpack или другой сервис с удалённой публикацией.
- Уточните, не работают ли мобильные приложения редакторов через XML-RPC.
- Посмотрите, есть ли в логах обращения к
xmlrpc.phpот ваших IP или сторонних сервисов. - Сделайте резервную копию конфигурации сервера и файла с кодом, если вносите правки вручную.
- Проверьте, не завязан ли на XML-RPC старый скрипт импорта или автопостинга.
Как проверить, что решение сработало
После внедрения не ограничивайтесь открытием сайта в браузере. Нужно проверить сам endpoint и связанные сценарии.
- Откройте
/xmlrpc.phpв браузере или черезcurl. - Убедитесь, что код ответа соответствует вашему способу блокировки: 403 для сервера, либо отсутствие доступа к функциям XML-RPC внутри WordPress.
- Проверьте логи веб-сервера: новых обращений к endpoint быть не должно, либо они должны получать отказ.
- Если у вас есть внешние сервисы публикации, выполните тестовую отправку записи.
Пример проверки через curl:
curl -I https://example.com/xmlrpc.phpЕсли вы закрывали endpoint на уровне сервера, в ответе обычно будет 403 Forbidden. Если отключали через WordPress-фильтр, поведение может зависеть от конфигурации сервера, но сам функционал XML-RPC должен перестать работать.
Частые ошибки и как их исправить
Отключили XML-RPC, а Jetpack перестал синхронизироваться
Это ожидаемо: часть функций Jetpack исторически использует удалённый доступ. Решение простое — либо вернуть XML-RPC, либо отказаться от этой интеграции и перевести задачу на REST API, если модуль это поддерживает.
Добавили код в тему, а после обновления он пропал
Так бывает, если код вставили в functions.php активной темы. Для системной настройки лучше использовать MU-плагин или отдельный мини-плагин, чтобы изменение не зависело от обновления темы.
Закрыли endpoint на сервере, но в логах всё ещё есть обращения
Это нормально: запросы продолжают приходить, но уже отсекаются до WordPress. Важен не сам факт обращения, а то, что сервер отвечает отказом и не тратит ресурсы на обработку PHP.
Сломали старый скрипт публикации
Если у вас есть внешняя автоматизация, проверьте, не использует ли она XML-RPC по привычке. В таких случаях безопаснее сначала перевести интеграцию на REST API, а уже потом отключать старый endpoint.
Практические советы по безопасности и производительности
Если цель — не просто убрать лишний endpoint, а реально снизить поверхность атаки, одной блокировки XML-RPC может быть мало. Полезно дополнительно:
- ограничить попытки входа в админку;
- проверить, не открыт ли
wp-login.phpдля массового перебора; - убрать ненужные плагины, которые добавляют удалённые вызовы без явной пользы;
- следить за логами 403 и 404, чтобы видеть повторяющиеся атаки;
- не держать в теме код, который можно вынести в MU-плагин.
Если на сайте уже используется набор для технической чистки и SEO-оптимизации, например Clearfy Pro, имеет смысл сверить его настройки с ручными правилами: иногда одну и ту же задачу лучше не дублировать в двух местах, чтобы не усложнять диагностику.
В итоге рабочая схема обычно выглядит так: сначала проверяете зависимости, затем выбираете способ блокировки, после этого тестируете внешние сервисы и только потом оставляете правило в постоянной конфигурации. Это проще, чем потом разбираться, почему перестала работать публикация из мобильного клиента или старого скрипта.