Grin Node Reachability Checker

You opened the port and the node says it is listening — but the only way to know whether the world can reach it is to ask from outside. Enter your host and this server POSTs get_tip to /v2/foreign from where it sits, and tells you exactly what came back.

This check is made by this server, not by your browser. The host you type is sent here, and the request to your node comes from this machine's address — which is the point: a test from your own network would answer a different question. Nothing about the host you enter is written to any log.

Node host

● Default port 3413 · one attempt · 5 s

What "reachable" means here — and what it does not

An HTTP 200 proves nothing. A parked domain, a CDN error page and a router login form all answer 200 on port 443. This tool only calls a node reachable when it POSTs get_tip and gets back an unwrapped {"Ok":{…}} with a real tip height in it — which is also why a plain GET in your browser tells you nothing: /v2/foreign is POST-only JSON-RPC.
Peer count and sync state are not knowable from outside. They live on the Owner API, and a node published for the public exposes /v2/foreign and refuses /v2/owner — as it should. So this page reports them unavailable. It will never print 0 peers for them: a zero would read as an idle node, when the truth is that the question cannot be asked from here.
A refusal and a timeout mean different things. Refused means the host answered and nothing is listening on that port — usually the node is down or bound to localhost. Timed out means nothing answered at all, which is what a firewall dropping packets looks like.
Reachable today is not reachable tomorrow. This is one probe at one moment, from one address. It says nothing about your peer count, your bandwidth, or whether your host will still route in an hour.

Why private addresses are refused

This server can reach places you cannot. It sits on a machine with its own loopback and its own LAN. Left open, a checker like this becomes a way to ask it "what is on 127.0.0.1:3413?" or "what is on 192.168.1.1?" — with the answers relayed back to a stranger. So the host is resolved first, and if the address it resolves to is loopback, RFC1918 private, link-local, carrier-grade NAT or an IPv6 equivalent, the request is never made.
The name is not what gets checked — the address is. Anyone can point a public host name at 127.0.0.1; that is a legal DNS record, not a trick. The check therefore runs on what DNS actually returned, and the connection is then made to that same address rather than looking the name up a second time.
Checking your node from your own LAN answers a different question. If your node is at 192.168.x.x, what you want to know is whether your router forwards the port — so enter the public host name or IP that should reach it.
Redirects are not followed and the reply is size-capped. One request, one answer, five seconds, no retry.

Running a public Grin node

3414 is the port that matters for the network; 3413 is the one for wallets. P2P runs on 3414 (testnet 13414) and is how you contribute to the chain. The API on 3413 (testnet 13413) is what a wallet dials — this tool checks the API, because that is the one people publish and the one that breaks quietly.
Publish the Foreign API only. /v2/foreign serves public chain data. /v2/owner manages the node and must never face the internet — if this tool reports your node reachable, check that /v2/owner answers 403 from outside too.
Behind TLS, use the host name. A node fronted by nginx on 443 is checked over HTTPS with the certificate verified, exactly as a wallet would.