Add labels for configured secrets and surface matched secret in logs

[dvershinin]

Context

MTProxy already supports multiple secrets via repeated -S flags, and Docker support for multi-secret startup landed in #54.

The remaining gap from the upstream discussion is operator visibility: being able to attach a stable human-readable label to each configured secret and see which label matched on incoming connections.

Reference discussion:

• Создание нескольких ключей секретов 9seconds/mtg#376 (comment)
• Создание нескольких ключей секретов 9seconds/mtg#376 (comment)

This is not a claim that secret rotation prevents IP blocking once a link has already escaped into the wild. The value here is narrower and operational:

• distinguish family / friends / test users / temporary shares
• identify which secret is being used when investigating abuse or abnormal traffic
• revoke one secret without touching the others

Requested behavior

• Keep current repeated -S <secret> behavior unchanged.
• Add an optional way to associate a human-readable label or ID with each configured secret.
• When a client handshake succeeds, surface the matched secret label/ID in logs and/or stats output.
• Do not expose raw secret values in runtime logs.
• Document both native and Docker usage.

Acceptance criteria

• Existing single-secret and multi-secret setups remain backward compatible.
• Operators can define labels for 1..N configured secrets.
• Secret matching still preserves current protocol behavior and compatibility.
• Only labels/IDs are emitted for observability; secret material is not.
• Tests cover labeled multi-secret matching and unknown-secret rejection.

Notes

Implementation detail is open. We do not need to copy mtg's TOML UX exactly if a simpler CLI- or Docker-oriented interface fits this codebase better.

Existing related work:

• Docker: support multiple secrets via environment variable #54
• Docker: print ready-to-share connection links at startup #55

[github-actions]

Thank you for opening this issue.

This project is maintained by a single developer in their free time.
Upstream TelegramMessenger/MTProxy is abandoned. This fork is the only actively maintained version.

Continued development depends on community support:

• GitHub Sponsors — sponsors' issues are prioritized
• TON: UQBOGq_b3eL63Qfkj6ykoBibK3zGJDQzLK91v2q-UCY7BPeb (send via @wallet in Telegram)
• USDT (TRC-20): TNVSj1QjZ5jqdaeshe7VCpXWo2S1n936Hj
• BTC: bc1qvxxldmanwggula7992uun5a2qxm65ej9h0unj7
• GetPageSpeed RPM packages — production-ready install with support

Issues without community interest may be closed after 60 days of inactivity.

[PentiumB]

The remaining gap from the upstream discussion is operator visibility: being able to attach a stable human-readable label to each configured secret and see which label matched on incoming connections.

Is it possible to display online activity for different secrets in metrics?
Usecase:
Determine which key may have been leaked.

Also, are there options for limiting the number of connections per secret?

[dvershinin]

@PentiumB Both requests from your comment are addressed:

Per-secret metrics — implemented in f5aacb9. When secrets have labels (-S secret:family), the stats endpoints now show per-secret connection counts:

• /metrics (Prometheus): mtproxy_secret_connections{secret="family"} 3 and mtproxy_secret_connections_created_total{secret="family"} 42
• /stats: secret_family_connections and secret_family_connections_created

This lets you identify which secret may have been leaked by comparing connection counts across secrets.

Per-secret connection limits — tracked as a follow-up in #66. The infrastructure is now in place (per-connection secret ID tracking), so adding limits will be straightforward.