A Node Liveness Quick Check

Half of "not working" tickets are solved by a five-minute check in order — from "is the server even alive" to "is real traffic flowing out." I'll show the checklist I run a node through top to bottom: each step cuts off a whole class of causes, and by the fifth command you already know where it broke. The commands work.

This material is about engineering your own network infrastructure and is educational. You comply with the laws of your jurisdiction yourself.

The logic: top to bottom

Don't poke at random. The causes of "not working" sit in layers, and you check them in order from the crudest to the finest: is the server alive → does the port answer → is xray running → is traffic flowing out → is it being throttled specifically under RF. Each layer you clear cuts off a whole class of hypotheses. If you stop at some step — you don't go further, you fix it here. Below is exactly that order.

Step 1: is the server itself alive

First the dumbest thing — does the machine ping and is SSH open. If not, there's no point looking further:

ping -c3 SERVER_IP
nc -w3 -vz SERVER_IP 22 && echo "ssh responds"

Ping can be cut by a firewall while the server is alive — that's normal, go by port 22. Neither ping nor SSH open — go to the host's panel and check whether the VM shut off or the balance ran out.

Step 2: does the working port answer

Now the port the entry sits on (usually 443). Open from the outside — already good:

nc -w3 -vz SERVER_IP 443 && echo "443 open"
# and how it looks to DPI: it should behave like an ordinary donor site
curl -sI https://your-domain.com | head -1

A curl to the Reality domain should return the status line of a live donor, not hang or hand back something strange. If it hangs — either the donor died or what's on the port isn't what you think.

Step 3: is xray alive on the node

The port could be holding anything, so get onto the server and look at the process itself and its logs:

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

Look for active (running) and the absence of fresh restart errors. A common symptom — xray crashes on start because of an unreachable certificate or a broken config; you can see it right in the log. On a dockerized node, check the container logs:

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

Step 4: is real traffic flowing out

The most important and most skipped one. An open port and a live process don't mean the tunnel carries traffic — the config could have ended up with no outbounds, and the client authenticates but the traffic dies. Check the real egress through a local client stood up on this node's tile:

# via the local client's socks on this node (port 10808):
curl -s --max-time 8 --socks5 127.0.0.1:10808 https://api.ipify.org; echo

The exit's external IP came back — traffic really flows, the node is alive. Empty, a timeout, or "failed to transfer payload" in the log with a live handshake — almost always empty/broken outbounds in the profile. This is the case of "connects, but no internet."

Step 5: is the exit throttled under RF

A node can be alive to the world and cut by TSPU specifically for Russian clients — you won't see that from the server itself. Run a series of probes through the tunnel from a Russian point (your own RF node or server) and count the success rate:

# run from an RF point, via its socks to the node's tile (port 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 "live probes: $ok/12"

Fewer than half succeeding with an open port — the node is being throttled under RF, even if everything's green from the world. The port answers but the bandwidth is choked — that's the very difference global monitoring doesn't catch. It's cured by rotating the entry or going behind a CDN, but that's a separate topic.

Bottom line: five minutes in order

• Server — ping/SSH; dead → to the host's panel.
• Port — 443 open and behaving like a donor.
• xray — active (running), no start-time crashes in the log.
• Egress — the real external IP via socks; empty → empty outbounds.
• RF throttling — a probe series from an RF point; <6/12 → burn the entry IP.

Run it top to bottom, and on any ticket you'll know in five minutes exactly which layer broke, instead of guessing and restarting everything at random.