High-performance MTProto proxy for Telegram with DPI resistance, fake-TLS camouflage, and production-grade monitoring.
Documentation | Docker Quick Start | Comparison | Telegram
Note
Teleproxy is maintained by one person. If it's useful to you, consider supporting development.
| Telegram | Donate via Tribute (cards, worldwide) |
| Web | Donate via Tribute |
| TON (The Open Network) | UQCRB931D__Q2YQmAbUfcuHQ7fHsG3_3At7e6pUtNa6b9bTh (Tonkeeper) |
| USDT — TON network ONLY | same address as above (not TRC20/ERC20) |
🎵 Ghost Protocol — the unofficial anthem
ghost-protocol-small.mp4
Get a proxy running in under 2 minutes:
The deploy page generates a unique secret, gives you a script to paste when creating a VPS, then shows your connection QR code. No terminal needed.
Supports: DigitalOcean · Vultr · Hetzner · Linode · any Ubuntu/Debian VPS
- Fake-TLS camouflage — emulates HTTPS handshakes and TLS records
- Direct-to-DC mode — bypass middle-end relays, zero config files needed
- Dynamic Record Sizing — varies record sizes and inter-record delays
- 8 MB Docker image — 7x smaller than the original
- Prometheus metrics — production monitoring out of the box
- Up to 16 secrets with labels and per-secret connection limits
- E2E tested — the only MTProto proxy with automated tests against real Telegram
Teleproxy's fake-TLS emulates HTTPS traffic. Automated tests check the framing and camouflage below; they do not prove that a deployment will pass current DPI rules. The Telegram client controls its ClientHello fingerprint, which the proxy cannot rewrite. See the current limitations and operator playbook.
| Layer | Implementation | Verified by |
|---|---|---|
| ClientHello fingerprint | 517-byte Chrome-profile hello with 15 TLS extensions, GREASE (RFC 8701), X25519 key share, padding | test_ja3_fingerprint, test_tls_extension_completeness, test_grease_randomness |
| ServerHello emulation | Live-probes the real backend (20 connections), mirrors extension order and encrypted record sizes | test_emulation_matches_backend, test_server_hello_tls13_compliance |
| Record sizing | Dynamic Record Sizing mimics TCP slow-start (1450→4096→16144 bytes) with ±100B noise and Weibull inter-record delays | test_drs_e2e.py |
| Active probing resistance | Every failed validation (wrong secret, stale timestamp, unknown SNI, replay, non-TLS) forwarded to real HTTPS backend | test_wrong_secret_rejected, test_unknown_sni_falls_back, test_browser_tls_sees_real_backend |
| Anti-replay | client_random dedup cache + 120-second timestamp window + HMAC-SHA256 binding | test_duplicate_client_random_rejected, test_stale_timestamp_rejected |
| Encrypted payload entropy | Fake application data passes Shannon entropy validation (H ≥ 7.0 bits/byte) | test_encrypted_data_entropy |
Every parser on the attack surface is fuzz-tested on every push (60s smoke) and weekly (30min deep exploration) with ASan + UBSan + libFuzzer. CodeQL and cppcheck run static analysis on every commit. The ASan CI even verifies itself by re-introducing a known heap overflow and confirming detection.
These tests cover specific protocol properties, from JA3 hash computation to encrypted-payload entropy and DRS timing distributions. Connectivity under censorship still needs testing with real Telegram clients on the affected networks.
Telegram Desktop 7.1 added a WEB proxy type. It carries normal MTProxy traffic through an embedded browser over real HTTPS or WebSockets. Telegram's tproxy-server relay converts those streams back into TCP connections to a local MTProxy backend.
Telegram WebView -> HTTPS frontend -> tproxy-server -> MTProxy backend -> Telegram
Teleproxy can serve as the MTProxy backend: tproxy-server forwards the standard obfs2 or padded MTProxy stream unchanged. The WEB transport is handled by the relay and HTTPS frontend. When using Teleproxy as the backend:
- Keep the backend listener private and use the same base 16-byte secret in the relay and Teleproxy. WEB clients accept plain or
dd-prefixed secrets, not fake-TLSeesecrets. - Use a dedicated backend without
EE_DOMAIN/-D, which enables TLS-only ingress. The public HTTPS connection terminates at the frontend. - Leave
PROXY_PROTOCOLdisabled: the reference relay sends raw MTProxy bytes without a PROXY header. Backend IP-based limits and statistics therefore see the relay address, not individual users.
The public TLS handshake comes from the browser engine rather than Telegram's fake-TLS implementation. A compatible HTTPS frontend can also negotiate Encrypted Client Hello (ECH) to hide the inner hostname, and TLS certificate compression to reduce full-handshake certificate bytes. These require client support; ECH also requires the client to obtain the server's ECH configuration. Neither hides the server IP or guarantees access through a blocked network.
docker run -d \
--name teleproxy \
-p 443:443 \
-p 127.0.0.1:8888:8888 \
--restart unless-stopped \
ghcr.io/teleproxy/teleproxy:latestCheck logs for connection links: docker logs teleproxy
curl -Lo teleproxy https://github.com/teleproxy/teleproxy/releases/latest/download/teleproxy-linux-amd64
chmod +x teleproxy
SECRET=$(head -c 16 /dev/urandom | xxd -ps)
./teleproxy -S "$SECRET" -H 443 --direct -p 8888 --aes-pwd /dev/null| Feature | Original | Teleproxy | mtg | telemt |
|---|---|---|---|---|
| Language | C | C | Go | Rust |
| Fake-TLS (EE mode) | Yes | Yes | Yes | Yes |
| Direct-to-DC mode | No | Yes | Yes | Yes |
| Multiple secrets | Yes | Yes (up to 16) | No | Yes |
| Anti-replay protection | Weak | Yes | Yes | Yes |
| Dynamic Record Sizing | No | Yes | Yes | No |
| Per-secret byte quotas | No | Yes | No | Yes |
| IP blocklist / allowlist | No | Yes | Yes | No |
| Docker image | ~57 MB | ~8 MB | ~3.5 MB | ~5 MB |
| ARM64 / Apple Silicon | No | Yes | Yes | Yes |
| Prometheus metrics | No | Yes | Yes | Yes |
| E2E tests (real Telegram) | No | Yes | No | No |
| TLS fingerprint validation (CI) | No | Yes | No | No |
| Fuzz testing (CI) | No | Yes | No | Partial |
ghcr.io/teleproxy/teleproxy:latestrkline0x/teleproxy:latest(Docker Hub)
GPLv2 — see LICENSE.