Clients stuck on “Connecting…” (works fine with official telegrammessenger/proxy on same port & secret)

[Alishahrokhiii]

Hi 👋
Thanks for maintaining this project.

I’m reporting a connection issue that I can reliably reproduce and that does not happen with the official MTProxy implementation.

---

Environment

• Server OS: Ubuntu 22.04
• Docker: latest
• Client: Telegram iOS / Android (Iranian ISPs)
• Port: 2096 (also tested 2083, 9443)
• Secret: standard 32-hex MTProto secret
• Transport: TCP
• Domain-based access (e.g. example.domain.com:2096)

---

What works (baseline)

Using the official MTProxy image:

telegrammessenger/proxy:latest

With:

• the same port
• the same secret
• the same server
• the same clients / ISPs

➡️ Connections are stable and immediate.

---

What does NOT work

Using GetPageSpeed/MTProxy with Docker:

ghcr.io/getpagespeed/mtproxy:latest

Symptoms:

• Telegram clients remain stuck on “Connecting…”
• No explicit error on client side
• Happens consistently on Iranian networks
• Sometimes works on non-restricted networks, but unreliable

---

Important observation

• The issue only appears when switching to this fork
• No firewall / iptables / UFW blocking (confirmed)
• Port is listening correctly and container is running
• Connections reach the container, but MTProto handshake never completes

---

Logs / Network behavior

Inside the container:

• TCP connections are created
• Handshake does not finalize
• Client retries indefinitely

On host:

• Port forwarding and DNAT work as expected

---

Hypothesis

This may be caused by:

• MTProto obfuscation differences vs the official implementation
• Subtle protocol incompatibility during initial handshake
• DPI-sensitive behavior (Iranian ISPs are very strict)

The official Telegram implementation seems more tolerant / compatible in this environment.

---

Question

• Is this fork fully MTProto-compatible at handshake level?
• Is there any recommended configuration for restricted networks?
• Are there known issues with DPI-heavy countries?

I’m happy to test patches or provide more logs if needed.

Thanks 🙏

[dvershinin]

Thanks for the detailed report.

Since the official image works with the same setup, this rules out DPI/network issues — the problem is specific to this fork. To diagnose, I need the following:

1. Server architecture

uname -m

This is critical — our Docker image is built for x86_64 only. If your server is ARM (aarch64), it runs under QEMU emulation which breaks crypto timing.

2. Full run commands for BOTH images

Please share the exact docker run (or docker-compose.yml) you use for:

• telegrammessenger/proxy:latest (the one that works)
• ghcr.io/getpagespeed/mtproxy:latest (the one that fails)

This helps spot configuration differences.

3. Is your server behind NAT?

Most cloud VPS use NAT. If so, did you set the EXTERNAL_IP environment variable? Without it, the proxy advertises its internal container IP to Telegram, which can prevent handshake completion.

Example:

-e EXTERNAL_IP=<your-server-public-ip>

4. Container logs

docker logs <container_name>

Even without debug mode, startup errors will appear here.

5. Stats while clients are stuck

curl http://localhost:8888/stats

Run this while a client is stuck on "Connecting..." — it shows whether connections are arriving and where they fail.

[kmurachev]

@Alishahrokhiii
#23 (comment)

...
git clone https://github.com/GetPageSpeed/MTProxy.git
cd MTProxy
git checkout f9d39fb5351688d9d91ed6b399cb554ae24f1276
...

[dvershinin]

@kmurachev Thanks for linking issue #23. To clarify for @Alishahrokhiii: the commit f9d39fb that kmurachev suggests is already the current master HEAD and what the ghcr.io/getpagespeed/mtproxy:latest Docker image is built from (rebuilt Jan 7).

There was a brief period (Dec 28) where two broken Copilot-generated PRs were on master that broke EE (fake-TLS) mode. Those were reverted via force-push. If you pulled the image during that window, you may have a stale cached image.

Please run:

docker pull ghcr.io/getpagespeed/mtproxy:latest

Then recreate the container and test again.

Also — issue #23 is specifically about EE (fake-TLS) mode. You mentioned using a "standard 32-hex MTProto secret". Are you using:

• Standard mode: secret is just 32 hex chars (e.g. abcdef1234...)
• DD mode: secret prefixed with dd
• EE mode: secret prefixed with ee + domain hex

This matters because the linked issue only affects EE mode. If you're on standard mode, it's a different problem and the diagnostic info from my previous comment will help narrow it down.

[dvershinin]

Closing as stale — no diagnostic information was provided since the initial report (3+ months).

Since this issue was opened, several fixes have been made that likely address the root cause:

• ARM64 support (Docker: add arm64 (Apple Silicon / ARM) support #48): If your server was ARM, the proxy now runs natively instead of under QEMU emulation
• NAT auto-detection: External IP is now detected automatically, fixing silent failures when --nat-info was missing
• EE mode fixes: Multiple fake-TLS bugs were fixed (single-record ServerHello, HMAC compatibility)
• TLS compatibility: Constant-time HMAC comparison, tighter replay window

Please update to the latest image (docker pull ghcr.io/getpagespeed/mtproxy:latest) and test again. If the issue persists, please reopen with the diagnostic info requested above (architecture, run commands, logs, stats output).