SOCKS5 mode is the default and most flexible way to use rVPN. It runs a local SOCKS5 proxy that individual apps can be pointed at — without affecting other traffic on your machine.
rVPN can also run as an HTTP proxy alongside the SOCKS5 proxy. This is useful when apps or environments expect HTTP_PROXY/HTTPS_PROXY environment variables pointing at an HTTP proxy (the most common convention for CLI tools like curl, git, npm, pip, and Docker).
Both proxies share the same WebSocket connection pool — running both simultaneously adds zero overhead.
HTTP CONNECT — used for HTTPS. The client sends CONNECT host:443 HTTP/1.1, the proxy responds with 200 Connection Established, and traffic flows through an encrypted tunnel to the destination.
Plain HTTP forwarding — used for unencrypted HTTP. The client sends GET http://host/path HTTP/1.1, the proxy connects to the host and forwards the request.
Both paths are split-tunnel-aware and use the same connection pool as SOCKS5.
Clients must send Proxy-Authorization: Basic ... header (browsers and curl -x handle this automatically when credentials are in the URL: http://user:[email protected]:8118).
In most cases, use the HTTP proxy with environment variables — it has the broadest compatibility with CLI tools and build systems. Use SOCKS5 for per-app routing or when you need UDP support.
Split tunneling lets you route only certain traffic through the VPN while the rest connects directly. This is useful when you want to reach blocked sites through the VPN while keeping local network and domestic traffic unaffected.
Important: Without the DNS proxy, your DNS queries may leak to your ISP even when using the SOCKS5 proxy. See DNS Leak Prevention for a complete explanation.
By default, DNS queries are resolved by your system’s DNS server — outside the VPN tunnel. This means your ISP can observe which domains you look up even while your traffic is proxied.
rVPN includes a built-in DNS proxy that resolves all queries server-side through the same encrypted WebSocket tunnel. It is also split-tunnel aware: bypass domains are resolved locally, and blocked ad/tracker domains return NXDOMAIN immediately without ever hitting the network.
All SOCKS5 flows share a single WebSocket connection with one shared DoubleRatchet session. Each SOCKS5 CONNECT creates a logical “flow” via CreateFlow/CloseFlow control messages over the same tunnel.
Benefits:
Single TLS handshake, single X3DH key exchange — ~250ms overhead vs ~600ms per-connection
0-RTT flow creation — data is sent immediately without waiting for server ACK
Lower server resource usage (one WebSocket, one ratchet vs one per flow)
Server supports up to 2000 concurrent flows per mux session
100% success rate in stress tests (vs ~85% for standard mode)
Trade-offs:
A single long-lived binary stream is a distinctive traffic pattern that classifiers can detect
All flows share one connection — if it drops, everything reconnects
How it works:
First SOCKS5 CONNECT opens the mux WebSocket tunnel ({server_path}/mux)
Performs X3DH handshake to establish the shared DoubleRatchet
Subsequent flows send CreateFlow control messages over the same tunnel
Client sends data immediately (0-RTT) — server buffers while connecting to target
Data flows through multiplexed frames
Security: The 0-RTT optimization is NOT TLS 0-RTT. The TLS handshake and X3DH key exchange are complete before any data flows. Replay protection is provided by the Double Ratchet — each message has a unique message_number, and the ratchet rejects messages with number < current (see ratchet.rs:decrypt). Message keys are consumed after use, so replays fail with “Message too old”.
Configuration:
[socks5]
multiplex = true
# mux_path defaults to {server_path}/mux automatically
Note: Standard mode opens one WebSocket per TCP flow. On busy networks (e.g. browsers with many tabs), this can exhaust the server’s max_connections_per_ip limit. If needed, increase the server’s rate limits:
