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

Ниже — порядок, которым я хожу по взломанному WP, когда нужно не «почистить то, что нашёл сканер», а понять, чем держится зараза, откуда зашли и что сделать, чтобы после смены пароля админа сайт не поднял шелл снова через час. Примеры путей и имён — типовые, не с конкретного клиента. Хосты и IP в логах подставляйте свои, чужие из интернета копировать вместе с «готовым лечением» не стоит.

Сначала стоп, снимок, доступ мимо wp-admin

Первое желание — зайти в админку и «поудалять левых пользователей». Если в теме или в mu-plugins сидит стилер куку, вы только подтвердите злоумышленнику, что хозяин на сайте, и отдадите свежую сессию.

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

Снять снимок, который можно откатить. На VPS — снапшот диска у хостера плюс архив каталога сайта и дамп базы на свою машину, не «бэкап плагином на этот же wp-content/uploads». На shared-хостинге — хотя бы tar корня сайта и mysqldump через панель или SSH. Если снимка нет, любое удаление файла потом не докажет, что именно он слал спам.

Посадить сайт на заглушку для посетителей, админку не оставлять открытой в интернет. Варианты, которые работают:

• В nginx/apache — отдать 503 на все PHP, кроме своего IP. Не «maintenance mode плагином»: его как раз и обходят.
• Временно подменить index.php в корне на статическую заглушку, оригинальный файл сохранить как index.php.orig рядом. Корень WP трогать аккуратно: не путать с index.php темы.
• На хостинге без SSH — закрыть каталог через панель / .htaccess по IP, если хостер это умеет. Если не умеет — хотя бы сменить пароли FTP и панели до того, как начнёте качать файлы на домашний ПК.

Дальше захожу по SSH или SFTP. wp-admin использую только когда уже понял, что сессия оттуда не исполняет чужой PHP. Почту, Telegram-ботов сайта и SMTP-плагин на время инцидента тоже считаю скомпрометированными: с них часто уходит фишинг от имени магазина.

Пока не закрыли вход, параллельно снимаю «кто ещё живой»: соседние сайты на том же аккаунте, cron пользователя, панели ISPmanager/cPanel. Один шелл в соседнем каталоге /var/www/site2 через час снова положит «уже почищенный» WP.

Что считать уликой, а не ощущением

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

• Корневой wp-config.php, .htaccess в корне, в wp-admin и в uploads (их часто дописывают отдельно).
• Drop-in файлы в wp-content: object-cache.php, advanced-cache.php, db.php, sunrise.php. Их сканеры ядра не считают «ядром», и туда любят класть одну строку include.
• Каталог wp-content/mu-plugins — must-use подключается всегда, без галочки в админке. Если зараза там, «деактивировать плагины» ничего не делает.
• Список пользователей ОС и crontab: crontab -l, /etc/cron.d/, /var/spool/cron/. PHP-шелл, который раз в пять минут дописывает себя в index.php, переживает любую «очистку файлов сайта».
• Логи веб-сервера за неделю-две, не за последний час. Нужны access и error, плюс PHP-fpm slowlog, если есть. POST на странный .php в uploads — классика.

По файлам смотрю не «все php в uploads», а свежие и с чужим владельцем:

# каталог сайта подставьте свой, не копируйте путь с чужого сервера
SITE=/var/www/example-site/public_html

find "$SITE" -type f -mtime -14 -printf '%TY-%Tm-%Td %TH:%TM %u:%g %p\n' | sort

find "$SITE/wp-content/uploads" -type f \( -name '*.php' -o -name '*.phtml' -o -name '*.phar' -o -name '.*.php' \) -print

find "$SITE" -type f \( -name '.*.ico' -o -name 'wp-*.php' -o -name '*timthumb*' \) -path '*/uploads/*' -print

ls -la "$SITE/wp-content/" "$SITE/wp-content/mu-plugins" 2>/dev/null
ls -la "$SITE/wp-content/"object-cache.php "$SITE/wp-content/"advanced-cache.php "$SITE/wp-content/"db.php 2>/dev/null

Свежий wp-login.php с датой «сегодня» при том, что ядро вы не обновляли — уже повод сверить контрольные суммы, а не «ну это же ядро, его не трогают». Свежий файл в wp-includes с именем вроде wp-vcd.php / class-wp-http-proxy.php рядом с настоящим классом — ещё чаще.

Владелец тоже врёт, если зараза работает от php-fpm того же пользователя, что и сайт. Тогда все файлы «как надо». Смотрите дату и содержимое, не только ls -l.

Ядро сверяю с эталоном, плагины — с zip из репозитория

WordPress умеет сам сказать, какие файлы ядра не совпали. С заражённой админки этой кнопке я не доверяю: подменённый update-core.php вам улыбнётся и покажет зелёное. С хоста, где есть wp-cli и исходящий HTTPS, или просто скачав zip той же версии:

# версию брать из wp-includes/version.php, не «ну наверное 6.4»
grep wp_version "$SITE/wp-includes/version.php"

# на чистой машине:
# curl -fsSLO "https://wordpress.org/wordpress-X.Y.Z.zip"
# unzip и rsync -avnc --delete ядра БЕЗ wp-content и без wp-config.php

wp core verify-checksums --path="$SITE"
wp plugin verify-checksums --all --path="$SITE"
wp theme verify-checksums --all --path="$SITE"

verify-checksums по плагину работает только для того, что лежит в wordpress.org. Платный Elementor, самопис, «нулёвая» тема с warez-сайта — для них эталона нет. Нулёвая тема — отдельный красный флаг: в ней бэкдор часто был с момента установки, и «вирус пришёл сам» тут ни при чём.

Что делать с расхождениями в ядре: не править файл руками «вырезать eval». Заменить пакет ядра целиком из официального zip. Исключения — wp-config.php и каталог wp-content. Если правили сами wp-config.php (соль, префиксы, константы) — файл не из zip, его сверяют глазами, не перезаписывают молча.

Плагин с расхождением: снимаю копию, ставлю тот же zip с wordpress.org. Если плагин платный — zip с кабинета разработчика, не «с форума, он тот же». Самопис, который «нам верстальщик оставил», читаю целиком. Там же часто лежит загрузчик файлов без проверки типа.

Где прячут PHP, когда «в файлах чисто»

Поиск по eval(base64_decode — полезный, но наивный. Нормальный PHP тоже бывает некрасивым. Я ищу сочетание: обфускация + место, куда CMS не должна писать исполняемое.

grep -R --include='*.php' -nE 'eval\s*\(|assert\s*\(|gzinflate\s*\(|gzuncompress\s*\(|str_rot13\s*\(|create_function\s*\(|preg_replace\s*\(.+/e' "$SITE" | head

grep -R --include='*.php' -nE 'FilesMan|c99shell|WSO\s|wp_vcd|wp-tmp|predli|\$GLOBALS\[.as.\]' "$SITE" | head

# одна строка в конце легитимного файла — классика
find "$SITE" -name '*.php' -size -8k -mtime -14 -print

# php внутри картинки / «.ico»
find "$SITE/wp-content/uploads" -type f -name '*.php.*' -o -name '*.jpg.php' -o -name '*.png.php'

Типовые гнёзда, которые я открываю всегда, даже если grep молчит:

• wp-content/uploads и кэш плагинов: *.php там не должен жить. Исключение — редкие плагины, которые сами кладут PHP в uploads; это повод такой плагин выкинуть, а не «ну так задумано».
• wp-content/upgrade, wp-content/upgrade-temp-backup, wp-content/blog.dir на мультисайте — мусор после обновлений, его не смотрят.
• Старая неактивная тема. «Мы на Astra, Twenty Twenty лежит на всякий» — в Twenty часто и сидит инжект в functions.php. Неактивная тема всё равно исполняется, если её кто-то дернул напрямую по URL.
• wp-config.php выше корня (правильная схема) и копия wp-config.php в корне/бэкапах *.bak, wp-config.php.old, config.php.save. Через них читают ключи БД без всякого шелла.

Отдельно — .htaccess. Не только редирект на чужой домен. Ещё auto_prepend_file / auto_append_file, php_value, RewriteRule на левый файл в uploads, закрытие .php «для всех кроме». Я сравниваю текущий файл с тем, что должен быть у выбранных постоянных ссылок. Если permalinks — «название записи», в корневом htaccess должен быть стандартный кусок WP, а не три килограмма чужих правил.

База. Файловый сканер её не видит. Смотрю:

• Лишние администраторы в wp_users + wp_usermeta (wp_capabilities = administrator). Пользователь wp_update / wpadmin1 / почта на одноразовом домене — не «сотрудник хостера».
• siteurl и home в wp_options. Если там чужой домен — редирект может быть не в файлах.
• active_plugins, recently_activated, опции с автозагрузкой autoload=yes и телом в десятки килобайт: туда кладут PHP, который потом evalят из темы одной строкой.
• Контент записей и виджетов: iframe, eval, короткие ссылки, спам-страницы в черновиках и ревизиях. Ревизии чистить отдельно: «удалил пост» не удаляет wp_posts с post_type=revision.
• Cron внутри WP: cron в wp_options или wp cron event list. Хук, которого нет ни в одном вашем плагине, раз в 10 минут дергает URL — это не «оптимизация».

wp user list --role=administrator --path="$SITE"
wp option get siteurl --path="$SITE"
wp option get home --path="$SITE"
wp plugin list --path="$SITE"
wp cron event list --path="$SITE"
wp db query "SELECT option_name, LENGTH(option_value) AS sz, autoload FROM wp_options ORDER BY sz DESC LIMIT 30;" --path="$SITE"

Префикс таблиц берите из wp-config.php, не считайте что он всегда wp_.

Дыру ищу до «лечения», иначе она зашьёт файл обратно

Удалить шелл и не закрыть вход — значит пригласить того же бота через пару часов. Пока файлы ещё на месте, по логам видно, какой URL принял POST до появления файла.

Ищу в access-логе не «все 404», а успешные запросы к тому, чего в чистом WP нет, и POST на плагины с известными дырами. Имена ниже — примеры шаблона, не диагноз конкретного сайта:

# nginx: подставьте свой лог
grep -E 'POST /(wp-admin/admin-ajax\.php|xmlrpc\.php|wp-login\.php)' /var/log/nginx/example.access.log | awk '{print $1}' | sort | uniq -c | sort -nr | head

grep -E ' 200 | 302 ' /var/log/nginx/example.access.log | grep -Ei 'uploads/.+\.php|wp-content/plugins/.+/upload|filemanager|wp-setup|radio\.php|about\.php'

# php в uploads, который уже отработал
grep 'wp-content/uploads/.*\.php' /var/log/nginx/example.access.log | grep -E ' 200 | 500 '

Что чаще всего оказывается входом на обычных магазинах и лендингах, которые мне приносят:

• Слабый пароль администратора + открытый xmlrpc.php с system.multicall. Брут идёт не через форму логина, лимит на wp-login.php его не видит.
• Устаревший плагин формы, слайдера, «добавить товар из Excel», файловый менеджер, который кто-то поставил «на пять минут».
• Нулёвая тема / «пак плагинов». Бэкдор там с завода.
• Утекла сессия админа: тот же пароль, что в панели хостинга, что в FTP, что в почте. После взлома пароль «тот же, я его недавно менял» меня не успокаивает.
• Соседний сайт в том же пользователе UNIX. Дыра была не в этом WP.

Версии плагинов фиксирую сразу, до обновления: wp plugin list + даты файлов. Обновить всё «на всякий случай» до разбора — значит затереть следы, какой именно компонент принял запрос. Обновлять надо, но после снимка и записи версий.

Если вход не находится за час — это нормально. Тогда я всё равно меняю секреты и убираю известные дыры, но в отчёте пишу честно: persistence сняли, вектор не доказан. Не пишу «всё закрыто», если в логах дырка.

Чистить на месте или накатывать чистый слепок

Правило, которым я пользуюсь. Если есть проверенный бэкап до даты взлома — проще поднять его на чистый каталог, накатить контент (uploads без PHP, дамп таблиц контента без левых пользователей) и заново поставить ядро и плагины из официальных zip. «Лечить» живой каталог имеет смысл, когда бэкапа нет или взлом свежий, и заказчик не может быть сутки в 503.

Чего не делаю:

• Не ставлю поверх заразы «свежий WordPress» в тот же каталог. Старый mu-plugin и object-cache.php переживут.
• Не верю кнопке Repair у сканера как единственному действию. Она вычищает известные сигнатуры. Не вычищает новый include в wp-blog-header.php из трёх символов.
• Не оставляю «карантин» плагина внутри wp-content, если этот карантин всё ещё исполняется по прямому URL.
• Не правлю обфусцированный файл «вырезать кусок». Файл целиком из эталона или удалить.

Порядок очистки на месте, если слепка до взлома нет:

1. Снимок, логи, список админов, crontab, drop-in, mu-plugins — уже сняты.
2. Ядро заменить официальным zip той же (или уже новой, если дыра в ядре) версии.
3. Каждый плагин и тему — либо zip с официального источника, либо удалить. Неактивное — тоже удалить с диска, не «выключить».
4. Из uploads удалить любой PHP/phtml/phar и файлы с двойным расширением. Картинки не «лечить антивирусом», а не исполнять: в nginx для uploads — location ~ \.php$ deny.
5. База: лишние админы, option с длинным autoload, спам-посты и ревизии, подмена siteurl, чужие cron-хуки.
6. Секреты: ключи в wp-config.php (AUTH_KEY и остальные — сгенерировать заново), пароли всех админов, пароль БД, FTP, панели хостинга, SMTP, токены платёжек и Telegram, application passwords, ключи REST. Сессии: сменить соли, чтобы старые куки умерли.
7. Только после этого обновлять плагины до текущих версий и включать сайт для своих IP на проверку.

Запрет исполнения PHP в uploads — это не «оптимизация», это то, без чего чистка часто бессмысленна:

location ~* ^/wp-content/uploads/.*\.php$ {
    deny all;
}

На apache — в uploads/.htaccess что-то в духе php_flag engine off плюс <FilesMatch> на php. Точный синтаксис зависит от того, mod_php у вас или php-fpm через cgi. Если не уверены — лучше сломать загрузку шелла, чем угадать директиву и оставить выполнение. Проверка простая: положить свой test.php с echo 1; в uploads, открыть в браузере, получить 403/скачивание, файл удалить.

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

Сайт открываю с своего IP. Смотрю исходник главной и пары внутренних: нет ли внешнего скрипта с левого домена, нет ли display:none простыни ссылок, не подменён ли каноникал. В базе ещё раз siteurl/home. В файлах — даты за последние часы: если после «чистки» снова появились php в uploads, persistence жива (cron, соседний сайт, украденный FTP, незакрытая дыра).

Технически полезно:

# повтор через несколько часов, не сразу
find "$SITE" -type f -mmin -180 -printf '%TY-%Tm-%Td %TH:%TM %p\n' | sort
crontab -l
wp user list --role=administrator --path="$SITE"
wp plugin list --path="$SITE"

Снаружи: Search Console на странные URL, письмо хостера про исходящий спам, очередь почты на сервере (mailq, логи exim/postfix). Исходящий спам после «уже чистого сайта» почти всегда значит, что PHP-шелл или SMTP-креды живы.

Сканер после этого можно поставить. Один. Как датчик на будущее, не как доказательство чистоты. Я смотрю на него так же, как на fail2ban: хорошо, что пишет, плохо, если им заменяют работу руками.

И ещё: пароли, которые «и так сложные», после инцидента всё равно меняю. В том числе в панели домена и у регистратора. Бывали случаи, когда после чистки сайта через сутки меняли NS — это уже не WordPress, это украденный аккаунт регистратора, и файловый grep этого не увидит.

Что я не обещаю одним плагином

Плагин-сканер не видит crontab ОС, соседний vhost, подмену NS и письмо, которое уже ушло ночью. Он плохо видит инжект в базе и drop-in на одну строку. Он может быть сам заражён, если его поставили в уже дырявый WP.

Разбор — это снимок, сверка ядра, поиск persistence, закрытие входа, смена секретов и проверка через несколько часов. Скучно, зато сайт не «зеленеет» в сканере и не краснеет у клиентов на следующий день.

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

Смотрю конфиг — почти всегда одно и то же. На пире стоит AllowedIPs = 0.0.0.0/0 «чтобы точно работало», DNS прописан 8.8.8.8, на VPS ip_forward выключен, а проверку сделали командой ping 10.66.66.1. Пинг до адреса туннеля проходит. Это доказывает только то, что два пира видят друг друга. Это не доказывает, что рабочий трафик идёт в туннель, что DNS не утекает мимо, и что обратный путь из офисной сети существует.

Ниже — как я собираю офис VPS так, чтобы маршруты, DNS и split-tunnel не врали, и чем проверяю, что пакет реально ушёл в wg0, а не красиво показал handshake в wg show. Без «поставьте GUI» и без схемы «все в 0.0.0.0/0 и будет счастье».

Два разных туннеля, которые путают в одном конфиге

Мне на стол приносят три задачи, и их пытаются решить одним [Peer]:

• С ноутбука в офисе ходить на сервисы на VPS: SSH, панель, приватный git, админка, которая слушает только внутренний адрес.
• С VPS ходить в офисную сеть: NAS, принтер, контроллер, камера, которой «интернет не нужен».
• Выгнать весь офисный интернет через VPS, «чтобы как на работе».

Это не один туннель с разными галочками. Это разный AllowedIPs, разный форвардинг и разный DNS. Первые две задачи я почти всегда делаю split-tunnel: в туннель уезжает только нужная подсеть. Третья — полный туннель, и за неё отдельно платят CPU, трафиком и сломанным Zoom, если MTU не поправили.

Адреса в примерах ниже документационные, не боевые. Публичный VPS — 203.0.113.10, белый офиса — 198.51.100.20, туннель — 10.66.66.0/24, LAN офиса — 192.168.40.0/24. Свои цифры подставьте, чужие из интернета не копируйте вместе с ключами.

AllowedIPs — это маршрут, а не «список друзей»

В WireGuard AllowedIPs делает две вещи сразу. Снаружи это криптоключ: пакет с таким источником примут только от этого пира. Изнутри wg-quick по этому списку ставит маршруты. Написали 0.0.0.0/0 — получите дефолт через туннель (у wg-quick ещё и отдельная таблица, обычно 51820). Написали 10.66.66.0/24 — в туннель пойдёт только эта сеть.

Поэтому «handshake есть, а сайт на VPS открывается по белому IP» — нормально для split-tunnel и баг, если вы хотели полный туннель. Браузер пошёл на 203.0.113.10 напрямую, UDP 51820 при этом живой. Туннель тут ни при чём.

Смотрю, что система думает про маршрут, не что написано в комментарии к конфигу:

wg show
ip -4 addr show dev wg0
ip -4 route show
ip -4 route show table all | grep -E 'wg0|51820'
ip -4 route get 10.66.66.1
ip -4 route get 203.0.113.10
ip -4 route get 8.8.8.8

ip route get врёт меньше, чем ощущения. Если до внутреннего адреса VPS маршрут не через wg0, дальше можно не гадать — трафик в туннель не собирался.

Split-tunnel: офис ходит на VPS, интернет офиса не трогаем

Это тот вариант, который я ставлю по умолчанию. Офисный пир (ноутбук или маленький шлюз) держит туннель, в AllowedIPs только сеть туннеля и, если надо, приватные сети на стороне VPS. Исходящий веб офиса идёт как раньше, через местного провайдера.

VPS:

[Interface]
Address = 10.66.66.1/24
ListenPort = 51820
PrivateKey = <ключ VPS>

[Peer]
PublicKey = <ключ офиса>
AllowedIPs = 10.66.66.2/32

Офис (за NAT, поэтому keepalive):

[Interface]
Address = 10.66.66.2/24
PrivateKey = <ключ офиса>

[Peer]
PublicKey = <ключ VPS>
Endpoint = 203.0.113.10:51820
AllowedIPs = 10.66.66.0/24
PersistentKeepalive = 25

Если на VPS сервисы торчат в docker-сети или во втором внутреннем интерфейсе, в AllowedIPs офиса добавляю эту сеть, не «весь мир». И на VPS тогда уже нужен форвардинг и фильтр, иначе пакет дойдёт до ядра и умрёт в FORWARD.

На VPS для split-tunnel NAT наружу обычно не нужен. Нужен, когда офис должен ходить не на сам VPS, а через него дальше. Пока задача «SSH на 10.66.66.1» — без маскарада.

PersistentKeepalive = 25 ставлю на том конце, который за NAT или с динамическим белым. Без него UDP-маппинг у провайдера офиса схлопывается, handshake в wg show становится старше пары минут, и «туннель встал сам» ровно до первой попытки зайти с другой стороны.

Когда VPS должен видеть LAN офиса

Вторая заявка: бэкап с VPS на NAS, мониторинг контроллера, SSH на станок, который «в интернет не смотрит». Тогда на стороне VPS в пире офиса мало /32 туннельного адреса. Нужна офисная подсеть:

# на VPS, peer = офисный шлюз
[Peer]
PublicKey = <ключ офисного шлюза>
AllowedIPs = 10.66.66.2/32, 192.168.40.0/24

Офисный шлюз должен форвардить. Это уже не «WireGuard на ноутбуке бухгалтера». Ноутбук не маршрутизатор: пакет с VPS на 192.168.40.15 дойдёт до ноутбука и останется там, NAS его не увидит, а ответ NAS пойдёт в локальный шлюз офиса и умрёт, потому что шлюз про 10.66.66.0/24 ничего не знает.

На шлюзе офиса:

sysctl -w net.ipv4.ip_forward=1
# постоянное место — /etc/sysctl.d/, не «в сессии до ребута»

iptables -C FORWARD -i wg0 -o eth0 -s 10.66.66.0/24 -d 192.168.40.0/24 -j ACCEPT 2>/dev/null || \
iptables -A FORWARD -i wg0 -o eth0 -s 10.66.66.0/24 -d 192.168.40.0/24 -j ACCEPT
iptables -C FORWARD -i eth0 -o wg0 -s 192.168.40.0/24 -d 10.66.66.0/24 -j ACCEPT 2>/dev/null || \
iptables -A FORWARD -i eth0 -o wg0 -s 192.168.40.0/24 -d 10.66.66.0/24 -j ACCEPT

Имена интерфейсов свои. eth0 в статье — заглушка. На машине смотрю ip -br link, не копирую с чужого скриншота.

Обратный маршрут в LAN часто забывают. NAS отвечает на запрос с 10.66.66.1 через дефолтный шлюз офиса. Шлюз этот пакет не ждал — в лучшем случае дроп, в худшем NAT в интернет. Варианты, которые работают:

• Статический маршрут на роутере офиса: 10.66.66.0/24 via 192.168.40.2, где .2 — шлюз с WireGuard.
• Или маскарад на офисном WG-хосте в сторону LAN, если роутер трогать нельзя. Работает, в логах NAS все запросы с одного адреса шлюза. Для бэкапа терпимо, для разбора «кто стучится» — нет.

Пересечение подсетей ловлю сразу. Офис на 192.168.1.0/24, docker на VPS тоже 192.168.1.0/24 — туннель поднимется, маршруты будут врать по очереди. Одну из сетей надо сменить. Спорить, «чья 192.168.1 важнее», бесполезно: важнее та, которую проще перенумеровать.

Полный туннель: 0.0.0.0/0, таблица 51820 и NAT на VPS

AllowedIPs = 0.0.0.0/0 на офисном пире означает: весь IPv4, кроме того что wg-quick сам вычтет для Endpoint, должен идти в туннель. wg-quick для этого поднимает policy routing, не просто ip route add default. Поэтому «я убрал default из main, а туннель живой» — ещё не победа. Смотреть надо ip rule и таблицу, которую создал WireGuard:

ip rule
ip route show table 51820
ip route get 8.8.8.8
ip route get 203.0.113.10

До Endpoint маршрут обязан остаться в физический интерфейс. Иначе туннель пытается нести сам себя и тихо умирает после первого же пересчёта маршрутов.

На VPS для чужого интернета нужны три вещи, не одна:

• net.ipv4.ip_forward=1
• NAT с туннеля в внешний интерфейс, иначе провайдер VPS не пропустит чужие RFC1918 как source
• FORWARD в файрволе в обе стороны, не только INPUT на 51820/udp

# на VPS, внешний интерфейс уточнить: ip -br addr
sysctl -w net.ipv4.ip_forward=1

iptables -t nat -C POSTROUTING -s 10.66.66.0/24 -o ens3 -j MASQUERADE 2>/dev/null || \
iptables -t nat -A POSTROUTING -s 10.66.66.0/24 -o ens3 -j MASQUERADE

iptables -C FORWARD -i wg0 -o ens3 -j ACCEPT 2>/dev/null || iptables -A FORWARD -i wg0 -o ens3 -j ACCEPT
iptables -C FORWARD -i ens3 -o wg0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT 2>/dev/null || \
iptables -A FORWARD -i ens3 -o wg0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

Правила в статье — эскиз под iptables. На машине с nftables я пишу в ту таблицу, которая уже живая, а не добавляю второй файрвол «рядом». ufw route allow и iptables -A FORWARD одновременно — классический способ получить «у меня же разрешено», когда пакет режет другая цепочка.

Полный туннель я не ставлю «на всякий случай». Он нужен, когда офисный канал дырявый, нужен выход с фиксированного белого VPS, или политика «весь трафик только через нас». Для доступа к одной админке на VPS это дорогой способ сломать DNS, MTU и чужой Zoom.

DNS: туннель живой, а имена резолвятся мимо

Самая частая ложь после wg show. Туннель есть, curl https://10.66.66.1 работает, а curl https://panel.internal идёт неизвестно куда или не идёт вовсе. Причина почти всегда в резолвере, не в маршрутах.

DNS = в wg-quick — не магия. На systemd-resolved это попытка прикрутить домены к интерфейсу. На машине без resolved это может записаться в /etc/resolv.conf и затереть офисный DNS. На Windows-клиенте это отдельная история с «использовать DNS этого адаптера». Я не верю строке в конфиге, пока не увижу, куда реально уходит запрос.

Проверка с офисного пира:

resolvectl status
resolvectl query panel.internal
getent hosts panel.internal

# куда уходит UDP/53, пока стучите в имя
tcpdump -ni wg0 port 53
tcpdump -ni eth0 port 53

Если дамп на физическом интерфейсе показывает запросы на 8.8.8.8, а на wg0 тихо — split-tunnel сделал ровно то, что вы написали: маршрут до публичного DNS прямой. Внутреннее имя при этом либо не резолвится, либо резолвится в публичный адрес, и вы снова обходите туннель.

Рабочая схема для split-tunnel, которой я пользуюсь:

• На VPS крутится DNS, который знает внутренние имена. Слушает 10.66.66.1, не 0.0.0.0 в интернет.
• У офисного пира DNS = 10.66.66.1, и этот адрес уже входит в AllowedIPs.
• Если нужен только суффикс internal, в resolved указываю домен на интерфейс туннеля, а не подменяю весь резолвер офиса.

Для полного туннеля публичный DNS тоже должен быть достижим через туннель. Иначе получаете курицу и яйцо: чтобы поднять туннель, нужен DNS Endpoint, а DNS вы уже отправили в туннель, которого нет. Поэтому Endpoint я пишу IP, не именем. Имя в Endpoint оставляю только там, где белый VPS прыгает и без DNS туннель не собрать — тогда DNS офиса должен резолвить этот хост до подъёма wg0.

IPv6 утекает отдельно, MTU ломает «сайты открываются через раз»

Настроили IPv4, про IPv6 забыли. Браузер берёт AAAA, пакеты идут мимо туннеля в родной канал. curl -4 при этом красивый. Если полный туннель — в AllowedIPs нужен и ::/0, и на VPS форвардинг/NAT6, либо IPv6 на офисном пире надо выключить осознанно, не «само как-нибудь».

Для split-tunnel я проверяю оба стека:

ip -6 route get 2001:db8::1
curl -4 -s https://ifconfig.me
curl -6 -s https://ifconfig.me

Документационный 2001:db8::1 в route get нужен, чтобы увидеть, в какой интерфейс ядро отправит «чужой» v6. Если полного туннеля нет, прямой маршрут — ожидаемо. Если полный туннель заявлен, а v6 уходит в eth0 — дыра.

MTU. UDP + WireGuard + внешний Ethernet обычно просит 1420, на части каналов — ниже. Симптом не «туннель мёртв», а «SSH живой, HTTPS висит, крупные POST отваливаются, мессенджеры отваливаются на картинках». Ловлю так:

ip link show wg0
ping -M do -s 1372 10.66.66.1
ping -M do -s 1200 10.66.66.1

Если 1372 с DF не проходит, опускаю MTU на wg0, пока не начнёт. На VPS с jumbo или с PPPoE за NAT цифры другие — подбираю, не копирую 1280 «потому что все так пишут», если канал нормально держит больше.

Проверка, что рабочий трафик в туннеле, а не только handshake

Чеклист, которым я пользуюсь после wg-quick up. По порядку, не выборочно.

# 1. пир живой
wg show
# handshake секунды-минуты, не часы; transfer растёт, когда вы сами генерируете трафик

# 2. адрес и маршрут
ip route get 10.66.66.1
# ожидаю dev wg0

# 3. ICMP внутри туннеля — необходимое, но не достаточное
ping -c 3 10.66.66.1

# 4. TCP на сервис, который слушает только внутренний адрес
curl -v --connect-timeout 5 http://10.66.66.1:8080/
ss -tlnp | grep 8080   # это уже на VPS: сервис не на 0.0.0.0:80 случайно?

Дальше — дамп. Это единственный способ перестать спорить. На офисном пире в одном окне генерирую трафик, в двух других:

tcpdump -ni wg0 host 10.66.66.1
tcpdump -ni eth0 udp port 51820
tcpdump -ni eth0 host 203.0.113.10 and not udp port 51820

Нормальная картина split-tunnel, когда я хожу на внутренний сервис: на wg0 видны пакеты до 10.66.66.1, на физическом интерфейсе до VPS — только UDP 51820. Если на физическом интерфейсе всплыл обычный TCP на белый 203.0.113.10:443, вы открыли публичный nginx, не туннель.

Для полного туннеля добавляю:

# с офисного пира
curl -4 -s https://ifconfig.me
# должен вернуться белый VPS, не белый офиса

ip route get 1.1.1.1
# dev wg0 или таблица 51820, не eth0

tcpdump -ni eth0 tcp port 443
# во время curl на внешний сайт здесь не должно быть голого TCP
# только UDP 51820

Если ifconfig.me показал белый офиса — трафик мимо. Если показал белый VPS, но на eth0 всё равно виден TCP 443 — смотрю второй интерфейс, IPv6, браузерный DoH, «умный» антивирус со своим туннелем. Бывает, что curl в туннеле, а Firefox живёт своей жизнью.

На самой VPS в это время:

tcpdump -ni wg0
tcpdump -ni ens3 udp port 51820
# conntrack, если ping есть, а TCP нет
conntrack -L | grep 10.66.66

Ещё одна ловушка: сервис на VPS слушает 127.0.0.1 или только публичный адрес. Туннель доставляет пакет на 10.66.66.1, nginx его не принимает. Это не «WireGuard сломался». Это ss -tlnp до настройки туннеля, не после.

Что я проверяю, когда «подключилось, но не работает»

Короткий разбор по симптомам, без перебора всего man.

• Handshake старше нескольких минут, transfer ноль — NAT, файрвол хостера на UDP 51820, неверный Endpoint, часы сильно разъехались реже, но бывает. С офиса: nc -u -v 203.0.113.10 51820 ничего не доказывает (UDP без ответа), нужен дамп на VPS в момент wg-quick up.
• Handshake живой, ping до 10.66.66.x нет — AllowedIPs не покрывает адрес, или адреса туннеля пересеклись у двух пиров. Два клиента с 10.66.66.2/24 одновременно — классика копипаста.
• Ping есть, TCP нет — MTU, или сервис не слушает адрес туннеля, или FORWARD/фильтр режет не ICMP, а tcp.
• До VPS по внутреннему IP есть, до NAS в офисе нет — на VPS в AllowedIPs нет LAN, на офисе нет forward, на роутере офиса нет обратного маршрута.
• Браузер открывает сайт по домену «не туда» — DNS мимо туннеля или A-запись смотрит на белый, а вы думали, что ходите внутрь.
• После сна ноутбука туннель «есть», трафика нет — keepalive, stale UDP mapping, помогает wg-quick down; wg-quick up, а постоянно — keepalive и иногда NetworkManager dispatcher, не вечная сессия с 2023 года.

Ключи и чужие IP в тикет не кладу. В логах для разбора достаточно последних байт публичного ключа из wg show и документационных адресов. Боевой Endpoint заказчика в статью и в переписку с подрядчиком не тащу.

Что оставляю в конфиге, когда уже заработало

Минимальный набор, который я не выкидываю «потом допишем»:

• Endpoint только IP, порт явно 51820 или тот, что реально открыт у хостера. У части облаков UDP на дефолтном порту режут, тогда слушаю другой и это же пишу в Endpoint.
• AllowedIPs по задаче, не максимальный. Split-tunnel — сети, которые правда надо унести. Полный туннель — осознанный 0.0.0.0/0 плюс IPv6-решение.
• PersistentKeepalive на NAT-стороне.
• DNS только тот, который достижим через получившиеся маршруты.
• Проверка дампом один раз после подъёма, не «пинг прошёл — закрываем задачу».

Конфиг без этой проверки — это VPN на скриншоте. Скриншот wg show с handshake я в отчёт тоже прикладываю, но рядом кладу ip route get до рабочего адреса и кусок tcpdump, где видно UDP 51820 снаружи и целевой трафик внутри. Если второго нет, туннеля для работы тоже нет — есть только красивый интерфейс wg0.

Нужный результат простой: крутилка света в «0» (или Auto), при включении зажигания ничего лишнего не горит, после запуска двигателя автоматически ближний спереди и габариты сзади. Штатный ручной свет при этом остаётся как был.

Та самая таблица, которую все копируют

В интернете по Astra H / Zafira B гуляет одна и та же схема вариантов DRL — «Стандарт» и Version 1–5 в разрезе «зажигание» / «мотор заведён» и положения переключателя. Её перепечатывают на Drive2, в FAQ по OP-COM, на чешских и немецких форумах. Мы тоже от неё оттолкнулись.

По таблице кажется, что достаточно один раз выбрать Version 1 или Version 5 — и поведение «всё включится как надо». На деле таблица описывает логику варианта, а не то, что перед и зад программируются в разных блоках. Из‑за этого половина инструкций заканчивается на UEC, а про REC либо вскользь, либо никак.

Что получилось у нас на Version 1 и 5

Пробовали классику — ставили одинаковый вариант и смотрели глазами.

• Version 1: при включении зажигания уже горели передние габариты; после запуска двигателя они оставались, плюс включался ближний. Для «дневного» режима это слишком рано: ещё не завёл — уже светится.
• Version 5: при зажигании ничего, после запуска двигателя зажигается ближний..

И главное: задние габариты автоматически не включались ни в одном из этих режимов, пока трогали только то, что обычно трогают первым — передний блок. Спереди картина менялась, сзади — тишина. Вот тут и всплывает архитектура Astra H.

Почему перед и зад настраиваются отдельно

На Astra H (и близкой по электрике Zafira B) свет и кузовная периферия разнесены по двум «центрам»:

• UEC (Underhood Electrical Center, иногда FZM / Front Zone Module) — подкапотный блок. Передние фары, часть передней кузовной логики, датчик дождя/света и параметр Daytime Running Light именно для передка.
• REC (Rear Electrical Center, RZM / Rear Zone Module) — задний блок (обычно слева сзади). Задние фонари, центральный замок, охранка и свой такой же пункт Daytime Running Light.

Это не «одна настройка на всю машину». У каждого модуля свой Variant Configuration и свой CarPass-ввод. Можно поставить на UEC Version 5, а на REC оставить Disabled / Standard — и получите ровно нашу картину: спереди DRL ожил, сзади габариты ждут ручной крутилки. Таблица из интернета этого почти не объясняет: там одна строка «версия», как будто она глобальная.

Отсюда и редкий, но рабочий трюк: разные варианты на перед и зад. Мы не изобретали велосипед с нуля — в FAQ по OP-COM давно пишут, что DRL надо прописывать и в UEC, и в REC. А вот комбинацию «5 спереди + 1 сзади» под конкретное поведение мало где разжёвывают.

Что понадобится

• Диагностика с поддержкой Opel: OP-COM (качественный клон/оригинал) или Tech2 + CANdi.
• CarPass — четыре цифры security code с карточки, которую выдавали с машиной. Без него Program Variant Configuration не пустит. Потеряли — только через дилера / сервис с доступом к базе (это не «взлом», а штатная защита кодировки).
• Зажигание включено (шина живая), аккумулятор не на нуле.
• Желательно сохранить текущий конфиг кнопкой Save в OP-COM, если она есть — чтобы откатить, если вариант не зайдёт.

Как мы запрограммировали перед (UEC) — Variant 5

Путь в OP-COM:

Diagnostics → год выпуска → Astra-H → Body → UEC → Programming → Program Variant Configuration → CarPass (4 цифры) → Daytime Running Light → Variant 5 → Program

Variant 5 на передке как раз ближе к «скандинавскому» дневном режиму: не тянет габариты и приборку так, как ранние версии при одном только зажигании, и даёт ближний уже в логике DRL. Сам по себе он нам ещё не закрыл задачу — но как половинка связки сработал отлично.

Нюансы из заводских/форумных заметок по Version 5 (имейте в виду): пока DRL активен, подсветка дисплея/кнопок может вести себя иначе, чем в ручном ближнем; дальний по таблице включается только из положения переключателя «ближний»; при крутилке на габаритах DRL обычно глушится. Если стоит ксенон — на Version 2–4 в гайдах часто советуют не заигрывать (свет может гореть ещё до запуска мотора).

Как настроили зад (REC) — Variant 1

Тот же ритуал, другой блок:

Diagnostics → год выпуска → Astra-H → Body → REC → Programming → Program Variant Configuration → CarPass → Daytime Running Light → Variant 1 → Program

Именно Variant 1 на REC у нас наконец поднял задние габариты в автоматике. Пока REC оставался без своего DRL-варианта (или на «стандарте»), сзади тишина — сколько ни крути UEC.

После Program иногда помогает коротко выключить зажигание и снова завести, чтобы модули перечитали кодировку.

Итог на нашей машине

Связка UEC = Variant 5 + REC = Variant 1 на Astra H 2008 универсал бензин дала то, что хотели:

• зажигание включено, мотор не заведён — ничего не горит;
• двигатель запущен — автоматически ближний спереди и задние габариты;
• ручной режим света как штатный, без сюрпризов.

Если у вас другой год / хэтч / GTC / ксенон / датчик света — цифры вариантов могут понадобиться другие, но принцип тот же: не программируйте только UEC и не ждите чудес от задних фонарей. Сначала таблица из интернета, потом обязательно REC, и уже подбором (или нашей связкой 5+1) ловите нужную картину.

Лимит сработал. Просто он отстрелил своих вместе с ботами. Офис сидит за одним белым IP, xmlrpc дергает приложение каждые несколько секунд, а общий php-location обслуживает и логин, и admin-ajax.php, и оформление заказа.

Ниже — как я режу именно логин и xmlrpc, оставляя сайт живым, и где limit_req бесполезен, сколько его ни крути. Без «поставьте плагин лимита логинов» и без слепого deny all на xmlrpc, пока не ясно, кто им пользуется.

Что бьют на самом деле, и почему это две разные двери

На типичном WordPress без WAF смотрят три URL:

• /wp-login.php — форма входа. GET рисует форму, POST проверяет пароль.
• /xmlrpc.php — старый API. С него удобно перебирать пароли пачками через system.multicall и дёргать pingback.
• Иногда /wp-admin/ и REST /wp-json/ — это уже другие истории, их в ту же зону, что логин, я не кладу.

GET на логин — не атака. Человек открыл форму, браузер подтянул редирект, плагин 2FA нарисовал второй шаг. Если лимитировать любой метод, первый же заход «съедает» burst, а POST с паролем уже ловит 429. Поэтому ключ зоны я завязываю на POST, не на URL целиком.

xmlrpc почти всегда POST. Закрывать его наглухо можно, если им никто не пользуется: нет официального приложения WP, нет Jetpack, нет старых клиентов публикации. Если приложение нужно — return 403 хуже брутфорса: свои отвалятся сразу, боты просто перейдут на wp-login.php.

Почему общий limit_req на php убивает нормальных людей

admin-ajax.php на живом сайте стучит постоянно: пульс админки, автосохранение записи, корзина, фильтры каталога. Один редактор за минуту легко делает десятки POST. Посадили его в зону 1r/s burst=3 вместе с логином — получите «сайт тормозит», хотя CPU спокойный, а в логе 503 на ajax.

Вторая ловушка — общий IP. Офис, коворкинг, 4G-оператор с CGNAT, гостиница. Двадцать человек за одним адресом. Лимит «один запрос в секунду на IP» для брутфорса с ботнета ещё терпим, для офиса это коллективный бан после трёх неудачных паролей подряд.

Третья — статус по умолчанию. Nginx на превышение отдаёт 503. Мониторинг орёт «сайт мёртв», человек лезет в php-fpm и диск. Это не падение бэкенда, это отказ лимитера. Ставлю limit_req_status 429 и в логах сразу видно, что именно отсекли, а не «бэкенд не отвечает».

Две зоны, не одна

Зоны объявляю в http, не в server. Размер 10m для $binary_remote_addr — десятки тысяч IP, на обычный сайт с головой. Rate считаю отдельно:

# http { ... }
limit_req_zone $limit_key_wplogin zone=wplogin:10m rate=6r/m;
limit_req_zone $limit_key_xmlrpc  zone=xmlrpc:10m  rate=1r/s;
limit_req_status 429;
limit_req_log_level warn;

Шесть POST в минуту на логин — человек с кривым паролем ещё влезет, словарь на тысячи попыток уже нет. xmlrpc чуть свободнее по частоте HTTP-запросов: живое приложение иногда стучит пачкой. Это не дыра — дыра в xmlrpc не частота, а толстое тело, про это ниже.

Ключ пустой строкой означает «этого запроса в зоне нет». Так я выключаю лимит для GET и для белого списка.

map $request_method $limit_key_wplogin {
    POST $binary_remote_addr;
    default "";
}

# xmlrpc почти весь POST; GET на него мне не жалко тоже резать
map $request_method $limit_key_xmlrpc {
    default $binary_remote_addr;
}

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

geo $offnet {
    default 0;
    203.0.113.0/24 1;   # офис, подставьте свой
}

map $offnet $limit_key_wplogin {
    1      "";
    default $limit_wplogin_ip;
}

map $request_method $limit_wplogin_ip {
    POST $binary_remote_addr;
    default "";
}

Два map на одну переменную nginx не даст — ключ собираю в одном месте. Рабочий вариант без сюрпризов:

geo $is_office {
    default 0;
    203.0.113.0/24 1;
}

map "$is_office:$request_method" $limit_key_wplogin {
    "1:POST" "";
    "0:POST" $binary_remote_addr;
    default  "";
}

map $is_office $limit_key_xmlrpc {
    1       "";
    default $binary_remote_addr;
}

Белый список — не «интернет офиса целиком». Только тот префикс, с которого реально заходят в админку. Домашний динамический IP туда не тащу: через месяц он уедет соседу.

location: только эти два файла, тот же php, что у остальных

location = с точным именем бьёт точнее regex. Обработчик php не выдумываю — копирую то, что уже работает для *.php. На Debian это часто snippets/fastcgi-php.conf плюс ваш fastcgi_pass. Сокет не копируйте из чужой статьи: у вас может быть другой пул.

server {
    # ...

    location = /wp-login.php {
        limit_req zone=wplogin burst=4 nodelay;
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php-fpm.sock;  # как у вас в общем php
    }

    location = /xmlrpc.php {
        limit_req zone=xmlrpc burst=8 nodelay;
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php-fpm.sock;
    }

    # общий php — БЕЗ limit_req этих зон
    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php-fpm.sock;
    }
}

burst=4 nodelay на логине: четыре лишних POST проходят сразу, дальше 429, без очереди. Без nodelay nginx начинает задерживать запросы — форма «думает» секундами, человек жмёт ещё раз, вы сами себе множите POST. Для логина я предпочитаю жёсткий отказ, не задержку.

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

location = /xmlrpc.php {
    return 403;
}

Проверяю необходимость просто: grep xmlrpc access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head и user-agent. Если неделю стучат только словари и Hello world — закрываю. Если есть wp-iphone / wp-android с адресов редакции — оставляю зону.

Настоящий IP, иначе режете Cloudflare, а не бота

$binary_remote_addr — это TCP-пир. Стоит сайт за Cloudflare, nginx-прокси или балансировщиком хостера — пир один на всех. Лимит превращается в глобальный рубильник: первый бот выжигает burst, посетители с того же эджа ловят 429.

Смотрю, откуда приходит запрос:

log_format debugip '$remote_addr cf="$http_cf_connecting_ip" xff="$http_x_forwarded_for"';

Дальше set_real_ip_from на префиксы своего прокси и real_ip_header — тот заголовок, которому вы доверяете. Не доверяю X-Forwarded-For с интернета без фильтра: его подставляет кто угодно. Для Cloudflare — их диапазоны и CF-Connecting-IP. Для своего nginx-прокси — только его адрес в set_real_ip_from.

Пока real_ip не настроен, limit_req на логин я не включаю в боевой server. Иначе «защита» — это лотерея, кто первый постучал в этот воркер.

Где лимит бесполезен: system.multicall

Брутфорс по xmlrpc часто укладывается в один HTTP POST. Внутри system.multicall — сотни wp.getUsersBlogs с разными паролями. Для nginx это один запрос. Зона 1r/s его пропускает, php-fpm честно пережёвывает пачку, в auth.log WordPress — сотни неудачных логинов, в access.log — одна строка 200.

Поэтому «я поставил rate limit, xmlrpc больше не брутфорсят» — самообман, если multicall жив. Nginx $request_body в if на практике пустой: тело ещё не прочитано в той фазе, конфиг из гугла с if ($request_body ~ multicall) просто не срабатывает. Я это не рисую как рабочую схему.

Что работает без магии:

• xmlrpc не нужен — return 403 на location, плюс фильтр в WordPress на всякий случай;
• нужен только pingback — всё равно спорно, pingback сам по себе источник шума; чаще его выключают;
• нужно приложение — оставляю xmlrpc под limit_req и отдельно отключаю multicall на стороне PHP (му-плагин на xmlrpc_methods выкидывает system.multicall), либо режу на WAF, который тело реально видит;
• Application Passwords и REST — другая дверь, xmlrpc для них не обязателен. Если мобильный вход уже через REST, xmlrpc я закрываю, не лимитирую.

Лимит по запросам и разбор методов xmlrpc — два разных слоя. Первый без второго на этой двери недоделан.

Как проверить, что своих не задело

Не тестирую с того же ноутбука, с которого админю. Иначе сам себя выкину и буду чинить по аварийной консоли. С другого адреса, лучше с маленького VPS:

# форма должна открываться сколько угодно
for i in $(seq 1 20); do curl -s -o /dev/null -w "%{http_code}\n" https://example.com/wp-login.php; done

# POST — должны пойти 429 после burst
for i in $(seq 1 20); do
  curl -s -o /dev/null -w "%{http_code}\n" -X POST \
    -d "log=nosuchuser&pwd=wrong&wp-submit=Log+In" \
    https://example.com/wp-login.php
done

# ajax и главная не в этой зоне
for i in $(seq 1 30); do
  curl -s -o /dev/null -w "%{http_code}\n" -X POST https://example.com/wp-admin/admin-ajax.php
done

Ожидание: GET логина — сплошные 200 (или 302, если уже есть редирект). POST — несколько 200/302, потом 429, не 503. ajax — без 429. Главная и карточки товара — без 429.

Потом то же с офисного IP, если он в geo: POST не должен упираться в 429, иначе белый список не попал в ключ. Частая ошибка — geo по $remote_addr до real_ip, и офис виден как адрес Cloudflare.

В логе ищу не «много 404», а явно статус и зону. С limit_req_log_level warn в error.log будет limiting requests, excess: ... zone=wplogin. Если зоны в логе нет, а 503 есть — вы смотрите не на лимитер, а на php-fpm/upstream.

Что я не кладу в эти зоны

• admin-ajax.php, async-upload.php, cron wp-cron.php — это не брутфорс логина.
• REST /wp-json/ целиком. Там и легитимный редактор, и Application Passwords. Если резать — отдельные location на конкретные маршруты, не оптом.
• wp-admin/ GET статики и admin-post.php с авторизованной сессией.
• Статику и wp-content/uploads — к логину отношения не имеет.

Отдельно: плагины «кастомной страницы входа» часто POST-ят не на /wp-login.php, а на / или на /my-account/. Тогда мой location логин не защищает, зато WooCommerce-чекаут внезапно оказывается под лимитом, если кто-то прикрутил зону на location /. Смотрю в access.log реальный URI при неудачном входе, не название плагина на коробке.

fail2ban рядом, не вместо

Nginx лимитер не помнит «этот IP вчера перебирал пароли». Он держит короткое окно. fail2ban по error.log с zone=wplogin или по auth-логу WordPress закрывает упёртых на часы. Но jail, который банит после трёх 429, снова отстрелит офис. Либо офис в ignoreip, либо порог заметно выше человеческого «забыл пароль, нажал пять раз».

Я не баняю 429 с ajax и не баняю 404 на xmlrpc.php, если сами его закрыли 403: боты будут стучать вечно, jail раздует ipset, а толку ноль — они и так получают отказ.

Что оставляю на обычном сайте

Рабочий минимум, которым я заканчиваю, если это один WordPress на VPS без приложения:

• real_ip настроен, в логе виден клиент, не эдж;
• wp-login.php — POST-only зона ~6r/m, burst 4 nodelay, статус 429;
• xmlrpc.php — 403, если за неделю нет своих клиентов;
• если клиент есть — зона 1r/s + выключенный system.multicall в PHP;
• офисный префикс в geo, не «весь провайдер»;
• общий php-location без этих зон;
• проверка циклом curl с чужого IP и глазами error.log, что падает зона, а не 503 от fpm.

Плагин лимита логинов в WordPress я не считаю заменой: он срабатывает уже внутри PHP, после того как fpm взял воркер. Под словарём это дороже, чем отказ на nginx. Плагин имеет смысл как второй слой (капча, временная блокировка учётки), не как единственный.

Если после включения 429 сыпятся на живых редакторов — не поднимаю rate «пока не пройдёт». Сначала смотрю, какой URI и какой IP. Почти всегда это либо общий php-location, либо NAT офиса, либо xmlrpc приложения, которое я забыл, что оно существует.

Смотрю du -xhd1 /var и почти всегда в топе /var/log. Внутри него не nginx/access.log на первом месте, а /var/log/journal на гигабайты. Хостер предлагает «расширить диск». Расширять можно, но это не лечение: journald по умолчанию считает нормальным занять десятую часть файловой системы. На маленьком корне это уже не «логи», это треть полезного места.

Ниже — как я отличаю «журнал имеет право быть большим» от «он просто не ограничен», чем persistent отличается от volatile на практике, и что смотреть утром, если ночью диск дошёл до нуля. Без советов вида «поставьте плагин» и без удаления файлов наугад.

Где journald вообще пишет, и почему каталог внезапно появляется

У systemd-journald два реальных места на диске (точнее, на диске и в tmpfs):

• /run/log/journal — volatile, живёт в памяти/tmpfs, после ребута пусто.
• /var/log/journal — persistent, переживает перезагрузку.

Режим задаётся в /etc/systemd/journald.conf параметром Storage=. По умолчанию почти везде auto: если каталог /var/log/journal существует — пишем туда и храним между ребутами. Нет каталога — сидим в /run.

Это ловушка, на которую люди наступают сами. На «голом» облачном образе журнал был volatile, места хватало. Кто-то из документации скопировал mkdir -p /var/log/journal «чтобы логи не терялись», перезапустил systemd-journald — и auto молча стал persistent. Лимиты при этом никто не ставил. Через неделю диск красный.

Проверяю так:

df -h / /var /run
du -sh /var/log/journal /run/log/journal /var/log 2>/dev/null
journalctl --disk-usage
ls -ld /var/log/journal
systemd-analyze cat-config systemd/journald.conf

journalctl --disk-usage говорит, сколько journald сам считает занятым. du — сколько видит файловая система. Если они сильно расходятся, смотрю разреженные файлы и «хвосты» после неудачного vacuum: du -sh --apparent-size /var/log/journal рядом с обычным du -sh.

Почему «дефолт 10%» на VPS — уже инцидент

В man у journald это звучит безобидно: SystemMaxUse по умолчанию — около 10% файловой системы, с потолком 4G; SystemKeepFree — около 15% свободными. На корне в 40G это до четырёх гигабайт журнала. На корне в 20G — те же проценты, только больнее.

Четыре гигабайта логов на виртуалке, где сам сайт весит 800 мегабайт, — не «запас на разбор». Это место, которое ночью отъест MySQL, очередь почты или бэкап.

Важная оговорка: лимиты — не жёсткая квота в момент записи каждой строки. Journald ротирует и чистит архивные файлы, когда доходит до порога. Активный system.journal так просто не схлопнется. Если диск уже 100%, vacuum может не стартовать нормально, потому что некуда дописать ротацию. Классический труп: раздел полный, journald не вакуумит, сервисы не пишут, SSH на ключах ещё жив, потому что сессия старая.

Поэтому на маленьком VPS я не оставляю дефолт. Дефолт рассчитан на машину, где /var не равен всему диску, и где гигабайды логов — нормальная цена за историю.

Persistent vs volatile: это про утро после ребута, не про вкус

Volatile соблазнительно прост: ребутнул — логи кончились, диск не раздувается. Я так оставляю только там, где журнал всё равно уезжает на внешний syslog и локальная история после ребута не нужна. На обычном VPS с сайтом это почти никогда не тот случай.

Типичный ночной сценарий: в 03:14 гипервизор переехал, ядро поймало OOM, сработал watchdog хостера, или сам systemd ушёл в reboot после failed unit. Утром вам нужен предыдущий бут. Он берётся так:

journalctl --list-boots
journalctl -b -1 -p err..alert --no-pager
journalctl -b -1 -u ssh -u nginx -u php-fpm -u mysql --no-pager | tail -n 200

Если Storage=volatile, после ребута -b -1 пустой. Вы будете гадать по last reboot и по графику load у хостера. Это не диагностика, это гадание.

Persistent без лимита — другая крайность: история есть, но её некуда писать, потому что диск кончился самой историей.

Рабочая схема на VPS, которую я ставлю почти всегда: persistent, но маленький. История на несколько дней, не на квартал. Внешний syslog — если он уже есть; не вместо локального журнала, а поверх, чтобы переживать смерть самой машины.

Что смотреть overnight, пока диск ещё не ноль

Если диск уже 100% — сначала воздух, потом разбор. Если ещё есть 1–2 гигабайта, ночью я смотрю не «красивый dashboard», а четыре вещи.

Первое: это вообще journald или рядом лежит второй обжора. Часто параллельно толстеют /var/log от rsyslog, бинарные логи MySQL, json-file логи Docker. Journald виноватят первым, потому что путь незнакомый.

du -xhd1 /var /var/log /var/lib 2>/dev/null | sort -h
du -sh /var/lib/docker/containers 2>/dev/null
du -sh /var/lib/mysql 2>/dev/null
ls -lh /var/log/*.log /var/log/syslog /var/log/messages 2>/dev/null

Второе: журнал вырос за ночь или копился две недели. Смотрю даты файлов и размер активного относительно архивных:

ls -lhS /var/log/journal/*/* 2>/dev/null | head
journalctl --header | head -n 40

Архивные файлы с @ в имени — уже закрытые куски. Если за ночь вырос один свежий файл на гигабайт — это не «дефолтный 10%», это болтливый юнит. Если лежат десятки старых файлов по 300–400M — это никто никогда не ставил SystemMaxUse и не делал vacuum.

Третье: был ли ребут. journalctl --list-boots, who -b, last -x reboot | head. Если бут ночью был, первым делом journalctl -b -1 -p err, а не сегодняшний хвост. Сегодняшний хвост после ребута начинается с «диска мало» и маскирует причину.

Четвёртое: не забился ли /run. Volatile журнал живёт в tmpfs. На машине с 1–2 гигабайтами RAM /run маленький. Когда он полный, симптомы странные: не стартуют юниты, Failed to create ... No space left, при этом df -h / ещё живой. Смотрю df -h /run отдельно, всегда.

Кто орёт в журнал: без этого лимит только отодвинет взрыв

Ограничить размер — обязательно. Но если каждую ночь один сервис пишет сотни тысяч строк, вы просто быстрее упрётесь в потолок и начнёте терять именно те сообщения, которые нужны для разбора.

Счётчик по юнитам за ночь, без jq:

journalctl --since "6 hours ago" -o json --no-pager | python3 -c '
import sys, json, collections
c = collections.Counter()
for line in sys.stdin:
    try:
        j = json.loads(line)
    except Exception:
        continue
    key = j.get("_SYSTEMD_UNIT") or j.get("SYSLOG_IDENTIFIER") or "?"
    c[key] += 1
for k, v in c.most_common(20):
    print("%8d  %s" % (v, k))
'

На живой машине это может минуту помолчать — json тяжёлый. Если python3 жалко, грубее по short-формату:

journalctl --since "6 hours ago" --no-pager | awk '{print $5}' | sed 's/\[.*//' | sort | uniq -c | sort -nr | head

Пятое поле в short — не священная корова, на неанглийской локали колонки плывут. Для разбора лучше json.

Что обычно оказывается наверху, когда «за ночь съело диск»:

• systemd-таймер бэкапа с StandardOutput=journal и rsync -v / find на сотни тысяч файлов;
• fail2ban + ssh-парольный брут: одна попытка — несколько строк в journal и ещё дубль в auth.log;
• PHP/Node в debug, который кто-то включил «на час» в пятницу;
• сетевой юнит, который рестартует в цикле и каждый раз пишет stack trace;
• ядро и OOM-killer — это уже не болтовня, это авария, её резать лимитом журнала нельзя, её надо читать.

Для шумного, но не аварийного юнита правильнее прикрутить его вывод, а не бесконечно растить journal. В unit-файле: StandardOutput=append:/var/log/backup.log плюс logrotate, или убрать -v. RateLimit в journald.conf режет пачку одинаковых сообщений, но на бэкап с уникальными путями в каждой строке он почти не действует: burst исчерпывается, а диск всё равно пишется, пока не упрётся.

SystemMaxUse и соседние крутилки

Править лучше drop-in, а не жирный коммент в исходном journald.conf. Так видно, что меняли вы, а не пакет.

mkdir -p /etc/systemd/journald.conf.d
cat >/etc/systemd/journald.conf.d/size.conf <<'EOF'
[Journal]
Storage=persistent
SystemMaxUse=200M
SystemKeepFree=1G
SystemMaxFileSize=50M
RuntimeMaxUse=50M
MaxRetentionSec=7day
MaxFileSec=1day
Compress=yes
EOF
systemctl restart systemd-journald
journalctl --vacuum-size=200M --vacuum-time=7d
journalctl --disk-usage

Зачем каждая строка, коротко.

Storage=persistent — явно, чтобы не зависеть от «кто-то случайно создал каталог». Каталог после этого должен существовать: mkdir -p /var/log/journal, права оставить journald самому поправить.

SystemMaxUse=200M — потолок persistent-журнала. На VPS с сайтом и ssh мне для разбора инцидента обычно хватает десятков–пары сотен мегабайт, не гигабайт. Если это шлюз, с которого разбирают неделю брутфорса по сырым логам — поставьте больше, но цифрой, не дефолтом.

SystemKeepFree=1G — не съедать последний гигабайт, даже если MaxUse ещё не достигнут. На маленьком корне это важнее MaxUse: MySQL и очередь почты должны иметь куда писать.

SystemMaxFileSize — чтобы один файл не вырос в весь лимит. Vacuum чистит архивные; огромный активный файл неудобно и vacuum, и копировать.

RuntimeMaxUse — потолок для /run, чтобы volatile не убил tmpfs.

MaxRetentionSec=7day — дефолт по времени почти не режет, живёт размер. Я хочу неделю, не «пока влезает 10% диска». Для разбора overnight недели хватает. Месяц уже про хранение, его лучше делать на syslog-коллекторе, не на корне VPS.

После рестарта journald файлы сами не схлопнутся до новой цифры в ту же секунду. Поэтому сразу --vacuum-size / --vacuum-time. Рестарт журналы не удаляет — это не rm.

Vacuum — не rm -rf, особенно когда диск уже 100%

Нормальный путь:

journalctl --disk-usage
journalctl --vacuum-size=100M
journalctl --vacuum-time=2d
journalctl --verify

--verify иногда находит битый хвост после внезапного отключения питания. Битый файл vacuum может обходить стороной, и место не отдаётся. Тогда смотрю имена в /var/log/journal/<machine-id>/ и убираю архивные *@*.journal / *.journal~, не трогая текущий system.journal.

Чего не делаю, пока есть другой выход: rm -rf /var/log/journal/* на живой системе. Один раз из ста это проходит, в остальные journald остаётся с открытыми inode, место не возвращается, а после рестарта вы получаете пустой журнал ровно в тот момент, когда хотели понять, почему диск кончился.

Аварийный порядок, если писать уже некуда:

• найти и удалить пару самых старых архивных файлов *@*.journal — это даёт воздух;
• сразу journalctl --vacuum-size=80M;
• поставить drop-in с лимитами и перезапустить journald;
• только потом искать болтливый юнит, иначе пока вы читаете json, диск снова забьётся.

Сигнал «почистись прямо сейчас» у journald — SIGUSR2. SIGUSR1 — сбросить буфер на диск, не vacuum. Путать их бессмысленно, но люди путают.

Двойной учёт: journald, rsyslog и Docker

На Debian/Ubuntu часто живы оба мира. journald пишет своё. rsyslog забирает через imjournal или сокет и пишет /var/log/syslog, /var/log/auth.log. Итого одна и та же неудачная попытка SSH лежит дважды. Rate-limit в journald на файлы rsyslog не действует.

Проверяю, не тащим ли мы дубль:

systemctl is-active rsyslog syslog-ng 2>/dev/null
grep -RInE 'imjournal|imuxsock|ForwardToSyslog' /etc/rsyslog.conf /etc/rsyslog.d /etc/systemd/journald.conf /etc/systemd/journald.conf.d 2>/dev/null
du -sh /var/log/journal /var/log/syslog /var/log/auth.log 2>/dev/null

ForwardToSyslog=yes плюс persistent journald — сознательное удвоение. Имеет смысл, если внешний разбор завязан на syslog-файлы, а journal вы хотите маленьким. Не имеет смысла, если никто эти файлы не читает, а logrotate на syslog стоит «weekly, rotate 8» и молча держит ещё сотни мегабайт.

Docker — отдельная яма. json-file драйвер пишет в /var/lib/docker/containers/.../*.log, это не journald. Человек чистит journal, диск не отходит, начинается шаманство. Если в du победил docker — лимиты в daemon.json (log-opts max-size), не в journald.conf. Путь другой, болезнь похожая.

Что я реально оставляю на маленьком VPS

Для обычного сайта (nginx, php-fpm, mysql, ssh) на одном диске:

• persistent, 150–300M потолок, неделя хранения;
• /run ограничен десятками мегабайт;
• таймеры бэкапа не пишут verbose в journal;
• если rsyslog нужен файлами для fail2ban — пусть живёт, но logrotate жёсткий, не дефолтный weekly на 100M файлах;
• внешний syslog — когда машин больше двух или когда хочется историю длиннее недели.

Volatile я ставлю на одноразовые тестовые машины и на те VPS, где журнал и так уезжает агентом, а локальный диск маленький и ребут не является загадкой.

И я не храню journal как бэкап логов. Это кольцевой буфер для разбора. Если лог должен жить три месяца «по требованиям», ему место не в /var/log/journal на корне.

Утренний чеклист, если ночью диск снова опух

Короткий порядок, которым я хожу, чтобы не начать не с того конца:

• df -h / /run /var — какой именно раздел, не «диск вообще»;
• du -xhd1 /var — journal это или mysql/docker/бэкап;
• воздух: vacuum или пара архивных файлов, не apt и не /tmp;
• journalctl --list-boots и при ночном ребуте сразу -b -1 -p err;
• счётчик юнитов за ночь — кто писал, не «сколько процентов в SystemMaxUse»;
• drop-in с SystemMaxUse / SystemKeepFree, vacuum до новой цифры;
• проверка, что через час journalctl --disk-usage не ползёт обратно с той же скоростью.

Если после лимита журнал упирается в потолок каждые несколько часов — лимит сработал, но источник шума жив. Тогда это уже не настройка journald, а разбор конкретного юнита. Крутить SystemMaxUse вверх, «чтобы влезало», на маленьком VPS я не соглашаюсь: вы просто вернёте ту же заявку через неделю, только с более толстым журналом и снова нулём на диске.

Если вы пропустили новость или думаете «автообновление само всё поставило» — всё равно стоит проверить версию и пользователей. Патч вышел 17 июля в 6.9.5 и 7.0.2 (для ветки 6.8.x — 6.8.6, там закрыли только SQLi-компонент). WordPress даже включил принудительное автообновление — но на VPS, мультисайтах и «забытых» лендингах дыра нередко висит до сих пор.

Это не XSS2Shell

Чтобы не путаться: в начале августа вышел отдельный баг XSS2Shell (CVE-2026-64638) — reflected XSS на wp-login.php, патч в 7.0.3. Там другой вход и нужен залогиненный админ, которого уводят на фишинговую страницу. А wp2shell — полностью без авторизации, через batch-endpoint. В статьях и Medium их часто мешают в одну кучу, хотя это две разные истории. Ниже — про wp2shell.

В чём суть: две дыры в одной цепочке

CVE-2026-63030 — путаница маршрутов в batch-обработчике REST API (WP_REST_Server::serve_batch_request_v1). Batch-endpoint (/wp-json/batch/v1, а без ЧПУ — /?rest_route=/batch/v1) позволяет отправить несколько подзапросов одним POST. Если первый подзапрос падает с ошибкой при разборе URL, WordPress кладёт ошибку в один массив, но не синхронизирует второй. Индексы съезжают — и следующий подзапрос атакующего обрабатывается с чужими правами, мимо проверки «можно ли это без логина».

CVE-2026-60137 — SQL-инъекция в параметре author__not_in (в REST он приходит как author_exclude). Сама по себе она за auth-блоком. Но batch-баг протаскивает туда анонимный запрос. Инъекция слепая — в ответе данных нет, зато работает time-based oracle через SLEEP().

Одна без другой до полного RCE на типичном сайте не доводит. Вместе — критическая цепочка с CVSS 9.8.

Как выглядит атака: левый админ → плагин → шелл

Упрощённо, как описывают исследователи (Searchlight Cyber, публичные PoC вроде wp2shell на GitHub) и что видно в логах реальных инцидентов:

1. Анонимный POST на /wp-json/batch/v1 с «кривым» batch-envelope — срабатывает route confusion.
2. В том же batch — запрос с poisoned author_exclude, SQLi читает/меняет данные в БД (часто через blind SQLi и манипуляции с object cache / changeset — детали в PoC различаются).
3. Через REST создаётся новый пользователь с ролью administrator — логин обычно вида wp2_*, email иногда на подставных доменах вроде @wordpress-svc.internal. Brute bcrypt-хеша существующего админа для этого не нужен — аккаунт поднимают «с нуля».
4. Атакующий логинится под этой учёткой (в логах потом видны нормальные запросы в wp-admin с валидным nonce).
5. Через Загрузку плагина (update.php?action=upload-plugin) заливается ZIP с PHP — имена в инцидентах разные: media-optimization-core-*, sgio-wp2shell-* и т.п. Активировать плагин в списке не обязательно — PHP в wp-content/plugins/ часто доступен по URL напрямую.
6. Дальше — id, uname, выкачка wp-config.php, спам-рассылки, бэкдоры в mu-plugins, cron, переименование Wordfence.

Именно этот сценарий — «создали админа, зашли, залили шелл через плагины» — описан в публичных разборах wp2shell, в том числе на Medium. Не социнженерия и не «админ кликнул фишинг».

Кого касается

Полная цепочка до RCE:

• WordPress 6.9.0 – 6.9.4
• WordPress 7.0.0 – 7.0.1

Только SQLi (без batch-RCE, но всё равно надо патчить): 6.8.0 – 6.8.5 → фикс в 6.8.6.

Версии ниже 6.8 batch-механизм в том виде, в каком его эксплуатируют, не затрагивают — но это не повод радоваться, если у вас вообще древний WP.

Нюанс из advisory: полный RCE-chain на практике чаще срабатывает, когда нет внешнего persistent object cache (Redis/Memcached). На обычном shared-хостинге это как раз большинство сайтов.

Как понять, что уже взломали

Картина похожа на массовые взломы через Elementor или Битрикс — только вход другой.

• Незнакомые администраторы в «Пользователи» — логины wp2_*, wpsvc_*, странные email.
• Новые папки в wp-content/plugins/ с «оптимизационными» или «сервисными» названиями и свежей датой.
• В access-логах — массовые POST на batch/v1, ответы 207 Multi-Status, User-Agent вроде wp2shell-rce/1.0.
• После входа «левого» админа — запросы на upload-plugin, активация плагинов, дефейс главной.
• Пersistence: cron у пользователя веб-сервера, записи в wp_options, must-use plugins в wp-content/mu-plugins/.

Из разбора реального инцидента (deface «Hacked by CoupDeGrace»): сайт обновили до 7.0.2, но бэкдоры продолжали работать — патч закрывает вход, но не чистит сервер. Как с Битриксом: обновили CMS, а webshell из прошлого взлома остался.

Что делать

1. Обновить ядро. Единственный нормальный способ, как разработчики и задумывали: 6.9.5, 7.0.2 или новее (на сегодня логично сразу до актуального security-release — 7.0.4 и аналогов в своей ветке). Анонс: WordPress 7.0.2 Security Release. Advisory: GHSA batch-route confusion и GHSA SQL injection.

2. Убедиться, что автообновление реально сработало. Зайдите в Консоль → Обновления и посмотрите версию. «Должно было само» ≠ «обновилось».

3. Проверить пользователей. Удалите всех незнакомых админов. Смените пароли нормальным администраторам, отзовите Application Passwords.

4. Пройтись по файлам. plugins/, mu-plugins/, uploads/, лишние .php в корне. Сравните с чистым архивом той же версии WP, если есть сомнения в целостности ядра.

5. Посмотреть логи. POST на batch/v1 с июля 2026 — повод считать сайт скомпрометированным, даже если визуально всё чисто.

6. Временная мера, если обновиться прямо сейчас нельзя: заблокировать на WAF/nginx /wp-json/batch/v1 и ?rest_route=/batch/v1 для анонимов. Как временный запрет POST на отдельные файлы у Битрикса — не 100%, но лучше, чем ничего.

Важно: если взлом подтвердился — сначала чистка и ротация секретов (БД, FTP, SMTP), потом спокойное обновление. Восстановление из бэкапа только если копия точно старше первого POST на batch и гарантированно чистая.

UPD — август: XSS2Shell и Imagick RCE

После wp2shell WordPress выпустил ещё security-релизы:

• 7.0.3 (6 августа) — XSS2Shell, CVE-2026-64638, XSS на экране входа с цепочкой через Application Password (другой сценарий, нужен фишинг админа).
• 7.0.4 (12 августа) — CVE-2026-65640, RCE через загрузку Postscript при Imagick + Ghostscript, нужен пользователь с upload_files.

Если вы на 7.0.2 после wp2shell — докатите до актуального патча своей ветки. Это уже не wp2shell, но дыры тоже серьёзные.

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

Решил собрать всё в одном месте — ilserby.net. Это мой каталог сетевых и dev-инструментов: без аккаунта, бесплатно, с нормальным русским/английским интерфейсом и понятным результатом, а не просто сырой дамп. Ниже — несколько штук из сетевого блока, которыми пользуюсь чаще всего.

Домены и DNS

WHOIS / RDAP Lookup — когда нужно быстро понять, кто владелец домена, когда истекает регистрация и какие NS стоят. Тянет и RDAP, и классический WHOIS, если для зоны так принято.

DNS Lookup — A, AAAA, MX, TXT, CNAME, SOA, CAA, плюс DNSSEC и проверка распространения A-записей через публичные резолверы. Удобно после смены хостинга или почты, когда «вроде всё прописал, но где-то ещё старое».

Email Authentication — SPF, DMARC, DKIM и MX в одном заходе. Перед тем как жаловаться на спам или недоставку писем, я обычно начинаю отсюда: видно, что реально опубликовано в DNS, а не что «должно быть по инструкции провайдера».

Lookalike Domains — генератор похожих доменов с homoglyph и punycode. Не замена мониторинга бренда, но для осознания, как может выглядеть фишинговая ссылка «почти как ваш», — полезная штука.

IP, прокси и репутация

IP Lookup — reverse DNS, гео, ASN, сеть и RDAP по публичному адресу. Часто хватает одного экрана, чтобы понять «это хостинг, CDN или что-то странное».

IP Blacklist Check — проверка по DNSBL/RBL: спам, abuse, брутфорс. Если с сервера перестали принимать почту или API начали резать по IP — смотрю сюда в первую очередь.

Proxy Checker — до 50 прокси за раз, HTTP/HTTPS/SOCKS4/SOCKS5, с exit IP, гео и временем ответа. Результаты приходят по одному, можно остановить очередь и выгрузить только рабочие.

HTTPS, заголовки и безопасность

SSL Checker — срок действия, цепочка, SAN, hostname match и типичные косяки установки. Перед продлением Let’s Encrypt или после переезда на новый сервер — must have.

HTTP Headers — цепочка редиректов, security headers, robots.txt и sitemap. Быстрый аудит «как отвечает главная» без curl в терминале.

Browser Fingerprint — canvas, WebGL, шрифты, Client Hints и композитный ID. Всё считается локально в браузере, никуда не уходит. Полезно, когда тестируешь приватность или сравниваешь профили.

Подсети, сертификаты и мелкий sysadmin

IPv4 Subnet Calculator — network/broadcast, маска, wildcard, диапазон хостов из CIDR. Планирую firewall или VPC — не считаю в голове.

CIDR Overlap & Contains — пересекаются ли две подсети и входит ли IP в блок. Спасает от классической ошибки «прокинули peering, а маршруты бьются».

Self-Signed Certificate Generator — ключ и самоподписанный сертификат прямо в браузере, с SAN. Для dev/staging, не для публичного продакшена.

OpenSSH Public Key Inspector — разбор .pub и целого authorized_keys: тип, SHA256/MD5, дубликаты. Быстрее, чем гонять ssh-keygen по каждой строке.

Nginx .htaccess Converter — черновой перевод редиректов и rewrite между nginx и Apache. Не волшебная кнопка, но стартовая точка при миграции — норм.

SLA & Uptime Calculator — перевод 99.9 / 99.99 в минуты простоя за день, месяц, год и обратно. Удобно для договоров и postmortem после инцидента.

Зачем вообще свой каталог

Не претендую, что ilserby заменит специализированные сервисы уровня Shodan или полноценный мониторинг. Идея проще: один вход, одинаковый UX, инструменты, которые реально нужны в повседневной админке и вебмастерской рутине. Плюс там же лежат конвертеры, генераторы и SEO-штуки — но сетевой блок я использую чаще всего.

Каталог буду допиливать и расширять: новые проверки, мелкие улучшения интерфейса, то, что сам всплывает в работе и бесит на чужих сайтах. Цель простая — чтобы в итоге получился самый удобный для меня (и не только) набор онлайн-инструментов в одном месте. Заглядывайте на ilserby.net — и если чего-то не хватает, пишите, что добавить в первую очередь.

--link-dest лежит между этими двумя дуростями. Каждый слепок выглядит как полный каталог: зашёл в /backup/site/2026-08-27/ — видишь весь сайт, как в тот день. На диске при этом лежат только изменившиеся файлы. Неизменные — hardlink на inode прошлого слепка. Это не магия файловой системы и не «инкремент в проприетарном формате». Это обычный ext4/xfs и обычный rsync. Именно поэтому я его до сих пор ставлю там, где не нужен Borg/restic со своими репозиториями, а нужен каталог, из которого файл можно просто скопировать.

Ниже — как я это собираю, где оно ломается, и как проверить restore так, чтобы не узнать о битом бэкапе в день аварии.

Что именно делает –link-dest, без сказки про «инкремент»

Rsync сравнивает источник с каталогом назначения. Если файла в назначении ещё нет, он смотрит в каталог из --link-dest. Файл там есть, размер и mtime совпали — в новый слепок кладётся hardlink, байты заново не копируются. Файл изменился — в новый слепок пишется новая копия, старый inode остаётся в старом слепке.

Поэтому:

• каждый дневной каталог самодостаточный: ls, grep, cp работают как по живому дереву;
• место растёт примерно на объём изменений, а не на полный размер каждый день;
• удалили файл на проде — в новом слепке его нет (--delete), в старом он ещё лежит, пока слепок не выкинете.

Hardlink — это не копия и не симлинк. Два имени, один inode. Пока на inode есть хотя бы одна ссылка, данные живы. Выкинули самый старый слепок — unlink уменьшил счётчик, и только для тех файлов, которые больше ни в одном слепке не встречаются, место реально освободилось.

Важное следствие, из-за которого люди потом материются: правка файла внутри слепка правит все слепки, которые ссылаются на тот же inode. Бэкап — не рабочая копия. Залезли поправить «на всякий случай конфиг в бэкапе» — поправили историю. Restore всегда копированием в другой каталог, никогда правкой на месте.

Раскладка каталогов, с которой потом не стыдно жить

Я не нумерую snapshot.0 … snapshot.7, если нет rsnapshot. Номера крутятся mv, в панике в три ночи легко перепутать, что сейчас «сегодня». Даты читаются без расшифровки:

/backup/host-a/
    2026-08-25/
    2026-08-26/
    2026-08-27/
    latest -> 2026-08-27

Отдельный корневой каталог на хост. Не сваливать сайты разных машин в одну кучу: hardlink работает только внутри одной файловой системы, а путать, чей это wp-config.php, в аварии дорого.

Диск под бэкапы — отдельный раздел или отдельный диск. Не /var той же машины, которую снимаете. И не NFS, если рассчитываете на hardlink: на NFS hardlink либо запрещён, либо ведёт себя так, что экономии не получите, а du сойдёт с ума. --link-dest требует, чтобы каталог назначения и каталог link-dest были на одной ФС. Проверка перед первым запуском:

df -P /backup/host-a | awk 'NR==1 || {print $1, $6}'
stat -f -c '%i' /backup/host-a   # filesystem id, должен совпасть у всех слепков

Если снимаете несколько источников на один раздел — нормально. Если бэкап-диск собрали из двух mount — rsync молча начнёт копировать файлы вместо hardlink, место кончится через несколько ночей, в логе это будет не ошибкой.

Первый слепок и все следующие

Первый прогон — обычный полный rsync, без --link-dest. Каталога для ссылок ещё нет.

SRC=/var/www/site
ROOT=/backup/host-a
TODAY=$(date +%F)

mkdir -p "$ROOT/$TODAY"
rsync -aH --numeric-ids --delete --one-file-system \
  "$SRC/" "$ROOT/$TODAY/"
ln -sfn "$TODAY" "$ROOT/latest"

Следующие ночи — тот же приём, плюс ссылка на предыдущий слепок. Предыдущий я беру не из latest до обновления симлинка, а явно: последний каталог с датой, который не равен сегодняшнему. Если ночной прогон перезапустили дважды за сутки, второй раз должен писать в тот же $TODAY, а не плодить 2026-08-27-1.

SRC=/var/www/site
ROOT=/backup/host-a
TODAY=$(date +%F)
DEST="$ROOT/$TODAY"
PREV=$(find "$ROOT" -mindepth 1 -maxdepth 1 -type d -name '20*' \
        ! -path "$DEST" | sort | tail -n1)

mkdir -p "$DEST"
RSYNC_OPTS=(-aH --numeric-ids --delete --one-file-system --partial)

if [ -n "$PREV" ]; then
  rsync "${RSYNC_OPTS[@]}" --link-dest="$PREV" "$SRC/" "$DEST/"
else
  rsync "${RSYNC_OPTS[@]}" "$SRC/" "$DEST/"
fi

ln -sfn "$TODAY" "$ROOT/latest"

Слэш после $SRC/ обязателен: копируем содержимое, а не каталог «site» внутрь слепка. Без слэша через год получите /backup/host-a/2026-08-27/site/... вперемешку со старыми прогонами, где слэш уже стоял.

По флагам, без которых потом больно:

• -a — права, времена, симлинки, устройства. Без этого слепок «как файлы», не «как система».
• -H — сохранить hardlink в источнике. Это не про --link-dest. Если на проде два имени на один inode, без -H в бэкапе станут две копии.
• --numeric-ids — uid/gid цифрами, без подстановки имён. На бэкап-сервере пользователь www-data часто другой uid. Без флага права «починятся» молча и неправильно.
• --delete — в новом слепке нет того, чего уже нет на источнике. Старые слепки это не трогает.
• --one-file-system — не уехать в /mnt, bind-mount и чужой NFS, который примонтировали «на пять минут».

ACL и xattr на нормальном сайте часто не нужны. Если нужны — добавляю -AX, и проверяю, что приёмник их умеет. На копии «через промежуточный tar на FAT» они умрут, hardlink тут ни при чём.

Тянуть по SSH с другой машины — тот же набор, источник user@host-a:/var/www/site/. Ключ только для чтения нужных путей, не root с интерактивным шеллом «потому что так проще». Хостнеймы в скриптах и known_hosts — свои, не клиентские FQDN из тикета.

Что rsync считает «тем же файлом»

По умолчанию — размер и mtime. Совпали оба, содержимое не читает. Для дерева из сотен тысяч php/jpg это правильно: иначе каждую ночь будете гонять диск впустую.

Где это врёт:

• бэкап-скрипт или деплой делают touch по дереву — mtime новый, rsync решит, что всё изменилось, hardlink не состоится, слепок станет почти полным;
• наоборот: файл переписали, mtime оставили (редкость, но бывает у кривых копировщиков) — в слепке останется старое содержимое через hardlink;
• права/владелец поменялись, размер и mtime нет — с обычным -a rsync всё же обновит метаданные. С hardlink это тонкое место: смена владельца на inode видна во всех слепках, которые на него ссылаются. На практике для «сайт + загруженные картинки» почти не всплывает. На домашних каталогах с постоянным chown — всплывает.

--checksum лечит второй случай и наказывает диск. Я включаю его точечно, не «на всякий случай каждый день». Для проверки целого слепка после аварии — да. Для ночного прогона магазина с десятками гигабайт upload — нет.

Ещё одна мина: --inplace. Он пишет в существующий файл. Существующий файл в новом слепке после hardlink — это тот же inode, что вчера. --inplace вместе с --link-dest портит историю. Не включать.

Что не класть в слепок живьём

Rsync снимает файлы. Он не делает консистентный снимок СУБД и не понимает очереди почты.

MySQL/MariaDB: ночью mysqldump (или mariadb-dump) в файл, и в слепок идёт дамп, не /var/lib/mysql. Снимать datadir на работающем сервере — лотерея с битым InnoDB. Если очень нужен сырой datadir — только после FLUSH TABLES WITH READ LOCK / горячего снимка LVM/ZFS, и это уже другая схема, не «просто rsync».

PostgreSQL: pg_dump или pg_basebackup, не rsync по base/ на живой базе.

Сессии PHP, кэш, node_modules, очереди — либо exclude, либо смириться, что слепок на 80% состоит из мусора, который ещё и каждый раз «изменился». Типичный exclude для сайта:

/wp-content/cache/
/wp-content/uploads/cache/
/tmp/
/var/tmp/
*.log

Передаю через --exclude-from=/etc/backup/site.excludes. Не размазывать exclude по трём скриптам: через полгода никто не вспомнит, почему картинки из uploads вдруг не попали в слепок.

Полный бэкап системы — отдельный разговор. /proc, /sys, /dev, /run не снимают. --one-file-system как раз спасает от этого, если корневой слепок берёте с /. Загрузчик, UUID в fstab, криптозаголовки — rsync их «как файлы» скопирует, но загрузиться с такого каталога просто так нельзя. Для «откатить сайт» этого достаточно. Для «восстановить весь сервер» я не выдаю rsync-слепок за образ диска.

Место на диске: почему du врёт, если мерить по одному каталогу

Заходите в слепок — du -sh 2026-08-27 показывает почти полный размер сайта. Так и должно быть: внутри каталога почти все файлы «настоящие» с точки зрения дерева, просто inode общие с соседом. Смотреть надо сумму по корню и сравнение «по отдельности vs вместе»:

du -sh /backup/host-a
du -sh /backup/host-a/20*
du -sh --apparent-size /backup/host-a/20*

Первая строка — сколько занято уникальными данными. Список по датам — каждый слепок выглядит толстым. --apparent-size ближе к «логическому» объёму дерева. Если уникальный du по корню прыгает на размер всего сайта после очередной ночи — hardlink не сработал. Типичные причины: слепки на разных ФС, первый прогон без --link-dest в уже существующий каталог с другими inode, массовый touch, копирование через промежуточный диск без сохранения inode.

Иноды кончаются раньше байтов, если мелких файлов много. WordPress с кэшем и тучей php это умеет:

df -h /backup
df -i /backup

Если IUse% под 80%, а место ещё есть — либо чистить старые слепки, либо не снимать то, что exclude должен был отсечь.

Ротация у меня тупая и предсказуемая: хранить 7 дневных, плюс «первое число месяца», если место позволяет. Удалять целиком каталог даты, не файлы изнутри:

# всё старше 14 дней, кроме 01-го числа
find /backup/host-a -mindepth 1 -maxdepth 1 -type d -name '20*' \
  | sort | head -n -14 | while read -r d; do
      b=$(basename "$d")
      case $b in *-01) continue ;; esac
      rm -rf "$d"
    done

rm -rf по hardlink-дереву безопасен: уменьшает nlink, чужие слепки не трогает. Не делать chmod -R a-w по слепку «чтобы никто не правил». chmod пишет в inode. Общий inode — права поменяются и во вчерашнем слепке. «Защита от записи» — монтированием раздела ro на чтение, отдельным пользователем без записи, не chmod по живым hardlink.

Проверка restore: код 0 у rsync ничего не доказывает

Ночной прогон вернул 0. Это значит: rsync отработал. Это не значит, что из слепка поднимется сайт. Я отдельно гоняю проверку, хотя бы раз в неделю, на копию в песочницу, не на прод.

Минимум, который реально ловит беду:

SNAP=/backup/host-a/2026-08-27
TEST=/tmp/restore-test.$$
mkdir -p "$TEST"

# копируем, не линкуем: иначе снова общий inode
rsync -aH --numeric-ids "$SNAP/" "$TEST/"

# дерево не пустое, ключевые файлы на месте
test -s "$TEST/wp-config.php"
test -d "$TEST/wp-content/uploads"

# сравнение числа файлов — расхождение сразу видно
echo -n "snap:  "; find "$SNAP" -type f | wc -l
echo -n "copy:  "; find "$TEST" -type f | wc -l

# несколько случайных файлов — содержимое не нулевое и совпадает
find "$SNAP" -type f | shuf -n 20 | while read -r f; do
  rel=${f#"$SNAP"/}
  cmp -s "$SNAP/$rel" "$TEST/$rel" || echo "DIFF $rel"
done

Если это дамп базы — мало «файл не пустой». Нужен пробный импорт в отдельный экземпляр и SELECT COUNT(*) по жирной таблице, плюс открыть пару записей глазами. Дамп в 200 байт с ошибкой доступа тоже «файл на месте».

Если бэкап тянется по SSH — раз в неделю снимаю md5/sha256 списка ключевых файлов на источнике и в свежем слепке. Не всего дерева: достаточно конфигов, .env, пары известных загрузок. Расхождение mtime при том же содержимом меня не пугает. Расхождение содержимого — уже инцидент, даже если сайт «вроде открывается».

Что я ещё смотрю после ночного прогона, не дожидаясь недели:

• код выхода rsync и последние строки лога: rsync error, обрыв по SSH, vanished files пачкой;
• размер корня du -sh /backup/host-a относительно вчера — скачок на полный объём сайта;
• что симлинк latest указывает на сегодняшнюю дату, а не застрял на прошлой неделе;
• что в слепке нет пустого дерева из-за опечатки в источнике (rsync прекрасно синхронизирует пустой каталог и с --delete вычистит новый слепок подчистую, старые не трогая).

Пустой источник — отдельный класс аварии. Защита простая: если find "$SRC" -type f | wc -l меньше порога, скрипт выходит, не вызывая rsync. Порог свой для каждого дерева, не «больше нуля».

Типичные поломки, которые я уже не ищу по второму разу

Слэш и не тот каталог. Источник без завершающего /, destination уже с предыдущим мусором. Слепок «есть», сайта внутри нет, зато есть вложенная лишняя директория.

Два слепка на разных ФС. --link-dest молча деградирует в полное копирование. Лечится только тем, что df смотрят до, а не после письма «диск кончился».

Запуск от пользователя, который не читает часть дерева. Rsync пропускает файлы с Permission denied и в конце может вернуть код 23. Часть людей глотает 23 как «ну почти ноль». Для бэкапа 23 — это дырка. Либо root на чтение, либо доступ по группе, либо явный список, и код 23 будит, а не пишется в лог «на всякий случай».

Живая база в слепке. Сайт после restore «открывается», заказы за вчерашние полдня разъехались. Dump рядом со слепком файлов, одной датой.

chmod/chown по слепкам. История переписана во всех датах, которые делили inode.

Один и тот же destination каждый раз, а –link-dest в соседнюю копию «для экономии». Если destination не чистый каталог новой даты, а вечно живой /backup/current, вы снова приехали к схеме «есть только сегодня». --link-dest имеет смысл, когда новый слепок — новый каталог.

Cron в локальной полночи и пик записи на сайте. Для файлового дерева это обычно терпимо: максимум файл середины заливки. Для заказов и почты — нет. Файлы ночью, дамп базы в окно минимальной нагрузки, не наоборот.

Когда этого достаточно, а когда уже нет

rsync --link-dest хорошо закрывает: сайт, домашние каталоги, конфиги, каталог загрузок, «хочу зайти и забрать вчерашний wp-content». Прозрачность тут важнее степени сжатия. Я могу отдать человеку путь и сказать: копируй отсюда. Без fuse, без restic mount, без сюрприза «репозиторий не открывается, ключ от другого хоста».

Плохо закрывает: много маленьких постоянно меняющихся файлов (тотальный выигрыш hardlink падает), нужна дедупликация между разными машинами, нужен шифрованный репозиторий на чужой площадке. Туда Borg/restic. Не вместо проверки restore — поверх другой модели хранения.

Обёртки вроде rsnapshot делают ровно это же, плюс ротацию hourly.0. Если ставит человек, который не хочет писать скрипт — пусть ставит. Если уже наступил на chmod и на NFS, лучше свой скрипт на два экрана: в нём видно, куда смотреть, когда слепок внезапно стал полным по диску.

И последнее, без чего схему не считаю рабочей: хотя бы один успешный restore в отдельный каталог, с поднятым экземпляром или хотя бы с проверенным дампом. Пока этого не было, у вас не бэкап, а ночной rsync с красивыми датами на каталогах.

Типичная болячка платформы Zafira A / Astra G: в резиновой гофре между стойкой кузова и торцом двери переламывается жгут. Симптомы обычно по одной двери:

• стеклоподъёмник то работает, то нет;
• не отрабатывает ЦЗ этой двери;
• пропал или хрипит звук из этой двери (провода динамика идут тем же жгутом);
• на приборке нет индикации открытой двери.

Менять замок, мотор стеклоподъёмника и сам динамик чаще всего рано. Дверь изнутри разбирать не нужно: жгут от двери отстёгивается разъёмом на торце, а ремонтируется та часть проводки, которая уходит в кузов через гофру (стойка / порог).

Левая и правая — разные жгуты и разная распиновка. Чините правую — не копируйте цвета с левой.

Почему ломается

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

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

Что нужно

• мультиметр;
• пайка или медные гильзы + термоусадка;
• мягкий провод (силикон / фторопласт): сигнальные ~0.5–0.75 мм², силовые стеклоподъёмника заметно толще;
• по желанию — более мягкая гофра и смазка, чтобы при закрытии двери провода уходили в стойку, а не ломались в перегибе.

Минус АКБ снять сразу: толстый красный на мотор стекла часто под постоянным плюсом.

Как добраться до жгута (дверь не разбираем)

Всё делается снаружи торца двери и из салона у стойки.

1. Открыть заднюю дверь. На переднем нижнем торце — многоконтактная колодка, вокруг неё стопорное кольцо (часто синее).
2. Нажать/сжать кольцо и вытянуть разъём из двери. Дверь остаётся в сборе: обшивку, динамик, замок не трогаем.
3. Снять пластиковое кольцо/фиксатор, которым гофра держится на колодке.
4. Со стороны кузова освободить гофру из отверстия в стойке. При необходимости снять накладку порога / низ облицовки стойки — так жгут удобнее вытянуть в салон.
5. Вытянуть в салон именно кузовную часть жгута вместе с гофрой и осмотреть жилы. Удобный приём: после снятия разъёма слегка прикрыть заднюю дверь и работать из проёма передней — жгут подаётся вперёд, к обрывам проще подобраться.

Оборванный провод часто находится натяжением: целые держат, оборванный выезжает отдельно. Типичное место — зона постоянного перегиба в гофре.

До резки: фото колодки и маркировка каждого провода. Левый и правый жгуты потом легко перепутать.

Чем левая дверь отличается от правой

• на разборке жгуты идут отдельно «задняя левая» / «задняя правая»;
• свои цепи: мотор стекла, активатор ЦЗ, концевик, динамик — у сторон разные;
• расцветка тонких жил (особенно акустика и управление стеклом с водительского пульта) слева и справа не обязана совпадать — «по аналогии с другой дверью» как раз и ошибаются;
• общее у обеих: толстый красный (+) и толстый коричневый (масса) мотора стеклоподъёмника — силовая пара, её ломает чаще всего.

Типовая распиновка разъёма (ориентир)

Это колодка на стыке «дверь жгут в кузов». Ниже — рабочий ориентир по ролям контактов (LHD, типовая комплектация). Пустые номера — резерв/опции. Точные цвета тонких жил сверяйте на своей стороне двери.

Перед наращиванием: прозвонка от потребителя до обрыва и сверка цветов на стойке и на ответной части этой же двери. Силовую пару с сигнальными не путать. Даже если «умерло» только стекло — осмотрите соседние жилы.

Как ремонтировать

1. Вырезать повреждённый участок на кузовной стороне жгута (в зоне гофры / входа в стойку).
2. Вставить мягкий провод с запасом длины, чтобы жгут мог уходить в стойку при закрытии двери, а не стоять внатяг.
3. Стыки (пайка + термоусадка или обжим) вынести из зоны постоянного перегиба — внутрь стойки/порога, не оставлять «шишку» посередине гофры.
4. Собрать гофру, воткнуть разъём обратно в торец двери, проверить на этой двери: стекло, ЦЗ, звук, концевик.

Чтобы гофра снова не убила жгут: чуть смазки на провода и/или более мягкая гофра — при закрытии двери жилы должны ускользать в кузов, а гофра сжиматься сама.

Готовые ремкомплекты с маркетплейсов

Можно не нарезать провода вручную: на маркетплейсах продают готовые ремкомплекты жгута задней двери (мягкая проводка + разъём/пины под штатную колодку). У Опелей они с виду похожи, но не взаимозаменяемые вслепую.

• отличаются по поколению (Zafira A ≠ Zafira B, ловите дорест/рест);
• отдельно под левую и под правую заднюю дверь;
• сверьте фото разъёма и комплектацию в карточке со своей колодкой до заказа.

Берите ремкомплект именно под свою машину и именно под ту дверь, которую чините.

Итого: дверь не разбираем. Отщёлкнули разъём на торце, вытянули кузовную часть жгута из стойки, нарастили/поменяли участок в зоне гофры, собрали обратно. Левая и правая — разные жгуты; цвета с «другой стороны» не копировать.

На виртуалке load врёт чаще, чем на железе. Он не отделяет «мои процессы жрут CPU» от «диск лёг» и от «гипервизор забрал кванты времени у соседа». Если не разложить эти три штуки, будете лечить не того.

Что на самом деле считает load average

Load — это не «загрузка процессора в процентах». Это средняя длина очереди: сколько задач либо готовы бежать на CPU, либо спят в uninterruptible sleep (состояние D, обычно ожидание диска или NFS).

Поэтому картина «load 12 при 70% idle» на двух ядрах — нормальная, если в D висит десяток php-fpm, а диск отвечает по 80–200 мс. Процессор свободен, очередь растёт. С steal time та же история: задача хочет CPU, гипервизор её не планирует, очередь тоже растёт, а в top вы видите idle плюс st.

Смотрю сразу три числа: load за 1/5/15 минут и сколько ядер (nproc). Load 4 на четырёх ядрах — ещё можно жить. Load 4 на одном vCPU уже несколько минут — уже инцидент. Пятнадцатиминутный load запаздывает: если тормоза начались три минуты назад, ориентируйтесь на единицу и на живые счётчики, не на «среднее за четверть часа».

Три столбца в top, без которых диагностика — гадание

В шапке top (клавиша 1 включает разбивку по ядрам) мне важна строка CPU:

%Cpu(s):  8.4 us,  3.1 sy,  0.0 ni, 41.0 id, 27.2 wa,  0.0 hi,  1.1 si, 19.2 st

Коротко по делу:

• us + sy — ваши процессы реально крутят код. Вот это «нехватка CPU у приложения».
• id — простой. Высокий idle сам по себе ничего не лечит и ничего не доказывает.
• wa — iowait: процессор свободен, но есть незавершённый I/O. Это не «диск загрузил CPU», это ожидание.
• st — steal: гипервизор отдал эти тики не вам. Ваша виртуалка хотела считать — ей не дали.
• si — softirq. Если внезапно большой на фоне сети, смотрю пакеты и netfilter, а не PHP.

Правило, которым я пользуюсь в первые 30 секунд: если us+sy низкие, а load высокий — это не «надо больше ядер приложению». Это либо диск, либо гипервизор, либо cgroup-троттлинг, который в st может вообще не попасть.

Steal time: когда виноват не ваш код, а сосед по ноде

Steal — доля времени, когда vCPU был готов работать, но гипервизор забрал слот. На нормально выделенном KVM с гарантией CPU st обычно около нуля, редкие всплески на 1–2% можно не драматизировать. На дешёвых VPS вечером я регулярно вижу 10–30% steal пачками по несколько минут. Формально у вас «2 ядра», фактически в этот момент — полтора или меньше.

Как это ощущается снаружи: сайт отвечает рывками, CPU в панели хостера «зелёный», процессы в top не жрут по 100%, латентность прыгает без изменения трафика. Внутри в это же время растёт очередь PHP/очередь диска — не потому что MySQL внезапно стал писать в десять раз больше, а потому что кванты CPU приходят дыряво.

Подтверждаю не одним кадром top, а рядом:

nproc
uptime
mpstat -P ALL 1 30
vmstat 1 30

В mpstat смотрю столбец %steal по каждому vCPU. Если steal сидит на всех ядрах стабильно выше примерно 5–8% и при этом %usr/%sys не упёрлись в потолок — это не ваше приложение «уперлось в CPU». Это нода. Если steal скачет нуль–сорок нуль–сорок синхронно на всех vCPU — классика оверселла, «шумный сосед» или ночной бэкап гипервизора.

В vmstat те же буквы в последнем столбце st, плюс r (run queue) и b (blocked on IO). Высокий r при низком us и ненулевом st — задачи ждут планировщика, а не вашего кода.

Важный нюанс: на части облаков CPU режут не через steal, а через кредиты/квоты. Тогда st может быть нулевым, а приложение всё равно ползёт. Это уже следующий раздел, не путайте с «честным» KVM-steal.

Iowait: load большой, процессор скучает, диск не отвечает

Вторая частая ловушка. Load 10, idle 60%, wa 30–40%. В ps куча процессов в D. Человек видит load и думает «CPU». Нет: очередь — на I/O.

ps -eo pid,user,state,wchan:24,etime,cmd | awk 'NR==1 || $3 ~ /D/'
iostat -xz 1 20
vmstat 1 20

В iostat мне важны не «красивые» MB/s, а await, aqu-sz и %util. Если на vda/vdb await уехал в десятки–сотни миллисекунд при скромном объёме записи — это не «MySQL плохо настроен», это сторадж ноды. На дешёвом VPS диск почти всегда общий. Сосед запустил бэкап — ваш InnoDB начинает ждать fsync.

Отдельно проверяю swap:

free -h
vmstat 1 10

Ненулевые si/so в vmstat плюс высокий iowait — это уже не «мало CPU», это память кончилась и система молотит страницы. Добавление ядер тут бесполезно. И увеличение pm.max_children в такой ситуации обычно делает хуже: больше процессов — больше давления на диск и RAM.

NFS, CIFS, зависший iSCSI дают ту же картину: D-state, растущий load, CPU почти idle. wchan в ps часто прямо намекает (io_schedule, nfs, wait_on_page). Не лечите это рестартом php-fpm, пока не поняли, на чём они спят.

Реальная нагрузка: когда процессы правда жрут CPU

Это самый скучный и самый честный случай. us+sy под 80–100% на всех ядрах, steal около нуля, iowait низкий, в top по CPU видны конкретные pid: php-fpm, mysqld, node, python. Load примерно согласован с числом ядер и run queue.

Тогда уже имеет смысл:

pidstat -u 1 10
ps -eo pid,user,pcpu,pmem,cmd --sort=-pcpu | head
# если есть perf и можно ненадолго:
# perf top -g

Искать медленный запрос, воркера без лимита, cron, который внезапно переложил всю таблицу. Здесь апгрейд CPU поможет. На steal и на дохлый диск — нет, вы просто будете дороже ждать то же самое.

Не путайте короткий всплеск (деплой, прогрев кэша, один тяжёлый отчёт) с системной нехваткой. Смотрите 5-минутное окно, не один кадр.

Четвёртая ловушка: cgroup throttle без steal

На контейнерах (LXC, часть «VPS из панели», Kubernetes) CPU часто режут квотой cgroup, а не классическим steal. В top тогда st=0, idle может быть приличным, а латентность всё равно плохая: вас просто не пускают на CPU сверх квоты.

На cgroup v2:

cat /sys/fs/cgroup/cpu.stat
cat /sys/fs/cgroup/cpu.max
cat /proc/pressure/cpu

В cpu.stat смотрю nr_throttled и throttled_usec. Если throttled растёт на глазах — вас режут. cpu.max вида 20000 100000 на двух видимых vCPU означает, что «два ядра» в nproc — картинка, а лимит другой.

PSI (/proc/pressure/cpu и io) удобен тем, что показывает stall some/full за 10/60/300 секунд. full по CPU — никто не мог работать. Это ближе к правде, чем load, когда хочется понять «прямо сейчас нас душили или пять минут назад».

На старых OpenVZ/Virtuozzo картина ещё мутнее: иногда steal есть, иногда только failcnt в beancounters. Если попали на такое — не делайте выводы по одному top, смотрите лимиты панели и cpu.stat.

Порядок, которым я отличаю гипервизор от реальной нагрузки

Не распухающий чеклист, а последовательность на пять минут.

1. Снять размер машины и load: nproc, uptime, free -h. Понять, не swap ли это вообще.
2. Живой top, клавиша 1. Записать us/sy/id/wa/st. Не скриншот «процессы», а шапку CPU.
3. mpstat -P ALL 1 30 и vmstat 1 30 — steal стабильный или вспышками, run queue, blocked.
4. Если wa заметный — iostat -xz 1 20 и список D-процессов с wchan.
5. Если st≈0 и CPU не упирается — cpu.stat / cpu.max / /proc/pressure/cpu.
6. Только если us+sy высокие и лимиты не душат — иду в pidstat и уже в приложение.

За эти пять минут обычно ясно, в какую из четырёх корзин класть инцидент. Дальше уже либо тикет хостеру с цифрами, либо диск, либо квота, либо профилирование PHP/SQL.

Что не делать, пока не поставили диагноз

Не поднимать pm.max_children «чтобы очередь рассосалась». На iowait и на steal это увеличивает очередь, а не уменьшает.

Не добавлять swap «для запаса», если si/so уже ненулевые. Вы лечите нехватку RAM ещё большим iowait.

Не рестартить MySQL по кругу, если await диска сотни миллисекунд. Рестарт в этот момент — лотерея с порчей и долгим recovery.

Не просить «ещё два ядра» у хостера, имея на руках только load average. Load на оверсолде растёт и от steal, и от диска. Без mpstat/iostat вам продадут тот же оверсолл подороже — или, что чаще, просто перекинут на такую же ноду.

Как разговаривать с хостером, чтобы это не было «сайт тормозит»

Тикет без цифр на оверсолде заканчивается шаблоном «на ноде всё хорошо, смотрите приложение». Я прикладываю 30 секунд mpstat -P ALL, кусок vmstat, если надо — iostat, время (UTC), и формулировку в духе: «на 2 vCPU стабильно %steal 15–25 при %usr+%sys < 30, load растёт, iowait такой-то. Прошу проверить contention на ноде / переезд». Не имена клиентов, не внутренние IP, не «у нас прод упал».

Если хостер нормальный, на устойчивом steal они переезжают. Если нет — имеет смысл менять площадку, а не тюнить opcache. Оптимизация приложения на 10% не лечит потерю четверти CPU каждую минуту.

Для себя оставляю те же логи локально на время разбора. Через час steal может исчезнуть, и вы останетесь с «ну у нас сейчас всё зелёное».

Коротко: как не перепутать корзины

Реальная нагрузка: us+sy высокие, st≈0, wa низкий, в top видны конкретные процессы. Лечите код, запросы, лишние воркеры. Ядра помогут.

Нехватка CPU у гипервизора: st стабильно заметный, us+sy не упираются, load и латентность прыгают без роста трафика. Лечите площадку, не php.ini.

Диск: wa высокий, процессы в D, await большой. Часто на тех же дешёвых VPS соседствует со steal — нода оверsold и по CPU, и по стораджу. Сначала цифры, потом выводы.

Квота cgroup: st=0, cpu.stat throttled растёт, PSI full по CPU. «Два ядра» в панели ≠ два ядра в планировщике.

Пока эти четыре строки не разложены, любой совет «увеличьте лимиты PHP» — гадание. Снимается это стандартными утилитами за несколько минут, без агентов и без панелей. Панель хостера в этот момент почти всегда врёт в оптимистичную сторону: она рисует «выданные» ядра, а не те, которые вам реально отдали.