Как закрыть xmlrpc.php в WordPress и не сломать нужные интеграции

Автор: Тимур Никитин | Опубликовано: 27.09.2026

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

Ниже — рабочая схема: как понять, нужен ли вам xmlrpc.php, как закрыть его без лишних поломок и как проверить, что всё действительно работает так, как вы ожидаете.

Когда xmlrpc.php лучше закрыть

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

Оставлять его открытым имеет смысл только тогда, когда вы точно знаете, зачем он нужен. Типичные причины:

подключение старого мобильного приложения WordPress;
публикация через внешние редакторы, которые не умеют REST API;
интеграции с сервисами, где явно указан XML-RPC как обязательный протокол;
исторически настроенные pingback/trackback, которые вы ещё не перевели на другие механики.

Что именно даёт риск

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

Диагностика: нужен ли вам XML-RPC сейчас

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

Быстрая проверка вручную

Откройте /xmlrpc.php в браузере. Если файл доступен, WordPress обычно отвечает сообщением о том, что XML-RPC сервер принимает только POST-запросы.
Проверьте, используете ли вы мобильное приложение WordPress, Jetpack или сторонний сервис публикации.
Посмотрите логи веб-сервера на предмет частых обращений к xmlrpc.php и подозрительных POST-запросов.
Если у вас есть интеграции с внешними системами, найдите в их настройках упоминание XML-RPC, pingback или trackback.

Что проверить в админке и на сервере

Полезно посмотреть, не включены ли старые механизмы обратных ссылок. В WordPress это не всегда очевидно, потому что часть настроек живёт в теме, часть — в плагинах, а часть — в исторических данных сайта. Если у вас есть плагин для технической чистки, например Clearfy Pro, там обычно проще найти связанные с безопасностью и дублями настройки, чем вручную вылавливать всё по отдельности.

Подход	Что даёт	Ограничения
Оставить как есть	Ничего не ломает сразу	Сохраняет лишнюю поверхность атаки
Отключить через код	Контроль на уровне сайта	Нужно понимать, где и как это внедрено
Закрыть на уровне сервера	Быстро режет доступ до WordPress	Можно случайно заблокировать нужный сервис

Как отключить xmlrpc.php в WordPress

Есть два нормальных пути: через код и через серверную конфигурацию. Если вам нужен управляемый вариант внутри WordPress, используйте фильтр xmlrpc_enabled. Если задача — просто закрыть доступ ко всем запросам, можно блокировать сам файл на уровне веб-сервера.

Вариант 1: отключить XML-RPC через functions.php или mu-plugin

Этот способ удобен, если вы хотите оставить управление внутри WordPress и при необходимости быстро вернуть всё назад. Лучше использовать mu-plugin, чтобы настройка не зависела от темы.

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

Если нужен более явный контроль, можно добавить проверку и не отключать XML-RPC на staging-копии, где вы тестируете старые интеграции:

<?php
add_filter( 'xmlrpc_enabled', function( $enabled ) {
	if ( defined( 'WP_ENVIRONMENT_TYPE' ) && WP_ENVIRONMENT_TYPE === 'staging' ) {
		return $enabled;
	}

	return false;
} );

Такой вариант не требует правок сервера и легко откатывается. Но он не защитит от запросов, которые даже не доходят до WordPress, если у вас есть отдельные правила на уровне nginx или Apache.

Вариант 2: закрыть xmlrpc.php на сервере

Если вы уверены, что XML-RPC не нужен вообще, можно заблокировать файл раньше, чем WordPress начнёт его обрабатывать. Это полезно на сайтах с повышенной нагрузкой или когда вы хотите минимизировать лишние запросы.

Для nginx:

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

Для Apache в .htaccess:

<Files xmlrpc.php>
	Require all denied
</Files>

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

Пошаговое решение без лишних поломок

Составьте список всех внешних интеграций: мобильные клиенты, сервисы автопостинга, старые плагины синхронизации.
Проверьте, есть ли обращения к xmlrpc.php в логах за последние дни.
На staging-сайте отключите XML-RPC через фильтр xmlrpc_enabled и протестируйте публикацию, авторизацию и внешние запросы.
Если всё работает, перенесите изменение на production.
При необходимости добавьте серверную блокировку, чтобы закрыть доступ раньше WordPress.

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

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

Проверка должна быть не только визуальной. После отключения откройте /xmlrpc.php напрямую и посмотрите ответ сервера. В нормальном сценарии вы должны увидеть отказ в доступе или отсутствие ответа, а не стандартное сообщение WordPress о том, что XML-RPC доступен только через POST.

Дальше проверьте рабочие сценарии:

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

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

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

Отключили XML-RPC, но забыли про нужный сервис

Это самая неприятная ситуация: сайт формально защищён, но редактор на телефоне или внешний автопостинг перестал работать. Исправление простое — вернуть доступ временно, проверить логи и найти конкретную интеграцию. После этого решать, чем её заменить.

Блокируют не только xmlrpc.php, но и лишние URL

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

Дублируют защиту в плагине и на сервере без понимания порядка обработки

Если плагин безопасности уже отключил XML-RPC, а вы сверху добавили ещё и жёсткий deny в nginx, при отладке будет сложно понять, где именно сработала блокировка. Для поддержки это неудобно. Лучше зафиксировать один основной способ и отдельно документировать второй как резервный.

Считают, что отключение XML-RPC заменяет нормальную защиту входа

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

Практические советы по безопасности и производительности

Если вы закрываете xmlrpc.php именно ради безопасности, проверьте соседние настройки:

уберите неиспользуемые плагины, которые добавляют внешние точки входа;
обновите ядро, тему и активные плагины;
ограничьте попытки входа в админку;
проверьте, не включены ли старые trackback/pingback, если они вам не нужны;
посмотрите, нет ли в логах регулярных запросов к xmlrpc.php с одного и того же IP.

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

Главная идея простая: отключайте XML-RPC только после проверки реальных сценариев использования. Тогда вы уберёте лишнюю точку риска и не потеряете нужные интеграции.