Экспресс-проверка живости ноды

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

Логика проверки: сверху вниз

Не тычь наугад. Причины «не работает» лежат слоями, и проверять их надо по порядку от самого грубого к самому тонкому: жив ли сервер → отвечает ли порт → запущен ли xray → идёт ли трафик наружу → не задушен ли он именно под РФ. Каждый пройденный слой отсекает целый класс гипотез. Если остановился на каком-то шаге — дальше не идёшь, чинишь тут. Ниже ровно этот порядок.

Шаг 1: жив ли сам сервер

Сначала самое тупое — пингуется ли машина и открыт ли SSH. Если нет, дальше можно не смотреть:

ping -c3 SERVER_IP
nc -w3 -vz SERVER_IP 22 && echo "ssh отвечает"

Пинг может резаться файрволом при живом сервере — это нормально, ориентируйся на порт 22. Не открыт ни пинг, ни SSH — иди к панели хостера смотреть, не выключилась ли VM и не кончился ли баланс.

Шаг 2: отвечает ли рабочий порт

Теперь порт, на котором висит вход (обычно 443). Открыт снаружи — уже хорошо:

nc -w3 -vz SERVER_IP 443 && echo "443 открыт"
# и как это выглядит для DPI: должно вести себя как обычный сайт-донор
curl -sI https://your-domain.com | head -1

curl на Reality-домен должен вернуть строку статуса живого донора, а не повиснуть и не отдать что-то странное. Повисло — либо донор сдох, либо на порту не то, что ты думаешь.

Шаг 3: жив ли xray на ноде

Порт может держать что угодно, поэтому лезем на сервер и смотрим сам процесс и его логи:

systemctl status xray --no-pager | head -5
journalctl -u xray -n 20 --no-pager

Ищем active (running) и отсутствие свежих ошибок рестарта. Частый симптом — xray падает на старте из-за недоступного сертификата или битого конфига; это видно прямо в логе. В докерной ноде смотри логи контейнера:

docker logs --tail 30 remnanode 2>&1 | tail -30

Шаг 4: идёт ли реальный трафик наружу

Самое важное и самое пропускаемое. Открытый порт и живой процесс не значат, что туннель возит, — конфиг мог остаться без outbounds, и клиент авторизуется, но трафик дохнет. Проверяем реальный egress через локальный клиент, поднятый на плитку этой ноды:

# через socks локального клиента на этой ноде (порт 10808):
curl -s --max-time 8 --socks5 127.0.0.1:10808 https://api.ipify.org; echo

Вернулся внешний IP выхода — трафик реально ходит, нода живая. Пусто, таймаут или «failed to transfer payload» в логе при живом хендшейке — почти всегда пустые/битые outbounds в профиле. Это тот случай, когда «подключается, но интернета нет».

Шаг 5: не задушен ли выход под РФ

Нода может быть жива в мире и зарезана ТСПУ именно для российских клиентов — с самого сервера этого не увидишь. Прогони серию проб сквозь туннель с российской точки (свой РФ-узел или сервер) и посчитай процент удачных:

# запускать с РФ-точки, через её socks на плитку ноды (порт 10808):
ok=0
for i in $(seq 1 12); do
  code=$(curl -s -o /dev/null -w "%{http_code}" --max-time 5 \
    --socks5 127.0.0.1:10808 https://www.gstatic.com/generate_204)
  [ "$code" = "204" ] && ok=$((ok+1))
done
echo "живых проб: $ok/12"

Меньше половины удачных при открытом порте — нода душится под РФ, даже если из мира всё зелёное. Порт отвечает, но полоса задавлена — это и есть та разница, которую глобальный мониторинг не ловит. Лечится ротацией входа или уходом за CDN, но это уже отдельная тема.

Итог: пять минут по порядку

• Сервер — пинг/SSH; мёртв → к панели хостера.
• Порт — 443 открыт и ведёт себя как донор.
• xray — active (running), в логе нет падений на старте.
• Egress — реальный внешний IP через socks; пусто → пустые outbounds.
• РФ-душение — серия проб с РФ-точки; <6/12 → входной IP жгут.

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