Network Guide Featured Tags: Telegram MTProto split routing desktop

Telegram Stuck Connecting?Clash Split Rules for Domains and MTProto Fix

On the Telegram Desktop client, a forever Connecting banner usually means the app never finishes the initial handshake to Telegram data centers—not a missing sticker pack. When you layer Clash or Mihomo on top, failures cluster into a short list: DNS returning unusable answers under fake-ip, split routing rows that send telegram.org traffic to the wrong policy group, a double proxy where Telegram’s built-in SOCKS points at the same mixed port your OS already chains, or simply an exit node whose path to Telegram DCs never completes TCP handshakes on the ports Telegram expects—often 443 for MTProto-style transports. This guide walks those checks in order so you stop swapping subscriptions blindly.

Approx. 22 min read
Clash Editorial
Table of Contents

1. Mental model: MTProto paths while Clash classifies flows

Telegram Desktop speaks Telegram’s MTProto protocol over long-lived TCP connections toward geographically distributed data centers. End-user documentation rarely prints static IP lists because assignments rotate; instead the client resolves hostnames under telegram.org (plus auxiliary endpoints used for updates and Web experiences) and opens outbound connections—most commonly toward TCP port 443, because networks that only permit “HTTPS-shaped” traffic tolerate it more often than exotic high ports.

Clash does not magically “understand Telegram” as a label; it sees IP destinations, optional metadata from sniffers, and whichever RULE row matches first. If your resolver hands the app a wrong or filtered address, or your rule stack sends Telegram flows through a congested proxy group while stripping idle timers halfway, the symptom surfaces exactly like poor LTE—except Wi-Fi looks fine for browsers because different domains ride different buckets.

Tip: Read your fork’s docs on rule precedence and DNS modes in the documentation hub so vocabulary matches what your GUI prints—keyword spelling drift breaks silently across Mihomo-derived builds.

2. Triage: classify “Connecting” versus partial sync failures

Spend sixty seconds narrowing what “stuck” means:

  • Cold start never completes: after launching Telegram Desktop, the status bar stays at Connecting indefinitely—often DNS or first-hop routing.
  • Worked yesterday after idle suspend: typical of interface or route changes, half-open TCP state, or VPN handoffs; less about Telegram itself and more about your stack resuming consistently—compare with our TUN routing on Windows notes if you recently toggled adapters.
  • Only media stalls: text arrives but thumbnails spin—that pattern skews CDN fetching rather than MTProto login; rule placement differs.
  • Only after enabling SOCKS inside Telegram: suspect duplicate chaining—address that before rewriting YAML.

Collect facts once: confirm whether browsers reach unrelated HTTPS sites through Clash, note whether Telegram succeeds when Clash pauses temporarily (ethical testing on networks you administer), and capture whether logs show repeated TCP dial timeouts versus silent DNS refusal.

3. System proxy, TUN mode, and capture completeness

If Telegram bypasses Clash entirely—because no rule captures its socket—you observe bizarre partial successes depending on OS scheduler quirks. Three configurations dominate desktop setups:

  • System proxy pointing at Mixed inbound: apps honoring OS proxy settings route through Clash; stubborn binaries ignoring them leak direct.
  • TUN / virtual adapter forwarding: broader capture across processes as long as exclusions lists stay sane—yet misconfigured exempt CIDR ranges silently recreate leaks.
  • No global capture: Telegram must voluntarily proxy—and many builds respect neither PAC quirks nor localhost SOCKS unless explicitly configured inside the app.

Before blaming Telegram servers, reconcile whether your GUI claims “enabled” while Windows still harbors stale enterprise proxy WPAD overrides—orthogonal bugs overlap symptoms discussed in our system proxy residue guide, inverted here because Clash remains active.

4. DNS, fake-ip pools, and fake-ip-filter hygiene

Mihomo-class cores rewrite DNS answers when operating fake-ip mode to accelerate classification; domains absent from your fake-ip-filter lists receive synthetic addresses that map through policy routing differently than naive expectations. Telegram resolves numerous names (*.telegram.org, occasionally sibling zones); half-maintained profiles omit trailing domains until Sniffer reconstructs TLS—but MTProto sessions may never expose convenient plaintext hostnames.

Structured checks:

  1. Ensure resolver chains resolve publicly reachable DNS upstream without cyclic dependence through Clash unless intentional.
  2. Expand filter lists deliberately for Telegram-owned zones rather than disabling fake-ip wholesale.
  3. Compare outcomes against redir-host or system-resolver baselines during A/B testing to separate DNS from node health.
  4. Audit DoH endpoints and captive-portal VLANs—some corporate LANs intercept DNS queries bound for public resolvers entirely.

Deep pattern reference: fake-ip blocking and DNS troubleshooting—carry the same discipline to Telegram as you would to SaaS dashboards that “load only sometimes.”

Warning: Flipping random “boost” DNS knobs in parallel (OS, browser, router, provider app) fragments trust in any single resolution path—stabilize one architecture, then iterate.

5. Split rules: ordered DOMAIN-SUFFIX placement and policy groups

Author explicit split rules high in the stack—before ultra-broad GEOIP shortcuts that might classify DC IP blocks unpredictably after database updates. A minimal sketch (syntax varies by fork; treat as structural inspiration, not verbatim drop-in):

rules:
  - DOMAIN-SUFFIX,telegram.org,PROXY-TG
  - DOMAIN-SUFFIX,t.me,PROXY-TG
  - DOMAIN-SUFFIX,tdesktop.com,PROXY-TG
  # ... your existing GEOIP / MATCH rows

PROXY-TG denotes whichever selector holds exits that reliably reach Telegram infrastructure—not necessarily your fastest streaming node. Maintain naming clarity so midnight edits do not confuse “generic PROXY” pools tuned for browser CDN sites with latency profiles ill-suited to long MTProto streams.

Importing colossal remote RULE-SET archives without reading order invites shadowing: duplicate or broader rules above your Telegram rows silently capture traffic differently than you recall. Diff profiles when symptoms reappear after subscription refresh—automation beats memory.

6. MTProto ports, data centers, and what “443” implies

Marketing text often collapses “MTProto” into a single checkbox; operationally Telegram clients interleave RPC over TCP toward DC-specific endpoints. Operators care about:

  • TCP 443: widely allowed; restrictive firewalls sometimes only pass this alongside 80.
  • Alternate ports: some networks or censorship appliances throttle non-standard combinations—if your node provider advertises exotic egress filters, validate rather than assume.
  • IP rotation: Yesterday’s stable path may reroute—keep mmdb and remote rule providers current; stale country tags mis-hairpin traffic through wrong policy groups.

Because you cannot paste a permanent “Telgram IP whitelist” into YAML and expect peace for months, prefer domain-first policies with cautious IP-CIDR supplements you actually control—private tests, not scraped forum tables of unknown vintage.

If logs show TLS-like handshakes timing out toward certain exits, broader transport diagnosis appears in TLS handshake timeout triage; MTProto is not TLS in the browser sense, but carrier middleboxes sometimes disturb long TCP flows similarly.

7. Telegram’s own proxy fields versus OS-level capture

Telegram Desktop exposes optional SOCKS5 / HTTP proxy settings. If you point them at 127.0.0.1 with the same port Clash already exposes while simultaneously forcing system-wide proxying, you can construct circular or double-encrypted paths that waste CPU and occasionally fail silently after updates.

Saner defaults for many users:

  • Let Clash own system / TUN capture; leave Telegram’s internal proxy unset unless you truly require per-app isolation.
  • If you must isolate Telegram only, disable conflicting global hooks or document explicit bypass lists so only one component chains toward remote exits.
  • After toggling, fully quit Telegram—not just closing the window on macOS—so stale sockets do not overlap new policy.

8. Node selection, url-test tuning, and false “bad app” conclusions

A node that excels for static site browsing may stall MTProto when peering toward certain DC regions exhibits bufferbloat or recurrent loss. Practical steps:

  1. Manually pin a small set of exits through a dedicated selector referenced by your PROXY-TG group—avoid aggressive url-test flapping mid-session.
  2. Validate test URLs mirror what you optimize; default HTTP probes do not perfectly predict long-lived MTProto flows.
  3. Watch for quotas: some budget nodes deprioritize sustained high-throughput tunnels after a few minutes.

Cross-check idle-time behavior with our url-test interval and tolerance guide before chasing lower headline latency numbers that oscillate policy every few seconds.

10. Cheat sheet: quick mapping from symptom to first action

What you notice Check first
Connecting forever on launch DNS + fake-ip-filter coverage for telegram.org; verify capture mode (system vs TUN)
Worked until SOCKS toggled Remove double proxy; single chain to exit; restart Telegram fully
TLS timeout logs toward exit Swap test nodes; read TLS timeout article; confirm clock skew minimal
Only on corporate LAN Inspect upstream filtering of long TCP flows; try alternate exits or compliant MTProto proxies approved by policy
Other apps fine, Telegram alone Explicit DOMAIN-SUFFIX rows above broad GEOIP; dedicated policy group

Print or archive this matrix beside your YAML repo so teammates stop rerunning identical experiments each outage.

11. Summary

Telegram Desktop stuck Connecting under Clash rewards structured diagnosis: align DNS and fake-ip behavior, place split rules for Telegram zones ahead of blunt GEOIP shortcuts, avoid double proxy chains through overlapping SOCKS and system capture, and treat MTProto as sustained TCP toward rotating DC endpoints—most often observed on paths compatible with port 443 expectations. Nodes matter, but subscription roulette before resolver hygiene wastes hours.

Compared with glossy one-click VPN brochures, disciplined Mihomo operators collect reproducible evidence: ordered rule hits, resolver traces, and documented selector intent. Obtain installers from vendor-trusted channels so debugging ends in configuration clarity rather than binary doubt.

After Telegram connects reliably, snapshot the working YAML and annotate why each PROXY-TG member exists—the next upstream subscription refresh should not become a mystery merge.

→ Download Clash for free and experience the difference