Why this problem is harder than a list of IP addresses
An MTProto proxy directory looks simple from the outside: a host, a port, a secret, and a button that opens Telegram. In practice, the useful part is everything around that data. Public proxies disappear, become overloaded, change latency, or stop accepting connections. A directory that only stores rows quickly becomes stale.
While working on mtproto.cloud, I ended up treating the page as a small reliability product rather than a static catalog. These are the engineering and UX principles that matter most.
1. Freshness is a feature
A proxy should never be presented as permanently available. The interface needs to communicate when it was last checked and whether the latest check succeeded. Fresh health information is more useful than a very large list.
A practical data model separates the proxy identity from its observations:
- endpoint: host, port, protocol variant;
- public connection parameter: the Telegram-compatible secret;
- observation: check time, status, latency, and failure reason;
- display state: online, recently unavailable, or expired.
This makes it possible to retain history without pretending that an old successful check is current.
2. Health checks should be conservative
A TCP connection alone is not enough to prove that a proxy is useful, but aggressive application-level probing can create unnecessary load. The checker should have strict timeouts, limited concurrency, backoff after failures, and a clear distinction between network errors and invalid configuration.
The important operational rule is to avoid turning monitoring into abuse. Checks should be lightweight and scheduled, not continuous.
3. Connection data needs careful handling
MTProto proxy connection parameters are not account credentials, but they still deserve deliberate treatment. A directory should avoid hidden redirects, unexpected downloads, and scripts that modify the connection target. Users should be able to inspect the host and port before opening Telegram.
For the connection action, a transparent Telegram deep link is easier to understand than a custom launcher. The page should also explain that a proxy is not a full VPN and does not protect all device traffic.
4. The interface should reduce uncertainty
The primary questions a visitor has are simple:
- Is this proxy currently reachable?
- When was it checked?
- What will happen when I click?
- Can I copy the parameters instead?
Those questions should be answered on the card itself. Decorative metrics are less useful than a visible status, timestamp, copy action, and connection action. Mobile layouts deserve special attention because many visitors open the directory on the same phone that has Telegram installed.
5. Do not hide the limitations
A public directory cannot guarantee ownership, privacy practices, uptime, or speed of third-party proxies. That limitation should be explicit. Good product copy is part of the security model: it prevents the interface from promising more than the system can verify.
The safest message is straightforward: use public proxies only when you understand the trade-offs, do not treat them as a substitute for a trusted VPN, and disconnect any endpoint you no longer need.
6. A small reliable list beats a huge stale one
Search pages often reward volume, but users reward working results. Expiring old entries, limiting repeated failures, and prioritizing recent successful checks makes the directory smaller and more useful.
This also reduces operational cost. You spend fewer checks on endpoints that have been unavailable for a long time and more on entries people can actually use.
What I would measure next
The next useful metrics are not raw page views. I would measure:
- time from page load to a successful connection action;
- percentage of visible entries checked within the freshness window;
- copy versus deep-link usage on desktop and mobile;
- how often users return after a proxy becomes unavailable;
- the error rate of the health-check pipeline itself.
These measurements can improve the product without collecting message content or Telegram account data.
Closing thought
The main lesson is that connectivity tools earn trust through clarity. Keep the checks lightweight, the status honest, the actions transparent, and the limitations visible. The directory is useful only when a visitor can understand exactly what is known — and what is not.
Disclosure: I work on mtproto.cloud. This post describes general product and engineering lessons, not a guarantee about any third-party proxy.
Top comments (0)