Как отключить XML-RPC в WordPress без поломки приложений и пингбеков

Автор: Артем Сорокин | Опубликовано: 27.08.2026

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

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

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

Файл xmlrpc.php исторически нужен для удалённой публикации, pingback/trackback и некоторых старых интеграций. На современных сайтах он часто не нужен вообще, но это не значит, что его можно выключить без проверки. Проблема в том, что часть клиентов и сервисов продолжает использовать XML-RPC неявно: мобильные приложения, старые десктопные редакторы, отдельные инструменты автопостинга, некоторые интеграции с внешними системами.

Если у вас обычный сайт без удалённой публикации и без старых клиентов, отключение обычно оправдано. Если же редакторы публикуют через приложение WordPress или у вас есть внешняя автоматизация, сначала проверьте, чем именно пользуются люди и сервисы.

Быстрая диагностика: кто обращается к xmlrpc.php

Самый полезный первый шаг — посмотреть логи веб-сервера. В access log обычно видно, какие IP и user-agent стучатся в /xmlrpc.php. Это не всегда даст полную картину, но быстро покажет, есть ли реальные обращения.

grep 'xmlrpc.php' /var/log/nginx/access.log | tail -n 50

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

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

Что именно отключать: полное блокирование или только pingback

Здесь есть два разных сценария. Первый — вам не нужен XML-RPC вообще. Второй — вам нужен сам протокол для публикации, но не нужны pingback/trackback, которые часто используют для мусорных запросов. Во втором случае лучше отключать только pingback-методы, а не весь файл.

Подход	Что даёт	Минус
Полностью закрыть `xmlrpc.php`	Убирает лишнюю точку входа и часть атак	Ломает все сценарии, завязанные на XML-RPC
Отключить только pingback-методы	Снижает мусор и часть злоупотреблений	Не убирает сам протокол целиком
Оставить как есть	Ничего не ломает	Сохраняет лишнюю поверхность атаки

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

Вариант 1. Отключить через код темы или mu-plugin

Если вы хотите контролировать поведение без лишних плагинов, добавьте код в functions.php дочерней темы или, лучше, в mu-plugin. Для полного отключения WordPress предоставляет фильтр xmlrpc_enabled.

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

Этот вариант простой, но он не подходит, если вам нужен XML-RPC для отдельных сценариев. Тогда лучше не рубить всё целиком.

Вариант 2. Заблокировать доступ на уровне сервера

Если задача — именно закрыть файл от внешних запросов, лучше делать это на уровне веб-сервера. Тогда WordPress даже не будет обрабатывать запрос. Для Nginx можно добавить отдельное правило:

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

Для Apache обычно используют правило в .htaccess или конфигурации виртуального хоста:

<Files xmlrpc.php>
    Require all denied
</Files>

Такой подход быстрее и надёжнее, чем блокировать запрос уже внутри WordPress. Но если у вас несколько сайтов за одним сервером, не забудьте проверить, не используется ли XML-RPC где-то ещё.

Вариант 3. Отключить только pingback, оставить остальное

Если вы не хотите ломать внешнюю публикацию, но pingback вам не нужен, можно убрать только pingback-методы. Это полезно, когда сайт получает лишние запросы или вы видите подозрительную активность на pingback.ping.

<?php
add_filter( 'xmlrpc_methods', function( $methods ) {
    unset( $methods['pingback.ping'] );
    unset( $methods['pingback.extensions.getPingbacks'] );
    return $methods;
} );

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

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

После отключения важно не ограничиться «страница открывается». Нужно проверить именно те точки, которые могли сломаться.

Откройте /xmlrpc.php в браузере или через curl и убедитесь, что ответ соответствует выбранному способу блокировки.
Проверьте мобильное приложение WordPress, если редакторы им пользуются.
Проверьте внешние сервисы автопостинга, если они есть.
Посмотрите access log: запросы к xmlrpc.php должны исчезнуть или получать ожидаемый код ответа.
Убедитесь, что обычная публикация записей и работа REST API не затронуты.

Для быстрой проверки через командную строку удобно использовать curl:

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

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

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

Отключили XML-RPC, а потом сломалось мобильное приложение

Причина почти всегда одна: кто-то реально использовал XML-RPC для публикации или синхронизации. Решение — вернуть доступ и перейти на более точечное ограничение, например отключить только pingback или закрыть доступ по IP, если интеграция работает с фиксированного адреса.

Поставили плагин безопасности и забыли, что он уже блокирует xmlrpc.php

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

Сделали блокировку в .htaccess, но сайт на Nginx

Это типичная ошибка при переносе инструкций между хостингами. .htaccess работает только на Apache/LiteSpeed с поддержкой таких правил. На Nginx нужно править конфиг сервера, иначе правило просто не сработает.

Полностью закрыли XML-RPC, не проверив интеграции

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

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

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

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

Ещё один момент — не смешивайте уровень сервера и уровень WordPress без необходимости. Если вы уже закрыли xmlrpc.php на Nginx или Apache, не нужно дублировать то же самое в нескольких плагинах. Чем меньше слоёв, тем проще поддержка и диагностика.

Как понять, что решение сработало

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

Проверка через curl даёт ожидаемый ответ.
В access log нет регулярных успешных обращений к xmlrpc.php.
Редакторы и интеграции, которые вам нужны, продолжают публиковать без ошибок.
На сайте не появилось новых 403/500, связанных с изменением конфигурации.

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