Telegram Desktop has received a fundamentally new method for bypassing blockages, which camouflages the messenger's traffic as ordinary website visits over a secure connection. The experimental WEB-proxy technology presented on August 21, 2026, transmits MTProxy data via WebView transport based on HTTPS or WebSocket. This makes the data stream indistinguishable from legitimate web browsing and opens new prospects for accessing the service under restrictive conditions.
How the Invisible Tunnel Works
The essence of the innovation lies in using a multiplexed stream that is directed through a browser engine embedded within the application. The client preserves the familiar encryption and framing of MTProxy but sends all data through a single WebView session instead of direct TCP connections. A special frame format - OPEN, DATA, WINDOW, and CLOSE - allows packaging multiple logical Telegram connections into one secure channel that externally resembles a standard webpage loading.
On the server side, a relay operates, receiving this unified stream and carefully separating it into individual connections for transmission to the standard MTProxy. The intermediate node does not decrypt the content or know the final destination addresses, acting merely as a blind courier. The payload remains opaque at all stages after the initial transformation by the application, guaranteeing confidentiality even when passing through additional nodes.
The Double Life of a Domain Name
The WEB-proxy operates on a regular HTTPS domain that continues to serve a full-fledged public website. The bridging page for proxying is activated exclusively when a special parameter, calculated based on the configuration, is present. Any regular request receives the site's standard homepage, creating a reliable cover against automatic detection systems.
The choice of data transmission method is rigidly fixed in the generated intermediate page for each specific session. A local adapter converts TCP connections into logical streams and combines them within a single transport session tied to the original domain. This architecture allows using the infrastructure of ordinary hosting services and content delivery networks without drawing attention to proxy activity.
Technical Implementation Details
Complete documentation on deployment and the protocol is published in the tproxy-server repository, describing all configuration nuances. The user specifies the canonical hostname and the MTProxy secret, from which a unique capability identifier for connecting to the bridge is derived using HMAC-SHA256. Only an exact GET request with a specific 43-character parameter grants access to the special page; all other visits are processed as ordinary ones.
The connection link looks like https://t.me/webproxy?server=proxy.example.com&secret=... or uses the tg://webproxy scheme. Port 443 and the HTTPS protocol are mandatory and fixed by the WEB-proxy type specification. The described protocol ensures strict typing of requests and prevents accidental bridge activation.
Current Project Status
The development is in the proof-of-concept stage and includes a desktop implementation, an experimental Android client, and plans for iOS support. All platforms use the identical intermediate page, frame format, and server components, simplifying testing and further development. Unifying the client and server parts allows for rapid changes and hypothesis testing across different operating systems.
The emergence of WEB-proxy demonstrates a shift towards more sophisticated methods of integrating with legitimate web infrastructure. Using standard browser mechanisms and secure protocols complicates the task for filtering systems, which must choose between completely blocking HTTPS traffic and maintaining the availability of regular services. The practical value of the technology will be determined by its resilience to adaptive traffic analysis methods and its ability to scale without performance loss.
AI Perspective
From a machine data analysis standpoint, the presented WEB-proxy scheme structurally repeats an earlier technique of camouflaging traffic as legitimate HTTPS – "domain fronting." This method gained traction in the mid-2010s and is described as a way to hide the true connection destination through a mismatch between SNI and HTTP Host. Major CDN providers eventually restricted this capability at the infrastructure level, forcing developers to seek alternative camouflage paths – in Telegram's case, this path became using a parameterized bridge page within WebView. The situation demonstrates the cyclical nature of the struggle between censorship and circumvention technologies: each technical solution works until filtering systems adapt to the new traffic pattern. Will WEB-proxy remain resilient to the analysis of packet timing characteristics and session volume, or will developers once again need to find a new level of camouflage?
end-content
