На VDS WordPress часто страдает не от «взлома в лоб», а от мелких, но постоянных вещей: боты долбят xmlrpc.php, идут попытки входа в админку, в логах копятся 404 на служебные пути, а сайт при этом продолжает нормально работать только до первой ошибки в конфиге. Если задача — не «сделать всё максимально закрытым», а убрать лишние точки входа без побочных эффектов, лучше идти по шагам и проверять каждый.
Когда это действительно нужно
Сценарий типичный для сайтов на отдельном сервере или VDS:
- в логах Nginx/Apache много запросов к
/xmlrpc.php; - в админке видны регулярные попытки входа с разных IP;
- нужна защита от индексации служебных страниц, но сайт уже открыт для поисковиков;
- после переноса на VDS хочется убрать лишние поверхности атаки, не ломая REST API, мобильные приложения и внешние интеграции.
Важно не смешивать разные задачи. Закрытие от индексации, отключение XML-RPC и ограничение brute force — это три разных изменения. Их можно внедрять отдельно и откатывать тоже отдельно.
Диагностика: что именно у вас сейчас открыто
Сначала проверьте, какие точки реально используются. Это экономит время и помогает не отключить то, что нужно сайту.
Проверка индексации служебных страниц
Посмотрите, не попали ли в индекс служебные URL:
/wp-login.php;/wp-admin/;/xmlrpc.php;- страницы поиска с пустыми запросами;
- архивы автора, если они не нужны.
Проверка простая: в поиске используйте site:example.ru wp-login или посмотрите отчёт по страницам в Google Search Console. Если служебные URL уже в индексе, сначала закройте их от индексации, а потом дождитесь переобхода.
Проверка XML-RPC
Если XML-RPC не нужен, его обычно можно отключить. Но сначала убедитесь, что вы не используете:
- старые мобильные клиенты WordPress;
- Jetpack в режимах, где он опирается на XML-RPC;
- внешние сервисы публикации, которые работают через XML-RPC;
- синхронизацию с некоторыми десктопными редакторами.
Если не уверены, проверьте запрос вручную:
curl -I https://example.ru/xmlrpc.phpОтвет 200 OK сам по себе ещё не означает проблему, но если этот путь активно сканируют, его имеет смысл закрыть или ограничить.
Проверка brute force
Посмотрите логи авторизации и веб-сервера. Если видите повторяющиеся POST-запросы к /wp-login.php с одинаковыми или меняющимися логинами, это уже не «шум», а перебор. На VDS это особенно заметно: сервер не падает, но нагрузка и мусор в логах растут.
Что делать: пошаговая настройка без лишних рисков
1. Закройте сайт от индексации только там, где это нужно
Если речь о продакшене, не трогайте весь сайт ради одной служебной страницы. Для WordPress правильнее убрать из индекса конкретные URL через robots.txt и мета-теги, а не ставить глобальные запреты на всё подряд.
Для служебных страниц можно добавить правило в robots.txt, если оно ещё не конфликтует с вашей схемой индексации:
User-agent: *
Disallow: /wp-admin/
Disallow: /wp-login.php
Disallow: /xmlrpc.phpНо помните: robots.txt не защищает от доступа, он только просит поисковики не сканировать. Для реальной защиты нужны серверные ограничения.
2. Отключите XML-RPC, если он не нужен
Самый безопасный способ — отключить обработку на уровне WordPress. Вставьте код в functions.php дочерней темы или в небольшой mu-plugin, если не хотите зависеть от темы:
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Если нужен более жёсткий вариант, можно возвращать 403 на уровне веб-сервера. Для Nginx это делается отдельным location-блоком:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Такой вариант уменьшает шум в логах и не отдаёт лишнюю обработку PHP. Но используйте его только если уверены, что XML-RPC не нужен ни одному сервису.
3. Ограничьте попытки входа в админку
Для brute force лучше комбинировать несколько мер. Одна мера редко даёт достаточный эффект, а вот связка работает заметно стабильнее:
- сменить стандартный логин администратора, если он слишком очевидный;
- включить двухфакторную аутентификацию через проверенный плагин;
- ограничить доступ к
/wp-login.phpпо IP, если у вас фиксированный офисный адрес или VPN; - добавить rate limit на уровне Nginx;
- использовать CAPTCHA только там, где она не ломает UX.
Пример простого ограничения по количеству запросов в Nginx:
http {
limit_req_zone $binary_remote_addr zone=login_limit:10m rate=5r/m;
}
server {
location = /wp-login.php {
limit_req zone=login_limit burst=10 nodelay;
include fastcgi_params;
fastcgi_pass unix:/run/php/php8.2-fpm.sock;
}
}Это не блокирует вход полностью, а режет частоту запросов. Для реального использования проверьте, не мешает ли это вашим пользователям при повторных попытках входа.
4. Спрячьте лишние подсказки в админке и на фронте
Если задача ещё и в уменьшении информационного шума, можно убрать генератор версии WordPress, отключить эмодзи-скрипты и лишние REST-эндпоинты, которые не используются. Но здесь важно не переусердствовать: REST API нужен многим плагинам и редактору блоков.
Минимальный безопасный набор для чистки обычно такой:
<?php
remove_action( 'wp_head', 'wp_generator' );
remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
remove_action( 'wp_print_styles', 'print_emoji_styles' );Это не защита от атак, а уменьшение лишних следов. Используйте как дополнение, а не как основную меру.
Сравнение подходов: плагин, код или сервер
| Подход | Что решает | Плюсы | Минусы |
|---|---|---|---|
| Плагин безопасности | 2FA, лимиты входа, журнал событий | Быстро включить, меньше ручной настройки | Дополнительная нагрузка и зависимость от плагина |
| Код в теме / mu-plugin | Отключение XML-RPC, чистка head | Прозрачно, легко контролировать | Нужна аккуратность при обновлениях |
| Настройка Nginx | Ограничение запросов, блокировка путей | Ранний отсев мусора, меньше нагрузки на PHP | Требует доступа к конфигу и тестирования |
На практике лучше не выбирать один вариант, а разделить задачи: сервер — для отсечения мусора, WordPress — для логики, плагин — для удобства администрирования.
Проверка результата после внедрения
После изменений не ограничивайтесь «сайт открывается». Проверьте именно те точки, которые вы закрывали.
curl -I https://example.ru/xmlrpc.php— должен возвращать запрет или хотя бы не использоваться в рабочем сценарии;- попробуйте войти в админку с обычным пользователем и убедитесь, что лимит не мешает;
- посмотрите логи Nginx: количество запросов к
/xmlrpc.phpдолжно снизиться или исчезнуть; - проверьте, что REST API и редактор блоков работают;
- убедитесь, что служебные URL не попадают в новые страницы индексации.
Если используете Google Search Console, проверьте отчёт по страницам и статус обхода. Для серверной части полезно сравнить логи до и после по одному и тому же периоду, а не по ощущениям.
Частые ошибки и как их исправить
Отключили XML-RPC и сломали интеграцию
Такое бывает, если на сайте работает Jetpack, мобильное приложение или внешний сервис публикации. Решение простое: сначала выяснить зависимость, потом либо оставить XML-RPC включённым, либо заменить интеграцию на REST API, если сервис это поддерживает.
Закрыли wp-login.php по IP и заблокировали сами себя
Ошибка типичная для офисов с динамическим IP или при работе через мобильный интернет. Перед ограничением по IP проверьте, есть ли у вас стабильный адрес или VPN. Если нет — используйте 2FA и rate limit, а не жёсткую IP-блокировку.
Добавили запрет в robots.txt и решили, что этого достаточно
Это не защита. Поисковики могут не сканировать, но любой бот и любой человек по-прежнему откроет URL напрямую. Для безопасности нужны серверные правила или ограничения на уровне приложения.
Поставили тяжёлый security-плагин и получили лишнюю нагрузку
На слабом VDS это заметно сразу: больше запросов к базе, больше фоновых проверок, больше задач в cron. Если сервер уже на грани, лучше оставить точечные меры: Nginx rate limit, 2FA, отключение XML-RPC и аккуратную чистку кода.
Что ещё стоит проверить на VDS
Если вы уже полезли в конфиг, имеет смысл заодно посмотреть базовые вещи, которые влияют на безопасность и стабильность:
- обновления PHP и расширений;
- права на файлы и каталоги WordPress;
- наличие отдельного пользователя для сайта;
- регулярные бэкапы базы и
wp-content; - ограничение доступа к панели хостинга и SSH по ключам;
- отдельный лог-файл для ошибок PHP, чтобы не искать проблему вслепую.
Если нужен более удобный способ убрать дубли, служебные элементы и часть мусора из WordPress без ручной возни, можно посмотреть в сторону Clearfy Pro. Но даже в этом случае серверные ограничения и проверка логов остаются обязательными: плагин не заменяет конфиг VDS.
Самая практичная схема для большинства сайтов такая: не трогать лишнее, отключить только ненужные точки входа, ограничить частоту запросов на сервере и после этого проверить логи, REST API и вход в админку. Тогда защита не превращается в набор случайных галочек и не мешает обычной работе WordPress.