Documentation
Complete guide to setting up website monitoring with PingZen. API documentation, code examples, and best practices.
Monitor Telegram MTProto Proxy servers with PingZen. MTProxy uses the proprietary MTProto protocol with Fake TLS obfuscation to bypass DPI censorship. PingZen performs cryptographic handshake validation to verify your proxy is alive, accepts your secret and relays traffic to Telegram.
What It Is For
A proxy your community actually uses
Port 443 is open almost everywhere: behind it there may be your proxy, an ordinary website, or a DPI stub. A green TCP check says nothing about which one it is; an MTProto handshake does.
Is the secret still accepted
A proxy with the wrong secret does not break — it starts behaving like an ordinary website (domain fronting). PingZen verifies the HMAC cryptographically, so that proxy turns red instead of staying green.
Blocked by an ISP or by DPI
The server itself can be perfectly alive while the path to it from one network is cut. The check runs from outside, from the region you pick, so you can tell "the proxy is down" from "the proxy is blocked".
What It Is Not For
The check performs a real MTProto handshake against your proxy. It does not answer these:
| You want to know | Use instead |
|---|---|
| Is a SOCKS5 proxy working? | SOCKS5 monitor |
| Does the certificate of the fronted domain expire soon? | Nothing to watch — EE mode uses FakeTLS, a forged handshake with no real certificate behind it |
| Is Telegram itself having an outage? | Out of scope — the check proves your proxy relays to a Telegram data centre, not that Telegram is healthy |
| Can the proxy reach every Telegram data centre? | Not covered — the request goes to data centre 2 only. A proxy that cannot reach another data centre stays green, while users whose account lives there cannot connect through it |
| Is a website reachable through the proxy? | An HTTP monitor checks a site directly |
How It Works
- PingZen connects to your MTProxy server via TCP (usually port 443)
- For EE secrets (Fake TLS): sends a TLS 1.3 ClientHello with HMAC-SHA256 authentication embedded in the Random field
- The proxy responds with a ServerHello containing its own HMAC — PingZen validates it; a mismatch means a wrong secret or a fronted website, and the check fails
- PingZen opens the obfuscated2 channel (AES-256-CTR, keys derived from your secret) — inside TLS Application Data for EE, directly for DD/plain — and sends an MTProto
req_pq_multiaddressed to Telegram data centre 2 - The proxy has to forward that request to Telegram: the check is UP only when the data centre’s
resPQcomes back carrying PingZen’s nonce. If the HMAC is valid but nothing comes back, the check fails with “Proxy alive (HMAC valid) but not relaying to Telegram DC”
The response time covers the whole path: resolving the host name, the TCP connection, the FakeTLS handshake (EE only) and one request through the proxy to a Telegram data centre and back.
Check Levels
PingZen performs multi-level validation depending on your secret format:
FakeTLS HMAC + MTProto relay (EE secrets)
The HMAC proves the proxy knows your secret and catches domain fronting (wrong secret → proxy forwards to real website). An MTProto request (req_pq) then goes through the FakeTLS channel to Telegram, proving the proxy actually relays — a live proxy with a dead upstream turns red.
Obfuscated2 + MTProto relay (DD/plain secrets)
Sends AES-256-CTR encrypted init payload, then an MTProto request (req_pq) through the proxy to Telegram. These proxies silently accept an init built from a wrong secret, so only Telegram's answer proves both the secret and the relay.
TCP Connectivity
Basic TCP port check. Confirms the server is reachable but cannot verify secret validity.
Secret Formats
MTProxy supports three secret formats. Modern proxies use EE (Fake TLS) almost exclusively:
Plain (32 hex chars)
Original format. 16-byte secret without obfuscation prefix. Easily detectable by DPI. Example: cafe1234cafe1234cafe1234cafe1234
DD (dd + 32 hex chars)
Padded intermediate mode. Adds random padding to packet sizes, making DPI fingerprinting harder. Example: ddcafe1234cafe1234cafe1234cafe1234
EE (ee + 32 hex + domain hex)
Fake TLS mode — the current standard. Traffic looks like HTTPS to the specified domain. Example: ee0123456789abcdef0123456789abcdef676f6f676c652e636f6d (domain: google.com)
Configuration
Server Address
Hostname or IP address with port (e.g., proxy.example.com:443). Default port: 443.
Secret
Your MTProxy secret in hex or base64 format. Supports three formats: plain (32 hex chars), DD (dd + 32 hex), and EE (ee + 32 hex + hex-encoded domain) for Fake TLS mode.
SOCKS5 vs MTProxy
Both protocols can proxy Telegram traffic, but they differ significantly in DPI resistance:
| Feature | SOCKS5 | MTProxy |
|---|---|---|
| DPI Resistance | None — RFC 1928 handshake is fingerprinted | High — Fake TLS looks like regular HTTPS |
| Traffic Scope | Any TCP/UDP application | Telegram only |
| Authentication | Username/password (RFC 1929) | 16-byte shared secret (HMAC-SHA256) |
| Port | 1080 (default) | 443 (mimics HTTPS) |
| Secret Validation | Protocol handshake | Cryptographic HMAC proof |
| Domain Fronting | Not applicable | Built-in — invalid clients see real website |
Key Features
- Cryptographic handshake validation (not just TCP port check)
- FakeTLS (EE) HMAC-SHA256 verification
- Support for all secret formats: plain, DD, and EE
- Domain fronting detection for EE secrets
- Human-readable error messages for handshake failures
- SSRF protection — private IP targets are blocked
- Zero external dependencies — pure Python asyncio sockets
- End-to-end verification for every secret format — EE, DD and plain — via an MTProto req_pq relayed through the proxy to a Telegram data centre
- Works with mtg, mtprotoproxy, Erlang mtproto_proxy, and other MTProxy servers
Common Questions
What protocols can I monitor?
PingZen supports 23 protocols: HTTP/HTTPS, WebSocket (WS/WSS), TCP, UDP, ICMP Ping, gRPC, DNS, WHOIS, TLS/SSL certificates, Email (SMTP/IMAP/POP3), FTP/FTPS, DNSBL, PageSpeed, SOCKS5, MTProxy, API Check, and Transaction. You can monitor websites, APIs, servers, databases, and any network service.
How fast can I get alerts?
Telegram alerts are delivered within 1-2 seconds of detection. Slack and Discord notifications arrive almost instantly. You can configure multiple alert channels for redundancy.
Can I organize monitors by project?
Yes! PingZen supports workspaces, which let you organize monitors by project, environment, or team. Each workspace can have its own alert configurations and team members.
Is there an API for automation?
Absolutely. PingZen provides a full REST API with OpenAPI documentation. You can create, update, and delete monitors programmatically.
How do status pages work?
Status pages are public, branded pages showing your services' uptime. You can display real-time status and allow customers to subscribe for updates.
What happens if I reach my monitor limit?
We'll notify you when approaching your limit. You can pause some monitors or contact us for increased capacity. We never stop monitoring without warning, ensuring your critical services stay protected.
Ready to stop missing downtime?
Join thousands of teams who trust PingZen. Setup takes 30 seconds.