Imagine two friends trying to pass notes in a room full of locked doors. They can't reach each other directly, so they slip their notes — already sealed in envelopes — to a trusted courier standing in the middle of the room. The courier doesn't open the envelopes. They just read the name on the outside and pass them along. That, in essence, is DERP.
DERP stands for Designated Encrypted Relay for Packets. It's a protocol designed to relay encrypted network traffic between two devices that can't talk to each other directly — because of firewalls, NAT, corporate network restrictions, or any number of real-world obstacles that make the internet far messier than the textbooks suggest.
This post explains what DERP is, why it exists, how it works under the hood, and when it actually comes into play. No prior networking deep-dive required.
Why direct connections often fail
In a perfect world, every device on the internet would have a unique public IP address and could talk directly to every other device. In practice, that world doesn't exist. Most devices sit behind NAT — Network Address Translation — where a router maps multiple private devices onto a single public IP.
When device A (behind one NAT) tries to reach device B (behind a different NAT), neither knows the other's true address. They only know each other's internal addresses, which aren't routable over the open internet. This is often called the NAT traversal problem, and it's been a thorn in the side of peer-to-peer networking for decades.
On top of NAT, you've got firewalls that block outbound UDP, mobile carrier networks running CGNAT (multiple layers of NAT stacked on top of each other), and corporate environments that lock down almost everything except standard HTTPS traffic. In these scenarios, direct device-to-device communication simply isn't possible.
The classic solution is a relay server — a publicly reachable middleman that both devices can connect to, and through which they can exchange traffic. DERP is one specific, well-designed implementation of that idea.
When a direct path is blocked, both devices connect to the DERP server instead, which forwards packets between them.
What makes DERP different from other relay approaches
Relay servers aren't a new idea. Protocols like TURN (Traversal Using Relays around NAT, defined in RFC 5766) have existed for years and serve a similar purpose in WebRTC-based applications. So what makes DERP distinct?
The key difference is in the trust model. A traditional relay might see the traffic it forwards in plaintext, relying on the relay operator to behave honestly. DERP takes a different stance: the relay is cryptographically blind. By the time a packet reaches a DERP server, it has already been encrypted end-to-end between the two communicating devices. The server receives sealed envelopes, reads only the destination address on the outside, and forwards them — it has no way to open them even if it wanted to.
This is sometimes described as DERP being a "dumb pipe for ciphertext." The relay never participates in the key exchange between the two devices. It never sees plaintext. It is, by design, incapable of inspecting what it carries.
The other notable design choice is the addressing scheme. Traditional relays route traffic based on IP addresses. DERP routes packets using public cryptographic keys as addresses — specifically Curve25519 keys. Each device is identified by its key, not its IP. This makes the protocol naturally suited for overlay networks where logical identity matters more than physical location.
How DERP actually works — step by step
Let's walk through what happens from the moment two devices try to communicate, all the way through a DERP-relayed connection.
Step 1 — Both devices connect to a DERP server
Each device reaches out to its nearest DERP server over HTTPS (TCP port 443). This is a deliberate choice: HTTPS is almost never blocked, even in heavily restricted environments. The DERP connection rides inside a standard TLS session, making it virtually indistinguishable from regular web traffic to a firewall. Once connected, the device authenticates using its private key and maintains a persistent long-lived connection to its "home" DERP server.
Step 2 — Discovery messages fly through DERP first
Before any real application data is relayed, the two devices use DERP as a channel to exchange discovery messages — sometimes called DISCO packets. These messages contain each device's network coordinates: its public IP (as seen from outside its NAT), its internal IP, and any other candidate addresses it might be reachable at. Both devices collect this information and use it to attempt a direct connection.
Step 3 — NAT traversal attempt (hole punching)
Armed with each other's network coordinates, the two devices simultaneously fire UDP packets at each other's public addresses. This technique — called UDP hole punching — tricks the NAT devices on both sides into opening a path through. If both NATs are cooperative (i.e. not symmetric NAT), the packets get through and a direct encrypted tunnel is established. DERP becomes unnecessary at this point, and the connection upgrades to direct peer-to-peer.
Step 4 — DERP as the fallback
If hole punching fails — because one or both devices are behind a particularly strict NAT, because UDP is blocked entirely, or because some other network condition prevents it — the connection doesn't die. It simply stays on DERP. The two devices continue communicating through the relay server, with DERP forwarding their already-encrypted packets back and forth. They keep periodically retrying the direct connection in the background. If conditions ever improve (the device moves to a different network, for example), the connection upgrades to direct automatically.
Every connection starts via DERP. The protocol immediately tries to upgrade to a direct path — and falls back gracefully if it can't.
The encryption model — why you can trust a server you don't control
One of the most important properties of DERP is that trusting the relay server operator is entirely optional. Here's why.
Before any packet reaches a DERP server, it has been encrypted using a WireGuard session established directly between the two end devices. The DERP server receives this ciphertext — a blob of scrambled bytes — along with the destination device's public key. It reads only the key (the "address on the envelope"), looks up which connection that key belongs to, and forwards the blob. At no point does it hold, derive, or have any access to the decryption keys. Those keys live exclusively on the communicating devices.
What this means practically: even if a DERP server were compromised, the attacker would only get ciphertext they have no way to decrypt. The security guarantee doesn't depend on the relay being honest or uncompromised — it's enforced cryptographically at the protocol level.
Key point: DERP uses two layers of encryption simultaneously. The application payload is encrypted by the WireGuard session between the two peers. That WireGuard ciphertext is then wrapped inside a TLS session between each device and the DERP server. An observer on the DERP server's network sees only TLS — not even which two devices are communicating with each other.
The DERP frame protocol
DERP is a binary framing protocol running over an HTTP/WebSocket connection. Each message on the wire is a frame — a fixed-format structure with a one-byte type header followed by a four-byte length field and then the payload.
When a client first connects to a DERP server, the server sends a ServerKey frame containing its Curve25519 public key, proving its identity. The client responds with a ClientInfo frame containing its own public key and a signed nonce — a short-lived proof that it controls the private key for the address it's claiming. Once this handshake completes, the client is registered on the server under its public key.
From that point on, when device A wants to send something to device B, it wraps the payload in a SendPacket frame and writes B's public key as the destination. The server looks up which connected client owns that key, and delivers it as a RecvPacket frame. That's the entire relay mechanic. The payload content is never inspected.
The DERP handshake and packet relay sequence. The server reads only destination keys — never packet contents.
DERP server infrastructure
A single DERP server is a single point of failure, so production deployments run clusters of them. The approach is organised into regions — geographic groupings of servers — with typically three or more nodes per region. The reasoning is practical: two nodes at 50% capacity is dangerously close to failure; if one falls over, the remaining node gets 100% of load and likely fails too. Three nodes gives meaningful headroom.
Nodes within a region form a mesh — each node maintains a persistent TCP connection to every other node in the same region. This means if device A connects to node 1 and device B connects to node 2 (in the same region), their packets can still be forwarded via the mesh. Crucially, forwarding only happens within a region, and at most one hop. There's no cross-region routing.
When a client first connects, it measures latency to available DERP servers and picks the lowest-latency one as its home. It reports this choice to the coordination server, which shares it with peers. When another device wants to reach it, they know which DERP region to send through. Over time, client homing tends to self-balance across nodes in a region.
Nodes within a region are meshed together. Packets can hop at most once between nodes — no cross-region routing exists.
DERP vs. TURN — a quick comparison
If you've worked with WebRTC, you've likely encountered TURN servers. Both TURN and DERP solve the same underlying problem — relaying traffic when direct connections fail — but their design philosophies differ meaningfully.
| DERP | TURN | |
|---|---|---|
| Addressing | Cryptographic public keys | IP addresses + ports |
| Transport | HTTPS / WebSocket (TCP) | UDP (primarily) |
| Relay visibility | Cryptographically blind — cannot decrypt | Relay can inspect traffic unless app encrypts |
| Firewall traversal | Excellent — uses port 443 | Good — but UDP may be blocked |
| Designed for | Overlay networks, VPN-like connectivity | Real-time media (WebRTC, VoIP) |
When does DERP actually kick in?
Despite how foundational it is, DERP is designed to be the exception, not the rule. In well-behaved networks — home broadband, cloud VMs with public IPs, servers in data centres — direct connections usually succeed and DERP is never used for data relay. It might be used briefly for the initial DISCO exchange, but then steps aside.
DERP becomes the ongoing transport in situations like:
- Mobile carrier networks running CGNAT, where devices don't have predictable public addresses and symmetric NAT blocks hole punching
- Corporate environments that block all outbound UDP, leaving TCP-over-HTTPS as the only viable path
- Double-NAT home setups, where both an ISP modem and a consumer router are NATting simultaneously
- Strict firewalls with stateful inspection that close UDP flows too aggressively
If you're frequently landing on DERP-relayed connections and performance matters, the right fix is usually to improve the network conditions for the affected device — not to optimise the relay. DERP will reliably get your traffic through, but a direct connection will always be faster.
Wrapping up
DERP is a quietly elegant solution to a genuinely hard problem. The internet's patchwork of NATs, firewalls, and carrier-grade address sharing means that direct device-to-device communication is often impossible, regardless of how well-intentioned the network design was. A relay is necessary.
What DERP gets right is making that relay trustless by design. It doesn't ask you to trust the relay operator with your data — it makes trust irrelevant by ensuring the relay only ever touches ciphertext it can't decrypt. It runs over HTTPS so it works in the most restrictive environments imaginable. And it steps out of the way the moment a direct connection becomes possible.
Next time you're connected over a network that should be terrible but somehow isn't — that's probably DERP quietly doing its job in the background.