Telegram handshake timeout in Russian networks

[bam80]

Hi, is this problem applicable here? Sorry if it was already reported:
telemt/telemt#617

[dolonet]

Yes — same root cause as telemt/telemt#617. Russian TSPU has escalated MTProto FakeTLS detection since ~2026-04-01; affects mtg equally. Tracked on mtg in #458, #463, #443 and related; #476 is effectively a duplicate of #458, which has the fullest discussion.

Short version of the mitigation the community converged on (and that BEST_PRACTICES.md already prescribes as of March):

• Real domain, A/AAAA pointing at the proxy VPS.
• Real Let's Encrypt cert, real webserver on :443 (nginx/Caddy/HAProxy/Traefik) with ssl_reject_handshake on for unknown SNI.
• mtg behind the webserver, tls_domain / mask_host set to the same real domain.
• Recent startup-check help: Warn about SNI/IP mismatch at proxy startup #461 warns on SNI/IP mismatch; Add docker-compose example with HAProxy SNI router #462 ships a docker-compose HAProxy SNI-router example; proxy-protocol-v2 now passes real client IP through. All merged to master.

Fallback if a real domain isn't an option: switching users to dd-prefixed secrets (random padding) has been reported stable by some operators in the telemt thread, at the cost of re-issuing every user's link. Doesn't address the SNI-verification arms race though, so it's a stopgap.

Suggest closing as duplicate of #458.

[bam80]

Thanks @dolonet, one thing to clarify - if I do something wrong or not enough, would I have a chance to recover on the same VPS, or the blocking is irreversible and it's important to do everything right from the first attempt?

[dolonet]

Recoverable in practice — TSPU's MTProto/FakeTLS classifiers re-evaluate periodically rather than hard-listing the IP forever. What people report:

• A flagged IP typically clears in ~24–72h once the offending fingerprint stops appearing, provided :443 keeps serving a real TLS site with a valid cert.
• Repeated mis-attempts from the same IP extend the cooldown — the dwell time grows each cycle. So it's not "irreversible," but it's not free either.
• The thing that actually bricks an IP is sustained vanilla-MTProto exposure or ssl_reject_handshake off with no real site behind it. A short window of misconfiguration during bring-up isn't fatal.

Practical bring-up order to avoid burning the IP:

1. Stand up the webserver + real cert on :443 first. Verify externally with curl -v https://your.domain and openssl s_client -connect ip:443 -servername wrong.example (must reject).
2. Bring mtg up behind it. Test the link from a non-RU client first — if mtg is reachable and the SNI router is correct, FakeTLS handshake will look clean.
3. Only then test from inside RU. If it fails, take mtg offline, leave the plain webserver up for a day or two, fix the config, repeat.

So yes — you have room to iterate on the same VPS, just don't point Russian clients at it until you've verified the externally-observable handshake.