MASKING_HOST/MASKING_PORT is ignored and forced to CUSTOM_IP:443 in the generated telemt config

[rvalitov]

Environment

• MTProxyMax manager v1.4.0-LTS, telemt engine v3.5.6-3693d1e
• Mask backend is a local HTTPS server on the same host that terminates the proxy tls_domain with a valid cert

Summary

When the mask backend is a local/loopback server, mtproxymax does not honor MASKING_HOST/MASKING_PORT
from settings.conf. Every regeneration of the telemt config.toml instead hard-codes the mask to
mask_host = CUSTOM_IP and mask_port = PROXY_PORT. Relaying to the public host causes the client's original
ClientHello (SNI = the proxy tls_domain) to route back into the proxy, so the TLS handshake never completes and
HTTPS access to the mask/tls_domain site fails.

Settings vs generated config

settings.conf (intended):

MASKING_ENABLED='true'
MASKING_HOST='127.0.0.1'
MASKING_PORT='8443'
UNKNOWN_SNI_ACTION='mask'
CUSTOM_IP='<PUBLIC_CONNECT_HOST>'
PROXY_DOMAIN='<TLS_DOMAIN>'
PROXY_PORT='443'

config.toml produced by the manager after mtproxymax mask-backend 127.0.0.1:8443:

[censorship]
tls_domain = "<TLS_DOMAIN>"
unknown_sni_action = "mask"
mask = true
mask_port = 443        # expected 8443
mask_host = "<PUBLIC_CONNECT_HOST>"   # expected "127.0.0.1"

Passing a non-loopback LAN address behaves the same: mtproxymax mask-backend <LAN_IP>:8443 still yields
mask_host = "<PUBLIC_CONNECT_HOST>", mask_port = 443.

Repro

1. Set MASKING_HOST='127.0.0.1', MASKING_PORT='8443' in settings.conf, with a real HTTPS server for the
   tls_domain on that address/port.
2. Run mtproxymax mask-backend 127.0.0.1:8443 → it prints "Mask backend set to 127.0.0.1:8443", regenerates
   config.toml, and restarts the engine.
3. Inspect config.toml → mask_host/mask_port are CUSTOM_IP/PROXY_PORT, not 127.0.0.1/8443.
4. curl -v https://<TLS_DOMAIN>/ from an external host → TLS handshake never completes
   (error:0A000126:SSL routines::unexpected eof while reading).

Expected behavior

UNKNOWN_SNI_ACTION='mask'
CUSTOM_IP='<PUBLIC_CONNECT_HOST>'
PROXY_DOMAIN='<TLS_DOMAIN>'
PROXY_PORT='443'

config.toml produced by the manager after mtproxymax mask-backend 127.0.0.1:8443:

[censorship]
tls_domain = "<TLS_DOMAIN>"
unknown_sni_action = "mask"
mask = true
mask_port = 443        # expected 8443
mask_host = "<PUBLIC_CONNECT_HOST>"   # expected "127.0.0.1"

Passing a non-loopback LAN address behaves the same: mtproxymax mask-backend <LAN_IP>:8443 still yields
mask_host = "<PUBLIC_CONNECT_HOST>", mask_port = 443.

Repro

1. Set MASKING_HOST='127.0.0.1', MASKING_PORT='8443' in settings.conf, with a real HTTPS server for the
   tls_domain on that address/port.
2. Run mtproxymax mask-backend 127.0.0.1:8443 → it prints "Mask backend set to 127.0.0.1:8443", regenerates
   config.toml, and restarts the engine.
3. Inspect config.toml → mask_host/mask_port are CUSTOM_IP/PROXY_PORT, not 127.0.0.1/8443.
4. curl -v https://<TLS_DOMAIN>/ from an external host → TLS handshake never completes
   (error:0A000126:SSL routines::unexpected eof while reading).

Expected behavior

config.toml should reflect the configured backend verbatim:

mask = true
mask_port = 8443
mask_host = "127.0.0.1"

so non-Telegram TLS is relayed to the local server that actually terminates the tls_domain.

Sample screenshots

Config shown in the TUI:

Config of telemt shown in the TUI (v command):

Related issues about masking: #71, #72

[rvalitov]

I also see that changing the masked settings (like local IP address) in the UI regenerates the user secrets. I suspect that regeneration of secrets is not required in such case. Please also check when the secrets are regenerated when they shouldn't 🙏

[rvalitov]

Update — found the real cause and a proper workaround.

Root cause: it's the Cover Shield feature overriding the mask backend during config
generation, not just the backend setting. In the generator, when
COVER_SHIELD_ENABLED=true and COVER_FALLBACK_TARGET is set, mask_host/mask_port
are taken from the fallback URL (host[:port]) and take precedence over
MASKING_HOST/MASKING_PORT. My fallback target had no port, so it was forced to
CUSTOM_IP:443 (the routing-loop case). MASKING_HOST/PORT is only honored when Cover
Shield is off.

Workaround that survives regenerations/updates:

mtproxymax cover-shield target https://127.0.0.1:8443
mtproxymax restart

Now config.toml is generated with mask_host="127.0.0.1", mask_port=8443 and stays
that way across updates. Suggestion for a fix: when Cover Shield is enabled, either honor
the scheme/port in COVER_FALLBACK_TARGET and emit it verbatim (it does parse host:port,
so this is mostly already there), or give mask-backend precedence over Cover Shield when
both are set explicitly.