Add docker-compose example with HAProxy SNI router

[dolonet]

Summary

A turnkey docker compose setup in contrib/sni-router/ that deploys
mtg behind an HAProxy SNI router alongside a real Caddy web server with
automatic HTTPS.

Motivation

The setup recommended in BEST_PRACTICES.md — own domain, real web
server, SNI-based routing — requires piecing together several services.
This bundle packages it so operators can clone and run with minimal
configuration.

How it works:

• HAProxy on :443 peeks at the TLS ClientHello SNI.
• Connections with the configured domain SNI → mtg (FakeTLS).
• Everything else → Caddy (real TLS, real certificate, real content).
• HAProxy on :80 redirects to HTTPS.

Active probes see a genuine website with a valid Let's Encrypt
certificate. Passive DPI sees consistent SNI/IP because the domain's DNS
points to this server.

Files

File	Purpose
docker-compose.yml	Three services: haproxy, mtg, caddy
haproxy.cfg	SNI routing rules (edit the domain)
mtg-config.toml	Minimal mtg config (paste your secret)
Caddyfile	Caddy auto-HTTPS on internal port
www/index.html	Placeholder site content
README.md	Quick start, architecture diagram, ACME notes

Test plan

• docker compose config validates the compose file
• Deploy on a test VPS with a real domain, verify:
  • curl https://DOMAIN/ returns the Caddy-served page
  • openssl s_client -connect IP:443 -servername random.example gets Caddy's cert
  • Telegram client connects through the proxy

Refs: #458

[ivulit]

I believe that in this scheme, you should use the PROXY protocol to pass the real client IP to MTG and the web server. MTG supports the PROXY protocol for both inbound and outbound connections, so please consider the configuration changes required to use the PROXY protocol.

[9seconds]

Nice one! But agree with @ivulit about PROXY protocol

[dolonet]

Pushed 170346b wiring up PROXY protocol v2 end-to-end:

• haproxy.cfg — send-proxy-v2 on the mtg and web backends (left web_acme alone — ACME HTTP-01 doesn't need it)
• mtg-config.toml — proxy-protocol-listener = true
• Caddyfile — listener_wrappers { proxy_protocol { allow <RFC1918> } tls } on :8443
• README.md — new section flagging that the three settings must stay in sync

Verified on a test VPS: HAProxy emits a well-formed v2 header and Caddy's wrapper unwraps it — RemoteAddr/LocalAddr in Caddy match the real client port and HAProxy's frontend port (would otherwise be the backend-side ephemeral port). mtg-side parsing not tested end-to-end, but the config key is the one referenced from internal/cli/run_proxy.go.

[9seconds]

Thanks!

[gaudima]

This setup does not work for me when fronting domain is same as mtp server domain unless I pin container IPs in docker-compose and add the following section to mtg-config.toml:

[domain-fronting]
ip = "CADDY_IP"
port = 8443
proxy-protocol = true

Without this modification mtg tries to access the server with sni which haproxy routes to mtg and then the cycle repeats and it gets stuck in a loop.

[gaudima]

Also, after reading some issues and another PRs in this repo I started to suspect that @dolonet is an LLM or is using an LLM.

[dolonet]

Also, after reading some issues and another PRs in this repo I started to suspect that @dolonet is an LLM or is using an LLM.

I am a human :). Yes, I use AI tools, but do it cautiously. Especially in public repos. AI now is not able to produce high quality output architecturally on its own, even today's Opus 4.7