TinyExplorer Every Grin block, one link away.

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 checks both halves from where it sits: it POSTs get_tip to your wallet API, and it opens a TCP connection to the P2P port on 3414. You get a separate answer for each — they fail independently, and a node with one open and the other closed is usually configured that way on purpose.

Give a host name and the API is checked over HTTPS on 443, because that is where a node published through nginx actually answers. Give a bare IP and it is checked on 3413, because an address with no name has no certificate to present. Either assumption is one click to undo, and typing an explicit port or scheme overrides both.

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
P2P port
● API 443 · name — 3413 · IP + P2P 3414 · one attempt each
What "reachable" means here — and what it does not
  • The two legs prove different amounts, and are labelled differently. The API leg says answered get_tip — that is proof of a Grin node. The P2P leg says port open and never more than that: it is a bare TCP connection that sends no bytes and reads none, so all it establishes is that something accepted a connection there. Reading the two as equally strong is the one mistake this page is built to prevent.
  • 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 the API leg 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. And since a bare TCP accept is weaker evidence than an HTTP 200, the P2P leg never claims a node at all.
  • One open and one closed is not a failure. A node published to serve wallets may answer on 3413 with 3414 firewalled. A node that only peers may do exactly the reverse — and that is the safer of the two to leave closed. This page reports those as configurations, not errors; only both closed is a red ✕.
  • 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 — on either leg. Refused means the host answered and nothing is listening on that port — usually the node is down or bound to localhost. Filtered means nothing answered at all, which is what a firewall dropping packets looks like. For a P2P port that second one is the commonest real answer, because forwarding 3414 is a step people skip.
  • 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.
  • Both legs go through the same gate, and the P2P port is not yours to choose. The address is checked once and both legs dial that same cleared address. The API port is whatever you typed; the P2P port is only ever 3414 or 13414 — a connect-only probe on an arbitrary port would be a port scanner, and this is deliberately not one.
  • Redirects are not followed and the reply is size-capped. One request per leg, no retry, five seconds for the API and four for the connect. The P2P probe sends nothing and closes the moment it has its answer.
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 accept inbound peers and contribute to the chain. The API on 3413 (testnet 13413) is what a wallet dials. This tool checks both, and reports them apart — because they are opened separately, they break separately, and neither one answers the other's question.
  • Which P2P port gets dialled is never guessed from the host name. On Auto the only signal used is a port you typed yourself: give :13413 and the testnet P2P port 13414 is checked. Type a bare host name and mainnet 3414 is assumed — say so with the Testnet button if that is wrong, or a closed testnet node will be reported against a port it never opened.
  • 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 — and that is the default. A node fronted by nginx on 443 is checked over HTTPS with the certificate verified, exactly as a wallet would. Typing a bare name gets that endpoint, because it is what Script 04 deploys; typing name:3413 gets the direct port instead, and a failed guess offers the other form in one click.