Atlas selects relays using observed network performance, not a marketing region label. Every published relay is externally verified, cryptographically identified and removable from the map when it becomes stale.
Illustrative sample data—not a public status or SLA statement.
Relays self-register with region, addresses, version and identity. The control plane probes the claimed addresses from outside and only publishes a relay after successful verification.
Accurate mapping classification requires different destination IP addresses—not merely two ports. Each relay publishes one IPv4 observation address, and four of the five also publish IPv6; a node classifies its mapping by pairing two different relays, which always answer from different IP addresses.
Candidate relays are probed and peer pairs can deterministically converge on the same best shared set. A direct path remains additional to the configured relay count.
Heartbeats report liveness and load to the operator console, and a stale relay is dropped from the next signed map the operator mints — the map is signed outside the serving control plane, so publication changes are a deliberate operator action, never a server-side one. Established Atlas paths and cached maps remain independent of the directory either way.
Each node attaches to a relay near it, which keeps the first hop short where cellular uplinks, NAT bindings and lossy radios matter most. Nodes homed in different regions still reach each other, and neither end holds a session across the world to do it.
Both ends rank the relays they share by combined round-trip time, the full relayed path rather than either leg alone, and arrive at the same choice independently.
When a peer is on none of the relays a node holds, the node reads the peer’s sealed presence record and attaches to the relay the peer is on. The usual authenticated handshake follows.
Or the node stays on its own relay and marks its frames with a “via” hint naming the peer’s relay. Its relay forwards each frame once, over an authenticated relay-to-relay session, and the peer’s relay delivers it.
A frame that arrives from another relay is delivered or refused, never forwarded again.
Relay-to-relay traffic has its own rate limit for each relay pair, and every frame still counts against the sender’s session quota at both ends.
A relay-to-relay path crosses two relays, so it is used only with end-to-end sealing on, unless an operator allows otherwise.
Shared and relay-to-relay paths are ranked on one scale: the measured round trip from end to end, with the relay-to-relay leg taken from the published relay matrix. A path through two relays is chosen when it is the best one available, and the direct path stays on top of either.
Reaching a node in another region never requires a list of which node is on which relay, so no such list exists to be read, subpoenaed or leaked.
Every relay host also runs a hosted exit: an Atlas endpoint a phone or laptop can terminate its bonded tunnel on and reach the internet through, with the whole device routed through the bond and DNS kept inside the tunnel.
Exits are published in their own signed map with region, city and a load hint.
A client ranks exits by measured round trip, just as it ranks relays.
Los Angeles, New York, Zurich, Hong Kong and Sydney serve today.
An exit sits inside the tunnel, not beside it — what an exit can see. How exits are published, verified and chosen is on the engineering site.
Static relay configuration remains available even when automatic discovery is enabled, allowing public, private and mixed relay estates.
Use the signed public relay inventory and measured relay selection with no relay servers to operate.
Pin relay addresses and identities in configuration for sovereign or closed operational environments.
Keep an organization-controlled relay beside hosted geographic redundancy and direct connectivity.
Dedicated relay and observation nodes can run in your cloud accounts, data centres, field sites, or isolated operational zones. They are configured only for authorized Atlas nodes, are not published in the public signed map, and do not appear on the public live-network page.
Organizations can use a fully private estate or combine it with public geographic redundancy and direct paths. Identity pinning keeps trust independent of DNS and IP ownership in either model.
Apply as a pilot partner if you have a deployment ready to test, or start evaluating Nexus Atlas Traversal as a future customer. Tell us enough to understand the endpoints, carriers, regions, and operational constraints involved.
Run an early deployment with direct engineering contact and help shape priorities through real-world feedback.
Research architecture, security, deployment options, and commercial fit before committing to a pilot.
