Exit Gateway Services

Exit Gateways are where traffic leaves the Nym network and reaches the wider internet. Each Exit Gateway runs two distinct proxy services that handle different kinds of outbound traffic:

• Network Requester (NR), an application-layer SOCKS proxy
• IP Packet Router (IPR), a raw IP tunnel with address allocation

Both services run on every Exit Gateway. Which one handles your traffic depends on how you connect.

Network Requester

The Network Requester is a SOCKS4/4a/5 proxy. Clients send SOCKS-formatted requests through the mixnet, and the NR makes the corresponding connection on their behalf: resolving hostnames, opening TCP connections, and relaying data.

Client → Entry Gateway → Mixnodes1..3 → Exit Gateway (NR) → SOCKS connect → destination
                                                          ← relay response ←

Because it operates at the application layer, the NR:

• Resolves DNS on behalf of the client, but only when the client sends a hostname. SOCKS5 also permits a pre-resolved IPv4 or IPv6 address. An application that resolves locally has already leaked the DNS query on clearnet. Use socks5h://, or curl --socks5-hostname, to send the name rather than the address
• Opens individual TCP connections per SOCKS request
• Can enforce allow/deny lists on destination hosts and ports

Used by: the SDK's SOCKS5 module and the standalone SOCKS5 client.

IP Packet Router

The IP Packet Router operates at the IP layer. Instead of proxying individual connections, it allocates a virtual IP address to the client and routes raw IP packets between the client and the internet, functioning as a tunnel endpoint.

Client → Entry Gateway → Mixnodes1..3 → Exit Gateway (IPR) → raw IP packets → destination
                                                           ← raw IP packets ←

On connection, the IPR:

1. Allocates an IPv4/IPv6 address pair to the client
2. Accepts raw IP packets (TCP, UDP, or any IP protocol) from the client via the mixnet
3. Sends them to the internet from the gateway's own IP address
4. Routes response packets back through the mixnet to the client

Because it operates at the IP layer, the IPR does not resolve DNS. The client handles its own, either over clearnet or by sending DNS queries as UDP packets through the tunnel.

The exit policy applies

Both exit services enforce the same Nym exit policy (opens in a new tab): a deny list of destination ports and addresses that may not be reached through the mixnet. It is identical across operators, and an individual operator cannot vary it. That uniformity is what makes exit behaviour predictable for the clients that depend on it.

For anyone building on Nym, that policy is the first constraint to check. If the port your service listens on is not permitted, no client-side configuration changes the outcome.

The policy is a deny list rather than an allow list, replacing the earlier allowed.list, and it was shaped after Tor's reduced exit policy. Changes are made through operator governance rather than by Nym directly. If you need a port or destination the policy currently refuses, the route is a governance proposal, which the exit gateway community counsel describes, decided by an operator vote on the Nym forum (opens in a new tab).

Used by: NymVPN anonymous mode (5-hop mixnet routing to the IPR), smolmix (programmatic TcpStream/UdpSocket access to the IPR via the Rust SDK), and the browser mix-* packages built on smolmix: mix-tunnel, mix-fetch, mix-dns, and mix-websocket.

Comparison

What each hop sees

Sphinx encryption is the mixnet transport layer: it protects packets as they traverse the mix nodes. The Exit Gateway strips the Sphinx layers and forwards the request onward, analogous to how a Tor exit node or VPN endpoint unwraps its tunnel.

you → entry gateway → 3 mix layers → exit gateway → destination
└─────────────── Sphinx-encrypted ──────────────┘└─ clearnet ─┘
                                     exit gateway
                                     strips Sphinx
                                     here

Encrypt your own payload

Because the Exit Gateway removes the Sphinx layers, whatever is inside is visible to the exit unless you encrypted it yourself.

• Application-layer encryption closes the gap. TLS, the Noise Protocol, or any authenticated encryption keeps the payload as ciphertext to the exit. It still sees the destination, but not the content. Over TLS the exit only ever handles ciphertext bound for that destination.
• Unencrypted payloads are fully visible. Plain HTTP, unencrypted WebSocket (ws://), and plain UDP DNS are readable in full at the exit. The mixnet still hides your identity, so the exit reads the content without being able to attribute it to you.

Traffic between the Exit Gateway and the destination travels over the public internet exactly as it would from any other server. Use TLS or another application-layer cipher, just as you would on a direct connection.

Trust model

Both services share the same fundamental trust property: the Exit Gateway can see destinations but not senders. The mixnet's layered encryption ensures that the Exit Gateway cannot determine who sent a given packet; it only knows where it is going. The sender's identity is protected by 5-hop routing, Sphinx encryption, cover traffic, and packet mixing.

Neither service learns your IP address. What else they learn differs sharply, and the SOCKS-based Network Requester is the weaker of the two by default.

• IP Packet Router. Sees the destination IP and port, the unencrypted payload, and traffic volume and timing at the exit hop. Client traffic arrives under an ephemeral sender tag, so the IPR never learns your Nym address or your Entry Gateway. It does link every packet within a tunnel session, because it allocated the address they come from, but that linkage is confined to the session and cannot be attributed to a person or an IP.
• Network Requester. Sees the destination and payload as above. In addition, the default SOCKS5 configuration sends replies to a return address rather than over SURBs, so the NR receives your Nym address on every connect request. That address embeds your Entry Gateway identity and is stable across sessions, which makes it a far stronger correlator than anything the IPR holds. Anonymous replies remove it, and they are off by default.

You trust the Exit Gateway in the same way you trust a VPN exit or a Tor exit node, but the shape of that trust differs between the two services:

• IP Packet Router. A packet forwarder, like a VPN exit. It receives raw IP packets, so it sees the destination IP and port and reads any packet payload you did not encrypt. It works at the network layer and does not parse your application protocol.
• Network Requester. A SOCKS proxy that makes the request on your behalf, so your trust in it is exactly the trust you place in any SOCKS5 proxy. With socks5h:// the client hands it the destination hostname plus the byte stream, and the NR opens the TCP connection itself and relays bytes back. With plain socks5:// the client resolves first and sends an IP, so the NR sees an address instead of a name and the lookup has already gone out over clearnet.

You also trust the mixnet to provide unlinkability between sender and receiver. Sphinx provides this cryptographically at the per-packet level: a node cannot read addressing beyond its own hop. Unlinkability of your traffic pattern over time is weaker, and statistical rather than absolute. It comes from mixing and cover traffic, and it degrades with low network traffic, with cover traffic or Poisson timing disabled, and against an adversary observing a large fraction of the network.

What the exit does not protect against

The mixnet operates at the network layer. It hides your IP and unlinks sender from receiver, and it does nothing at the application layer, so anything you reveal in the content of your traffic is yours to manage. If you log in, send a cookie, or include an API token, the destination knows who you are regardless of the network path. A stable request pattern or a recognisable account correlates your traffic across sessions in the same way.

That split is the subject of the two-layer model: transport hides who you are talking to and from whom, while hygiene disciplines what your request pattern leaks to the destination. Choosing an exit service is a transport decision and settles only the first half.

Read more

• Threat actors: who the exit is, and is not, defending you against.
• Nym vs other systems: how this exit model compares with VPNs, Tor, I2P, and end-to-end encryption.
• Exit security for developers: which exit service each Nym package uses, and how to pin one.