telEgo Combines MTProxy and WEB Proxy on Single Port 443 with TLS Fronting
telEgo is a fast Telegram proxy written in Go that leverages the gnet library for epoll and kqueue-based networking. In its latest release, the tool added support for all four WEB proxy transport modes while continuing to handle classic MTProxy traffic.
Telegram Desktop can now connect through WEB proxies. From the outside, the connection appears as ordinary HTTPS traffic to a website, which then serves as the transport between the client and the proxy.
How MTProxy and WEB Share Port 443
The architecture keeps only one public listener on port 443. telEgo inspects incoming connections: valid MTProxy handshakes are handled directly, while regular TLS sessions are spliced to Nginx on private port 8443 using PROXY protocol v2. Nginx terminates the real TLS certificate, serves the website, and forwards authenticated WEB carrier requests to the internal telEgo WEB listener on port 8080.
Four carrier modes are available: https, https-lanes, websocket, and websocket-lanes. The https-lanes mode uses separate HTTP/2 channels per Telegram stream, while websocket-lanes creates an individual WebSocket per stream.
Deployment with Docker Compose
The example repository provides docker-compose.yml, telego.toml, and an Nginx configuration. Users generate a base secret with the Docker image, configure the [web-proxy] section, obtain a Let's Encrypt certificate via standalone mode, and start the stack. Only port 443 is exposed publicly for telEgo.
Existing ee and dd MTProxy links remain valid. WEB links are generated automatically from the same secret and can be added directly in Telegram Desktop.
The setup requires a VPS with open ports 80 and 443, a domain with an A record, and Docker with Compose. When an existing Nginx instance is present, its server blocks must be adapted to listen on private ports only.
Related articles
Step-by-Step Guide to Removing Personal Data from Search Engines, Databases and Social Networks
The guide provides a practical seven-step checklist for individuals seeking to reduce their digital footprint by removing personal information from websites, search engines, and social platforms. It emphasizes starting with a 20-minute audit to compile exact URLs rather than vague requests, followed by direct contact with site owners under Russia's 152-FZ personal data law. Subsequent steps cover submissions to Yandex and Google for de-indexing, manual cleanup of old social media accounts, handling of phone numbers in caller ID services, and removal from directories and review sites. The process includes templates for formal requests, timelines for responses, and escalation paths to Roskomnadzor when operators fail to comply. Special attention is given to leaked databases, where technical removal is impossible, and to web archives such as Internet Archive that require specific legal justifications. The full cycle is estimated at two months, with quarterly maintenance recommended to sustain results.
From HAProxy to VLESS+Reality: Overcoming DPI Blocks for MTProto Telegram Proxies
A detailed case study describes the challenges of running an MTProto proxy for Telegram on Russian servers facing ISP-level DPI. Initial attempts using HAProxy TCP relays and SOCKS5 tunnels failed because modern DPI systems detect MTProto and fake-TLS signatures regardless of transparent forwarding. The author eventually succeeded by layering mtg with an Xray VLESS+Reality tunnel that performs genuine TLS 1.3 handshakes to legitimate domains. Key configuration pitfalls included the xtls-rprx-vision flow breaking non-TLS payloads, missing mux causing handshake timeouts on short-lived connections, and provider-specific network policies. Final architecture places mtg and an Xray client on the Russian entry server while the foreign exit server runs Xray in VLESS+Reality inbound mode. The guide supplies complete docker-compose examples, key generation commands, and a checklist of common misconfigurations to avoid.
TLS MITM and Throttling to 10 Mbps: Two Distinct Network Degradation Patterns Observed in Russia
Russian users have reported sudden slowdowns and instability on international connections over the past several days. Analysis of Tunnel Cat logs revealed two separate issues that produce similar user symptoms but require different diagnostic approaches. The first pattern involves successful TCP and TLS handshakes followed by sharp drops in throughput, often from 80 Mbps to 8-12 Mbps, consistent with DPI-based throttling of international traffic. The second pattern shows TLS certificate substitution on Windows systems, indicating active man-in-the-middle interception. Tunnel Cat now detects invalid certificates and terminates such sessions, yet the underlying network phenomena persist. The observations highlight the need to examine both bandwidth dynamics and certificate chains when troubleshooting connectivity problems from Russia.
Deleted Database Records Remain Recoverable in SQLite Files Despite DELETE Operations
A standard DELETE query in SQLite removes rows from the table view but leaves the actual data intact inside the database file until pages are reused. The pragma secure_delete setting controls whether freed pages are zeroed immediately or simply marked as available. With the default setting of 0, strings containing names and credit card numbers can still be extracted using grep even after deletion. The same behavior appears in PostgreSQL through dead row versions until VACUUM runs and in MySQL InnoDB through undo logs and the binary log. The issue directly affects compliance with personal data deletion requests because backups, replicas, and analytics exports often retain the original records. Proper mitigation requires enabling secure_delete, running VACUUM after bulk deletions, or encrypting sensitive fields with per-record keys that can be destroyed on request.