# SoliSpirit/mtproto: How the Auto-Updated Telegram Proxy List Works

> SoliSpirit/mtproto publishes a plain-text list of free Telegram MTProto proxy links that a bot scans and verifies every 12 hours. It suits users seeking a current list, but the repository provides no source code, generation script, license, or details about proxy ownership and privacy.

**SoliSpirit/mtproto** — Fresh and reliable Telegram MTProto proxies updated automatically every 12 hours. Free, fast, and verified proxy list to bypass censorship and ensure secure Telegram access worldwide.

- Repository: https://github.com/SoliSpirit/mtproto
- Stars: 1,919 · Forks: 92
- Language: Unknown
- License: not declared
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/solispirit-mtproto

## What SoliSpirit/mtproto Actually Supplies

SoliSpirit/mtproto addresses one narrow problem: obtaining a current list of Telegram MTProto proxy links from a single text file. Its intended users are Telegram users who need access to the service through an MTProto proxy, particularly when their normal route is blocked or unsuitable. The repository does not implement Telegram, a VPN client, or a full proxy network. It distributes addresses that point to separate public proxy servers.

The main artifact is `all_proxies.txt`. According to the README, each line contains a working MTProto proxy in Telegram's standard link format. A user can copy a line into a browser or paste it into Telegram's proxy settings. The repository is therefore closer to a directory than an application. There is no documented dashboard, account system, configuration file, local daemon, or client library to install.

This distinction matters because control remains with the remote proxy operator. A URL hosted in this repository can direct Telegram traffic to a server maintained elsewhere. The README describes the list as private and secure, but it supplies no protocol analysis, operator policy, retention policy, or independent audit. Based on the repository layout, users receive proxy identifiers, not infrastructure they can inspect or operate themselves.

## The 12-Hour Collection and Publishing Flow

The documented update mechanism uses a custom script and a bot. According to the README, the script scans for publicly available MTProto proxies, verifies them, generates `all_proxies.txt`, and pushes the resulting list into the repository every 12 hours. The public artifact is available through this URL:

```text
https://raw.githubusercontent.com/SoliSpirit/mtproto/master/all_proxies.txt
```

The raw URL is the clearest consumption interface because it returns the file without requiring repository navigation. The README does not publish the custom script, so its proxy sources, verification procedure, timeout policy, retry behavior, and acceptance criteria cannot be inspected.

The visible outcome is a line-oriented text format. The README gives this example:

```text
tg://proxy?server=example.com&port=443&secret=ee00000000000000000000000000000000000000
```

The example uses the `server`, `port`, and `secret` URL parameters. It is illustrative rather than a recommendation from the repository, and the README does not say that `example.com` is an available endpoint. Since there is no published update log per entry, users cannot trace when a particular line was added, which verification checks it passed, or whether a failure removed it immediately.

A 12-hour publication interval also does not guarantee that every listed proxy remains usable for the full interval. Proxy availability can change between automated runs. The README's wording is that the script verifies entries before publishing, but it does not document how quickly Telegram clients will reject a degraded proxy.

## Using a Proxy Link in Telegram

SoliSpirit/mtproto has no installation command because it is a repository of text data rather than a software package. The README directs users to copy a line from `all_proxies.txt` and open it in a phone or desktop browser. Telegram is expected to recognize the `tg://proxy` link and offer a proxy connection. The manual route is Telegram's "Data and Storage" settings area, where a user pastes the same link under "Proxy".

A first use can proceed as follows. Open the raw `all_proxies.txt` URL, select one complete line without adding spaces or line breaks, and copy that line. Open it in a browser on the device that has Telegram installed. The expected result described by the README is that Telegram offers to connect using the proxy. If it does not, return to Telegram's "Data and Storage" settings, open the proxy configuration described in the README, and paste the complete link there.

No replacement token, account identifier, project-specific password, or local configuration is documented for this repository. The `secret` belongs to the individual MTProto proxy link and must remain part of the copied URL. The README does not provide commands for testing every entry, checking latency, selecting a geographic location, or rotating proxies automatically.

Because the list contains public third-party servers, the first-use check should remain limited to what the documentation establishes: whether Telegram recognizes the link and whether that proxy works at that moment. The repository does not document checks for operator identity, traffic logging, availability guarantees, or long-term endpoint ownership.

## Repository Limits and Proxy Trust Boundaries

The clearest limitation is missing auditability. The README names a custom scanning and verification script, but the script itself is absent from the listed repository entries. That leaves users unable to determine what constitutes a successful check or which public sources feed the list. A generated file is convenient, but it does not provide the evidence required to evaluate collection quality.

The README also describes every line as working when published while acknowledging only that refreshes happen every 12 hours. That leaves a normal failure mode for any user: an address can pass the bot's check and later become unreachable, overloaded, or unusable from a different network. The documentation provides no status field, failure history, geographic coverage, or fallback procedure.

The project is the wrong tool when someone needs a controlled proxy service, documented server ownership, or an accountable operator. It also does not replace a local VPN or a proxy client because it contains only links. Users who require evidence about how a proxy operator handles connection metadata should not treat a bot-generated public list as sufficient documentation.

No license is identified. That creates an unresolved reuse question for engineers who want to embed the file in another service, mirror it, modify it, or redistribute it. The README does not grant reuse rights, and this review cannot supply a license that the repository does not state. No GitHub releases are published, so consumers also cannot use tagged release artifacts as a stable distribution mechanism.

## SoliSpirit/mtproto Compared with a Self-Managed Proxy

The practical alternative is a self-managed MTProto proxy. The difference is one of ownership and control. SoliSpirit/mtproto compiles addresses for publicly available proxies, while a self-managed approach requires the adopter to obtain or operate the proxy server, maintain its configuration, and control updates. The repository documentation does not describe setup for a self-managed server, so this comparison concerns the distribution model rather than specific third-party software.

SoliSpirit/mtproto offers a simpler exchange: the user receives a ready-made link and relies on the collection bot plus remote proxy operator. A self-managed service adds operational work but places the endpoint lifecycle with the adopter. The repository is more suitable when the immediate goal is obtaining several public links without running infrastructure. It is less suitable when availability, incident response, or data-handling accountability must remain under the adopter's control.

Neither option should be represented as a documented privacy guarantee based on this repository alone. The README says the proxies are intended to support privacy and secure access, but it provides no audit evidence or technical detail about server administration. That distinction is particularly important because the list can change automatically even when a consumer does not review a manual change.

## Refresh Cadence, Releases, and Upgrade Cost

The README states that the bot pushes a new proxy list every 12 hours. That automation removes the need for users to request routine list updates manually, assuming the workflow described in the README continues to operate. The last push was on 2026-10-16. However, a recent repository push does not guarantee that every endpoint in the file is healthy or that the custom script remains functional, because the repository does not publish workflow logs or proxy verification details.

There are no GitHub releases. Consumers therefore have no documented release tags, versioned archives, or release notes to inspect. Upgrading is not described as a package operation. For a direct text-file consumer, the main question is whether the URL is fetched on each use, cached, or imported once; the repository does not document an integration pattern.

The repository is not archived. Its last push was on 2026-10-16, but it is not appropriate to infer server quality or proxy coverage from that activity alone. The unknown license is a separate adoption cost because redistribution and incorporation into a product remain undocumented. Teams that need repeatability should first verify the raw file format, refresh expectations, and ownership terms rather than treating the bot cadence as a service-level commitment.

## Conclusion

SoliSpirit/mtproto may suit Telegram users who want a frequently refreshed list of public MTProto proxy links and can tolerate verification failures. It is a poor choice for organizations that require an inspectable generation process, a defined license, proxy ownership disclosures, or a supported service. Before adoption, inspect all_proxies.txt, confirm that the links open in the intended Telegram client, and determine who operates the listed proxies and what data they can observe.

## FAQ

### How often does SoliSpirit/mtproto update its Telegram proxy list?

The README says a bot generates and pushes the list every 12 hours using a custom script.

### How do I use a proxy from SoliSpirit/mtproto in Telegram?

Copy a complete link from `all_proxies.txt` and open it in a browser, where Telegram is expected to offer a proxy connection. You can also paste the link into Telegram's "Data and Storage" settings under "Proxy".

### Does SoliSpirit/mtproto verify its MTProto proxies?

The README states that its custom script scans for publicly available proxies and verifies them before publishing. It does not publish the script or describe the verification checks.

### Does SoliSpirit/mtproto provide releases or a software installation package?

No GitHub releases are published, and the repository contains documentation plus `all_proxies.txt`. The README does not provide an installation command because the project distributes links in a text file.

## Sources

- [Issues](https://github.com/SoliSpirit/mtproto/issues)
- [README](https://github.com/SoliSpirit/mtproto/blob/master/README.md)
- [SoliSpirit/mtproto on GitHub](https://github.com/SoliSpirit/mtproto)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/solispirit-mtproto
