Как отключить xmlrpc.php в WordPress и не сломать сайт

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

Но отключать его «в лоб» тоже не стоит. Если на сайте есть Jetpack, сторонний сервис автопостинга или старая интеграция, можно сломать отправку контента, синхронизацию или удаленное управление. Поэтому сначала стоит понять, используется ли endpoint вообще, а уже потом выбирать способ блокировки.

Когда xmlrpc.php действительно стоит отключать

Сценарий обычно один и тот же: в логах появляются запросы к /xmlrpc.php, иногда с попытками подбора логина и пароля, а сам сайт не использует XML-RPC-функции. Для большинства современных проектов это нормальная ситуация: публикация через REST API, мобильные приложения и интеграции давно ушли в другие механизмы.

Отключение особенно уместно, если:

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

Диагностика: используется ли XML-RPC на вашем сайте

Перед блокировкой проверьте, нет ли завязанных на XML-RPC сервисов. Самый простой способ — посмотреть, кто обращается к endpoint, и протестировать ответ напрямую.

Проверка ответа сервера

Если открыть https://example.com/xmlrpc.php в браузере, WordPress обычно отвечает сообщением о том, что XML-RPC сервер принимает только POST-запросы. Это еще не значит, что он нужен, но подтверждает, что файл доступен.

Более полезна проверка через curl:

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

Если сервер отдает 200 или 405, endpoint существует и доступен. После корректной блокировки вы должны увидеть 403 или другой отказ на уровне сервера.

Что проверить в админке и интеграциях

Перед изменениями пройдитесь по списку:

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

Если ничего из этого не используется, отключение обычно безопасно.

Как отключить xmlrpc.php: три рабочих подхода

Есть три нормальных варианта: через код, через веб-сервер и через плагин безопасности. Выбор зависит от того, есть ли доступ к конфигу сервера и насколько вам важно закрыть endpoint именно на уровне HTTP, а не только внутри WordPress.

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

Если нужен быстрый и понятный вариант, добавьте фильтр в functions.php дочерней темы или, лучше, в небольшой mu-plugin. Так решение не потеряется при смене темы.

<?php
add_filter( 'xmlrpc_enabled', '__return_false' );

Это отключает XML-RPC на уровне WordPress. Запросы к xmlrpc.php будут попадать в систему, но сам функционал перестанет работать.

Если вы предпочитаете mu-plugin, создайте файл, например wp-content/mu-plugins/disable-xmlrpc.php:

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

Способ 2. Закрыть xmlrpc.php на уровне nginx

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

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

После правки конфигурации не забудьте проверить синтаксис и перезагрузить nginx. Если у вас несколько сайтов на одном сервере, правило должно попасть именно в нужный server-блок.

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

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

Для небольших проектов это удобно, но на продакшене я бы все равно предпочел серверное правило или mu-plugin: они прозрачнее и меньше зависят от интерфейса админки.

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

1. Проверьте, не используются ли интеграции, завязанные на XML-RPC.
2. Выберите способ блокировки: код, сервер или плагин.
3. Внедрите одно правило, а не несколько одновременно.
4. Очистите кеш сайта и, если есть, кеш на уровне CDN.
5. Проверьте ответ /xmlrpc.php снаружи.

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

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

После внедрения решения проверьте три вещи: HTTP-статус, поведение WordPress и отсутствие побочных эффектов в интеграциях.

Проверка через curl

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

Ожидаемый результат после блокировки на сервере — 403 Forbidden или похожий отказ. Если вы отключали только через фильтр WordPress, сервер может по-прежнему отдавать ответ, но XML-RPC-функции внутри WordPress будут недоступны.

Проверка в админке

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

Что смотреть в логах

После блокировки в access log должно стать меньше обращений к /xmlrpc.php. Это не мгновенный индикатор безопасности, но хороший практический сигнал: endpoint перестал быть точкой входа для случайных и автоматических запросов.

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

• Отключили XML-RPC, а Jetpack перестал синхронизироваться. Значит, модуль или сервис реально использовал этот протокол. Верните доступ и перенесите интеграцию на другой способ, если он поддерживается.
• Добавили правило в functions.php, но endpoint все равно отвечает. Фильтр отключает функциональность WordPress, но не блокирует сам файл на уровне веб-сервера.
• Закрыли доступ в nginx, но забыли проверить Apache или CDN. Если перед сайтом стоит прокси или CDN, запрос может обрабатываться не там, где вы ожидаете. Проверяйте весь путь запроса.
• Включили несколько решений сразу и не понимаете, что сработало. Оставьте один способ, иначе диагностика станет бессмысленной.

Безопасность и производительность: что важно не упустить

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

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

Для проектов, где важна техническая чистота, удобно держать такие изменения в mu-plugins или в конфигурации сервера, а не в активной теме. Так решение не исчезнет после обновления шаблона и не будет зависеть от редакторских правок.

Когда XML-RPC лучше не отключать

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

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