[Feature request] SNI-based XTLS-Reality detour

[uprtdev]

The proposal is to add SNI-based XTLS-Reality fallback support.

According to the XTLS-Reality idea, the only fallback possible is transferring the connection to some real 3rd-party website (like google.com) with its real certificate.

However, this prevents having the same time on the same port VLESS+XTLS-Reality, and a backup option with VLESS+WS or VLESS+gRPC to work over CDNs in case if server's IP address is blocked.

This can be achieved by analyzing the SNI field of the incoming TLS connection ClientHello and setting a special "fallback domain" in the config. The simple implementation of SNI proxy in Go is naive and short.

So when a new connection is established, we may have the following:

1. If the user is valid according to XTLS-Reality mechanism, the connection is established with the proxy (VLESS or Trojan)
2. If not - we check the SNI in ClientHello. If it equals the "secret fallback domain", we pass it to the corresponding fallback handler.
3. If it is not equal to the "secret fallback domain" - we pass it to the upstream server ("dest" field) as usual in XTLS-Reality.

So by this, we can have XTLS-Reality and WS/gRPC backup on the same server and port. "Fallback" is a secret domain used only to connect through CDNs, so the censors will not see any direct connections to the server using it and cannot detect it.

I know this can be achieved by using haproxy or sniproxy behind or in front of XRay, but would be nice to have a built-in functionality.

[RPRX]

Use nginx.

REALITY 的实现比较严谨，暂时不会加 SNI 分流 #2017 (comment)