Protocol Stack
Dombay Protocol is built on top of VLESS with REALITY TLS camouflage and XTLS-Vision flow. These are the same primitives used by the most censorship-resistant tools deployed in Russia, China, and Iran — but assembled into a coherent, maintained product with automatic fallback and a zero-configuration client.
Why not WireGuard or OpenVPN?
WireGuard and OpenVPN both have distinctive packet fingerprints that are trivially blocked by modern DPI systems. Roskomnadzor (Russia's censorship agency) and the Chinese GFW both maintain active block lists for these protocols. VLESS+REALITY does not have a detectable VPN fingerprint — the handshake is cryptographically identical to a real TLS 1.3 connection to the named server.
| Protocol | DPI-detectable? | Blocked in Russia? | Blocked in China? |
|---|---|---|---|
| WireGuard | Yes — UDP pattern + handshake | Commonly | Yes |
| OpenVPN | Yes — TLS fingerprint + port | Commonly | Yes |
| IKEv2/IPSec | Yes — ESP headers | Partially | Often |
| Dombay Protocol | No — real TLS 1.3 | No | No (currently) |
TLS Camouflage — REALITY
REALITY is a novel TLS extension developed for censorship evasion. Instead of using a self-signed certificate (which is trivially detectable), REALITY borrows the real certificate of a legitimate high-traffic domain during the handshake negotiation phase — without proxying actual traffic to that domain.
www.microsoft.com (or another configured destination). The client verifies it is talking
to a genuine Dombay node using an out-of-band Ed25519 public key embedded in the
connection config. To any passive observer, the connection looks like a legitimate HTTPS session.
SNI choice matters
The SNI (Server Name Indication) field in TLS ClientHello is visible to censors even before the
handshake completes. Dombay uses www.microsoft.com as the destination —
a domain with enormous traffic volume that is never blocked in any jurisdiction. Using a Russian or
regional domain (e.g. vk.com) would allow censors to selectively block connections where the
destination IP doesn't match known CDN ranges for that domain.
XTLS-Vision splice
XTLS-Vision intercepts the TLS handshake at the application layer and "splices" the inner TLS stream (your actual HTTPS traffic to e.g. YouTube) directly into the outer REALITY tunnel. This eliminates double encryption overhead and makes traffic patterns indistinguishable from a real browser session.
Transport Diversity
A single transport can be blocked. Dombay nodes support multiple protocols simultaneously; the client selects the best available one automatically.
| Transport | Port | Best for | Status |
|---|---|---|---|
| VLESS+REALITY | 443/TCP | Primary — all regions, undetectable | Active |
| Hysteria2 | 8443/UDP | High-loss networks, mobile; QUIC-based | Active |
| TUIC v5 | 8444/UDP | Low-latency UDP; 0-RTT reconnect | Enabled |
| ShadowTLS | 8445/TCP | Fallback when REALITY ports are filtered | Enabled |
Hysteria2 (UDP/QUIC)
Hysteria2 is a QUIC-based protocol that excels on high packet-loss or throttled connections common on Russian mobile networks. Because it uses UDP port 8443 with a custom QUIC implementation, it has a different traffic profile than VLESS and serves as a hot-standby transport. The client switches to Hysteria2 automatically if the primary TCP connection degrades.
Node Discovery & Resilience
A VPN that cannot reach its own servers is useless. Dombay uses a layered bootstrap system so the
client can always find at least one working node — even if dombayvpn.com is blocked.
Cloudflare Worker relay
Every API call can be routed through a Cloudflare Worker at dombay-relay.workers.dev.
Because Cloudflare's edge network serves billions of requests globally, its IP ranges are never
blocked — blocking them would take down most of the internet. The worker transparently proxies
/v1/* to api.dombayvpn.com.
DHT peer exchange
Dombay nodes participate in the BitTorrent DHT network under a deterministic info-hash derived from a well-known seed. Node metadata (hostname, public key, region) is encoded in the DHT peer record. The client can discover working nodes entirely without any central server — the same mechanism BitTorrent uses to find peers for a torrent without a tracker.
Silent FCM push
When a subscriber's app is in the background, Dombay pushes a silent Firebase Cloud Messaging data-only notification every 10 minutes containing a compact base64-encoded node list. This ensures the client always has a fresh list even if it has been offline for a while. No notification is ever shown to the user — only the data payload is processed.
Node Infrastructure
All Dombay nodes run the same containerised xray-based stack. Nodes are stateless — configuration is injected at start time via environment variables. The same Docker image runs on GCP, Hetzner, Vultr, and bare-metal VPS providers.
Custom xray build
Dombay does not use the upstream xray binary. Every release builds xray-core from source with branding patches applied and metadata stripped. This means:
- No "Xray" strings in logs or process name — harder to fingerprint via host introspection
- Build ID stripped — no reproducibility oracle for attackers
- Version string set to
internalrather than publishing the exact upstream tag
Multi-region deployment
| Region | Location | Nodes |
|---|---|---|
| europe-west3 | Frankfurt, Germany | 4 × StatefulSet pods (HPA up to 10) |
| europe-west4 | Netherlands | 1 node |
| europe-north1 | Finland | 1 node |
| asia-northeast1 | Tokyo, Japan | 1 node |
| asia-south1 | Mumbai, India | 1 node |
Autoscaling
The primary node fleet (europe-west3) has a Kubernetes HorizontalPodAutoscaler (HPA) that scales between 2 and 10 pods based on CPU utilization (>60%) and average memory (>400 Mi). Scale-out takes approximately 60 seconds; new pods register with the API server automatically via a startup heartbeat.
Partner node trust model
Partner-hosted nodes must authenticate heartbeats with an HMAC-SHA256 signature over a server-issued nonce. Replay attacks are prevented by a 5-minute nonce window. Node public keys are pinned on the API server — a compromised node cannot forge credentials for another node.
Privacy & Zero Logs
The VPN nodes keep no per-connection logs. Here is what we store and what we do not:
| Data point | Stored? | Notes |
|---|---|---|
| Destination IPs / URLs | Never | Not logged by node or API server |
| DNS queries | Never | Resolved by Unbound on the node; not forwarded or logged |
| Bandwidth per session | Never | Aggregate node load only, no per-user stats |
| Connection timestamps | Session only | Required for abuse mitigation; rotated every 24h |
| Account & subscription | Yes | Email, payment record — standard e-commerce data |
| Device fingerprint | Hashed | SHA-256 hash for device-limit enforcement; not reversible |
DNS privacy
Each VPN node runs a local Unbound recursive resolver. DNS queries from clients are resolved directly at the node without forwarding to Google/Cloudflare DNS — so even DNS lookups are not visible to third parties. The resolver uses DNSSEC validation where available.
Client Architecture
Android
The Android client embeds flutter_v2ray, which wraps xray-core via a native JNI
layer and manages the Android VpnService lifecycle. The xray config is generated
programmatically from node credentials and written to a temp file before each connect. The VPN
service runs in its own process, isolated from the UI.
iOS / macOS / Windows
On Apple platforms, the client uses NEVPNManager (IKEv2) via a Swift platform channel. EAP-MSCHAPv2 credentials are derived deterministically from the subscriber's VLESS UUID and node short ID, then stored in the system Keychain. No passwords are ever transmitted in plaintext.
Split tunneling
Users can exclude specific apps from the VPN tunnel (e.g. local banking apps, Max Messenger, VK). Excluded apps use the native network stack directly. This is configured per-app via the bypass list in Settings.
Auto-reconnect watchdog
A background watchdog timer pings the gateway every 30 seconds. If three consecutive pings fail while the tunnel is marked "connected", the watchdog tears down and restarts the tunnel automatically — recovering from silent connection drops without user intervention.
Protocol selection
On each connect, the client probes all available transports (VLESS+REALITY, Hysteria2) with a short TCP/UDP timeout. The lowest-latency available transport wins. The user can also pin a specific transport in Advanced Settings.