One relay. Two carriers. Independent directions.

A cross-platform relay that composes TLS/TCP and QUIC/UDP
independently for every flow.

Architecture · Quick start · Live operations · Documentation · Wire protocol

Nowhere joins TLS/TCP and QUIC/UDP behind one service edge. Vector accepts local SOCKS5 traffic; Portal authenticates carriers and reaches the target. Each flow selects its uplink and downlink independently.

 Application
  TCP / UDP
      |
    SOCKS5
      |
      v
+------------+  Uplink carrier   +--------------+  Native `next` uplink   +-------------+
|   Vector   |==================>| Entry Portal |========================>| Next Portal |
|            |<==================|              |<========================| (optional)  |
+------------+  Downlink carrier +--------------+  Native `next` downlink +-------------+
                                         |                                       |
                                 direct or SOCKS5                        direct or SOCKS5
                                         |                                       |
                                         v                                       v
                                  +------------+                          +------------+
                                  |   Target   |                          |   Target   |
                                  +------------+                          +------------+

Each service URL uses either a compact endpoint for both carriers on one port, or an explicit endpoint that assigns carriers, ports, and address families.

* is reserved for Portal listeners; Vector and next require a concrete address or hostname. On Portal, @:2000 is shorthand for @*:2000. The full grammar is documented in Configuration.

up and down accept tcp, udp, or mix. With both carriers available, the default is TCP; mux=1 enables TLS multiplexing.

T is TLS/TCP and Q is QUIC/UDP, with uplink first. mix makes one 50/50 choice per flow and may try the alternate route once before commitment. Portal next= applies the same policy independently on each hop.

Authentication belongs to each physical carrier; routing belongs to each logical flow. Once Portal returns READY, application data travels as a plain byte stream or QUIC DATAGRAM payload.

Carrier bootstrap                 Logical flow

+----------------+                +----------------+----------+-------------+
| AuthFrame      |                | FlowHeader     | Target?  | Payload ... |
| 32 bytes       |                | 5 bytes        | variable | after READY |
+----------------+                +----------------+----------+-------------+
        |                                  |
        +-- TLS: dedicated lane or Mux     +-- TCP: reliable byte stream
        +-- QUIC: first stream only        +-- UDP: UoT or QUIC DATAGRAM

Frames are compact, DATA payload queues are bounded by byte credit, and hot-path buffers are reused. See Protocol for the wire contract and Security for trust boundaries.

morph=1 masks the bare TLS/QUIC wire image with a transform derived from the shared key:

TCP  client -> server   [ nonce 12B ][ ChaCha20-XOR(TLS stream) ]
     server -> client                [ ChaCha20-XOR(TLS stream) ]

UDP  each datagram      [ nonce 12B ][ ChaCha20-XOR(QUIC datagram) ]

Both endpoints on a hop must enable it. Morph is wire masking, with no protocol camouflage or added security semantics. See Protocol.

A Portal can open the next Nowhere hop directly:

nowhere \
  'portal://relay-key@:[email protected]:2000&up=udp&down=udp'

next is lazy, mutually exclusive with outbound socks, and bounded to seven hops.

Use a stable Rust toolchain on a supported target.

cargo build --release --locked

Listen on TLS/TCP and QUIC/UDP at port 2000:

./target/release/nowhere 'portal://[email protected]:2000'

Expose SOCKS5 on 127.0.0.1:1080:

./target/release/nowhere \
  'vector://[email protected]:2000?up=tcp&down=tcp&socks=127.0.0.1:1080'

More examples are available in Configuration and the extended quick start.

Open the local TUI from another terminal:

./target/release/nowhere tui

The read-only TUI discovers local Portal and Vector instances and presents traffic, carrier, process, and log data without controlling their lifecycle.

The local examples disable certificate verification by omitting sni. Public deployments should use a trusted certificate and verified server name:

nowhere 'portal://change-me@:2000?tls=2&crt=/etc/nowhere/cert.pem&key=/etc/nowhere/key.pem'
nowhere 'vector://[email protected]:2000?sni=relay.example&socks=127.0.0.1:1080'

Certificate pinning is also available. Review Security and Configuration before exposing a Portal.

Portal, Vector, relay, TUI, and discovery share the supported platform matrix; process telemetry varies by operating system. See Platforms and Operations.

The documentation index covers configuration, protocol, security, operations, platforms, and integrations.

Run the standard checks on a supported host:

cargo fmt --all -- --check
cargo test --all-targets --locked
cargo clippy --all-targets --locked -- -D warnings
cargo build --release --locked

On macOS, Apple Container provides the reusable Linux check environment:

./scripts/check-linux.sh

CI covers Linux, macOS, and Windows. Release packaging covers Linux GNU/musl on x86-64 and AArch64, macOS on Apple Silicon, and Windows x86-64 MSVC. Protocol changes must update the wire document and protocol vectors together.

Nowhere is licensed under the GNU General Public License v3.0.

© 2026 NodePassProject. All rights reserved.