Feature Request: Per-connection SNI rotation with configurable selection strategy

[egorov-denis]

Problem

Some network environments apply connection throttling or temporary blocking based on repeated TLS handshakes using the same SNI. The heuristic appears to count multiple TLS/QUIC connection attempts sharing the same Server Name Indication within a short time window.

This can affect legitimate long-running clients that reconnect periodically or establish several independent TLS/QUIC connections over time.

When all connections always use the same configured server_name, every new handshake contributes to the same SNI-specific counter.

For deployments using a wildcard certificate or multiple equivalent hostnames pointing to the same server, there is currently no way to distribute new connections across multiple valid SNI values.

Proposed feature

Allow server_name to accept multiple values together with a per-connection selection strategy.

Example:

{
  "tls": {
    "enabled": true,
    "server_name": [
      "cdn1.example.com",
      "cdn2.example.com",
      "cdn3.example.com"
    ],
    "server_name_strategy": "random"
  }
}

The selected SNI must remain fixed for the lifetime of a single TLS/QUIC connection.

A new value is chosen only when a completely new TLS/QUIC connection is established.

The SNI must never change during an active connection.

Possible strategies

• first (default, current behavior)
• random
• round_robin

Potential future extensions:

• weighted
• hash
• custom plugin/provider

Use cases

• Deployments using wildcard certificates (*.example.com)
• Multiple equivalent hostnames pointing to the same server
• Load distribution across hostnames
• Reducing repeated use of identical TLS metadata across independent connections
• Improving resilience in networks that apply SNI-based connection heuristics

Benefits

• Eliminates the need to duplicate multiple nearly identical outbound configurations.
• Keeps configuration compact and maintainable.
• Fully backward compatible (first preserves existing behavior).
• Works for every TLS-based transport (Hysteria2, TUIC, Trojan, VLESS+TLS, etc.).

Notes

This feature only affects the SNI chosen when initiating a new TLS/QUIC handshake. It does not modify the SNI after the connection has been established and therefore does not affect protocol correctness or certificate validation.