One configuration contract
Clients share the native INI and qeli:// parser. The panel validates changes before saving, detects stale revisions and preserves working settings when an operation fails.
Open source · Rust
One VPN — for devices, networks and servers
Connect computers, phones, routers, home networks and remote sites through one secure tunnel.
- 01L3 TUN — full tunnel, split tunnel, and site to site
- 02Six modes — transports over TCP and UDP
- 03IPv4 + IPv6 — routes, DNS, and roaming
- 04X25519 + ML-KEM-768 — hybrid key exchange
self-hosted You select and administer the server; Qeli provides the protocol, service, and clients.
2.09
Gbps · TCP FakeTLS, one stream · Linux 0.8.2
6
Platforms with builds
IPv4 + IPv6
Full dual stack inside the tunnel
Open source
Source code and development on GitHub
0.8.2 · released
Qeli 0.8.2: configuration, networking and recovery
A substantial reliability update: shared validation for INI and connection links, more predictable network-state recovery and a revised management panel. Linux gains manual IPv6 management and a configurable TUN queue.
Recovery without a false “connected” state
Routes, DNS and firewall rules are installed and removed with resource ownership tracking. Incomplete cleanup remains a visible error; recovery attempts can be cancelled.
IPv6 under your control
Manual mode leaves IPv6 forwarding and firewall policy to the administrator. Qeli manages the tunnel, addresses and optional session-aware NDP proxy. This mode does not require ip6tables.
Linux TUN and client applications
Linux-owned TUN queue length is configurable through tun.tx_queue_len. UDP processing, connection shutdown, profile storage and diagnostics are revised; install each new app with its bundled native core.
0.8.2 is a released beta, not a stable release. The set contains 15 delivery files and SHA256SUMS. The detailed release overview covers changes, upgrading, separate Linux measurements and validation limits. The 0.8.0 comparison charts below are unchanged.
About
Why Qeli
An ordinary commercial VPN routes your traffic through someone else's servers. Qeli is built for those who want to keep privacy and the whole infrastructure under their own control — on their own server.
The problem
Off-the-shelf commercial VPNs route all your traffic through someone else's servers — you don't know who owns the infrastructure, whether logs are kept, or who they're shared with. Your credentials, history and metadata end up with a third-party service.
Qeli's answer
Qeli runs on your own server: keys, traffic and logs stay with you, with no middlemen and no subscriptions. Modern cryptography (X25519, ChaCha20-Poly1305), metadata privacy, and in reality-tls mode — genuine TLS 1.3.
IP tunnels and proxies: what differs
Qeli carries IP packets through a L3 TUN. VLESS and Shadowsocks relay streams and datagrams through a proxy; clients built on Xray and other cores can cover the whole device using TUN or transparent redirection. The difference is architecture and route configuration, not a requirement to configure every application.
Proxy connection
VLESS · V2Ray · Shadowsocks · Xray
- SOCKS/HTTP accepts traffic from applications using that proxy
- TUN and transparent redirection can cover the whole device
- TCP, UDP and ICMP support depends on the protocol and implementation
- Routes and DNS are configured on the client or gateway
- Leak protection depends on routes, DNS and blocking rules
IP tunnel
Qeli
- Creates a L3 TUN and carries IP packets between peers
- In full-tunnel mode, routes device traffic through the server
- Applications do not need SOCKS or HTTP proxy support
- Routes, DNS and fail-closed policy define the protection boundary
- Supports full tunnel, split tunnel and inter-network routes
In practice: configure forward and return routes for home LAN access or site-to-site connectivity. To send the whole device through the server, enable full tunnel and verify DNS and fail-closed policy. Having a VPN or TUN alone does not replace those checks.
Features
What Qeli is made of and what it does
First, the architecture: what Qeli is built from and why it's self-contained. Then, what it does for your security and connection stability.
Multiple transport modes
Several transport modes are built into the protocol itself, no third-party tools needed. The flagship one is reality-tls (real TLS 1.3); the rest switch with a single setting.
Several profiles at once
TCP, UDP and REALITY at once in a single service — each with its own key, its own users and separate access.
Post-quantum encryption
Tunnel keys are derived from a hybrid of X25519 + ML-KEM-768 (post-quantum) — the key exchange is designed to resist a future quantum computer under current cryptographic assumptions. Used in every mode except plain. ChaCha20-Poly1305 encryption, no exposed counter in packets.
Built-in web panel
Full control from the browser: all profile settings, users, routes and server-key rotation — no SSH or file editing. Built-in HTTPS and an IP allowlist let you expose the panel safely without nginx; connection links and QR codes, a Russian/English interface.
Routing and joining networks
The L3 tunnel carries IP packets, providing access to the LAN behind the server and connecting subnets across sites. Connectivity requires matching forward and return routes and firewall rules that allow the traffic.
Network-joining scenarios →
Transport modes
One protocol — six transport modes
The mode determines the traffic shape and is configured by a matching pair of profile and client settings. The installer deploys reality-tls by default; the built-in config default is fake-tls. Other modes suit trusted networks, compatibility and fallback channels.
flagshipTCP · TLS 1.3
Real TLS 1.3
reality-tls · browser TLS 1.3 (realtls)
Qeli's flagship mode: the client sends a browser TLS 1.3 handshake (JA4 fingerprint t13d1516h2_8daaf6152771), and the server terminates real TLS 1.3 (realtls), carrying the tunnel inside. On the wire this is genuine TLS 1.3, not a mimicry; inside it carries the qeli tunnel, while trust rests on the pinned server key. It works on Linux, Android, iOS, Windows and macOS through the shared realtls engine.
The server borrows the target site's real certificate — even an active prober sees legitimate TLS, like Xray-REALITY.
in traffic
ClientHello (Chrome JA4) → TLS 1.3 (realtls)
encrypted flight → tunnel inside real TLS
- A genuine TLS 1.3 handshake with a Chrome browser JA4 fingerprint
- The server terminates TLS (realtls); the tunnel runs inside
- A single realtls engine across all clients (Linux, Android, iOS, Windows, macOS)
1212 ↑ / 1066 ↓ Mbps · TCP P=4, IPv4 · Recordizer
0.8.0 report · 1 Sep 2026
0.8.0 report · 1 Sep 2026
Qeli 0.8.2 · Linux · 19 October 2026
What the packaged build measured
Four transport profiles, IPv4 and IPv6, upload and download. Both endpoints used the packaged Linux 0.8.2 binary, required Recordizer and 2 vCPU / 2 GiB of memory each.
2.09 Gbps
The mean of four directions for one profile
Each IPv4/IPv6 upload/download result is the median of three runs; the figure is their mean. It describes TCP FakeTLS, not the average speed of every Qeli mode.
TCP P=1
IPv4 + IPv6
upload + download
A separate UDP series
600 Mbps with no loss in the measured windows
All 48 windows at an offered UDP load of 600 Mbps recorded no receiver packet loss or TUN drops. The test covered four profiles, both IP families and both directions.
This checks a fixed load, not maximum throughput. Unrestricted TCP retained retransmissions and TUN drops; separate UDP tests at 900/950 Mbps recorded small end-to-end losses.
Recordizeractive in every tested Qeli profile
IPv4 + IPv6both address families tested independently
3 × 4three repeats and four TCP directions
The comparison with other VPNs was run separately on Qeli 0.8.0 and remains on the Technology page. TCP P=1 and P=4 results are not used to calculate gains between releases.
This is lab throughput, not a speed promise for every VPS. A real connection depends on routing, CPU, provider, loss and the selected transport.
0.8.2 measurements and methodology →
Practical choice
Speed is only one of three characteristics
Do not choose a transport mode by the longest benchmark bar alone. Throughput, masking level and the behavior of the actual network all matter.
Throughput
Compare profiles within the same class. TCP and UDP are measured differently and target different network conditions.
Traffic masking
Unmasked modes reveal the testbed ceiling but are not direct competitors to modes that reshape the connection's external profile.
Network behavior
Loss, mobile NAT, UDP availability and Wi-Fi/cellular changes can matter more than peak laboratory throughput.
Under the hood
How Qeli works →
Want to verify the details?
The full technical breakdown: the handshake, all six transport modes, cryptography, measured benchmarks and the comparison matrix.
Clients
Six platforms have builds; iOS is feature-complete but unpublished
Every client is wire-compatible with the server and sends the same real TLS 1.3 (reality-tls) through the shared realtls engine. A link or QR code carries the connection parameters (server, mode, key) in one tap; local settings — routes, DNS, MTU, kill-switch — are configured in the client itself.
Linux — server and client
Rust
- The network tunnel is built into the program
- Server and client in a single program
- Runs as a service, a .deb package or a multi-arch Docker image
- Commands to manage keys and add clients
macOS
C# · Avalonia · .NET 10
- Tunnel via utun (kernel-control), WireGuard-style routes
- Menu-bar app, cross-platform Avalonia UI
- Import by link and QR, runs as a launchd daemon
- Universal build: Apple Silicon and Intel
Windows
C# · .NET
- Built-in network driver, no separate install needed
- Runs as a Windows service — even before sign-in
- Tray icon, notifications, system theme, Russian and English
- A single file: 77 MB with .NET bundled, or 11 MB if .NET is already installed
Android
Kotlin
- Works over TCP and UDP
- Import by link and a QR scanner
- All transport modes; all traffic through the VPN by default
- Download and upload speed indicator
- Seamless reconnect on network change — Wi-Fi ↔ mobile data
iOS not published
Swift
- NetworkExtension (Packet Tunnel Provider)
- Import by link and QR code
- All transport modes
- Builds and passes unit tests in CI; not yet tested on a device
Keenetic
Rust · KeeneticOS
- Router-level VPN — the whole home, no setup on each device
- A KeeneticOS package, mipsel and aarch64 architectures
- All transport modes
- Tested on real Keenetic hardware and verified as a working client-only router VPN
OpenWrt
Rust · procd / UCI / LuCI
- Router-level VPN — the whole home through one gateway
- Native package: a procd service, UCI config and a LuCI page
- Firewall zone (fw4) with NAT for the home network
- Builds for aarch64, armv7, mipsel and x86_64
- Tested on real OpenWrt hardware and verified as a working client-only router VPN
Open source
The project on GitHub
All the code is open — the protocol, server and clients for Linux, Windows, macOS, Android, iOS and routers. Study it, build it yourself, report issues and suggest improvements.
litvinovtd / qeli
Public
Star
A full self-host VPN with its own network protocol and private transport — HTTPS, WebSocket, QUIC-shaped UDP and reality-tls.
vpnrustprivacyself-hostedtunreality
Rust
AGPL-3.0
$ git clone https://github.com/litvinovtd/qeli.git