Overview
Here is the fast snapshot of what you are getting and who it is for. MTProto Proxy on VPS carries Telegram traffic over the MTProto protocol with TLS-style obfuscation, so it blends in on restrictive networks. Typical uses include personal or community proxy hosting and keeping Telegram reachable where it is filtered. Personas include privacy-minded users and Telegram community admins.
Description
This image provides an open-source MTProto Proxy configured for private communication with Telegram. It is designed for regions or networks with censorship by speaking MTProto and supporting TLS obfuscation to disguise traffic.
Access the Web Interface
First-run is a simple handoff from server to Telegram. You import a ready link and connect without extra dashboards.
Retrieve the tg://proxy link from /root/.proxy on the server, then import it into the Telegram client to start using the proxy.
Advanced Features
These are the practical traits that matter for a Telegram transport. They keep access predictable and usable in filtered environments.
- MTProto protocol compatibility for Telegram traffic.
- TLS obfuscation support to disguise traffic patterns.
- Suited to personal or community proxy hosting and restricted networks.
Ease of Use
You pick a supported LTS image, provisioning runs on first boot, and the service is managed via the native init.
- OS options: Ubuntu 24.04 LTS or Ubuntu 22.04 LTS.
- Init system: systemd for service control.
- Provisioning: cloud-init for initial setup.
Performance Focus
Cloudzy’s raw performance traits keep latency tight and throughput steady for Telegram sessions. Dedicated EPYC vCPUs, DDR5 RAM, and pure-NVMe disks cut first-byte time. A 10 Gbps backbone absorbs surges without choking connections, while on-demand snapshots and hourly billing let you test changes safely and scale up only when traffic grows.
Full Website Control
Think of this as your own clean room for transport.
You have root access for firewall rules, backup scheduling, and update cadence. KVM isolation keeps your VM workloads apart from noisy neighbors, and a dedicated IP helps keep access predictable.
Powerful Tools
Here is what you get out of the box and what is one click away:
- MTProto Proxy service running under systemd for simple start, stop, and status.
- cloud-init provisioning so the instance is ready on first boot.
- Day-1 helper: a prewritten tg://proxy link saved at /root/.proxy for quick import into Telegram.
- Platform helpers: snapshots for safe rollbacks and hourly billing to clone short-lived test nodes when needed.
Global Reach
Place the proxy close to your users to cut round-trip time. Cloudzy operates 10 points of presence across three continents:
- North America: New York City, Dallas, Miami, Utah, Las Vegas
- Europe: London, Amsterdam, Frankfurt, Zurich (Switzerland)
- Asia-Pacific: Singapore
Every location offers a 10 Gbps uplink, a Tier-1 carrier mix, and a 99.95% uptime SLA. The only variable is distance.
Application Details
OS:
Ubuntu 24.04 LTS
Ubuntu 22.04 LTS
Runtime:
Not Specified.
Application:
MTProto Proxy.
Init System:
systemd.
Provisioning:
Cloud-init.
Minimum RAM: 1 GB
Minimum CPU: 1 vCPU
Minimum Disk: 10 GB
Deploy Cloudzy’s MTProto Proxy on VPS Now: host your own Telegram-compatible proxy and import the link into your client in minutes.
Important: Configuration & Domain Responsibilities
You get full SSH/root access on every OCA. That power also means your changes can break the app. Please read this before tweaking configs.
- You manage the domain. We don’t sell or host domains/DNS. If the app needs a domain, you must point your domain to the server (A/AAAA/CNAME, and MX/TXT if relevant). SSL issuance and many dashboards depend on this being correct.
- Changing the domain/hostname after install isn’t trivial. Many OCAs write the domain into configs (.env, reverse proxy, app URLs). If you change it, also update:
- Reverse proxy (Nginx/Caddy) and TLS certificates
- App “external URL”/base URL and callback/webhook URLs
- Any hard-coded links in the app or add-ons
- Credentials matter. Renaming the default admin, rotating passwords, or changing service ports without updating the app config can lock you out or stop services. Keep credentials safe and in sync across the app, proxy, and any integrations.
- Nameserver changes can cause downtime. Moving your domain to new nameservers or editing NS records triggers propagation delays. Plan changes, lower TTL ahead of time, and verify A/AAAA records before switching.
- Firewall/port edits can break access. If you change SSH, HTTP/HTTPS, RDP, or app ports, update firewalls (UFW/CSF/security groups) and reverse-proxy rules accordingly.
- Email (SMTP) ports are restricted by default. Outbound mail ports (e.g., 25/465/587) may be closed to prevent abuse. If your OCA must send email, request SMTP Access from support or use a transactional email provider (SendGrid/Mailgun/SES) via API or approved SMTP.
- Email & allowlists. If the app sends mail or receives webhooks, changing IPs/hostnames may affect deliverability or allowlists. Update SPF/DKIM/DMARC and any IP allowlists.
- Before any big change, take a snapshot. Use the panel’s snapshot/backup first. If a plugin, update, or config edit backfires, you can roll back in minutes.
- Support scope. We provide the server and the preinstalled OCA image. Ongoing application-level configuration (domains, DNS, app settings, plugins, custom code) is the user’s responsibility.
Quick rule of thumb: if you touch domain, ports, passwords, hostnames, or proxy/SSL configs, expect to update the app’s settings too, and snapshot first.