Each layer is an independent detection-resistance mechanism. Zero diagnostic signatures, zero fingerprint leakage.
The TLS ClientHello is the first packet that DPI systems inspect for traffic classification. Standard TLS libraries (Go crypto/tls, OpenSSL) generate a ClientHello with a predictable cipher suite list, extensions, and ordering that immediately identifies it as a non-browser client.
NavLink uses uTLS — a library that clones real browser ClientHello fingerprints. One of four profiles is randomly selected per connection. Chrome is weighted double as the most common browser.
Multiple logical channels operate over a single TLS connection to the control node: the main tunnel, relay API, NAT signal channel, and others. The classic approach would be custom HTTP routing with non-standard headers — but that immediately reveals a non-browser protocol.
Instead, NavLink hides the channel byte inside the standard TLS Session ID field. Byte 0 is always 0xA7 (magic marker), byte 1 specifies the channel. To DPI this looks like 32 bytes of random data — exactly what a Session ID is supposed to contain.
| Byte | Channel |
|---|---|
| 0x00 | Main tunnel |
| 0x01 | Relay tracker API |
| 0x02 | NAT relay signal (yamux) |
| 0x03 | NAT relay data path |
| 0x04 | Para-exit (yamux) |
Tunnel traffic inside TLS looks like an ordinary browser file upload — a chunked POST request to a static-looking API path. Chunk sizes, padding, and write delays are randomized per connection.
This makes statistical traffic pattern attacks significantly harder: an observer sees an irregular data stream with variable chunk sizes and realistic User-Agent headers — exactly what a browser media upload looks like.
Even with a correct TLS fingerprint and HTTP obfuscation, advanced DPI can detect an anomaly: a host that receives constant connections but never requests CSS, JavaScript, or images. A real browser never behaves this way.
To address this, NavLink generates parallel uTLS connections to real CDN hosts. These requests are genuine — the CDN returns real files. Traffic statistics become indistinguishable from an ordinary browser session.
Tunnel traffic is inherently bursty: video and large file transfers generate spikes that statistically stand out against ordinary web browsing. Sharp rhythm changes are a characteristic tunnel signature.
Adaptive pacing smooths these bursts, keeping the traffic pattern within the normal range of web browsing behavior. It combines with the HTTP obfuscator's write jitter (layer 3) and decoy traffic (layer 4) to mask the full temporal profile.
Active probing is a common technique for detecting proxy servers: a scanner sends anomalous HTTP requests and analyzes the responses. A VPN server returns 401 or 403. A CONNECT proxy returns 200 on CONNECT. Shadowsocks hangs on arbitrary bytes.
NavLink returns 404 for any request that does not match the expected protocol. No VPN headers, no CONNECT support, no distinctive responses. To a scanner it looks like an ordinary web server with a missing resource.
IP-based blocking is the final frontier of network filtering. Classic VPNs publish a server list, and the ISP simply adds those IPs to a blocklist. Shadowsocks and V2Ray servers are detectable via active probing.
In NavLink, the client knows only control node addresses. Control knows exit node addresses but never exposes them to the client. Exit does not know the arbiter address. Each node sees at most 12 random peers in the manifest — the full topology is visible to no one. Blocking one exit node reveals nothing about the rest.
How the Architecture Works
A detailed breakdown of the four-node scheme and the data path.
Overview Architecture Comparison