Choosing a Domain and Hosting

The two decisions you make before installing mtg — which VPS provider and which domain to put on it — determine whether your proxy lives for months or gets blocked in a week. Almost every "my proxy died after a day" report on the issue tracker traces back to one of these choices.

This page is the deep dive. See Surviving Active Probing for why SNI/IP consistency matters in the first place; this page assumes you already understand that and focuses on how to pick the parts.

Note on dates. Pricing, ASN reputations, and TLD policies move fast. Every concrete claim below links to a primary source. When in doubt, re-verify against the linked URL — the proxy ecosystem is a moving target.

mtg's FakeTLS encodes a hostname into the secret. Telegram clients connect to that hostname, mtg announces it as the TLS SNI, and on a failed handshake mtg does domain fronting back to the real site. All of this only looks legitimate to a censor if:

1. The hostname's DNS resolves to the proxy's IP (or to a CDN that forwards to it).
2. The hosting IP doesn't already scream "datacenter VPN farm".
3. The TLS service on that IP behaves like a real website on probe.

Item 1 is about the domain. Item 2 is about the ASN/IP. Item 3 is covered in Surviving Active Probing. Pick wrong on 1 or 2 and items further down the stack don't save you.

A lot of older guides recommend generating the secret with www.cloudflare.com, azure.microsoft.com, or similar. Don't.

• The hostname is announced in plaintext SNI. A censor sees the SNI, resolves it via their own resolver, gets Cloudflare's IPs, compares to the IP you actually connect to, and the mismatch is obvious.
• It also creates the question "why is Hetzner-AS24940 serving cloudflare.com?" — that's a free DPI rule.
• mtg's own mtg doctor warns about this; recent builds also warn at startup.

The only case where borrowing an SNI works is when you put the proxy behind that provider's actual edge — e.g. behind Cloudflare with a domain whose DNS is on Cloudflare. That's covered in Surviving Active Probing § B.

Default recommendation: register or reuse a domain you own and point its A/AAAA records at the proxy's IP.

The TLD itself rarely gets blocked outright, but it influences:

• DNS-firewall and email-reputation filters that increasingly drop whole TLDs.
• The probability that the registrar suspends you on the first abuse report.
• How "real" the domain looks in a quick eyeball test by a censor analyst.

TLDs to avoid:

• .tk, .ml, .ga, .cf, .gq — defunct. Freenom exited the domain business and the registries no longer sell or renew these names (Domain Incite, 2024). Do not register here even if a reseller claims to offer them.
• .top — Spamhaus tracked 211,406 abuse detections in six months and a 50% jump in abuse rates (Spamhaus). New .top registrations were also up 94% in April–September 2025 (Spamhaus, 2025).
• .xyz — new registrations up 103% in April–September 2025 (Spamhaus, 2025); many email providers and DNS firewalls treat the whole TLD as suspicious.

TLDs that are usually fine:

• Legacy gTLDs: .com, .net, .org, .info, .biz.
• Country-code TLDs you have a real tie to: .de, .nl, .uk, .fr, .eu, .io, .ru for RU operators if you already use Russian infra.
• Niche but reputable: .dev, .app (HSTS-preloaded — TLS is required but that's what you want anyway).

A $10/yr .com is cheap insurance against TLD-level filtering.

• Age. Brand-new domains get extra scrutiny from DNS firewalls, mail filters, and some censorship systems. Spamhaus's best-practice guidance for newly registered domains warns against putting them straight into production traffic (Spamhaus, 2025). For a proxy this means: register a few weeks early, put a basic static page up, let the domain accumulate some Certificate Transparency entries before pointing Telegram clients at it.
• Registrar. Pick one that won't drop you on the first abuse complaint and that accepts your payment method. Namecheap, Porkbun, Cloudflare Registrar, INWX (EU), reg.ru (RU operators paying in rubles) are all reasonable. Avoid registrars known for aggressive content takedowns if your operating threat model includes complaints from your home country's authorities.
• WHOIS privacy. Turn it on. Most registrars offer it free. This doesn't hide you from law enforcement but it removes one easy fingerprint a censor can correlate across multiple proxy domains.
• Payment trail. If you're in an at-risk jurisdiction, paying with a card tied to your real name and using your real address in WHOIS defeats most of the privacy you got from technical measures. Crypto payment is supported by Namecheap, Njalla, and some smaller registrars.

If you have any personal domain — a blog, a CV site, anything you registered years ago — using a subdomain like tg.example.com for the proxy is almost certainly the best balance of cost, reputation, and operational ease:

• Zero marginal registration cost.
• The parent domain already has CT history and mail/DNS reputation.
• You can rotate the subdomain (tg2, m, etc.) without touching anything else.
• Let's Encrypt cert in Caddy/nginx is free and automated.

The only caveat: the subdomain's traffic pattern is now visible in passive DNS feeds against the parent. If the parent domain is tied to your real identity and your threat model excludes that link, register a separate domain instead.

These three are the default suggestions in every cheap-VPS guide, which is exactly the problem: their entire ASNs are flagged on practically every abuse-and-VPN list.

• Hetzner (AS24940, AS213230, etc.) — listed on bad-asn-list and similar curated blocklists.
• OVH (AS16276) — same story; UDP-targeted blocking from RU networks reported in late May 2025 (Mediazona/Cloudflare reporting, 2025-06).
• DigitalOcean (AS14061) — also subject to Russian throttling as part of the same campaign that hit Cloudflare and Hetzner (Mediazona, 2025-06).

What this means in practice for mtg:

• Russian DPI (TSPU) applied a 16-kilobyte data cap to traffic from Cloudflare, Hetzner and DigitalOcean during 2025 (Mediazona, 2025-06). A new IP from any of these may work for a while, then suddenly hit a per-connection ceiling.
• Iranian filtering tends toward whole-ASN rate-limiting; expect packet loss and TLS handshake stalls rather than outright RST.
• The Great Firewall is less ASN-driven and more SNI/active-probe driven, but well-known datacenter ranges still get extra love.

They're not interchangeable. Hetzner's Falkenstein DC behaves differently from Hetzner Helsinki, which differs from a fresh Hetzner Cloud project allocated last week. Recently allocated /24s can have much cleaner reputation than older ones; check the specific IP, not just the brand (see § 5).

For RU/IR operators, hosting inside the country sidesteps the "foreign-ASN-flagged" problem entirely, at the cost of legal exposure and (usually) worse uptime/peering.

Russia:

• Selectel — established, multiple DCs in Moscow / SPb. VDS pricing starts at 200 ₽/mo (vds.selectel.ru).
• Timeweb Cloud — VPS from 477 ₽/mo for 1 vCPU / 1 GB / 15 GB NVMe (Cloud MSK 15) with monthly billing (timeweb.cloud).
• reg.ru — convenient for RU customers because they're also a registrar; .ru domain + VPS in one place.
• Aeza, FirstVDS, Beget — smaller, often cheaper, sometimes rougher around the edges.

Trade-offs:

• (+) Inside-the-country routing → no TSPU at the border. Telegram clients in RU networks reach the proxy directly.
• (+) Payment in rubles, no currency-control friction.
• (–) Operator is subject to Russian law including SORM logging requirements, "Sovereign RuNet" controls, and Roskomnadzor takedown notices. A proxy that's used to bypass blocks from inside RU is legally risky for the operator; this is a personal call, not a technical one.
• (–) Foreign Telegram DC peering quality varies; latency to Telegram DC2 (Amsterdam) and DC4/5 (Singapore/USA) can be uneven.

Iran:

• Local providers like IranServer, Hostiran, Pars Pack, ArvanCloud — generally rial-billed, very cheap, varying quality. US sanctions complicate payment from outside Iran.

Trade-offs:

• (+) Iranian DPI throttles foreign datacenter traffic; domestic routes mostly avoid it.
• (–) The Iranian government can compel local hosts to block or hand over data. Protests and blackouts (e.g. 2022, 2025 mobile shutdowns) take domestic hosts offline along with everyone else.
• (–) Outbound peering to Telegram DCs sometimes goes through state-controlled chokepoints that are themselves rate-limited.

China: there's effectively no useful "domestic" option for an mtg-style FakeTLS proxy. Hosting inside China requires ICP filing, exposes the operator to direct legal liability, and the target service (Telegram) is blocked on the way out anyway. CN operators almost universally pick foreign hosting and accept the GFW fight.

If foreign-DC ASNs are blocked and domestic hosting is legally unsafe, some operators put the proxy on a foreign DC and front it with a residential IP via a tunnel (WireGuard / a paid residential proxy / a friend's home server with a static IP). This works but:

• Adds a hop, latency, and a single point of failure on the residential side.
• Most "residential proxy" services are themselves botnets or near-botnet IP brokers; using them for a long-lived TCP listener is shaky and probably violates their ToS.
• A friend's home connection is the most robust variant but limited to small numbers of users.

This is not a default; consider it only when datacenter options have been exhausted.

Usually overkill, sometimes worse:

• (–) Expensive: a comparable VM on AWS Lightsail or GCP e2-micro is several times the price of a budget Hetzner / DigitalOcean instance.
• (–) Egress bandwidth is metered and non-trivial — Telegram media traffic on an active proxy can chew through a free-tier quota quickly.
• (–) ASNs are flagged just like Hetzner's, and AWS in particular is treated as suspicious in some Chinese filtering contexts.
• (+) The IPs they hand out can have cleaner per-IP reputation than budget VPS ranges, since the major clouds aggressively recycle them and abuse response is fast.
• (+) Oracle Cloud's Always Free tier gives 4 OCPU / 24 GB Ampere ARM capacity (3,000 OCPU-hours and 18,000 GB-hours per month) (Oracle docs). Note: Oracle reclaims instances whose CPU, network, and memory utilisation all stay below 20% for 7 days (Oracle docs) — an idle proxy can disappear.

Pick big-cloud only if you specifically want their IP reputation or already have credits.

Telegram itself supports both: each Telegram DC has at least one v4 and one v6 endpoint exposed (core.telegram.org/api/datacenter). Both Telegram Desktop and the mobile clients support an explicit "Try IPv6" connection option.

Practical guidance:

• Dual-stack (v4 + v6) is the default. It costs nothing extra on most providers and maximizes reach. Make sure both A and AAAA records resolve to the proxy and that Telegram clients connect over whichever is faster.
• v6-only VPS is genuinely cheap on some providers but expect a meaningful fraction of clients to fail to connect, especially mobile users on networks that haven't deployed v6. Don't make it the only proxy you give to non-technical users.
• v4-only: still fine. The "v6 reaches around the censor" idea is overstated for mtg's traffic — TSPU and similar systems do filter v6, just less aggressively.

Always do this after you've allocated the VPS and before you hand the secret to users. It takes five minutes and it tells you whether you're starting in a hole.

When you check a freshly allocated IP, the boring answer is what you want:

ipinfo.io  →  ASN matches the provider, "hosting: true" only.
              No "vpn: true" / "proxy: true" / "tor: true".
GreyNoise  →  No classification (clean), or at most "benign".
Censys    →  No history at all (fresh allocation), or only the
              provider's default services (cloud-init, etc.).
AbuseIPDB →  0 reports, or a small number from > 6 months ago.

If the IP shows up as a previously seen VPN exit, OpenVPN server, WireGuard endpoint, or IRC bouncer — release it and request a new one. Most providers let you destroy and recreate the VM to roll the IP for free. Hetzner Cloud lets you swap primary IPs explicitly; OVH and DO require destroy/recreate.

IP=1.2.3.4

# ASN + geo + privacy flags (no auth)
curl -s "https://ipinfo.io/${IP}/json"

# GreyNoise community classification (no auth)
curl -s "https://api.greynoise.io/v3/community/${IP}" | jq

# AbuseIPDB (needs free API key in $ABUSE_KEY)
curl -s -G https://api.abuseipdb.com/api/v2/check \
  --data-urlencode "ipAddress=${IP}" \
  -H "Key: ${ABUSE_KEY}" -H "Accept: application/json" | jq

# Censys — show services seen on this IP (web UI is easier)
# https://search.censys.io/hosts/${IP}

# Past TLS certificates that named your domain (CT logs)
curl -s "https://crt.sh/?q=example.com&output=json" | jq '.[].name_value' | sort -u

For the domain, an extra step:

# Spamhaus DBL (domain blocklist) — returns NXDOMAIN if clean
dig +short "example.com.dbl.spamhaus.org"

• Rotate the IP when:
  • mtg sees a sustained drop in successful connections from a region that previously worked.
  • The IP starts showing up on AbuseIPDB / GreyNoise.
  • mtg doctor shows fronting failures that weren't there before.
• Rotate the domain when:
  • The IP rotated more than ~2× in a short window (the SNI is now correlated with bad IPs in DPI training data).
  • The Let's Encrypt cert was issued, revoked, and re-issued multiple times (visible via crt.sh; censors watch CT logs).
  • You have evidence the domain itself is being matched on (e.g. reachable from clean networks but not from RU/IR).

• IP-only rotation, same domain: clients pick up the new IP within one DNS TTL (set TTL to 60–300 s when you anticipate rotating). Push via your normal DNS provider; no client-side change needed.
• Domain rotation: the secret encodes the hostname, so you must re-issue the secret and redistribute it. This is the painful one — see § 6.3.
• Provider/ASN change: treat as full rotation; both IP and (often) domain.

Short answer: no, not in stock mtg.

The hostname is baked into the FakeTLS secret at generation time (mtg generate-secret your.domain). Changing the hostname means a new secret, which means new tg://proxy?... links for every user.

Practical mitigations:

• Use a stable parent domain and rotate the IP underneath. The hostname stays tg.example.com forever; you can move it across providers and IPs without touching the secret.
• Front via Cloudflare (Spectrum) or similar. The client-visible hostname becomes the CF edge name; the origin can rotate behind CF. This shifts the rotation problem from "SNI" to "origin IP" without touching users.
• Distribute via a bot. Run a small Telegram bot that hands out current tg://proxy?... links on demand. When you rotate, users re-fetch from the bot rather than waiting for you to repost.

Three concrete combos, priced from each provider's own pricing page. Re-check before ordering — most of these moved within the last 6 months.

If you're stuck, this is the default that works for most operators:

1. Use a subdomain on a domain you already own. No new registration, instant reputation.
2. Pick a Hetzner Cloud CX23 in a region close to your users. €3.99/mo as of 2026-04-01 (Hetzner price adjustment).
3. Before deploying mtg, run the IP through ipinfo.io, GreyNoise, Censys, AbuseIPDB. If anything's off, destroy and recreate.
4. Set the DNS TTL to 60–300 s so you can rotate IPs cheaply later.
5. Set up Caddy or nginx on the same VPS to serve a real page on the domain (see Surviving Active Probing § A).
6. Generate the secret with your real subdomain. Hand it out.

Total: under €5/month, 30 minutes of setup, survives most non-targeted DPI.