How to Set Up an MTProto Proxy That Works in Vietnam 2026
TL;DR
Rent a VPS outside Vietnam (Singapore is ideal), compile the official Telegram MTProto proxy binary with FakeTLS enabled on port 443, and paste the connection string into Telegram’s proxy settings. The catch is that most public MTProto proxies shared in Telegram channels are already catalogued and blocked by Vietnam’s Ministry of Information and Communications (MIC) through targeted DPI blocking orders. A fresh self-hosted IP is the only consistently reliable path in 2026.
why MTProto matters in Vietnam
MTProto is Telegram’s own wire protocol, and its proxy mode was built specifically to resist deep-packet inspection. In FakeTLS mode, every packet leaving your device is wrapped in a valid TLS handshake pointing at a real, benign hostname. To a carrier-level DPI box, the traffic looks like an ordinary HTTPS session to, say, a Google or Cloudflare endpoint. That matters specifically in Vietnam because Viettel, Vinaphone, and Mobifone, the three dominant carriers, run DPI hardware under MIC blocking orders designed to identify and throttle or drop traffic associated with non-compliant platforms. Telegram was one of several services caught in enforcement sweeps tied to the 2018 Cybersecurity Law, which requires foreign platforms to localise data and comply with government content requests. Enforcement has been uneven, but when a block is active it hits at the carrier level across all three ISPs simultaneously. Changing DNS or switching Wi-Fi networks makes no difference. For a fuller picture of the broader censorship context, see the 2026 Telegram censorship resource center.
OpenVPN and most commercial VPN protocols fail in Vietnam for a different and more fundamental reason. Vietnam’s MIC blocking orders explicitly target residential VPN signatures, and the handshake patterns for OpenVPN, L2TP, and standard WireGuard are well-documented in the DPI signature libraries Vietnamese carriers use. The protocol can be identified regardless of what port it runs on because the byte patterns in the initial negotiation are distinctive. MTProto’s FakeTLS mode sidesteps this entirely. It is not a VPN. It carries only Telegram traffic. It produces no recognisable VPN handshake. Each session presents as HTTPS, and because blocking all HTTPS on port 443 would take down every secure website in the country, DPI hardware must apply far more conservative rules to that traffic class. That asymmetry is why Vietnamese Telegram users who have exhausted every commercial VPN option often find self-hosted MTProto to be the most stable path forward, sometimes lasting weeks or months before an IP-level block is applied to their specific VPS address.
It is also worth understanding the enforcement cadence. MIC blocking orders tend to come in waves tied to political events, legislative sessions, or periods of heightened content moderation activity. During quieter periods, even publicly known proxy IPs may go unblocked for months. During active enforcement periods, fresh IPs can get blocked within 24 to 72 hours of their first sustained use. Knowing this rhythm helps you plan: keep a standby VPS ready, rotate secrets proactively ahead of sensitive dates, and do not share your proxy address in large public channels where it will be harvested immediately.
prerequisites
You need a virtual private server located outside Vietnam. Singapore is the best choice for two reasons: Telegram runs datacenters in Singapore (so the network path from a Vietnamese phone through a Singapore exit node to the Telegram datacenter is short and fast), and Singapore is a politically neutral jurisdiction with no content-blocking relationship with Vietnam. AWS (region ap-southeast-1), DigitalOcean (Singapore), and Vultr (Singapore) all work well. The smallest instance tier on any of these providers is sufficient. Expect to pay around 5 USD per month.
When selecting your VPS provider and plan, pay attention to the ASN (Autonomous System Number) your IP address will belong to. Cloud providers own multiple ASN blocks, and some of those blocks have been more heavily targeted by Vietnamese carrier blocklists than others. AWS and Google Cloud are relatively more exposed because they are well-known and frequently used for circumvention tools. Smaller, lesser-known providers in Singapore such as Contabo, Hetzner (which has a Singapore region), or regional hosts like Exabytes Singapore tend to have IP ranges that attract less automated blocking. The trade-off is that less prominent providers may have fewer reliability guarantees. A practical approach is to start with a small instance on a mid-tier provider and treat the IP as disposable if it gets blocked.
Operating system: Debian 12 or Ubuntu 22.04 LTS. Both are tested against the official Telegram MTProto proxy source and have all required build dependencies in their standard package repositories. Other distributions will work but the install commands below may differ.
You also need a domain name or subdomain that resolves to your VPS IP, used as the FakeTLS cover hostname. A bare IP technically works but a real domain produces a more convincing TLS handshake. A free subdomain from any dynamic DNS provider is enough if you do not own a domain.
Required access: root or sudo SSH access to the VPS. No control panel, no GUI.
step 1: spin up the VPS and connect
Log in to your VPS and prepare the environment:
ssh root@YOUR_VPS_IP
# update the package list and upgrade existing packages
apt update && apt upgrade -y
# install build tools and dependencies
apt install -y git build-essential libssl-dev zlib1g-dev \
curl wget openssl xxd net-tools ufw
# configure the firewall: allow SSH and the MTProto port
ufw allow 22/tcp
ufw allow 443/tcp
ufw --force enable
# confirm firewall status
ufw status verbose
Port 443 is chosen deliberately. Viettel, Vinaphone, and Mobifone all apply MIC-mandated DPI filters, but outbound port 443 gets lighter treatment than non-standard ports because blocking it would render every HTTPS site unreachable. Running MTProto in FakeTLS mode on 443 makes your Telegram packets look identical to ordinary HTTPS. That is the core of why this approach works when ports like 8443 or 8888 are blocked outright.
If you want additional hardening at the firewall layer, you can restrict inbound connections on port 443 to known Telegram datacenter IP ranges. That is optional and makes maintenance more complex, so this guide leaves the firewall open on 443 for simplicity.
step 2: build mtproto-proxy from the official Telegram repo
Telegram publishes the reference C implementation of MTProto proxy at github.com/TelegramMessenger/MTProxy. Compiling from source gives you the exact binary Telegram’s own team ships, with no third-party modifications or added code. For a detailed look at the architecture and advanced self-hosting options, mtproto self host server covers topics like multi-secret setups and clustering.
# clone the official repository
git clone https://github.com/TelegramMessenger/MTProxy.git
cd MTProxy
# compile the binary (approximately 60 seconds on a 1-vCPU instance)
make
# confirm the binary was produced
ls -lh objs/bin/mtproto-proxy
If make exits with an error about missing headers, you are likely missing a development package. The most common fix on Debian 12 and Ubuntu 22.04 is:
apt install -y libssl-dev
make clean && make
Once the binary is built, download the Telegram server configuration files. The proxy needs these to locate and authenticate with Telegram’s datacenters:
curl -s https://core.telegram.org/getProxySecret -o proxy-secret
curl -s https://core.telegram.org/getProxyConfig -o proxy-multi.conf
# confirm both files were downloaded
ls -lh proxy-secret proxy-multi.conf
Keep both files in the MTProxy working directory. The proxy-multi.conf file is re-read on a SIGHUP signal, so you can refresh Telegram’s datacenter list without restarting the service. Set a weekly cron job to re-download proxy-multi.conf since Telegram occasionally updates its datacenter configuration.
# add a weekly refresh cron job (runs Sunday at 02:00)
echo "0 2 * * 0 curl -s https://core.telegram.org/getProxyConfig \
-o /root/MTProxy/proxy-multi.conf && \
systemctl kill -s HUP mtproto-proxy" | crontab -
step 3: generate the secret and start the proxy
The MTProto “secret” is a 16-byte random value that acts as a shared credential between your proxy server and every Telegram client that uses it. In plain MTProto mode the secret is just a hex string. In FakeTLS mode, you prepend the two-byte marker ee and append the cover domain encoded as hex. The FakeTLS marker tells both sides to wrap traffic in a fake TLS session aimed at that domain, which is the mechanism that fools DPI hardware.
# generate a cryptographically random 16-byte secret
SECRET=$(dd if=/dev/urandom bs=16 count=1 2>/dev/null | xxd -p)
echo "raw secret: $SECRET"
# choose a real HTTPS-serving cover domain
# something common works best: www.google.com, www.cloudflare.com, etc.
DOMAIN="www.google.com"
# encode the domain as hex
DOMAIN_HEX=$(printf '%s' "$DOMAIN" | xxd -p)
# build the FakeTLS secret: ee + raw_secret + domain_hex
FAKETLS_SECRET="ee${SECRET}${DOMAIN_HEX}"
echo "FakeTLS secret: $FAKETLS_SECRET"
# save to a file so you can retrieve it later
cat > ~/proxy.env << EOF
SECRET=$SECRET
FAKETLS_SECRET=$FAKETLS_SECRET
DOMAIN=$DOMAIN
EOF
chmod 600 ~/proxy.env
Now create the systemd service unit. Systemd will restart the proxy automatically if it crashes and bring it back up after a VPS reboot:
cat > /etc/systemd/system/mtproto-proxy.service << 'UNIT'
[Unit]
Description=Telegram MTProto Proxy
After=network-online.target
Wants=network-online.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 proxy-secret proxy-multi.conf \
-M 1
Restart=on-failure
RestartSec=5
StandardOutput=journal
StandardError=journal
[Install]
WantedBy=multi-user.target
UNIT
# substitute the real secret into the unit file
source ~/proxy.env
sed -i "s/PLACEHOLDER_SECRET/$FAKETLS_SECRET/" \
/etc/systemd/system/mtproto-proxy.service
# reload systemd, enable and start the service
systemctl daemon-reload
systemctl enable mtproto-proxy
systemctl start mtproto-proxy
# check that it is running
systemctl status mtproto-proxy
A successful start shows active (running) in green. If you see a failure, check journalctl -u mtproto-proxy -n 50 for the error output.
Your connection details for Telegram clients are:
- server: your VPS public IP address
- port: 443
- secret: the value of
$FAKETLS_SECRET
The Telegram deep link that clients can tap to add the proxy automatically is:
tg://proxy?server=YOUR_VPS_IP&port=443&secret=YOUR_FAKETLS_SECRET
You can share this link over any channel, a Telegram message, a QR code, or a static web page. When a user taps it on their phone, Telegram opens and prompts them to add the proxy with one tap.
step 4: enter the proxy in Telegram on Android or iOS
These steps apply to both Android and iOS Telegram clients as of 2026. For iPhone-specific screenshots and the exact iOS UI flow, the iOS Telegram setup in Vietnam guide walks through each screen.
on Android:
- Open Telegram and tap the hamburger menu icon (three horizontal lines) in the top-left corner.
- Tap Settings.
- Tap Data and Storage.
- Scroll down to the Proxy section and tap it.
- Toggle Use Proxy on if it is not already enabled.
- Tap Add Proxy.
- Select the MTProto proxy type (not SOCKS5 and not HTTP).
- In the Server field enter your VPS IP address.
- In the Port field enter
443. - In the Secret field paste your
$FAKETLS_SECRETstring. - Tap the tick or save button in the top-right corner.
on iOS:
Follow the same path: Settings > Data and Storage > Proxy > Add Proxy > MTProto. The field names are identical. Alternatively, tap the tg:// deep link directly. Safari will ask whether to open it in Telegram, and tapping yes will pre-fill all three fields automatically.
After saving, Telegram will attempt to connect. A green dot and the label “Connected” next to the proxy entry confirms success. A yellow dot means the connection is in progress or intermittent. A red dot means the connection failed.
Common reasons for a red status after a correct configuration:
- port 443 is not open on the VPS firewall (run
ufw statuson the server to check) - the secret was pasted with a trailing space or newline character
- the VPS IP is already blocked by the carrier your SIM uses
If the proxy connects on Wi-Fi but fails on mobile data, that is a strong indicator that your carrier (Viettel, Vinaphone, or Mobifone) has blocked that specific VPS IP on the mobile network. The fix is to provision a fresh VPS with a new IP, which typically takes about ten minutes on any cloud provider.
For an overview of what Telegram looks like in Vietnam more broadly, including app version notes and which features are affected, see the Telegram in Vietnam 2026 guide.
step 5: monitoring and logging your proxy
Once your proxy is live, ongoing visibility matters. A silent failure , where the process stays running but stops accepting connections , is harder to catch than an outright crash. The systemd journal gives you a basic event stream, but adding structured monitoring saves time when troubleshooting across multiple users.
Check live connection counts using the management port (port 8888 in the systemd unit above):
# view live stats via the management interface
curl -s http://127.0.0.1:8888/stats | python3 -m json.tool
The JSON response includes active_connections, total_connections, and bytes transferred. A total_connections count that stops incrementing while you know users are trying to connect is a clear signal that something has changed upstream , either a new block at the carrier level or a problem with your proxy-multi.conf datacenter configuration.
For a lightweight health check you can run from any external host, use netcat or curl to verify that port 443 is accepting TCP connections:
# run this from a machine outside your VPS to confirm the port is reachable
nc -zv YOUR_VPS_IP 443
A successful response confirms the port is open at the network level. A timeout or “connection refused” means the port is blocked upstream or the service has stopped. Combine this with a cron job that sends you a Telegram message when the check fails, and you have a basic dead-man switch for your own proxy.
To view the last 100 lines of proxy logs in real time:
journalctl -u mtproto-proxy -n 100 -f
Look for repeated failed to complete handshake messages. A small number of these per hour is normal (automated scanners probe open ports constantly). A sudden spike is a sign that something is generating large volumes of bad traffic to your server, which can be a precursor to your IP being flagged at the carrier level.
what breaks in Vietnam (and how to harden)
The two most common failure modes in Vietnam are IP-level blocking and DNS poisoning, and they require different responses.
IP-level blocking works like this: the MIC issues a blocking order, and each ISP adds your VPS IP to a drop list at the carrier edge. Viettel, Vinaphone, and Mobifone maintain these lists independently, so a VPS IP can be blocked on Mobifone while still reachable on Vinaphone. If your proxy works fine on home broadband but fails on mobile data, the most likely explanation is that one carrier has added your VPS IP to its blocklist while the other has not yet done so. The practical defence is to maintain a standby VPS on a different IP prefix (a /24 that has not been flagged before), have a second systemd service ready to start on port 443 with the same secret, and switch the Telegram deep link to point at the new server. The client changeover takes about 30 seconds. Some operators keep a rotation of three or four IPs and cycle through them on a weekly schedule regardless of whether a block has been applied, which means users rarely experience a dead proxy.
DNS poisoning is used as a secondary enforcement tactic. Vietnamese ISPs have been documented poisoning DNS responses for known circumvention-related domains, returning either a non-routable address or a block page IP. This does not directly affect your MTProto proxy because Telegram clients connect to your proxy using a raw IP address, not a domain name. However, newer Telegram clients perform a certificate validation step during the FakeTLS handshake that involves resolving the cover hostname. If the cover domain you chose (such as www.google.com) is being DNS-poisoned on the client’s network, the FakeTLS handshake may fail at that validation step. The fix is to choose a cover domain that is either not blocked in Vietnam or to run a local DNS resolver (such as a DNS-over-HTTPS client) on the same device before connecting. Rotating your FakeTLS secret weekly also gives you a fresh handshake signature, making it harder for DPI hardware to build a reliable fingerprint of your traffic. Secret rotation takes under a minute: re-run the dd command from step 3, update the systemd unit file, reload and restart the service, and send the new tg:// link to your users. For current community intelligence on which configurations are surviving active blocks, best Telegram proxy for Vietnam tracks options that users report as working.
when MTProto isn’t enough (segue to SOCKS5)
I work with users who hit a wall where even a freshly provisioned MTProto proxy gets blocked within days of going live. The root cause in most cases is not the protocol, it is the IP’s reputation. When Vietnam’s MIC issues an order broad enough to cover an entire cloud provider’s ASN, such as AWS ap-southeast-1 or DigitalOcean’s Singapore IP range, every VPS on that network segment gets swept up regardless of what traffic it is running. At that point no FakeTLS tuning, port change, or secret rotation helps because the problem is that the source IP itself is in a blocked ASN. The only way around an ASN-level block is to exit through an IP that is not in a data-center address space at all.
We operate a pool of Singapore residential mobile proxies on real SingTel, StarHub, M1, and Vivifi SIM cards. Every IP in the pool belongs to a genuine consumer mobile carrier in Singapore, a politically neutral jurisdiction that has no content-blocking relationship with Vietnam. Residential carrier IPs do not appear in data-centre ASN blocklists because they are the same IP ranges that ordinary mobile phone users sit behind. You configure Telegram to route through the SOCKS5 endpoint, entering a credential string in the format 158.140.129.188:PORT:user:pass, the same way you would configure any SOCKS5 proxy in Telegram’s settings. Because Telegram has datacenters in Singapore, the network path from a Vietnamese phone through our Singapore SOCKS5 exit to the Telegram datacenter involves minimal additional latency compared to a direct connection. For context on why Singapore carrier IPs specifically matter for Southeast Asian users, why Singapore mobile IPs matter covers the routing and trust-signal advantages in detail. Plans are available at Singapore Mobile Proxy plans with a free trial option and no Vietnam KYC. Payment by crypto and credit card is accepted.
comparison: self-hosted MTProto vs SMP mobile SOCKS5
| factor | self-hosted MTProto on VPS | SMP residential mobile SOCKS5 |
|---|---|---|
| monthly cost | ~5 USD (VPS fee) | from 15 USD (proxy plan) |
| IP type | data-centre (blockable by ASN) | real residential carrier IP |
| setup effort | moderate (compile + systemd + firewall) | low (enter IP:port:user:pass in Telegram) |
| blocked if VPS IP flagged | yes, need a new VPS | no, IP pool is rotated automatically |
| survives Mobifone / Viettel / Vinaphone ASN blocks | depends on VPS provider subnet | yes, residential IPs bypass ASN blocks |
| Telegram DC proximity | varies by VPS region | Singapore exit, short path to Telegram DC |
| maintenance burden | weekly secret rotation, conf refresh | none on the user side |
| crypto payment | depends on VPS provider | yes, native support |
This comparison is not a pitch to abandon self-hosting. For users who want full control and are comfortable with a small amount of server maintenance, MTProto self-hosting is cost-effective and gives you complete visibility into what your proxy is doing. The SMP SOCKS5 option is better suited to users who need a reliable fallback with no maintenance overhead, or who are already dealing with ASN-level blocks on their VPS provider.
FAQ
Q: Does MTProto work on all Vietnamese carriers in 2026?
A: It depends on your VPS IP address and which carrier you are on. Viettel, Vinaphone, and Mobifone apply MIC blocking orders independently, so the same proxy can work on one carrier and be blocked on another at the same time. Using a VPS on a provider with a fresh IP range and running on port 443 in FakeTLS mode gives you the best chance of staying unblocked across all three.
Q: Why use port 443 instead of a custom port?
A: Port 443 is the standard HTTPS port. If a Vietnamese carrier blocked it entirely, every secure website in the country would stop working. DPI systems therefore cannot apply aggressive blocking rules to outbound 443 traffic, which is why MTProto in FakeTLS mode on that port is significantly more likely to pass inspection than the same proxy running on port 8443 or any non-standard port.
Q: How often should I rotate the FakeTLS secret?
A: Weekly is a sensible default for users in Vietnam. The secret functions as a shared credential, so rotating it prevents anyone who obtained an old secret from continuing to use your proxy, and it also resets the DPI fingerprint that carrier hardware may have built up on your traffic. Rotation takes about one minute: regenerate the secret with dd, update the systemd unit, run systemctl daemon-reload && systemctl restart mtproto-proxy, and share the new tg:// link with your users.
Q: Can I run the proxy on a VPS in a country other than Singapore?
A: Yes. Any VPS outside Vietnam that is not blocked by Vietnamese carriers will work. Singapore is recommended because of the short network path to Telegram’s datacenters there, but a VPS in Tokyo, Frankfurt, or any other major cloud region is a valid option. The farther from Singapore the VPS is, the higher the latency will be for Vietnamese clients.
Q: Can I use this setup for apps other than Telegram?
A: No. MTProto proxy is a Telegram-specific protocol that carries only Telegram traffic. It cannot proxy HTTP browser sessions, SOCKS5 connections, or any non-Telegram application. For general-purpose proxying across multiple apps you need a SOCKS5 or HTTP endpoint.
Q: What do I do when my VPS IP gets blocked mid-session?
A: Existing Telegram sessions will drop and the client will show a connection error. Provision a new VPS instance with a fresh IP (most cloud providers can do this in under five minutes), start the MTProto proxy service on the new instance using the same secret, update the tg:// deep link with the new IP, and share it. Clients reconnect as soon as they tap the new link. Keeping a second VPS on standby and pre-configured means the switchover takes seconds rather than minutes.
Q: How many simultaneous users can one VPS handle?
A: On a 1-vCPU, 1 GB RAM instance the official MTProto proxy binary handles several hundred simultaneous connections comfortably. CPU usage stays low because the proxy does minimal processing per packet , it decrypts the FakeTLS wrapper and re-encrypts for the Telegram datacenter. Memory usage grows roughly linearly with active connections. For small groups of ten to fifty users, the cheapest available instance tier is more than enough. For larger deployments, consider running multiple instances on separate IPs and distributing the connection string across them.
Q: Is there a way to test whether my proxy is reachable from inside Vietnam before sharing it?
A: The most direct test is to use a Vietnamese mobile SIM (or a Vietnamese mobile data connection via a friend or colleague in-country) and attempt a Telegram connection through the proxy. If you do not have that access, a secondary check is to use an online TCP port checker pointed at your VPS IP and port 443 , this confirms the port is reachable from the public internet, though it does not test carrier-level filtering. Community Telegram groups focused on Vietnam internet freedom often have members willing to test proxy reachability from specific carriers on request.
Q: What cover domain should I use for FakeTLS?
A: Choose a domain that serves real HTTPS traffic, is globally well-known, and is not itself blocked in Vietnam. Common choices include www.google.com, www.cloudflare.com, www.microsoft.com, and www.apple.com. Avoid using domains belonging to small or obscure services, as the contrast between a low-traffic domain and the volume of Telegram usage can itself look anomalous to statistical traffic analysis. The cover domain does not need to be your own domain , it is the hostname that appears in the fake TLS handshake, not a domain you control.
disclaimer
This article is provided for informational and educational purposes only. The authors and operators of singaporemobileproxy.com are not legal advisors. Vietnam’s 2018 Cybersecurity Law, subsequent Ministry of Information and Communications regulations, and Decree 13/2023/ND-CP impose obligations on both service providers and end users of internet tools in Vietnam. Enforcement has been described as uneven, but penalties for violations of Vietnamese internet law can be significant. Before using, distributing, or self-hosting proxy tools from within Vietnam, you should seek qualified legal advice relevant to your specific situation and jurisdiction. Nothing in this article constitutes legal advice, and no warranty is made that any described technique is permitted under Vietnamese law or any other applicable law.