XML-RPC в WordPress часто отключают «на всякий случай», а потом неожиданно ломают публикацию через мобильное приложение, внешние сервисы или старые интеграции. На практике задача не в том, чтобы просто закрыть доступ к xmlrpc.php, а в том, чтобы понять, кто его использует, и отключить только лишнее.
Если на сайте нет Jetpack, старых клиентов для публикации, удалённого управления или сторонних сервисов, XML-RPC обычно можно убрать. Но перед этим стоит проверить, не завязан ли на него ваш рабочий процесс. Ниже — рабочий сценарий: как диагностировать использование, как отключить XML-RPC кодом или через сервер, и как убедиться, что ничего важного не сломалось.
Когда XML-RPC лучше отключить, а когда оставить
XML-RPC — это не «лишний файл», а интерфейс удалённого доступа. Он нужен не всем, но если вы им пользуетесь, отключение даст не безопасность, а проблему. Поэтому сначала смотрят на реальные сценарии.
Обычно XML-RPC можно отключать, если
- сайт публикуется только через админку WordPress;
- нет Jetpack или он не использует удалённые функции;
- не подключены внешние сервисы, которые отправляют записи через XML-RPC;
- нет старых мобильных приложений или десктопных клиентов для публикации;
- вы не используете pingback/trackback и не планируете их использовать.
Лучше не отключать сразу, если
- редакторы публикуют материалы из стороннего клиента;
- на сайте есть интеграции, которые вы настраивали давно и не хотите проверять вслепую;
- вы не уверены, кто именно обращается к
xmlrpc.php; - сайт использует сервисы синхронизации контента.
Диагностика: кто вообще обращается к xmlrpc.php
Перед изменениями полезно посмотреть логи сервера. Если в них регулярно встречается /xmlrpc.php, это не всегда атака. Иногда это боты, иногда — легитимный сервис, который вы давно забыли.
На nginx можно быстро проверить обращения по access log:
grep "xmlrpc.php" /var/log/nginx/access.log | tail -n 50На Apache логика та же, только путь к файлу будет другим. Смотрите не только сам факт запросов, но и IP, User-Agent и частоту. Если видите много однотипных POST-запросов с разных адресов, это уже повод ограничить доступ.
Ещё один практический тест — временно переименовать файл на тестовой копии сайта и проверить, что перестанет работать. Но на боевом сайте так делать не стоит: лучше сначала собрать информацию из логов и проверить интеграции вручную.
Как отключить XML-RPC безопасно
Есть три нормальных подхода: через код, через веб-сервер и через плагин. Для большинства сайтов самый предсказуемый вариант — код в functions.php дочерней темы или в небольшом must-use плагине.
Вариант 1: отключить XML-RPC через фильтр
WordPress даёт фильтр xmlrpc_enabled. Это чистый способ, который не требует правок ядра и обычно работает так, как ожидается.
add_filter( 'xmlrpc_enabled', '__return_false' );Если нужно оставить XML-RPC включённым только для части окружений, можно добавить условие:
add_filter( 'xmlrpc_enabled', function( $enabled ) {
if ( defined( 'WP_ENVIRONMENT_TYPE' ) && WP_ENVIRONMENT_TYPE === 'local' ) {
return true;
}
return false;
} );Такой подход удобен, если локально вы тестируете старую интеграцию, а на продакшене хотите закрыть доступ.
Вариант 2: заблокировать доступ на уровне сервера
Если задача — именно снизить нагрузку и убрать лишний входной путь, блокировка на сервере работает жёстче. Но тут важно не переборщить: если у вас есть нужная интеграция, она тоже перестанет работать.
Для nginx можно добавить правило в конфигурацию сайта:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Для Apache обычно используют .htaccess:
<Files xmlrpc.php>
Require all denied
</Files>Этот вариант хорош, когда вы уверены, что XML-RPC не нужен вообще. Если уверенности нет, начните с фильтра WordPress, а не с жёсткой блокировки на сервере.
Вариант 3: отключить только pingback и trackback
Иногда полный запрет XML-RPC не нужен, но pingback/trackback уже точно не используются. Тогда можно убрать хотя бы их. Это не решает все вопросы безопасности, но уменьшает мусорный трафик и часть злоупотреблений.
add_filter( 'xmlrpc_methods', function( $methods ) {
unset( $methods['pingback.ping'] );
unset( $methods['pingback.extensions.getPingbacks'] );
return $methods;
} );Если вы не уверены, нужен ли вам полный запрет, этот промежуточный вариант иногда удобнее. Но он не заменяет полноценную проверку логов и интеграций.
Сравнение подходов: код, сервер, плагин
| Подход | Что делает | Плюсы | Минусы |
|---|---|---|---|
Фильтр xmlrpc_enabled | Отключает XML-RPC на уровне WordPress | Просто откатить, удобно для тестов | Запрос всё равно доходит до WordPress |
| Блокировка в nginx/Apache | Режет доступ до PHP | Меньше нагрузки, жёсткий запрет | Легко сломать нужную интеграцию |
| Плагин безопасности | Даёт переключатель в админке | Удобно для неразработчиков | Лишняя зависимость, не всегда прозрачно |
Если вы ведёте сайт как разработчик или техредактор, обычно лучше начинать с кода. Плагин имеет смысл, когда доступ к конфигам сервера ограничен, а править тему неудобно.
Проверка результата после внедрения
После отключения важно не ограничиться «страница открывается». Нужно проверить именно тот сценарий, который вы закрывали.
- Откройте
/xmlrpc.phpв браузере — в зависимости от способа блокировки вы должны увидеть отказ в доступе или стандартный ответ WordPress. - Проверьте публикацию через админку: создание и обновление записей должны работать как обычно.
- Если у вас есть Jetpack, мобильное приложение WordPress или внешняя интеграция, выполните тестовое подключение.
- Посмотрите access log: после блокировки запросы к
xmlrpc.phpне должны проходить дальше веб-сервера или должны получать отказ.
Если вы отключали XML-RPC через фильтр, полезно временно включить отладку на тестовой среде и убедиться, что в логах нет ошибок, связанных с публикацией или синхронизацией.
Частые ошибки и как их исправить
Отключили XML-RPC, а потом перестал работать Jetpack
Это типичный сценарий. Jetpack может использовать XML-RPC для части функций. Решение простое: либо вернуть XML-RPC, либо отключить только те функции Jetpack, которые завязаны на удалённый доступ, если это возможно в вашей конфигурации.
Поставили блокировку в .htaccess, но сайт на nginx
.htaccess не работает на nginx. Если сервер не Apache, правило нужно добавлять в конфиг nginx, а не в файл сайта. Иначе вы будете искать проблему в WordPress, хотя она вообще не на его стороне.
Спрятали проблему плагином, но не поняли источник запросов
Плагин может выключить XML-RPC, но не объяснит, кто им пользовался. Если у вас есть подозрение на легитимную интеграцию, сначала смотрите логи и только потом режьте доступ.
Отключили всё, а забыли про мобильную публикацию
Если редакция использует мобильное приложение WordPress, оно может перестать публиковать записи. Это не баг отключения, а ожидаемое поведение. Проверяйте рабочие сценарии до внедрения, а не после жалоб от контент-менеджеров.
Что ещё стоит сделать для безопасности и производительности
Отключение XML-RPC не заменяет базовую защиту. Если на сайте уже есть лишний трафик и попытки подбора, полезно закрыть и другие очевидные точки риска.
- ограничить число попыток входа;
- включить нормальный WAF или хотя бы базовые правила на уровне сервера;
- убрать ненужные pingback/trackback, если они не используются;
- проверить, не открыты ли лишние REST-эндпоинты для публичного доступа;
- следить за логами, а не только за визуальным состоянием сайта.
Если вам нужен инструмент для чистки дублей, технической оптимизации и отключения лишнего в WordPress, иногда удобнее собрать это в одном наборе настроек, чем держать десяток разрозненных решений. Но даже в этом случае сначала проверяйте, что именно меняется на сайте, а не включайте всё подряд.
Практический критерий простой: если после отключения XML-RPC ваш сайт публикуется, интеграции работают, а запросы к xmlrpc.php больше не проходят без причины, задача решена. Если что-то сломалось — значит, нужно не «искать другой плагин», а вернуться к диагностике и понять, кто использовал этот канал связи.