NAT
What --nat really controls
The --nat option controls how Erigon advertises its external address to other peers in the Ethereum P2P network.
It does not:
- open firewall ports for you
- guarantee inbound connectivity by itself
- directly control peer count
Instead, it determines whether other nodes can initiate inbound connections to your node, which has a significant impact on:
- peer diversity (inbound vs outbound)
- transaction gossip freshness
- block content quality for validators and block producers
Why NAT configuration matters more than peer count
Ethereum P2P is bidirectional:
- your node connects outbound to peers
- other nodes may connect inbound to you
Nodes that are reachable from the internet (i.e. correctly advertised via Network Address Translation (NAT)) tend to:
- receive transactions earlier
- receive a wider variety of transactions
- maintain a healthier "pending" transaction pool
For validators and block producers, this directly affects:
- transaction inclusion
- gas usage
- likelihood of producing empty or low-gas blocks
A high peer count alone does not guarantee good transaction propagation if most peers are outbound-only.
NAT modes explained (practical behavior)
nat: none
Disables external address advertisement.
Erigon will not advertise a reachable address to peers. In practice, this often results in:
- mostly outbound connections
- few or no inbound peers
- delayed or stale transaction gossip
Important: nat: none is generally not recommended for validators or block producers, even if peer count appears high. It is primarily suitable for:
- private networks
- non-proposing archive / RPC nodes
- restricted environments where inbound connectivity is intentionally disabled
nat: extip: (recommended for datacenters & VPS)
Explicitly advertises the given public IPv4 address to peers.
This is the most reliable and deterministic option when:
- your node has a stable public IPv4 address
- required P2P ports are open in the firewall
Benefits:
- enables inbound peer connections
- improves transaction gossip freshness
- leads to a healthier TxPool "pending" state
- strongly recommended for validators
Example:
nat: "extip:203.0.113.114"
nat: any
Enables automatic NAT detection (e.g. Universal Plug and Play (UPnP) / NAT-PMP where available).
Suitable for:
- home networks
- environments where the external IP is not known in advance
Less deterministic than extip, but generally better than none.
nat: stun
Uses Session Traversal Utilities for NAT (STUN) to discover the external address.
Useful when:
- running behind NAT
- no UPnP is available
- external IP cannot be configured manually
Caplin (consensus layer) NAT
If you are running Erigon with the embedded Caplin consensus layer, configure NAT for the Consensus Layer (CL) P2P separately using --caplin.nat.
This flag sets the external address advertised in the discv5 Ethereum Node Record (ENR) and libp2p multiaddrs; the socket itself still binds to --caplin.discovery.addr. It accepts the same values as --nat:
| Value | Behavior |
|---|---|
"" (default) | No NAT mapping — CL peers cannot reach you inbound |
extip:1.2.3.4 | Advertise a fixed public IP — recommended for virtual private servers (VPS) / datacenters |
stun | Discover external IP via STUN |
upnp | Use UPnP to discover and map the port |
pmp | Use NAT-PMP; optionally pmp:192.168.0.1 to specify the gateway |
Set both --nat and --caplin.nat to the same external IP, otherwise your execution-layer peers and consensus-layer peers will see different (or no) reachable addresses.
UPnP and NAT-PMP gateway discovery do not cross Docker's default bridge network, so use extip or host networking in that setup.
--nat extip:203.0.113.114 --caplin.nat extip:203.0.113.114