cdn-fallback

CDN transports and fallbacks

Two different jobs that are often confused:

• CDN fronting hides the server's IP behind Cloudflare (or another CDN) and makes the traffic look like ordinary HTTPS to a real website. It needs a domain, a certificate, and a transport the CDN can proxy: WebSocket, gRPC or xhttp.
• Fallbacks let one TLS inbound on 443 hand connections to other inbounds by path or ALPN, so a web server and several proxy protocols share the port.

They combine well — a CDN-fronted WS inbound as the fallback child of a master inbound on 443 — but decide which problem you are solving first.

CDN fronting

REALITY cannot be CDN-fronted: it impersonates someone else's TLS, and the CDN terminates TLS itself. Fronting means a real certificate for a domain you control.

Pick the transport. WebSocket is the most widely supported and the safest default. gRPC multiplexes better on a busy link but needs gRPC enabled on the CDN side. xhttp is the modern option and the most flexible over HTTP/2, but is the most sensitive to CDN buffering — try it after WS works, not before.

Ports the CDN will proxy matter. Cloudflare proxies HTTPS only on 443, 2053, 2083, 2087, 2096 and 8443. An inbound on any other port must be grey-clouded, which defeats the purpose. Set the inbound's port to one of those, or terminate on 443 and fall back internally.

Create it — the transport carries no TLS of its own when the CDN terminates in front of it and the origin is plain HTTP; give it TLS when the origin must also be encrypted (Cloudflare "Full" mode).

create_inbound
  remark="ws-cdn"
  port=2053
  protocol="vless"
  settings={"clients":[],"decryption":"none"}
  stream_settings={"network":"ws","security":"none","wsSettings":{"path":"/vlws","host":""}}

Then add_client inbound_ids=[<id>] email="alice" — and no flow. xtls-rprx-vision is valid only on TCP-based VLESS; setting it on a ws/grpc/xhttp client produces a connection failure that looks like a broken server.