Part of the Build a Bitcoin Node pathway. Use the guide library to follow another setup path.
What port 8333 does
TCP port 8333 is Bitcoin mainnet's default peer-to-peer listening port. Peers use that connection for the Bitcoin protocol. It is not a web page, wallet login or remote administration endpoint; opening it in a browser is not a reliable node test.
RPC is a different interface. Do not forward or publicly expose RPC as part of P2P setup. A node can validate through outbound peers without accepting inbound connections, so public port forwarding is a choice rather than a prerequisite for running a full node.
IPv4 router forwarding
On a typical home IPv4 network, your node has a private LAN address and the router has an internet-facing address. A forwarding rule sends inbound TCP connections on a selected public port to the node's LAN address and listening port. Router interfaces differ; use the vendor's instructions for your model.
- Confirm Bitcoin Core is running and configured to listen for inbound peers.
- Reserve a stable LAN address for the node in the router.
- Forward only the intended TCP P2P port to that address.
- Allow that port in the host firewall without disabling the whole firewall.
- Test the public address from outside the LAN with the node running.
- Remove rules you no longer need and keep RPC private.
IPv6 and host firewalls
A globally routable IPv6 address often does not need IPv4-style NAT forwarding, but the router and operating system may still block inbound traffic. Create a narrow rule for the node's P2P port instead of turning off filtering. IPv6 addresses and temporary address policies can change, so confirm the address you are checking.
Use brackets when combining an IPv6 address and port, such as [IPv6-address]:8333. In separate fields, enter the host without brackets and the port separately. A public IPv6 address still requires working IPv6 routing from the checker to your node.
CGNAT and double NAT
Some providers place subscribers behind carrier-grade NAT, so your router does not control the public IPv4 address. Forwarding on your router alone cannot open the provider's upstream NAT. Another router in the home can create double NAT with a similar symptom.
Compare your router's WAN status with the address your provider says is assigned and ask whether inbound public IPv4 is supported. A provider-supported public address or usable IPv6 may help. You can also keep outbound-only operation. Do not keep broadening firewall rules to compensate for an upstream routing limitation.
Interpret the reachability check
Atlas attempts a bounded Bitcoin P2P handshake from its server. Success confirms that exchange at that moment. It does not prove uptime, a completed sync, correct wallet configuration or security of the host.
A failure can reflect timeout, peer limits, routing, a firewall, an offline process or a wrong address. Record the time and exact configuration you intended to test, change one variable, and test again conservatively. Tor reachability uses a different network path and depends on checker support.
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.
Ready to test inbound P2P access? Check whether your Bitcoin node is reachable. To interpret what Atlas sees, explore observed Bitcoin nodes and our methodology.