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

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

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

Когда XML-RPC лучше отключить, а когда не трогать

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

Типичные сценарии, где XML-RPC ещё встречается

• старые мобильные клиенты WordPress;
• Jetpack и связанные с ним функции на некоторых конфигурациях;
• внешние сервисы автопубликации и кросспостинга;
• десктопные редакторы и устаревшие интеграции;
• некоторые плагины синхронизации контента.

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

Диагностика: кто вообще обращается к xmlrpc.php

Первый шаг — посмотреть логи веб-сервера. Это самый надёжный способ понять, есть ли реальные обращения к /xmlrpc.php. Если логов нет, можно временно включить их на уровне сервера или хотя бы посмотреть статистику в панели хостинга.

Ищите не только успешные запросы, но и массовые попытки POST с одинаковыми параметрами. XML-RPC часто используют для брутфорса, потому что endpoint публичный и предсказуемый.

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

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

Что должно насторожить

• регулярные POST-запросы к xmlrpc.php с разных IP;
• ошибки авторизации в логах, связанные с XML-RPC;
• плагины или сервисы, которые перестают синхронизироваться после тестового отключения;
• неожиданный рост 403/401 на этом endpoint.

Если обращений нет, отключение обычно проходит безболезненно. Если обращения есть, надо понять, это атаки или рабочий трафик.

Как отключить XML-RPC в WordPress: рабочие варианты

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

Вариант 1. Отключение через код

Самый аккуратный способ — отключить пингбэки и сам XML-RPC через фильтр. Для постоянного решения лучше положить код в mu-plugin, чтобы он не зависел от темы.

<?php
/**
 * Plugin Name: Disable XML-RPC
 */

add_filter( 'xmlrpc_enabled', '__return_false' );

add_filter( 'wp_headers', function( $headers ) {
    unset( $headers['X-Pingback'] );
    return $headers;
} );

add_filter( 'pings_open', '__return_false', 20, 2 );

Этот вариант отключает сам XML-RPC на уровне WordPress и убирает заголовок X-Pingback, который тоже не нужен, если вы не используете пингбэки.

Вариант 2. Блокировка на уровне nginx

Если у вас есть доступ к конфигу сервера, можно отрезать запросы ещё до WordPress. Это полезно, когда на сайт идёт много мусорных обращений и вы не хотите тратить PHP-ресурсы.

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

Для Apache логика похожая, но синтаксис будет другой. Смысл один: запросы к xmlrpc.php не должны доходить до PHP, если endpoint вам не нужен.

Вариант 3. Через плагин

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

Пошаговое решение без сюрпризов

1. Проверьте логи и список интеграций: мобильные приложения, Jetpack, внешние редакторы, автопостинг.
2. Сделайте тест на staging-копии сайта, а не на боевом домене.
3. Отключите XML-RPC одним из способов выше.
4. Проверьте вход в админку, публикацию записей и работу всех внешних сервисов.
5. Если что-то сломалось, верните доступ точечно, а не включайте XML-RPC целиком без разбора.

Если вам нужен только удалённый доступ к контенту через современный API, чаще всего лучше смотреть в сторону REST API, а не возвращать XML-RPC обратно.

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

Проверка должна быть не только визуальной. Откройте /xmlrpc.php в браузере — при отключении через WordPress вы обычно увидите сообщение о том, что XML-RPC недоступен, либо получите 403/404 в зависимости от способа блокировки.

Ещё надёжнее — отправить тестовый запрос. Например, через curl:

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

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

После этого проверьте:

• вход в админку по обычной форме;
• публикацию и редактирование записей;
• работу внешних сервисов, если они есть;
• отсутствие новых успешных обращений к xmlrpc.php в логах.

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

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

Значит, приложение использовало именно XML-RPC, а не REST API. Решение — либо оставить endpoint открытым только для нужного сервиса, либо перевести интеграцию на другой способ доступа. Полное включение обратно — не единственный вариант.

Поставили сниппет в тему и забыли

После смены темы защита исчезнет. Для постоянного решения используйте mu-plugin или отдельный мини-плагин. Это особенно важно на сайтах, где тема обновляется или часто меняется.

Отключили XML-RPC, но оставили пингбэки

Это не критично, но бессмысленно. Если вы не используете pingback-логику, уберите и заголовок X-Pingback, и открытые пинги. Иначе часть лишней поверхности атаки останется.

Заблокировали endpoint на сервере, но не проверили логи

В итоге можно не заметить, что какой-то рабочий сервис всё ещё пытается стучаться в xmlrpc.php. После блокировки обязательно смотрите логи хотя бы несколько дней, если сайт с внешними интеграциями.

Безопасность и производительность: что ещё имеет смысл сделать

Если цель — уменьшить атаки, одного отключения XML-RPC может быть мало. Проверьте ещё:

• ограничение попыток входа;
• 2FA для админов;
• актуальность ядра, тем и плагинов;
• отключение ненужных публичных endpoint-ов;
• корректные права на файлы и доступ к админке по HTTPS.

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

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