XML-RPC в WordPress часто отключают «на всякий случай», а потом внезапно перестают работать мобильное приложение, старые сервисы публикации или удалённые подключения. Проблема не в самом файле xmlrpc.php, а в том, что его выключают без проверки, кто именно им пользуется.
Если задача — снизить поверхность атаки и убрать лишний входной канал, отключать XML-RPC имеет смысл. Но делать это лучше после диагностики: сначала понять, нужен ли он вообще вашему сайту, затем выбрать способ отключения и только потом проверить, что ничего не отвалилось.
Когда XML-RPC действительно можно отключать
На большинстве современных сайтов XML-RPC уже не нужен. Если вы не используете старые десктопные клиенты, внешние сервисы автопубликации или интеграции, завязанные именно на этот протокол, файл xmlrpc.php можно закрыть без заметного ущерба для обычной работы сайта.
Типичный сценарий: сайт управляется через админку WordPress, контент публикуется вручную, мобильное приложение WordPress не используется, а внешние интеграции работают через REST API или вебхуки. В таком случае XML-RPC — это лишняя точка входа, которую лучше убрать.
Что обычно ломается после отключения
Чаще всего страдают не «современные» интеграции, а старые или редкие сценарии:
- мобильное приложение WordPress на старых схемах подключения;
- десктопные клиенты для публикации постов;
- сервисы, которые отправляют записи через XML-RPC, а не через REST API;
- некоторые плагины для удалённой публикации или синхронизации.
Если у вас есть сомнения, сначала проверьте логи и список подключений, а не отключайте доступ вслепую.
Диагностика: как понять, используется ли xmlrpc.php
Самый практичный способ — посмотреть обращения к /xmlrpc.php в логах веб-сервера или в логах безопасности. Если запросы идут только от ботов с перебором паролей, это аргумент в пользу отключения. Если видны обращения от ваших сервисов или IP партнёров, сначала разберитесь с ними.
Если доступа к логам нет, можно временно посмотреть, кто стучится в файл, через простую проверку на уровне сервера. Для Apache и Nginx это делается по-разному, но смысл один: найти реальные обращения к xmlrpc.php, а не гадать по ощущениям.
# Пример для поиска обращений в access.log на сервере Linux
# Путь к логам зависит от конфигурации хостинга
grep "xmlrpc.php" /var/log/nginx/access.log
Если вы видите только массовые попытки авторизации, а не легитимные запросы, отключение XML-RPC обычно безопасно. Но если есть интеграции, которые вы не хотите терять, лучше сначала перевести их на REST API или другой способ авторизации.
Как отключить XML-RPC: три рабочих варианта
Есть несколько способов закрыть XML-RPC. Выбор зависит от того, как у вас устроен сайт и есть ли доступ к серверной конфигурации.
| Способ | Когда использовать | Плюсы | Минусы |
|---|---|---|---|
| Через плагин безопасности | Если нужен быстрый и управляемый способ | Не требует правок кода, легко откатить | Добавляет зависимость от плагина |
| Через functions.php или mu-plugin | Если нужен точечный контроль | Минимум лишнего, работает предсказуемо | Нужно аккуратно править код |
| На уровне сервера | Если есть доступ к конфигу Nginx/Apache | Запросы режутся до WordPress | Требует доступа к серверу и понимания конфигурации |
Вариант 1: отключение через код
Если вы хотите убрать XML-RPC без лишних плагинов, используйте фильтр xmlrpc_enabled. Это самый понятный способ для проекта, где вы контролируете тему или mu-plugin.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );
Лучше размещать такой код не в теме, а в небольшом mu-plugin, чтобы он не исчез при смене темы. Это особенно важно на рабочих сайтах, где изменения в теме не должны влиять на безопасность.
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );
Вариант 2: блокировка на уровне веб-сервера
Если у вас Nginx, можно закрыть доступ к xmlrpc.php на уровне конфигурации. Это полезно, когда нужно отсечь запросы до того, как они попадут в WordPress и начнут нагружать PHP.
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}
Для Apache обычно используют правила в .htaccess, но на shared-хостинге это не всегда лучший путь: не все конфигурации одинаково предсказуемы, а лишние правила иногда конфликтуют с другими модулями.
Вариант 3: плагин безопасности
Если на сайте уже стоит плагин безопасности, проверьте, умеет ли он отключать XML-RPC штатно. Это удобно, когда вы не хотите держать отдельный кусок кода ради одной настройки. Но не ставьте новый плагин только ради этой функции, если задача решается проще.
Пошаговое решение без лишнего риска
- Проверьте логи и убедитесь, что XML-RPC не используется легитимными сервисами.
- Если есть сомнения, временно ограничьте доступ только для своих IP или тестовой среды.
- Выберите способ отключения: код, сервер или существующий плагин безопасности.
- Внесите изменение сначала на staging-сайте.
- Проверьте, не сломались ли публикации, удалённые интеграции и мобильные клиенты.
- После успешной проверки перенесите изменение на продакшен.
Если сайт большой, не меняйте сразу всё. Сначала отключите XML-RPC на копии, затем проверьте журналы ошибок и только после этого переносите настройку на боевой домен.
Как проверить, что отключение сработало
Проверка должна быть не «страница открывается», а именно контроль ответа на xmlrpc.php. Самый простой тест — отправить запрос и посмотреть, что сервер больше не принимает XML-RPC как рабочую точку входа.
curl -i https://example.com/xmlrpc.php
Если всё отключено корректно, вы не должны получать нормальный рабочий ответ для XML-RPC. В зависимости от способа блокировки это может быть 403 Forbidden, 404 Not Found или другой отказ в доступе. Главное — чтобы внешний вызов не проходил как раньше.
Дополнительно проверьте:
- вход в админку WordPress;
- публикацию записей вручную;
- работу REST API, если он используется;
- внешние сервисы, которые должны были остаться рабочими;
- отсутствие новых ошибок в логах после изменения.
Частые ошибки и как их исправить
Отключили XML-RPC, а потом перестала работать интеграция
Значит, интеграция действительно зависела от XML-RPC. Решение — либо вернуть доступ только для нужного сервиса, либо перевести интеграцию на REST API, если это поддерживается.
Поставили плагин, но файл всё равно отвечает
Некоторые плагины отключают только функциональность внутри WordPress, но не режут сам запрос на уровне сервера. В этом случае бот всё равно достучится до xmlrpc.php, даже если обработка будет заглушена. Для снижения нагрузки лучше блокировать запросы на уровне веб-сервера.
Добавили код в тему и забыли про него
Это плохая практика для технических ограничений. При смене темы защита исчезнет. Для таких задач используйте mu-plugin или обычный плагин, который не зависит от темы.
Сразу закрыли доступ без проверки логов
Так часто ломают старые рабочие сценарии и потом долго ищут причину. Сначала диагностика, потом блокировка. Это экономит время и снижает риск простоя.
Что учесть по безопасности и производительности
Отключение XML-RPC не заменяет базовую защиту сайта. Если у вас слабые пароли, нет ограничений на вход и не настроена двухфакторная аутентификация, закрытие одного файла не решит проблему полностью. Но как часть общей гигиены это полезный шаг.
С точки зрения производительности выгода обычно не в «ускорении сайта», а в уменьшении лишних запросов и попыток перебора. Если бот регулярно долбит xmlrpc.php, сервер тратит ресурсы на обработку мусора. Блокировка на уровне Nginx или Apache помогает отсечь это раньше, чем запрос дойдёт до PHP.
Если вам нужен более широкий набор технических чисток и отключений лишнего в WordPress, такие задачи часто закрывают инструментами уровня Clearfy Pro, но сам принцип остаётся тем же: сначала понять, что именно используется, потом отключать лишнее точечно, а не «всё подряд».
Мини-чек-лист перед выкладкой на продакшен
- Проверены логи запросов к
xmlrpc.php. - Известно, какие сервисы завязаны на XML-RPC.
- Выбран способ отключения, который можно быстро откатить.
- Изменение протестировано на staging.
- После отключения проверены вход в админку, публикации и внешние интеграции.
- В логах нет новых ошибок, связанных с блокировкой.
Если после отключения ничего не сломалось, значит, вы убрали лишний канал без побочных эффектов. Если что-то перестало работать, проблема не в самом решении, а в том, что зависимость не была найдена заранее. В таких случаях лучше не возвращать XML-RPC целиком, а точечно пересобрать интеграцию на более современный способ подключения.