[GH-ISSUE #3202] Telemt MTProxy: generated config enables TLS camouflage but disables fake-TLS mode, proxy cannot be connected to #1483

New issue

Open

opened 2026-10-13 20:43:39 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-13 20:43:39 +00:00

Owner

Originally created by @vtl94 on GitHub (Sep 23, 2026).
Original GitHub issue: https://github.com/amnezia-vpn/amnezia-client/issues/3202

Summary

When the Telemt MTProxy service is deployed from the client, the generated config.toml enables TLS camouflage but leaves the fake-TLS connection mode disabled. The resulting proxy cannot be connected to at all, and the link the client hands out is in a format the server will never accept.

Generated config (Ubuntu 24.04 server, container `amnezia-telemt`, `/data/config.toml`)

[general.modes]
classic = false
secure = true
tls = false

[censorship]
tls_domain = "googletagmanager.com"
mask = true
tls_emulation = false

With mask = true, telemt accepts only ee (fake-TLS) connections and silently forwards everything else to the real tls_domain. Because tls = false, no fake-TLS connection is ever offered, and the dd link the client shows can never complete a handshake. From the user's side this looks like a proxy that is up, reachable on 443, and simply does not work.

Setting tls = true / secure = false and restarting the container fixes it immediately.

Why this looks like an adapter bug rather than a user setting

The same client screen deploys the official MTProxy service correctly. Its generated start.sh gates the camouflage domain on the selected mode:

if [ "standard" = "faketls" ] && [ -n "googletagmanager.com" ]; then
    DOMAIN_ARG="--domain googletagmanager.com"
fi

The Telemt adapter has no equivalent gate — it writes mask = true and tls_domain regardless of the connection mode it selects. There is also no UI control to choose fake-TLS for Telemt, so the user cannot correct it from the app.

Impact

On ISPs where plain MTProto is filtered by signature, fake-TLS is the only mode that connects, so the Telemt service is unusable as shipped. Reconfiguring the service from the client rewrites config.toml and restores the broken state.

Suggested fix

Derive [general.modes] from the camouflage setting in the Telemt adapter: when mask = true, emit tls = true and disable secure/classic. Optionally expose the mode in the UI as the MTProxy service already does.

Environment

Server: Ubuntu 24.04, Docker, containers amnezia-telemt (443) and amnezia-mtproxy (8443)
Date observed: 2026-09-23

Originally created by @vtl94 on GitHub (Sep 23, 2026). Original GitHub issue: https://github.com/amnezia-vpn/amnezia-client/issues/3202 ### Summary When the Telemt MTProxy service is deployed from the client, the generated `config.toml` enables TLS camouflage but leaves the fake-TLS connection mode disabled. The resulting proxy cannot be connected to at all, and the link the client hands out is in a format the server will never accept. ### Generated config (Ubuntu 24.04 server, container `amnezia-telemt`, `/data/config.toml`) ```toml [general.modes] classic = false secure = true tls = false [censorship] tls_domain = "googletagmanager.com" mask = true tls_emulation = false ``` With `mask = true`, telemt accepts only `ee` (fake-TLS) connections and silently forwards everything else to the real `tls_domain`. Because `tls = false`, no fake-TLS connection is ever offered, and the `dd` link the client shows can never complete a handshake. From the user's side this looks like a proxy that is up, reachable on 443, and simply does not work. Setting `tls = true` / `secure = false` and restarting the container fixes it immediately. ### Why this looks like an adapter bug rather than a user setting The same client screen deploys the official MTProxy service correctly. Its generated `start.sh` gates the camouflage domain on the selected mode: ```sh if [ "standard" = "faketls" ] && [ -n "googletagmanager.com" ]; then DOMAIN_ARG="--domain googletagmanager.com" fi ``` The Telemt adapter has no equivalent gate — it writes `mask = true` and `tls_domain` regardless of the connection mode it selects. There is also no UI control to choose fake-TLS for Telemt, so the user cannot correct it from the app. ### Impact On ISPs where plain MTProto is filtered by signature, fake-TLS is the only mode that connects, so the Telemt service is unusable as shipped. Reconfiguring the service from the client rewrites `config.toml` and restores the broken state. ### Suggested fix Derive `[general.modes]` from the camouflage setting in the Telemt adapter: when `mask = true`, emit `tls = true` and disable `secure`/`classic`. Optionally expose the mode in the UI as the MTProxy service already does. ### Environment - Server: Ubuntu 24.04, Docker, containers `amnezia-telemt` (443) and `amnezia-mtproxy` (8443) - Date observed: 2026-09-23

bsakaguchi referenced this issue

2026-10-14 21:01:40 +00:00

[PR #1483] [MERGED] feature: retrieving support info from gateway #2383

bsakaguchi referenced this issue

2026-10-14 21:03:05 +00:00

[PR #1839] [MERGED] update new code from dev #2561