Port 443 is the only slot left in some networks — sharing it between protocols

[rokokol]

In Russia the practical situation on many operators is that only 443 survives. Alternative HTTPS ports are filtered: 2053 does not pass, and neither do the other common alt-HTTPS choices. On top of that, TLS is filtered by SNI against a whitelist, so the ClientHello has to carry a name from that list.

The consequence for deployment is not "one port is more convenient". It is that a server has exactly one TCP slot and one UDP slot, both on 443, and everything an operator wants to offer has to fit inside them.

Today the only mechanism for sharing that slot is fallbacks, and it discriminates by alpn and path. That works well for WebSocket and HTTP, whose path is fixed. It does not work for XHTTP: the client appends a session id and a sequence number, so the request path is /<configured>/<session>/<seq> and never equals the configured value. The matcher compares exactly, so a path-keyed fallback entry is never selected — the connection reaches the fallback stage and then matches nothing.

I verified this on 26.7.28. With path set, the log shows the fallback starting and then no fallback to line at all:

proxy/vless/inbound: firstLen = 70
proxy/vless/inbound: fallback starts > proxy/vless/encoding: invalid request version
proxy/vless/inbound: realName = <sni>
proxy/vless/inbound: realAlpn =

With an empty path — a catch-all — it works in every XHTTP mode (auto, packet-up, stream-one).

So the catch-all is the only working form, and it can hold exactly one child. A single 443 can host VLESS plus one fallback target, and no way to tell a third apart.

I am aware of #4832, which asked for wildcard path matching or an isXhttp flag and was closed as not planned. I am not re-opening that as a bug — I want to put the deployment constraint on the record, because I do not think it was part of that conversation. Where alternative ports are filtered, single-port multiplexing is not a convenience feature; it decides how many protocols an operator can offer at all, which in turn decides what they can fall back to when one of them starts being detected.

Concretely, any of these would be enough:

• prefix matching for path in fallbacks, so /x matches /x/<session>/<seq>
• a per-fallback flag saying the child is XHTTP, so the matcher compares against the base path
• any other documented way to route more than one protocol behind one 443

I can test a patch on a deployment that actually sits behind the filtering described above. That part is hard to reproduce in a lab, so if it helps, the offer stands.