XML-RPC в WordPress часто выключают «на всякий случай», а потом внезапно перестают работать мобильные клиенты, внешние публикации и часть интеграций. На практике задача не в том, чтобы просто заблокировать файл xmlrpc.php, а в том, чтобы понять, нужен ли он вообще вашему сайту и чем его заменить без побочных эффектов.
Если сайт не использует старые внешние клиенты, pingback и удалённую публикацию, XML-RPC обычно можно отключить. Но перед этим стоит проверить, не завязаны ли на него сторонние сервисы, которые вы уже забыли: приложения для постинга, автоматизация, некоторые бэкапы и мониторинг.
Когда XML-RPC действительно стоит отключать
Сам по себе xmlrpc.php не является «ошибкой», но он часто становится лишней точкой входа. Если сайт работает только через обычную админку WordPress и REST API, а внешние публикации не используются, отключение XML-RPC уменьшает поверхность атаки и убирает один из популярных векторов перебора паролей.
Отключать его имеет смысл, если у вас:
- нет публикации через старые мобильные приложения WordPress;
- не используются внешние сервисы, которые пишут в сайт через XML-RPC;
- не нужен pingback/trackback;
- есть отдельные требования по безопасности или фильтрации ботов.
Если же сайт подключён к сервисам автопостинга, кросспостинга или старым интеграциям, сначала проверьте документацию этих сервисов. Иногда они умеют работать через REST API, но не всегда это включено по умолчанию.
Диагностика: как понять, используется ли XML-RPC сейчас
Самый простой тест — открыть /xmlrpc.php в браузере. Если файл доступен, WordPress обычно отвечает сообщением о том, что XML-RPC сервер принимает только POST-запросы. Это не доказывает, что он нужен, но подтверждает, что точка входа открыта.
Дальше проверьте логи и интеграции:
- ищите запросы к
xmlrpc.phpв access-логах веб-сервера; - проверьте настройки мобильных приложений и внешних публикаций;
- посмотрите, нет ли в плагинах интеграций со сторонними CMS, сервисами автопостинга или резервного копирования;
- если есть WAF или security-плагин, проверьте, не блокирует ли он XML-RPC уже сейчас.
Быстрая проверка через CLI
Если есть доступ к серверу, можно быстро посмотреть, отвечает ли endpoint:
curl -I https://example.com/xmlrpc.phpДля WordPress это не даст полного ответа о функциональности, но покажет, доступен ли файл на уровне HTTP. Если вы видите 405 Method Not Allowed или похожий ответ на GET-запрос, это нормально: XML-RPC работает через POST.
Как отключить XML-RPC: три рабочих варианта
Выбор зависит от того, где вы хотите контролировать блокировку: в коде темы/плагина, на уровне сервера или через security-плагин. Если нужен предсказуемый и переносимый вариант, лучше использовать код в небольшом mu-plugin или в собственном плагине, а не в functions.php темы.
| Способ | Плюсы | Минусы |
|---|---|---|
| Код через хук | Контролируемо, легко откатить, работает в WordPress | Не блокирует запрос до загрузки WordPress |
| Правило на сервере | Ранний отказ, меньше нагрузки | Нужно править конфиг веб-сервера |
| Security-плагин | Быстро включить без кода | Зависимость от плагина и его логики |
Вариант 1: отключить XML-RPC через фильтр
Это самый аккуратный способ, если вам важно сохранить управляемость из WordPress. Добавьте код в mu-plugin или в собственный мини-плагин:
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );После этого WordPress перестанет принимать XML-RPC-запросы, но сам файл xmlrpc.php может по-прежнему отвечать на уровне веб-сервера. Для большинства сайтов этого достаточно.
Вариант 2: заблокировать доступ на уровне веб-сервера
Если нужно отрезать запросы раньше, можно закрыть xmlrpc.php в конфигурации сервера. Для Apache это обычно делают через .htaccess:
<Files xmlrpc.php>
Require all denied
</Files>Для Nginx логика будет другой, и правило лучше добавлять в конфиг виртуального хоста, а не в WordPress. Например, можно вернуть 403 для этого файла:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Этот вариант полезен, если сайт регулярно получает мусорные запросы к XML-RPC и вы хотите отсечь их до PHP.
Вариант 3: отключить только pingback, если XML-RPC нужен частично
Иногда полностью выключать XML-RPC нельзя, но pingback не нужен. Тогда можно оставить сам endpoint и убрать только pingback-часть. Это не универсальное решение, но для некоторых сайтов оно снижает шум без поломки интеграций.
<?php
add_filter( 'xmlrpc_methods', function( $methods ) {
unset( $methods['pingback.ping'] );
unset( $methods['pingback.extensions.getPingbacks'] );
return $methods;
} );Важно: если вы не уверены, какие именно методы нужны, сначала протестируйте на staging-копии. Частичное отключение проще сломать, чем полное.
Пошаговое решение без сюрпризов
- Составьте список внешних сервисов, которые пишут или читают данные из WordPress.
- Проверьте, есть ли среди них старые мобильные клиенты, автопостинг или резервное копирование через XML-RPC.
- Выберите способ отключения: фильтр WordPress, правило веб-сервера или security-плагин.
- Внесите изменение сначала на тестовой копии сайта.
- Проверьте, не сломались ли публикации, синхронизация и входящие запросы от интеграций.
- Только после этого переносите изменение на продакшн.
Если у вас уже есть плагин безопасности, не включайте сразу несколько механизмов блокировки. Например, фильтр в WordPress и правило в Nginx одновременно не всегда проблема, но при диагностике будет сложнее понять, что именно вернуло 403 или 404.
Как проверить, что отключение сработало
После внедрения важно проверить не только сам файл, но и реальные сценарии. Откройте https://example.com/xmlrpc.php и убедитесь, что ответ соответствует выбранному способу блокировки: 403 Forbidden на уровне сервера или отказ в обработке XML-RPC на уровне WordPress.
Затем проверьте функциональные тесты:
- публикация из внешнего сервиса, если он у вас есть;
- работа мобильного приложения WordPress, если оно используется;
- отсутствие новых ошибок в логах веб-сервера и PHP;
- нет ли жалоб от интеграций, которые раньше отправляли данные через XML-RPC.
Если у вас настроен мониторинг, полезно добавить отдельную проверку на доступность /xmlrpc.php. Это поможет быстро заметить, если правило на сервере случайно исчезло после обновления конфигурации.
Частые ошибки и как их исправить
Сломали внешнюю публикацию, хотя хотели только усилить безопасность
Чаще всего это происходит, когда XML-RPC отключили без инвентаризации интеграций. Исправление простое: верните доступ, найдите конкретный сервис, который зависит от XML-RPC, и переведите его на REST API или другой способ интеграции.
Добавили правило в тему, а потом потеряли его после обновления
Код в functions.php темы — плохое место для таких изменений. При смене темы или обновлении логика исчезнет. Для постоянного решения используйте mu-plugin или отдельный плагин.
Поставили сразу несколько блокировок и не понимаете, что именно сработало
Если XML-RPC закрыт и в WordPress, и на сервере, и в security-плагине, диагностика становится лишней. Сначала оставьте один слой защиты, проверьте результат, потом при необходимости добавляйте второй.
Отключили XML-RPC, но оставили старые trackback/pingback в контенте
Это не критическая ошибка, но лишний мусор в настройках и шаблонах может создавать путаницу. Если pingback не нужен, проверьте, не используются ли связанные функции в теме, и уберите лишние упоминания из настроек обсуждения.
Безопасность и производительность: что ещё стоит учесть
Отключение XML-RPC не заменяет нормальную защиту входа в админку. Если у вас слабые пароли, нет ограничения попыток входа и открыт /wp-login.php, один закрытый endpoint не решит проблему. Но как часть общей гигиены сайта это полезный шаг.
С точки зрения производительности выигрыш обычно не драматический, но на сайтах с постоянным мусорным трафиком к xmlrpc.php снижение нагрузки заметно по логам и числу бесполезных PHP-запросов. Если вы видите много таких обращений, имеет смысл дополнительно настроить кеш, WAF и базовую фильтрацию ботов.
Если нужен более широкий набор инструментов для технической чистки WordPress — от удаления дублей и лишних элементов до SEO-настроек — можно посмотреть в сторону Clearfy Pro: https://wpshop.ru/plugins/clearfy?utm_source=wptour.ru&utm_medium=article&utm_campaign=otkljuchit-xmlrpc-v-wordpress. Но даже в этом случае важно понимать, какой именно механизм блокировки вы включаете и как он влияет на интеграции.
Практический ориентир простой: если XML-RPC не нужен, отключайте его осознанно и проверяйте реальные сценарии, а не только статус файла. Если нужен хотя бы частично, ограничьте только лишние методы и зафиксируйте это в конфигурации, которая не потеряется после обновления темы.
