Как отключить XML-RPC в WordPress через функции и .htaccess без лишних рисков

Автор: Степан Панин | Опубликовано: 25.08.2026

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

Когда XML-RPC действительно можно отключать

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

Что именно стоит проверить перед отключением

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

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

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

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

Если вы видите ответ с кодом 200, это ещё не означает, что XML-RPC реально нужен. Это лишь значит, что файл доступен. Для диагностики полезнее искать обращения в access.log. Например, на nginx:

grep "xmlrpc.php" /var/log/nginx/access.log

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

Способы отключения: код, .htaccess и серверная блокировка

Есть три рабочих варианта. Выбор зависит от того, что у вас под контролем: тема, mu-plugin, обычный плагин или конфигурация веб-сервера. Для большинства сайтов удобнее начать с кода, потому что его проще откатить. Серверная блокировка жёстче и надёжнее, но требует аккуратности.

Способ	Когда подходит	Плюс	Минус
Фильтр в WordPress	Нужен быстрый и обратимый вариант	Легко включить и выключить	Файл всё ещё доступен на уровне сервера
.htaccess / nginx	Нужно закрыть доступ до загрузки WordPress	Надёжнее против лишних запросов	Требует доступа к конфигу
Плагин безопасности	Нужна настройка без правки кода	Удобно для редактора	Зависимость от плагина

Вариант 1: отключить XML-RPC через код

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

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

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

Вариант 2: закрыть `xmlrpc.php` через Apache

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

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

Этот фрагмент лучше добавлять выше стандартного блока WordPress, чтобы правило сработало гарантированно. Если у вас старый Apache 2.2, синтаксис будет другим, но на современных установках используется именно Require all denied.

Вариант 3: блокировка на nginx

На nginx правильнее закрывать доступ в конфиге виртуального хоста. Это не WordPress-решение, но оно надёжнее и не создаёт лишнюю нагрузку.

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

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

Пошаговое решение для типового сайта

Если нужен безопасный и управляемый сценарий, я бы делал так:

Проверить access.log и убедиться, что легитимных обращений к xmlrpc.php нет.
Добавить фильтр xmlrpc_enabled в дочернюю тему или mu-plugin.
Если есть доступ к серверу, дополнительно закрыть файл на уровне Apache/nginx.
После этого проверить, не сломались ли внешние интеграции.

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

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

Такой вариант удобен, если вы часто меняете тему и не хотите терять настройку при обновлениях.

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

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

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

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

Чек-лист после внедрения

Страница /xmlrpc.php не отвечает как рабочий endpoint.
В access.log нет новых обращений от ваших сервисов.
Админка WordPress открывается без ошибок.
Публикация записей из обычного редактора работает.
Сторонние интеграции не зависят от XML-RPC.

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

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

Значит, приложение или сервис всё ещё использует XML-RPC. Решение простое: либо вернуть доступ, либо перевести интеграцию на REST API, если это поддерживается.

Добавили правило в `.htaccess`, но файл всё равно открывается

Чаще всего правило стоит не в том месте, либо сайт работает не на Apache. Если у вас nginx или прокси перед Apache, блокировать нужно на том уровне, который реально обслуживает запрос.

Сайт начал отдавать 500 после правки конфигурации

Это почти всегда синтаксическая ошибка в конфиге. Сначала откатите последнее изменение, затем проверьте файл через apachectl configtest или nginx -t — в зависимости от сервера.

Отключили XML-RPC через код, но бот-сканер всё равно стучится в файл

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

Безопасность и производительность: что ещё имеет смысл сделать

Отключение XML-RPC само по себе не заменяет базовую защиту сайта. Если у вас уже есть регулярные сканирования, имеет смысл параллельно проверить, не открыт ли wp-login.php для грубого перебора, не включён ли лишний доступ к REST-эндпоинтам и нет ли старых плагинов с уязвимостями. Для чистки дублей, лишних мета-тегов и технического мусора иногда удобнее использовать специализированные инструменты вроде Clearfy Pro, но только если вы понимаете, что именно отключаете и зачем.

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

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

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