XML-RPC в WordPress часто оставляют включённым по привычке, хотя на большинстве сайтов он не нужен. Проблема не в самом файле xmlrpc.php, а в том, что через него можно получать лишнюю поверхность атаки: перебор логинов, pingback-спам, ненужные запросы к серверу. Если вы не используете мобильное приложение WordPress, внешние публикации или старые интеграции, доступ лучше закрыть на уровне веб-сервера.
Ниже — рабочие способы для Nginx и Apache, как проверить, что блокировка реально сработала, и какие ошибки чаще всего ломают сайт или оставляют XML-RPC доступным.
Когда XML-RPC действительно стоит закрыть
Не нужно отключать его вслепую. Сначала проверьте, есть ли у вас зависимость от этого интерфейса. XML-RPC может быть нужен, если:
- вы публикуете записи через старое приложение WordPress;
- используете внешние сервисы, которые до сих пор работают через XML-RPC;
- подключены старые интеграции для удалённой публикации или трекинга pingback.
Если ничего из этого не используется, закрытие доступа обычно безопасно. Для большинства современных сайтов REST API уже достаточно.
Диагностика проблемы перед изменениями
Сначала проверьте, доступен ли файл напрямую. Откройте в браузере или через curl адрес /xmlrpc.php. Если сервер отвечает не ошибкой 403, а страницей WordPress или сообщением о неверном запросе, значит файл доступен.
curl -I https://example.com/xmlrpc.phpПолезно посмотреть и логи веб-сервера. Если по xmlrpc.php идут частые запросы, это уже повод закрыть доступ даже без явной атаки. На практике в логах часто видно перебор по словарю или массовые обращения от ботов.
Как закрыть XML-RPC в Nginx
Для Nginx самый надёжный вариант — отдельное правило, которое отдаёт 403 на запросы к xmlrpc.php. Это лучше, чем пытаться «ломать» обработку на уровне WordPress, потому что запрос даже не дойдёт до PHP.
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Этот блок добавляют внутрь server, рядом с другими правилами для WordPress. После изменения конфигурации проверьте синтаксис и перезагрузите Nginx:
nginx -t
systemctl reload nginxЕсли у вас несколько конфигурационных файлов, убедитесь, что правило не перекрывается более общим location. В Nginx порядок и точность совпадения важны: правило с location = /xmlrpc.php должно срабатывать именно на этот файл.
Как закрыть XML-RPC в Apache через .htaccess
На Apache удобнее всего использовать .htaccess в корне сайта. Для современных конфигураций подойдёт такой вариант:
<Files xmlrpc.php>
Require all denied
</Files>Если сайт работает на старом Apache 2.2, иногда встречается синтаксис через Deny from all, но в актуальных установках лучше использовать Require all denied. После сохранения файла проверьте, что модуль mod_authz_core включён и директива вообще разрешена в AllowOverride.
Если у вас доступ к виртуальному хосту, надёжнее добавить правило туда, а не полагаться только на .htaccess. Это и быстрее, и проще для диагностики.
Что выбрать: серверное правило, плагин или код
| Подход | Плюсы | Минусы | Когда брать |
|---|---|---|---|
| Nginx / Apache | Блокирует запрос до PHP, меньше нагрузка | Нужен доступ к конфигу сервера | Если вы администрируете хостинг или VPS |
| Плагин безопасности | Просто включить, без правок конфигов | Запрос может доходить до WordPress | Если нет доступа к серверу |
| Код в WordPress | Можно быстро внедрить в тему или mu-plugin | Не лучший уровень для блокировки | Как временная мера или дополнительная защита |
Если есть доступ к серверу, выбирайте именно серверный уровень. Плагин или код в WordPress — это запасной вариант, а не основной.
Дополнительная защита через WordPress-код
Иногда нужно не только закрыть доступ на сервере, но и подстраховаться на уровне WordPress, например если сайт переезжает или у вас несколько окружений. Тогда можно добавить фильтр, который отключает XML-RPC-сервисы внутри WordPress.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Этот вариант не заменяет блокировку на Nginx или Apache, потому что сам файл xmlrpc.php остаётся доступным. Но если серверное правило временно не применилось, WordPress хотя бы не будет обслуживать XML-RPC-запросы.
Лучше размещать такой код в mu-plugin, а не в теме. Тогда он не пропадёт после смены шаблона.
Проверка результата после внедрения
После настройки проверьте три вещи: HTTP-статус, логи и поведение WordPress.
- Запрос к
/xmlrpc.phpдолжен возвращать403 Forbiddenили другой явно запрещающий ответ. - В логах веб-сервера не должно быть успешной обработки этого файла.
- Если вы добавили фильтр
xmlrpc_enabled, WordPress не должен принимать XML-RPC-вызовы даже при прямом доступе.
Проверка через curl выглядит так:
curl -I https://example.com/xmlrpc.phpЕсли вы видите 200 OK или ответ WordPress с телом страницы, блокировка не сработала. Если 403 приходит, но при этом сайт начал выдавать ошибки в админке, проверьте, не сломали ли вы правило слишком широким совпадением.
Частые ошибки и как их исправить
Правило добавили не в тот блок конфигурации
В Nginx часто вставляют правило в location /, а потом удивляются, что оно не применяется. Для точечной блокировки нужен отдельный location = /xmlrpc.php. Если правило стоит в неправильном месте, Nginx может выбрать другой блок.
В .htaccess использован устаревший синтаксис
На Apache 2.4 директива Deny from all без нужных модулей может не сработать. Используйте Require all denied и проверьте, что сервер действительно читает .htaccess.
Отключили XML-RPC через код, но файл всё ещё доступен
Это ожидаемо. Фильтр xmlrpc_enabled отключает функциональность WordPress, но не закрывает URL на уровне веб-сервера. Если нужна реальная блокировка, добавьте правило в Nginx или Apache.
Сломали интеграцию, которая зависела от XML-RPC
Такое бывает, если сайт использовал старое приложение или внешний сервис публикации. В этом случае не нужно откатывать защиту целиком: сначала выясните, какой именно сервис обращается к XML-RPC, и переведите его на REST API или другой поддерживаемый способ.
Практические советы по безопасности и производительности
Закрытие XML-RPC — не замена нормальной защите входа, но хороший слой обороны. Если у вас уже есть ограничение по логинам, 2FA и актуальные обновления ядра, блокировка XML-RPC убирает ещё один популярный вектор атак.
На высоконагруженных сайтах это ещё и небольшая экономия ресурсов: запросы к xmlrpc.php не будут запускать PHP и не создадут лишнюю нагрузку на базу. Эффект не стоит переоценивать, но в логах и по числу запросов разница обычно заметна.
Если вы ведёте несколько сайтов, удобно держать это правило в шаблоне конфигурации сервера или в базовом mu-plugin. Так вы не забудете закрыть XML-RPC на новом проекте.
Для сайтов, где важна техническая чистота, можно дополнительно проверить, не используются ли старые интеграции, и убрать лишние точки входа. Это касается не только XML-RPC, но и других устаревших механизмов, которые давно заменены более безопасными вариантами.