XML-RPC в WordPress часто отключают «на всякий случай», но это не всегда безопасно для проекта. Если на сайте используются мобильное приложение WordPress, внешние публикации, Jetpack, старые интеграции или удалённая публикация через сторонний софт, после жёсткого отключения часть сценариев перестанет работать. Поэтому сначала нужно понять, нужен ли этот интерфейс вообще, а потом уже выбирать способ блокировки.
Когда XML-RPC действительно стоит отключать
На большинстве обычных сайтов XML-RPC не нужен. Если вы не публикуете записи удалённо и не используете сервисы, которым нужен этот механизм, его можно закрыть. Практический смысл есть в двух случаях: уменьшить поверхность атаки и убрать лишний публичный endpoint, который часто сканируют боты.
Но есть и обратная сторона. Если вы используете Jetpack, приложение WordPress на телефоне или сторонний клиент для публикации, отключение может сломать авторизацию и отправку данных. Поэтому задача не в том, чтобы «выключить всё», а в том, чтобы убрать только лишнее.
Что проверить перед изменениями
- используется ли Jetpack;
- есть ли мобильная публикация через приложение WordPress;
- подключены ли внешние сервисы, которые работают через XML-RPC;
- есть ли в логах запросы к
/xmlrpc.phpс ошибками или частыми попытками подбора пароля.
Диагностика: как понять, нужен ли XML-RPC именно вам
Самый простой способ — посмотреть, отвечает ли endpoint и кто к нему обращается. Если открыть /xmlrpc.php в браузере, WordPress обычно отдаёт сообщение о том, что XML-RPC сервер принимает только POST-запросы. Это не ошибка само по себе, а признак того, что файл доступен извне.
Если есть доступ к логам веб-сервера, проверьте обращения к этому пути. Частые POST-запросы с ошибками авторизации или странными user-agent обычно означают автоматические попытки подбора. Это не доказательство атаки, но хороший повод закрыть endpoint, если он не нужен.
Быстрая проверка через curl
curl -I https://example.com/xmlrpc.phpЕсли сервер отдаёт ответ с кодом 200 или 405, файл доступен. Это нормально для WordPress, но если вы не используете XML-RPC, доступ можно ограничить.
Как отключить XML-RPC: сравнение подходов
| Способ | Когда подходит | Плюсы | Минусы |
|---|---|---|---|
| Плагин безопасности | Если нужен быстрый способ без правки кода | Просто включить, часто есть дополнительные настройки | Лишняя зависимость от плагина |
Код в functions.php или mu-plugin | Если нужен контролируемый и прозрачный вариант | Не добавляет тяжёлых зависимостей | Нужно аккуратно обновлять тему или использовать mu-plugin |
| Блокировка на уровне сервера | Если нужен жёсткий запрет до WordPress | Срезает лишние запросы раньше PHP | Нужно понимать конфиг Apache или Nginx |
Пошаговое решение через код
Если вы хотите отключить XML-RPC без установки дополнительного плагина, удобнее всего сделать это через mu-plugin. Такой файл не зависит от темы и не пропадёт при обновлении.
Вариант 1: полностью отключить XML-RPC
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Создайте файл, например wp-content/mu-plugins/disable-xmlrpc.php. Если папки mu-plugins нет, её можно создать вручную. После этого WordPress перестанет принимать XML-RPC-запросы.
Вариант 2: оставить только часть методов
Если вам нужен не полный запрет, а ограничение отдельных методов, можно фильтровать список доступных методов. Это уже более тонкая настройка, но её стоит использовать только если вы точно понимаете, какой интеграции нужен доступ.
<?php
/**
* Plugin Name: Limit XML-RPC Methods
*/
add_filter( 'xmlrpc_methods', function( $methods ) {
unset( $methods['system.multicall'] );
unset( $methods['pingback.ping'] );
return $methods;
} );Такой подход не выключает XML-RPC целиком, но убирает часть методов, которые часто используют для массовых запросов и pingback-спама. Если у вас нет явной причины сохранять XML-RPC, проще отключить его полностью.
Как закрыть XML-RPC на уровне сервера
Если сайт работает на Apache или Nginx, можно заблокировать доступ к xmlrpc.php ещё до запуска PHP. Это полезно, когда вы хотите уменьшить нагрузку и не отдавать лишний ответ WordPress на каждый запрос.
Apache через .htaccess
<Files xmlrpc.php>
Require all denied
</Files>Этот вариант подходит, если у вас Apache и разрешено использовать .htaccess. После добавления правила запросы к файлу будут получать отказ на уровне веб-сервера.
Nginx
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Для Nginx правило лучше добавлять в конфигурацию сайта, а не в WordPress. Это надёжнее и дешевле по ресурсам, чем блокировка через PHP.
Проверка результата после внедрения
После отключения нужно убедиться, что endpoint действительно недоступен и при этом не сломались нужные интеграции. Проверка должна быть не только визуальной, но и функциональной.
- откройте
/xmlrpc.phpв браузере и проверьте, что доступ закрыт или возвращается ожидаемый ответ; - выполните
curl -I https://example.com/xmlrpc.phpи посмотрите код ответа; - если используется Jetpack или мобильное приложение WordPress, проверьте авторизацию и публикацию;
- посмотрите логи сервера: запросы к
xmlrpc.phpдолжны либо исчезнуть, либо получать отказ.
Если вы отключали XML-RPC через код, дополнительно проверьте админку и фронтенд сайта. Иногда после неаккуратной правки в functions.php ломается не XML-RPC, а весь сайт из-за синтаксической ошибки. Для mu-plugin этот риск ниже, но он всё равно остаётся, если файл написан с ошибкой.
Частые ошибки и как их исправить
Отключили XML-RPC, а Jetpack перестал подключаться
Это ожидаемо. Jetpack использует XML-RPC для части функций. Если он нужен, не блокируйте endpoint полностью. Проверьте, действительно ли Jetpack используется, и если да — ищите более точечное ограничение, а не полный запрет.
Добавили правило в .htaccess, но доступ остался
Чаще всего причина в том, что сайт работает на Nginx, а не Apache, или правило стоит не в том месте. Ещё один вариант — конфигурация сервера игнорирует .htaccess. В таком случае блокировку нужно переносить в конфиг веб-сервера.
Сломали сайт после правки functions.php
Это типичная ошибка, если код вставлен в активную тему и в нём есть синтаксическая проблема. Для таких настроек лучше использовать mu-plugins. Тогда обновление темы не затрёт изменения, а риск случайно повредить шаблон ниже.
Поставили плагин и забыли про него
Плагин безопасности может быть удобен, но он добавляет ещё одну точку отказа и ещё одну сущность для поддержки. Если задача сводится только к отключению XML-RPC, код или серверное правило обычно проще сопровождать.
Практические советы по безопасности и производительности
Отключение XML-RPC не заменяет нормальную защиту входа в админку. Если на сайте слабые пароли, нет ограничений на попытки входа и не обновляются плагины, один закрытый endpoint проблему не решит. Но как часть общей гигиены это полезная мера.
Если вы хотите уменьшить лишний шум в логах и сократить поверхность атаки, сначала проверьте, не нужен ли XML-RPC реальным сценариям. Если не нужен — блокируйте на сервере. Если нужен частично — ограничивайте методы. Если нужен только для редких задач — держите включённым, но следите за логами и доступом.
Для более широкой технической чистки сайта можно смотреть в сторону инструментов вроде Clearfy Pro, если вам нужен набор настроек для удаления дублей и отключения лишнего функционала WordPress. Но и в этом случае важно понимать, что именно вы отключаете, а не просто нажимать все переключатели подряд.
