Feeler Connection

A feeler connection is a short-lived, single test connection that a Bitcoin Core node opens roughly once every two minutes to an address drawn from the "new" table of its Address Manager. Its sole job is to check whether that address belongs to a reachable, running Bitcoin node. If the handshake succeeds, the address is promoted into the "tried" table and the feeler is immediately closed — no blocks, no transactions, no lingering session. It is the network equivalent of knocking on a door to confirm someone actually lives there.

Keeping the tried table fresh

The Address Manager's two-table design separates hearsay from experience: the "new" table holds addresses your node has merely heard about through gossip, while the "tried" table holds addresses it has personally connected to. Without feelers, the tried table would only ever be updated by full outbound connections, which a node makes rarely — outbound peers are deliberately long-lived. Over months, the table would silt up with stale entries for nodes that have long since gone offline. By continuously probing "new" addresses in the background, feelers ensure that when the node next needs an outbound peer — after a restart, or when a peer disconnects — it chooses from a pool of recently verified, genuinely online nodes rather than gambling on rumors. The process is deliberately gentle: only one feeler runs at a time, and feelers are only attempted once all regular outbound slots are already filled, so the mechanism never competes with real connectivity.

An eclipse-attack countermeasure

Feelers were added to Bitcoin Core as one of the defenses recommended by the 2015 academic work on eclipse attacks. The attack's core move is table poisoning: flood a victim's Address Manager with attacker-controlled or dead addresses, then wait for a restart, after which the victim's outbound connections land disproportionately on attacker nodes. Feelers blunt this by ensuring the tried table — the preferred source for outbound selection — contains addresses that answered a real handshake recently. An attacker must now run actual, reachable infrastructure at every address they seed, rather than stuffing the tables with fiction, which multiplies the cost of mounting the attack. Feelers work alongside block-relay-only connections and anchor peers as complementary layers of eclipse-attack resistance.

What this means for a home node

Nothing to configure, and that is the point: the defense works precisely because it is automatic and universal. If you watch your node's logs or peer list, you will occasionally catch a connection flagged as feeler appearing and vanishing within seconds — expected behavior, not a probe from an attacker. For the sovereign operator whose node validates their money and feeds work to their miners, feelers are part of why "just leave the node running" is sound advice. The longer it runs, the more battle-tested its address book becomes, and the harder it gets for anyone to curate the set of peers through which you see the Bitcoin network.

Spotting feelers in diagnostics

Feelers are visible if you know where to look. Peer listings in Bitcoin Core expose a connection type field, and a feeler shows up with connection_type set to feeler — though you have to catch it in the act, since the connection typically lives for only a second or two. In debug logs, the pattern is a steady drumbeat of brief outbound attempts, many of which fail; a high failure rate is normal and expected, because the "new" table is full of hearsay addresses that were never guaranteed to be real. This matters practically when reading firewall or router logs: a healthy Bitcoin node generates a continuous trickle of short-lived outbound connections to ever-changing addresses, which can look alarming to intrusion-detection tooling. It is not malware beaconing — it is your node doing its due diligence, one two-minute knock at a time, so its address book stays honest.