Why Is My Bitcoin Node Not Reachable?

Separate node health from inbound reachability

An unreachable result means Atlas did not complete the expected handshake from its server. It does not establish that your node is broken or unable to validate. A node may have outbound peers and keep up with the chain while rejecting unsolicited inbound connections.

Do not reinstall Bitcoin Core or delete blockchain data as your first response. First establish whether the process is running, whether it has peers, and whether synchronization is progressing. These observations distinguish an application problem from an inbound network problem.

Start on the node itself

Inspect Bitcoin Core's interface or local diagnostic commands. Check disk space and logs for errors. On Linux, inspect listening sockets with your operating system's socket tools; confirm the P2P listener is bound as intended rather than only to a loopback address.

1. Confirm Bitcoin Core is running, not sleeping or exiting after an error.
2. Check that initial block download is progressing, or that the node is near the current tip.
3. Confirm the configured network and P2P port; mainnet normally uses 8333.
4. Check listening settings and connection limits.
5. Confirm you submitted the current public address rather than a private LAN address.

Check the host firewall

Allow inbound TCP only to the intended P2P port if public service is your goal. Review both operating system rules and any endpoint security software. A cloud server can also have a provider firewall separate from its host firewall.

Do not disable all filtering to make a test pass. Do not expose RPC, remote desktop or other management interfaces. If a narrow rule does not help, move to the routing checks rather than opening more ports.

Check the router and provider

For IPv4 NAT, verify that the forwarding rule points to the node's current LAN address. A DHCP change can leave a correct-looking rule forwarding to an old machine. Testing a public address from inside the same LAN may also depend on router loopback support; Atlas provides an external vantage point.

Double NAT or CGNAT can prevent inbound IPv4 even with a correct local rule. Read the port 8333 guide's CGNAT section and check your provider's inbound connectivity options. For IPv6, confirm a public address, inbound firewall permission and functioning IPv6 routing.

Retest conservatively and interpret the outcome

Change one setting at a time and allow the process and network to settle. Peer limits, transient congestion or the checker server's connectivity can cause occasional failures. Repeated rapid checks do not make the diagnosis better.

After a success, review the host and port shown in the result and leave only the intended P2P access enabled. If the check remains unsuccessful but outbound peers and sync work, you can continue operating outbound-only. Tor/onion tests depend on explicit support at the checker and are not a substitute for clearnet routing diagnostics.

Official references

Check settings against your installed release. The Bitcoin full node guide explains operation and connectivity; Bitcoin Core downloads includes verification instructions. For sync diagnostics, consult the versioned getblockchaininfo reference and your release's built-in help.