A technical case study details the difficulties of operating a reliable MTProto proxy for Telegram inside Russia when facing modern ISP deep-packet inspection. The author began with the popular mtg implementation and quickly discovered that simple forwarding solutions were insufficient against active protocol fingerprinting.
The first architecture placed HAProxy in TCP passthrough mode on a Russian server, forwarding traffic to a foreign mtg instance. Because HAProxy and raw iptables DNAT preserve every byte of the original stream, the ISP’s DPI continued to recognize the characteristic MTProto and fake-TLS patterns and throttled the connection. Changing ports or replacing HAProxy with SOCKS5 produced identical results, proving that any unauthenticated TCP tunnel remains detectable.
Only the introduction of VLESS+Reality delivered consistent connectivity. Reality performs a genuine TLS 1.3 handshake with a live destination domain, making the traffic indistinguishable from ordinary HTTPS for passive observers. The final topology routes client connections through local mtg, then through a localhost SOCKS5 listener into an Xray client that establishes a multiplexed VLESS+Reality tunnel to a foreign Xray server.
Several configuration errors were encountered and resolved. Enabling the xtls-rprx-vision flow caused immediate connection resets because the flow parser expects structured TLS records that MTProto payloads do not contain. Removing the flow parameter restored functionality. Even after that fix, short-lived Telegram connections frequently timed out during the full TLS handshake; enabling mux with concurrency 32 on the outbound eliminated repeated handshakes and stabilized the link.
Testing across multiple Russian providers revealed that some hosters apply aggressive DPI at their network edge while others do not. The same configuration that failed on the original provider worked immediately on a second provider, confirming that the root cause was the first provider’s traffic policy rather than the proxy architecture itself.
The article supplies complete configuration files, docker-compose stacks, Reality key-generation commands, and a practical checklist covering flow settings, IPv4 preference, destination domain selection, and connectivity validation with the built-in mtg doctor command.
