feat: implement routing based on incoming SNI

[kastov]

Hi there,

Currently it is almost impossible to do routing with only one Inbound.

Of course, you can use Dokedomo-Door > Routing > Vless > Routing > Out, but in this case you will still have to have several INCOMING Dokedomo-Doors if I need to route traffic somewhere else.

Simple example:

There is a server called TEST.
We have VLESS Reality, which is configured according to all generally accepted standards on port 443, there is no Nginx/Haproxy/etc in front of it.

And here is the task: from the TEST server to route traffic to the TEST_B, TEST_C servers.
This can be done quite simply, BUT then we will have two Inbound, and they cannot occupy port 443 at the same time.

On the other hand, we can put Nginx/Haproxy in front, as far as I know - putting something in front of Xray in the case of Reality is not recommended, from which I conclude that this method, although in theory it will be working, will be contrary to the principles of Reality.

This small PR adds the ability to define routing rules based on incoming SNI for Trojan+TLS, VLESS+Reality, VLESS+TLS.

With this routing, you will no longer need to create multiple inbounds on different ports if they are completely identical, and will also allow you to leave one single Reality on port 443 and at the same time have full routing capability based on SNI.

{
  "routing": {
    "rules": [
      {
        "type": "field",
        "incomingSni": ["domain:example.com", "sample.com"],
        "outboundTag": "BLOCK"
      }
    ],
    "domainStrategy": "AsIs"
  }
}

[Fangliding]

in port in SNI in protocol in xxxxx.... 哎。。。
还有这样quic读不出

[Jolymmiles]

in port in SNI in protocol in xxxxx.... 哎。。。 还有这样quic读不出

Could you explain pls?

[patterniha]

I think adding route-id to vless is better idea.

you want to allow the users to choose which server to connect to in the end.

but users have to change the sni to connect to another server! these two things are completely independent of each other.

Anyway, this is also a solution, but i think the correct way is to add route-id to vless.

[Jolymmiles]

I think adding route-id to vless-options is better idea.

you want to allow the users to choose which server to connect to in the end.

but users have to change the sni to connect to another server! these two things are completely independent of each other.

Anyway, this is also a solution, but i think the correct way is to add route-id to vless option.

If user go change sni, user stopping be user. Sni provide proxy provider

[patterniha]

1. users still can't choose the end-server in non-tls vless

2. does not work on Xhttp

So I think this PR should be closed.

@RPRX is writing vless-encryption. ask him to write route-id for vless too.

[kastov]

1. users still can't choose the end-server in non-tls vless
2. does not work on Xhttp

So I think this PR should be closed.

@RPRX is writing vless-encryption-option. ask him to write route-id-vless-option too.

This feature mostly not for end-users, but for providers.

I don't think that routing-id is an option, because it will be break changing for all clients and other client cores.

[patterniha]

Anyway, your code is incomplete and does not support Xhttp.

[Jolymmiles]

Anyway, your code is incomplete and does not support Xhttp.

Could you pls show where we should add it in xhhtp, I can't really find it(

[patterniha]

Anyway, your code is incomplete and does not support Xhttp.

Could you pls show where we should add it in xhhtp, I can't really find it(

Xray-core/transport/internet/splithttp/hub.go

Lines 286 to 291 in 0cceea7

	conn := splitConn{
	writer: httpSC,
	reader: httpSC,
	remoteAddr: remoteAddr,
	localAddr: h.localAddr,
	}

you need to add request.TLS.ServerName, but if we have separate "downloadSettings" with separate "sni", which "sni" should be chosen???

So i close this PR, you should add route-id to vless.

[kastov]

Anyway, your code is incomplete and does not support Xhttp.

Could you pls show where we should add it in xhhtp, I can't really find it(

Xray-core/transport/internet/splithttp/hub.go

Lines 286 to 291 in 0cceea7

	conn := splitConn{
	writer: httpSC,
	reader: httpSC,
	remoteAddr: remoteAddr,
	localAddr: h.localAddr,
	}

you need to add request.TLS.ServerName, but if we have separate "downloadSettings" with separate "sni", which "sni" should be chosen???

So i close this PR, you should add route-id to vless.

No, i don't think that route-id is good option. It will break all backward compability.