Diagnosing missing inbound peers on a Bitcoin node
A Bitcoin node behind a router can download blocks through outbound connections while accepting no inbound peers. Start with the direction of the connections before changing firewall rules.
Separate inbound and outbound traffic
bitcoin-cli getnetworkinfo | jq '{networkactive, connections_in, connections_out}'
bitcoin-cli getpeerinfo | jq 'group_by([.network, .inbound]) | map({network: .[0].network, inbound: .[0].inbound, count: length})'
The first command tells you whether peer networking is active. The second groups individual peers by transport network and direction without printing their addresses. For example, eight outbound IPv4 peers and zero inbound peers show that the node established connections successfully. This sample alone cannot tell you whether a remote peer ever tried to connect.
Test reachability from outside
If the node should accept public IPv4 peers, inspect its P2P listening address and port on the host. Trace that same port through the host firewall and the router's forwarding rule. From a second host outside that network, test a TCP connection to the advertised P2P address. A successful TCP connection establishes transport reachability. To verify the Bitcoin handshake, connect a second Bitcoin node and inspect getpeerinfo on the receiver.
Use the P2P listener for this test. The RPC listener serves administrative requests. A host configured to accept peers through an onion service also needs a reachability test through Tor, since the IPv4 test covers a different route.
bitcoincore.org getnetworkinfo · bitcoincore.org getpeerinfo