Как отключить XML-RPC в WordPress и не сломать мобильные приложения и Jetpack

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

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

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

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

Отключение оправдано, если:

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

Когда отключать нельзя без проверки

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

Диагностика: нужен ли вам XML-RPC сейчас

Перед изменениями проверьте, кто и как обращается к xmlrpc.php. Самый простой способ — посмотреть логи веб-сервера или статистику в панели хостинга. Если там есть регулярные POST-запросы к /xmlrpc.php, это уже повод разобраться, откуда они идут.

Полезно проверить и сам сайт вручную:

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

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

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

Как отключить XML-RPC: три рабочих способа

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

Способ 1. Отключить XML-RPC через код

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

<?php
/**
 * Plugin Name: Disable XML-RPC
 */
add_filter( 'xmlrpc_enabled', '__return_false' );

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

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

Если у вас Apache и сайт использует .htaccess, можно закрыть доступ к файлу напрямую. Это полезно, когда вы хотите отсечь запросы еще до запуска WordPress.

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

Для nginx правило обычно добавляют в конфиг сайта:

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

После изменения конфигурации не забудьте проверить синтаксис и перезагрузить сервер. Для nginx это обычно выглядит так:

nginx -t

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

Способ 3. Использовать плагин безопасности

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

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

Пошаговое решение без лишнего риска

1. Проверьте, используются ли Jetpack, мобильное приложение WordPress или внешние публикации.
2. Посмотрите логи и найдите обращения к /xmlrpc.php.
3. Выберите один способ блокировки: код или сервер.
4. Внесите изменение сначала на staging-копии, если она есть.
5. Проверьте, не исчезли ли нужные функции.
6. Только потом переносите настройку на боевой сайт.

Если у вас нет staging-среды, хотя бы сохраните текущую конфигурацию .htaccess или конфиг nginx перед правкой. Это банально, но именно здесь чаще всего теряют время на откат.

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

Проверка должна быть не только «страница открывается». Нужно убедиться, что сам XML-RPC больше не отвечает как рабочий интерфейс.

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

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

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

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

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

Добавили правило в несколько мест сразу

Если XML-RPC закрыт и в плагине, и в .htaccess, и в nginx, диагностика становится мутной. При проблемах непонятно, какая именно точка блокирует запрос. Лучше оставить один основной способ и документировать его рядом с конфигом.

Правило в .htaccess не сработало

Частая причина — сайт работает не на Apache, а на nginx, где .htaccess вообще не используется. Вторая причина — правило добавили не в тот блок или сервер не читает этот файл из-за настроек хостинга.

После блокировки остались запросы в логах

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

Что учесть по безопасности и производительности

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

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

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

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

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

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