MTProto Proxy Setup for Russia in 2026: Step-by-Step Guide

TL;DR

Rent a VPS outside Russia, compile the official Telegram MTProto proxy in FakeTLS mode on port 443, and open the resulting tg:// link on your phone. The catch: public MTProto proxy lists circulating on Russian Telegram channels get scanned and fingerprinted by Russia’s TSPU deep packet inspection infrastructure within hours of being posted. Running your own server on a private, unpublicised IP is the only approach that reliably survives past the next political news cycle.

why MTProto matters in Russia

MTProto is the custom binary protocol Telegram built for its own clients, and the proxy implementation adds a camouflage layer called FakeTLS. In FakeTLS mode, every proxy connection opens with a handshake that looks identical to a standard TLS 1.3 session pointed at a well-known web domain. To a stateful deep packet inspector, the flow reads as a browser connecting to a CDN edge node. Russia’s TSPU system (Технические средства противодействия угрозам) runs as mandatory hardware inside every major carrier, including MTS, MegaFon, Beeline, and Tele2. These boxes are purpose-built to detect and throttle the characteristic handshake patterns of OpenVPN, WireGuard, and similar VPN protocols. A WireGuard handshake has a well-defined byte structure that has been in TSPU rule sets since at least 2022, and OpenVPN’s TLS-auth header is equally recognisable. FakeTLS has no such fixed fingerprint, because the outer TLS layer mirrors real browser traffic and changes with each fresh secret you generate. That is the core architectural reason MTProto FakeTLS outperforms generic VPN protocols for Telegram access inside Russia, particularly during periods when regulators apply selective pressure on communications infrastructure.

Russia formally lifted the Telegram ban in June 2020, but the relationship between Russian telecoms regulators and the platform has remained uneasy. Throttling episodes have been documented during election periods, protest events, and moments of geopolitical tension, with carriers reducing Telegram throughput without formally blocking it. A federal law passed in late 2025 then introduced criminal liability for accessing content classified as extremist via a proxy service, regardless of the technical method used. This creates a legal backdrop that affects how users think about proxy access: the proxy tool itself is not explicitly prohibited, but what you access through it is subject to Russian law. For the full censorship and regulatory history, see the 2026 Telegram censorship resource center. Running your own server, under your own control, in a jurisdiction outside Russia, keeps the technical infrastructure at arms length from Russian regulatory reach.

There is also a latency argument for choosing the right server location. Telegram maintains major infrastructure nodes in Singapore. Routing Telegram traffic through a Singapore VPS keeps the hop count short: the round-trip time from a Singapore server to Telegram’s DCs is typically under 5 milliseconds. Compared to a European server, this translates to noticeably faster message delivery and quicker media loading for Russian users who route their connections eastward rather than westward.

prerequisites

Before starting, make sure you have the following in place:

• a VPS outside Russia with a public IPv4 address (AWS, DigitalOcean, Vultr, Hetzner, and Linode all work)
• Debian 12 or Ubuntu 22.04 LTS as the operating system
• root or sudo access to that server
• port 443 unblocked in the VPS provider’s control panel firewall (separate from the OS-level firewall)
• about 5 USD per month in hosting budget
• the latest version of Telegram installed on your Android or iOS device
• a terminal with SSH support (PuTTY on Windows, the built-in Terminal on macOS and Linux)

The VPS location matters considerably. Singapore is the recommended choice for this guide: Telegram DCs are present there, and Singapore is a politically neutral jurisdiction not subject to Russian or European regulatory pressure. A $6 DigitalOcean droplet in the Singapore region, or a Vultr High Frequency instance, can handle hundreds of simultaneous Telegram users without issue. The proxy is single-threaded by default and has a very small memory footprint, so the cheapest available tier is sufficient for personal use and small groups.

One common mistake: do not choose a Russian VPS provider even if the price looks appealing. Russian hosting providers operate under Roskomnadzor jurisdiction and are legally obligated to comply with blocking and logging orders. Always use a provider headquartered outside Russia. Finnish and Netherlands-based Hetzner, US-based DigitalOcean, and Singapore-based Vultr are all reasonable choices.

If you want background on why mobile residential proxy IPs behave differently from datacenter IPs and when you would need one, see what is a mobile proxy.

step 1: spin up the VPS

SSH into your new server and run the following to install build dependencies and configure the OS-level firewall:

ssh root@YOUR_VPS_IP

# update package lists and apply security patches
apt update && apt upgrade -y

# install build tools and crypto libraries
apt install -y \
    git \
    build-essential \
    libssl-dev \
    zlib1g-dev \
    openssl \
    xxd \
    curl \
    ufw

# configure the OS firewall
ufw allow 22/tcp     # keep SSH accessible
ufw allow 443/tcp    # MTProto proxy port
ufw --force enable

# verify
ufw status verbose

The packages libssl-dev and zlib1g-dev are required by the official MTProto proxy C implementation. The xxd utility is used in step 3 to hex-encode the FakeTLS domain string. If xxd is not in your distro’s default repositories (uncommon on Debian 12), installing vim-common provides it as a fallback.

After running the firewall commands, also check your VPS provider’s external control panel. Most providers have a separate security group or network firewall distinct from the OS-level ufw configuration. Both layers need to allow inbound TCP on port 443 before the proxy will accept connections from outside. Log into your provider’s dashboard and confirm that port 443 is open to all inbound traffic on that instance.

step 2: build mtproto-proxy from the official Telegram repo

The reference implementation of the MTProto proxy server is a C binary maintained by Telegram in their public GitHub repository. It compiles from source in under two minutes on any current VPS and produces a single executable with no external runtime dependencies beyond the OpenSSL libraries you already installed.

# clone the official repository
git clone https://github.com/TelegramMessenger/MTProxy.git
cd MTProxy

# compile the binary
make

# confirm the binary was produced
ls -lh objs/bin/mtproto-proxy

A successful build prints no errors and leaves objs/bin/mtproto-proxy on disk. If you see linker errors related to OpenSSL on Ubuntu 22.04, the most common fix is:

apt install -y pkg-config
make clean && make

On Debian 12, the build succeeds on the first attempt without additional packages in the vast majority of cases.

After building, download the Telegram proxy configuration files. These tell the proxy binary which Telegram datacenter IP addresses to route traffic to:

# fetch configuration files from Telegram's servers
curl -s https://core.telegram.org/getProxyConfig -o proxy-secret
curl -s https://core.telegram.org/getProxyMultiConfig -o proxy-multi-config

# verify both files are non-empty
wc -c proxy-secret proxy-multi-config

The proxy process reads these files at startup and re-fetches updated versions automatically every few hours. You do not need to refresh them manually. Keep both files in the MTProxy directory alongside the binary.

One important clarification: the proxy-secret file downloaded here is not the same as the user-facing secret you will generate in the next step. It is a server-side configuration file from Telegram that authorises your proxy binary to act as a legitimate MTProto relay. The two secrets serve different purposes and should not be confused with each other.

For more advanced self-hosting configurations, including running multiple proxy instances and managing them with Docker Compose, see mtproto self host server.

step 3: generate the secret and start the proxy

The user-facing secret is a 16-byte random value that Telegram clients use to authenticate connections to your proxy. In FakeTLS mode, the secret is extended: the ee prefix tells the Telegram client to perform a fake TLS 1.3 handshake before switching to MTProto, and a hex-encoded domain name appended to the secret provides the Server Name Indication (SNI) value used in that fake handshake.

# generate a random 16-byte secret
SECRET=$(dd if=/dev/urandom bs=16 count=1 2>/dev/null | xxd -p)
echo "raw secret: $SECRET"

# choose a high-traffic CDN domain to impersonate in the TLS SNI
# good choices: cdn.cloudflare.com, ajax.googleapis.com, www.google.com
DOMAIN="cdn.cloudflare.com"

# hex-encode the domain name
DOMAIN_HEX=$(echo -n "$DOMAIN" | xxd -p)

# assemble the FakeTLS secret
FAKETLS_SECRET="ee${SECRET}${DOMAIN_HEX}"
echo "FakeTLS secret: $FAKETLS_SECRET"

# save it for reference
echo "$FAKETLS_SECRET" > /root/MTProxy/current-secret.txt

The domain choice matters for survivability. Pick one whose TLS traffic Russia cannot afford to block without causing widespread collateral damage. cdn.cloudflare.com serves a significant fraction of the global web, so blocking it would break thousands of ordinary Russian websites at the same time. That collateral cost is a practical deterrent against adding it to TSPU blocklists.

Now create a systemd service unit so the proxy starts automatically at boot and restarts on failure:

cat > /etc/systemd/system/mtproto-proxy.service << 'EOF'
[Unit]
Description=Telegram MTProto Proxy
After=network.target

[Service]
Type=simple
WorkingDirectory=/root/MTProxy
ExecStart=/root/MTProxy/objs/bin/mtproto-proxy \
    -u nobody \
    -p 8888 \
    -H 443 \
    -S PLACEHOLDER_SECRET \
    --aes-pwd /root/MTProxy/proxy-secret \
    /root/MTProxy/proxy-multi-config \
    -M 1
Restart=on-failure
RestartSec=5
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target
EOF

# substitute the actual secret into the unit file
sed -i "s/PLACEHOLDER_SECRET/$FAKETLS_SECRET/" /etc/systemd/system/mtproto-proxy.service

# reload systemd and start the proxy
systemctl daemon-reload
systemctl enable mtproto-proxy
systemctl start mtproto-proxy

# confirm it is running
systemctl status mtproto-proxy --no-pager

The -H 443 flag binds the proxy to port 443. This is the most important configuration choice: Russia’s TSPU boxes apply heavier scrutiny to proxy-like traffic on non-standard ports, while port 443 is the global standard for HTTPS and blends into the background noise.

If the service shows active (running), the proxy is live. If it shows failed, check the journal:

journalctl -u mtproto-proxy -n 50 --no-pager

The most common failure is a port conflict. If Nginx or another service is already listening on port 443, either stop it or move the proxy to port 8443 by changing -H 443 to -H 8443 in the unit file and opening port 8443 in ufw.

Finally, build your shareable Telegram link:

VPS_IP="YOUR_VPS_IP"
echo "tg://proxy?server=${VPS_IP}&port=443&secret=${FAKETLS_SECRET}"

Replace YOUR_VPS_IP with your server’s actual public IPv4 address. Send this link to yourself via Telegram’s Saved Messages, then tap it from your phone to activate the proxy.

step 4: enter the proxy in Telegram on Android/iOS

From any Telegram client inside Russia, follow these steps to activate the proxy manually if the link tap approach is not available:

1. open Telegram and tap the hamburger menu (three lines) in the top-left corner
2. tap Settings
3. tap Data and Storage
4. scroll down to the Proxy section and tap it
5. tap Add Proxy in the upper-right corner
6. select the MTProto proxy type (not SOCKS5 or HTTP)
7. enter your VPS’s public IPv4 address in the Server field
8. enter 443 in the Port field
9. paste the full FakeTLS secret (the string beginning with ee) into the Secret field
10. tap Save, then tap the new entry to activate it

Telegram shows a connection status indicator at the top of the main screen. A green tick means the proxy is connected and active. A yellow indicator means Telegram is retrying or connecting. A red indicator means the proxy is unreachable: return to the server and run systemctl status mtproto-proxy to diagnose.

The tg://proxy?... link approach is faster. Open it in any mobile browser, and Telegram intercepts the URL scheme, pre-filling the proxy dialog automatically. This is also the most convenient distribution method if you are sharing the proxy with trusted friends or colleagues. Keep distribution private: do not post the link in any public group or channel, even one that appears invite-only. TSPU-adjacent infrastructure has been observed scanning publicly accessible Telegram channels for proxy links, and a posted link can land the IP on a blocklist within a few hours.

For a broader overview of the Telegram access landscape inside Russia, including a summary of which carriers throttle most aggressively and at what times, see the Telegram in Russia 2026 guide.

what breaks in Russia (and how to harden)

The primary threat to any self-hosted MTProto proxy operating in Russia is the TSPU infrastructure itself. These national DPI appliances are installed as mandatory network elements at the IXP and carrier level, and all four of Russia’s major mobile carriers (MTS, MegaFon, Beeline, and Tele2) operate them under Roskomnadzor mandate. The boxes are not purely blocklist-driven. They perform active flow analysis: examining packet inter-arrival timing, payload entropy, TLS handshake field combinations, and SNI field consistency across the session lifetime. A proxy IP that surfaces in a public Telegram channel can be added to a blocklist within minutes of discovery. More subtly, if the TSPU fingerprint database acquires a rule targeting the MTProto FakeTLS traffic pattern itself (rather than a specific IP), all connections matching that pattern can be throttled across every carrier simultaneously, regardless of whether the specific IP was ever published anywhere.

The countermeasures that hold up in practice are not complicated, but they require consistent discipline. First, rotate the secret at minimum once per week. Re-run the dd and xxd commands from step 3 to generate a fresh FAKETLS_SECRET, update the systemd unit file with sed -i, and restart the service with systemctl restart mtproto-proxy. Share the updated tg:// link only through a trusted private channel: a direct message to each user works better than a shared group. Second, keep the VPS purpose-minimal. Nothing else should listen on port 443, and no other services should generate traffic patterns distinguishable from a pure TLS relay. Third, consider deploying Nginx as a TLS termination front-end with a valid Let’s Encrypt certificate. In this configuration, Nginx accepts incoming connections on port 443 using a real certificate from a real domain and proxies the MTProto traffic internally to port 8888. To a passive observer at the TSPU layer, the server looks like an ordinary HTTPS web host. This is more complex to set up but raises the difficulty of accurate fingerprinting considerably.

If you are operating the proxy for more than a handful of people, run separate VPS instances for separate cohorts. A single discovered link should compromise only one IP, not your entire setup. One instance per 10-15 trusted users is a reasonable rule of thumb. For a deeper comparison of which hardening strategies have held up against the TSPU rule sets active in early 2026, see best Telegram proxy for Russia.

when MTProto isn’t enough (segue to SOCKS5)

We operate a network of real Singapore residential mobile proxies running on physical SingTel, StarHub, M1, and Vivifi SIM cards installed in hardware modems. Over the past year, working with users who maintain Telegram channels, manage multi-account setups, and run automation workflows from inside Russia, we have observed a consistent pattern: the self-hosted MTProto proxy is excellent for personal Telegram access on a single account, but it runs into hard limits as soon as the workflow expands. MTProto proxies speak only Telegram’s proprietary protocol. They cannot tunnel the Telegram desktop client’s connection to the web interface, they cannot carry traffic for any other application, and they do not support the kind of per-account IP assignment that proper multi-account management requires without triggering Telegram’s account anomaly detection.

A SOCKS5 proxy has none of these limitations. It operates at the TCP transport layer and is transparent to the application using it. Telegram desktop, Telegram web, and any third-party Telegram management or automation tool can all route through the same SOCKS5 endpoint simultaneously. Our Singapore mobile proxies use real carrier IP addresses that have never appeared in any blocklist, because they share address ranges with ordinary Singaporean consumer mobile traffic. Telegram maintains datacenters in Singapore, so the physical hop from our exit nodes to Telegram’s infrastructure is short: most connections complete in under 10 milliseconds from proxy exit to Telegram DC. The credential format is simple: 158.140.129.188:PORT:user:pass, configured in Telegram desktop under Settings > Advanced > Connection type > Use custom proxy > SOCKS5. We accept both cryptocurrency and credit cards, with no Russian-jurisdiction KYC requirement. You can review the full plan options at Singapore Mobile Proxy plans or start with a no-commitment free trial before subscribing.

The multi-account Telegram in Russia guide covers in detail how to pair a SOCKS5 mobile proxy with Telegram’s native multi-account feature, including which IP consistency patterns avoid triggering account suspension checks.

comparison: MTProto self-hosted vs. SOCKS5 mobile proxy

The table below is a quick reference for choosing between the two approaches based on your actual use case:

For most individual users who want reliable personal Telegram access in Russia, the self-hosted MTProto path is the right starting point. It is cheap, transparent, and entirely under your control. When you outgrow it because of multi-account needs, automation requirements, or persistent TSPU fingerprinting of your VPS IP, upgrading to a managed SOCKS5 mobile proxy is the logical next step. The two approaches are not mutually exclusive.

FAQ

Q: Is using an MTProto proxy legal in Russia in 2026?

A: Telegram itself is not banned in Russia. The 2020 formal unblocking remains in effect. However, a federal law passed in late 2025 introduced criminal liability for accessing content classified as extremist via a proxy service, regardless of the proxy technology used. The proxy tool itself is not explicitly illegal, but what you access through it is subject to Russian law. Nothing in this guide constitutes legal advice. If you have specific concerns about your situation, consult a qualified Russian legal professional.

Q: Why does my FakeTLS proxy stop working after a few days?

A: The most common cause is IP exposure. If your tg:// link was shared in any public group or channel, even a small one, TSPU-adjacent infrastructure can detect the server IP and add it to a blocklist within hours. The second most common cause is a TSPU rule database update that fingerprints your specific FakeTLS traffic pattern. The fix is the same in both cases: generate a new FAKETLS_SECRET using the dd command from step 3, deploy it to the systemd unit file with sed -i, restart the service, and redistribute the updated tg:// link only to people you trust directly.

Q: Can I use a port other than 443?

A: You can specify any port in the -H flag of the proxy binary, but port 443 is strongly recommended. MTS and MegaFon have both been observed applying heavier inspection to proxy-like traffic on non-standard ports. Port 443 is the global standard for HTTPS, so a well-configured FakeTLS proxy on that port blends into the background traffic profile rather than standing out as an anomaly in TSPU flow analysis.

Q: What is the difference between a plain MTProto secret and a FakeTLS secret?

A: A plain MTProto secret is a 32-character hex string with no prefix. A FakeTLS secret starts with the two-byte prefix ee, followed by the same 32-character hex string, followed by the hex-encoded ASCII representation of a domain name. The ee prefix signals to Telegram clients to open a fake TLS 1.3 handshake (using the appended domain as the SNI value) before switching to MTProto. Without the ee prefix, the proxy still works but lacks the TLS camouflage layer, making it substantially easier for TSPU equipment to classify and throttle the traffic.

Q: Does FakeTLS work on both Android and iOS?

A: Yes. Both the Android and iOS versions of Telegram support FakeTLS secrets in their proxy configuration dialogs. The input field is labelled Secret and accepts the full ee-prefixed hex string. If you are entering the secret manually rather than via a tg:// link tap, paste the entire string with no leading or trailing whitespace, as Telegram validates the secret length strictly.

Q: What is the risk of running a proxy for other people?

A: Running a proxy that others use carries a different risk profile than running one exclusively for personal use. Beeline and MTS have both been observed rate-limiting server IPs that show high Telegram relay traffic volumes. More critically, if any of your users access content that Russian authorities have classified as extremist, the 2025 law creates ambiguity around third-party liability for proxy operators. For personal use the risk profile is low and manageable. For operating a proxy at any meaningful scale, get qualified legal advice before proceeding.

disclaimer

This tutorial is provided for informational and educational purposes only. Internet access regulations and proxy laws in Russia change frequently and their application depends on jurisdiction, context, and the content being accessed. The 2025 Russian federal law on proxy use and extremist content is a real legal instrument carrying criminal penalties. Nothing in this article constitutes legal advice or encourages any activity that violates applicable law. Readers are solely responsible for verifying the current legal status of proxy use in their own jurisdiction before following these instructions. Singapore Mobile Proxy and singaporemobileproxy.com accept no liability for any consequences arising from the use of information presented here.