Игорь ведёт салон и правит акции с телефона. Хостинг прислал письмо о брутфорсе: сотни POST на /xmlrpc.php, будто долбят пароль к админке. В поиске он нашёл «удалите xmlrpc.php», но вспомнил приложение WordPress. Хочется закрыть атаку, не сломав вход, Jetpack и заявки с сайта. Ниже — за 20-30 минут понять, нужен ли XML-RPC, выбрать один способ отключения и проверить результат по логам и открытию xmlrpc.php.
xmlrpc.php — это старый «удалённый вход» в WordPress: через него когда-то публиковали с телефона и связывали Jetpack. Боты любят его за усиление атаки: в одном запросе можно перебрать сотни паролей (метод system.multicall). Официальный фильтр xmlrpc_enabled в PHP отключает не весь файл, а в основном методы с авторизацией; pingback и часть вызовов могут остаться. Файл не удаляют — его вернёт обновление ядра. Безопаснее: mu-plugin, правило на хостинге или плагин из каталога, плюс проверка до и после.
Если путаете XML-RPC с REST API — вы не одиноки. /wp-json/ — канал блоков и многих приложений; /xmlrpc.php — отдельная дверь с версии 3.5 без галочки в настройках. На неё смотрят боты, когда в логах сыпятся POST на xmlrpc.php.
- Разберите, что открывает xmlrpc.php и чем он отличается от wp-json
- Пройдите чек-лист за пять минут: можно ли отключать XML-RPC полностью
- Выберите способ A: mu-plugin без правки темы (фильтр и отсечение multicall)
- Настройте способ B на хостинге: deny для ботов и allowlist для Jetpack
- Подключите способ C: плагин из каталога WordPress, если к коду не лезете
- Проверьте результат и поймите, что сработало
- Частые вопросы
- Можно ли просто удалить xmlrpc.php из папки сайта?
- Чем xmlrpc.php отличается от REST API wp-json?
- Достаточно ли одной строки add_filter( ‘xmlrpc_enabled’, ‘__return_false’ )?
- Сломает ли отключение XML-RPC форму заявок на сайте?
- Нужен ли Jetpack для мобильного приложения WordPress?
- Как оставить Jetpack и закрыть xmlrpc.php для всего мира?
- Что должно измениться в логах после успешного отключения?
Разберите, что открывает xmlrpc.php и чем он отличается от wp-json
Это задний служебный вход: витрина для клиентов — обычный сайт, а xmlrpc.php нужен был приложению и Jetpack. Через него удалённо вызывали методы WordPress, в том числе проверку логина и пароля администратора.
/wp-json/ — другой протокол. Приложения в 2025-2026 чаще живут на REST и пароле приложения, но Jetpack всё ещё стучится в xmlrpc.php. Файл в корне отвечает на POST; в браузере бывает текст «XML-RPC server accepts POST requests only» — для Jetpack это норма.
Атаки опаснее перебора на wp-login.php: в одном запросе упаковывают сотни попыток входа (multicall). Sucuri и Cloudflare описывают это как усиление брутфорса. Вы закрываете способ массово проверять пароли, а не «лишнюю страницу».
Пройдите чек-лист за пять минут: можно ли отключать XML-RPC полностью
Перед правкой зафиксируйте зависимости. Салону часто хватает админки в браузере — XML-RPC режут жёстко. Если стоят Jetpack или публикация с телефона — сначала тест, потом блокировка.
- Шаг 1. Откройте в браузере https://ваш-домен/xmlrpc.php. Запомните ответ до правок: живой endpoint, отказ или уже 403.
- Шаг 2. В админке посмотрите активные плагины: Jetpack, автопостинг в соцсети, старые интеграции — часто тянут XML-RPC.
- Шаг 3. На хостинге или в плагине безопасности найдите логи: сколько POST на /xmlrpc.php за сутки. Это мотивация и база «до».
- Шаг 4. С телефона сделайте тестовый черновик или просмотр ленты в приложении WordPress — запишите, работает ли сейчас.
- Шаг 5. Решите ветку: полное отключение, только срез multicall/pingback или компромисс «Jetpack жив, мир закрыт» через allowlist IP Automattic (диапазон 192.0.64.0/18).
Security guide WordPress.org: не нужен — отключите; нужен — ограничьте и следите за частотой запросов. Ниже один способ, а не десять строк с форума.
Выберите способ A: mu-plugin без правки темы (фильтр и отсечение multicall)
mu-plugin лежит в wp-content/mu-plugins/, тема его не сотрёт. Удалили файл — откат за минуту.
Фильтр из документации WordPress отключает методы с авторизацией:
add_filter( ‘xmlrpc_enabled’, ‘__return_false’ );
Одной строки мало: pingback может остаться. Stack Exchange советует убрать system.multicall и pingback.ping:
add_filter( ‘xmlrpc_methods’, function ( $methods ) {
unset( $methods[‘system.multicall’] );
unset( $methods[‘pingback.ping’] );
return $methods;
} );
Workflow: папка mu-plugins на хостинге → файл disable-xmlrpc.php с фильтрами → сохранить → открыть /xmlrpc.php → проверить wp-login.php и приложение. На практике хостинги вроде Hostinger в tutorial 2026 тоже советуют резать legacy API, если вы не пользуетесь удалённой публикацией — смысл тот же: меньше дверей для ботов.
Настройте способ B на хостинге: deny для ботов и allowlist для Jetpack
На nginx или Apache можно запретить /xmlrpc.php одним правилом. Плагин littlebizzy/disable-xml-rpc на GitHub отдаёт 403 — видно в браузере.
С Jetpack часто делают allowlist: xmlrpc.php только для 192.0.64.0/18 (Automattic), остальным deny. Полная блокировка рвёт связь Jetpack, пока не откроете диапазон.
| Способ | Что реально режет | Jetpack / приложение | Откат |
|---|---|---|---|
| Только xmlrpc_enabled | Авторизованные методы; не весь endpoint | Часто ломает старый вход в приложении | Удалить строку из mu-plugin |
| xmlrpc_methods + multicall off | Усилитель атак и pingback | Зависит от сценария; тест обязателен | Убрать unset из mu-plugin |
| 403 на сервере / плагин | Весь файл для клиента | Jetpack — только с allowlist IP | Отключить правило или плагин |
| Удалить xmlrpc.php | Ненадёжно | Риск поломки; файл вернётся при обновлении ядра | Не использовать |
Вердикт: не удаляйте файл. Для салона без Jetpack чаще хватает mu-plugin или плагина Disable XML-RPC-API из каталога ru.wordpress.org. Для Jetpack планируйте allowlist, а не «одну волшебную строку».
Подключите способ C: плагин из каталога WordPress, если к коду не лезете
Без кода — плагин Disable XML-RPC-API из ru.wordpress.org. После активации /xmlrpc.php должен дать 403 или понятный текст об отключении сервиса.
Типичная ошибка — не сверить логи через сутки. Успех — меньше POST на xmlrpc.php при рабочем wp-login.php и заявках на сайте.
Проверьте результат и поймите, что сработало
Критерии успеха из практики владельцев сайтов:
- В логах меньше частых или успешных POST на /xmlrpc.php.
- Открытие /xmlrpc.php в браузере после блокировки даёт 403, запрет или fault «disabled», а не рабочий приём POST для ботов.
- Вход через wp-login.php и обычная публикация из админки работают.
- Если нужно приложение — тестовый пост или лента проходят, либо вы переходите на пароль приложения и REST (в релизах WordPress iOS на GitHub есть ограниченный режим без XML-RPC).
Сломалось — отключите mu-plugin, снимите правило или плагин. Рядом по безопасности: двухфакторная защита и запрет редактора в админке.
Некогда копаться в логах — услуги по WordPress и SEO. Вопросы — контакты в мессенджер. Ещё гайды — статьи, канал t.me/DikiiTelegram.
Материал проверен: Андрей Дикий (создаёт сайты и продвигает их статьями, SEO/GEO).
Источники и сверка: developer.wordpress.org (xmlrpc_enabled, wp_xmlrpc_server, brute-force hardening); jetpack.com (XML-RPC и проверка соединения); blog.sucuri.net и blog.cloudflare.com (multicall amplification); wordpress.stackexchange.com (eliminate xmlrpc); GitHub WordPress-iOS releases (поведение приложения); ru.wordpress.org/plugins/disable-xml-rpc-api/; rtfm.wiki (allowlist 192.0.64.0/18). Частотность запросов: Яндекс Вордстат, прогон 2026-10-03 (MCP недоступен, точные показы не верифицированы).
Частые вопросы
Можно ли просто удалить xmlrpc.php из папки сайта?
Нет. При обновлении ядра WordPress файл вернётся, а ручное удаление не учит систему безопасно отключать методы. Используйте фильтр, mu-plugin, правило сервера или плагин из каталога.
Чем xmlrpc.php отличается от REST API wp-json?
Это два разных входа. REST по /wp-json/ питает блоки, многие современные интеграции и пароли приложений. xmlrpc.php — legacy-канал для старых удалённых вызовов и Jetpack. Путаница мешает понять, что именно вы закрываете в логах.
Достаточно ли одной строки add_filter( ‘xmlrpc_enabled’, ‘__return_false’ )?
Часто для среза авторизованных методов — да, но не для полного спокойствия: pingback и отдельные вызовы могут остаться. Для атак multicall добавьте отключение system.multicall через xmlrpc_methods или серверный deny.
Сломает ли отключение XML-RPC форму заявок на сайте?
Обычно нет: формы на Contact Form 7, WPForms и аналогах ходят на свои обработчики, не в xmlrpc.php. Если форма перестала работать после правок — ищите другой плагин или кеш, а не связь с XML-RPC.
Нужен ли Jetpack для мобильного приложения WordPress?
Для self-hosted Jetpack не обязателен для Android, но отключение XML-RPC может урезать медиа и старые сценарии входа. Сделайте тестовый пост до и после блокировки; при необходимости настройте пароль приложения в профиле пользователя WordPress.
Как оставить Jetpack и закрыть xmlrpc.php для всего мира?
Разрешите доступ к /xmlrpc.php только с диапазона 192.0.64.0/18 (Automattic), остальным IP — запрет на уровне nginx или Apache. Jetpack документирует зависимость от доступного endpoint.
Что должно измениться в логах после успешного отключения?
Число POST на /xmlrpc.php падает или ответы 403/disabled. wp-login.php и админка работают. Сохраните выгрузку логов «до» и «после» — хостингу проще закрыть тикет, когда видно, что шум ушёл, а сайт для клиентов не лёг.
