MTProxyMax wraps a Rust MTProto engine in one bash script and a TUI

One script around a Rust engine

MTProxyMax is a full-featured Telegram MTProto proxy manager powered by the telemt 3.x Rust engine, and it wraps that engine with an interactive TUI, a complete CLI, a Telegram bot for remote management, per-user access control, traffic monitoring, proxy chaining and automatic updates, all in a single bash script.

The primary language of the repository is Shell, and the repository tree is correspondingly small: install.sh, mtproxymax.sh, a main.png screenshot, a tests/ directory, the LICENSE and the .github directory.

The split matters. The proxy engine itself is not written here, it is telemt, a Rust and Tokio implementation built with link time optimization, and MTProxyMax is the layer that turns it into something an operator can run without knowing the engine's configuration format. One of the listed features is engine tuning with whitelisted parameters, so you adjust the engine through the tool rather than editing raw TOML, which is the whole point of the arrangement.

The version badge in the README shows 1.4.2-LTS, and the release list shows the same line published on 2026-09-29, with 1.4.1-LTS on 2026-09-15 and 1.4.0-LTS on 2026-07-13. The release title for the current one mentions the telemt 3.5.9 engine along with self-healing resilience and enterprise hardening. The last push to the repository was on 2026-09-29, and the project is MIT licensed.

Three ways to install, one of them a root shell from a URL

The quick start offers a one-line install, a manual install and a container image.

The one-liner is this.

sudo bash -c "$(curl -fsSL https://raw.githubusercontent.com/SamNet-dev/MTProxyMax/main/install.sh)"

It pipes a script fetched over the network into a root shell. The README says the interactive wizard then walks you through the port, the domain, the first user secret and optional Telegram bot setup, and the argument is that the wizard handles the configuration that would otherwise be the hard part.

The manual route downloads the main script and installs it yourself.

curl -fsSL https://raw.githubusercontent.com/SamNet-dev/MTProxyMax/main/mtproxymax.sh -o mtproxymax
chmod +x mtproxymax
sudo ./mtproxymax install

After installation there are two commands worth knowing.

mtproxymax           # Open interactive TUI
mtproxymax status    # Check proxy health

The container route pulls a pre-built multi-architecture image from GitHub Container Registry.

docker pull ghcr.io/samnet-dev/mtproxymax-telemt:latest

The README says the images cover linux/amd64 and linux/arm64 and package the pre-compiled Rust and Tokio telemt engine built with link time optimization. The platform badge says Linux and the bash badge says 4.2 or newer, so the shell requirement is explicit.

Per-user quotas are the reason the tool exists

Most MTProxy tools, the README argues, give you a proxy and a link. The distinguishing feature here is that the proxy is treated as a service with users.

The multi-user secrets feature gives each user their own secret with individual bandwidth quotas, device limits and expiry dates. On top of that sit shared quota pools, where a group of users sits under a common bandwidth ceiling, and calendar schedules, which offer unmetered weekend and holiday data passes. Tags and templates let you group users by category and onboard new ones with reusable limit sets, and a monthly quota reset gives each user a subscription-style automatic traffic reset.

The rate shaping is done with the Linux kernel rather than in the application. The README describes real-time QoS bandwidth shaping through tc and htb hierarchical rate limits, dynamically mapped to active per-user IP sessions without container restarts, and the same mechanism appears again in the bandwidth and quotas list. There is also a set of automated Telegram abuse and expiry alerts.

The difference in approach from the simple case is worth naming. A basic MTProxy setup is a binary and a secret, and everyone who has the secret shares one bucket. Here the bucket is per user, enforced by the kernel, visible in Prometheus metrics, and adjustable at runtime, which is the difference between a proxy and a proxy service.

A Telegram bot as the operations console

The bot is described as dual-tier and self-service, and the two tiers are separated by authentication.

The public tier is for end users, with commands including /start, /my_status with a label, and /voucher. The protected tier is the admin control plane, with commands including /mp_fleet, /mp_secrets and /mp_lockdown.

That separation is the design. A user who wants to check their own quota does not need an operator's credentials, and an operator can lock down the server from a chat without a shell. The emergency lockdown switch is described as an instant panic posture hardening available through the CLI or the bot.

The feature list mentions a Telegram bot with 21 administrative commands, while the table of contents in the README refers to a Telegram Bot section titled with 27 commands. That discrepancy is small but worth flagging, because it tells you the README is maintained by hand alongside the code.

The commercial layer sits on top of the same structure: batch gift code vouchers with create and redeem, role-based access control through admin add, and a static status portal described as glassmorphism.

There is also a webhook command for multi-channel JSON notifications to Discord, Slack and DingTalk, which is how an operator would be told that a failover happened without watching a terminal.

Fleet, backups and replication for more than one server

Three features cover the case where one server is not enough.

The fleet command is described as multi-server fleet federation with centralized master-slave telemetry aggregation, global concurrent connection health and pooled bandwidth tracking across a server mesh. The migrate command is a one-click emergency evacuation that does instant SSH or rsync migration to another server. The replication feature syncs configuration to slave servers automatically over rsync and SSH, and server migration is tarball-based export and import with one command.

Backups come in three flavours. The cloud backup command does one-click and cron tarball offloading, either directly to a Telegram admin chat using sendDocument, or to multi-cloud storage through rclone with S3 or R2. There is also a dedicated encrypted backup feature with AES-256 and an autoclean policy, and a maintenance mode that handles a graceful pre-restart so that the proxy is not simply dropped.

The other operational commands are what you would expect from a tool that runs unattended on a server. A doctor and verify pair gives diagnostics, an audit log records change history, a lockdown switch hardens the host on demand, and auto-recovery with auto-rotate detects downtime and rotates aging secrets automatically. A scanner-shield feature blacklists live Shodan and Censys scanners through ipset, and a live-diag command gives a real-time ASCII traffic dashboard, with a printable QR onboarding sheet for handing out access.

Anti-DPI features and what they assume about your network

The feature list includes a next-generation anti-DPI and stealth suite: BBRv3 congestion control, anti-DPI packet padding through a shield command, a reverse-proxy probe trapdoor called cover-shield, and active forensic inspection through dpi-inspect. There is also automated cover domain hunting with auto-sni, TLS fingerprint randomization with cert-shield, and automated Let's Encrypt certificate issuance with domain TLS SNI validation through openssl.

These are the features that distinguish this from a plain MTProxy binary, and they are also the features that carry the most operational risk. Packet padding changes the traffic characteristics your network sees, cover domain hunting depends on a domain you control continuing to resolve to the server, and certificate issuance needs the DNS and the port 80 or 443 path to work. A misconfigured certificate or a cover domain that stops resolving is an outage that is hard to diagnose from the outside.

The scanner shield deserves a specific note. Blacklisting Shodan and Censys scanners through ipset reduces the noise in your logs and the exposure of your proxy to automated scanning, and the README pairs it with the forensic inspection command, which suggests the author assumes an adversary is looking. That is a reasonable assumption for a public proxy, and it also means the project is aimed at operators who already think in those terms.

The pricing of the whole system is bandwidth and attention. A proxy that manages per-user quotas, expiry, failover and secret rotation is a small operations job, and this script is the automation for it.

Where MTProxyMax is the wrong tool

Three situations rule it out.

The first is a single user who needs one link. Every feature that makes this tool worth using, quotas, vouchers, pools, calendars, fleet federation, a bot with a public and an admin tier, is aimed at a server serving many people. A single user is better served by the upstream engine on its own, with a secret and a link.

The second is an environment where running a root shell from a URL is not acceptable. The recommended install pipes a fetched script into sudo bash, and the script's whole job is to configure a system service, certificates, firewall rules and, with the QoS features, the kernel traffic control. Organisations with configuration management requirements will want to read what the script does and reproduce it, which is a different project from running it.

The third is a host that is not Linux, or that does not meet the stated requirements. The platform badge says Linux, the shell requirement is Bash 4.2 or newer, and the rate shaping depends on tc and htb, which are Linux kernel facilities. The Docker images cover amd64 and arm64, which helps with architecture but not with the operating system.

There is a fourth, quieter one. The project is a single large bash script with a Rust engine underneath, maintained by one organisation, with an LTS version label that suggests long term support but no published compatibility matrix for the operating systems or the engine in the visible documentation. For a service that other people depend on to reach Telegram, that is the risk to weigh.

Editorial conclusion

MTProxyMax fits an operator who wants to run a Telegram proxy for a group of users and wants quotas, expiry, remote management and audit trails rather than a single shared secret, since those are the features the script exists to provide. It is the wrong choice for a single user who needs one link, since the whole surface is aimed at managing a server, and it is the wrong choice if you will not run a shell script fetched over the network with root privileges, because the one line install does exactly that. Before deploying it, read the install script rather than piping it blind, check the Bash 4.2 and Linux requirements against your host, and decide whether the self-healing and secret rotation features are ones you want running unattended.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. SamNet-dev/MTProxyMax on GitHub