Help with fallbacks - Githubissues

Hello all. Thanks for making it possible to breach the GFW.

I'm trying to set up a server using VLess-REALITY, with a fallback to a "decoy" website on port 444. That is, I'd like connections from a browser (or anything else not running XRay REALITY) to hit the website once they fail the first-packet screening. The "decoy" is in fact an existing server set up using Nginx and using Let's Encrypt/Certbot for HTTPS that I've been using for some time. If needed, I can provide the Nginx configuration as well, but I suspect that that's not the issue, as it's been minimally modified (I just switched it from listening on port 443 directly to 444) and I can still get the homepage with curl -k 127.0.0.1:444.

Is this in fact what the fallbacks option in XRay is for? That was my original impression when reading through the documentation, but several hours of debugging later I'm no longer convinced of my understanding.

Here's my configuration, with various parts censored with ◆s:

{
    "log": {
        "loglevel": "debug",
        "access": "/home/xray/xray_log/access.log",
        "error": "/home/xray/xray_log/error.log"
    },
    "routing": {
        "domainStrategy": "IPIfNonMatch",
        "rules": [
            {
                "type": "field",
                "domain": [
                    "geosite:category-ads-all"
                ],
                "outboundTag": "block"
            },
            {
                "type": "field",
                "domain": [
                    "geosite:cn"
                ],
                "outboundTag": "warp"
            },
            {
                "type": "field",
                "ip": [
                    "geoip:cn"
                ],
                "outboundTag": "warp"
            }
        ]
    },
    "inbounds": [
        {
            "port": 443,
            "protocol": "vless",
            "settings": {
                "clients": [
                    {
                        "id": "◆◆◆◆◆◆",
                        "flow": "xtls-rprx-vision",
                        "level": 0,
                        "email": "impossarchi@◆◆◆◆◆◆"
                    }
                ],
                "decryption": "none",
                "fallbacks": [{
                    "alpn": "h2",
                    "dest": 444
                }]
            },
            "streamSettings": {
                "network": "h2",
                "security": "reality",
                "realitySettings": {
                    "show": true,
                    "dest": "bancatransilvania.ro:443",
                    "xver": 1,
                    "serverNames": [
                        "bancatransilvania.ro",
                        "www.bancatransilvania.ro"
                    ],
                    "privateKey": "◆◆◆◆◆◆",
                    "minClientVer": "",
                    "maxClientVer": "",
                    "maxTimeDiff": 0,
                    "shortIds": [
                        "8a74"
                    ],
                   "fingerprint": "random",
                   "certificates": [
                        {
                            "ocspStapling": 3600,
                            "certificateFile": "/etc/letsencrypt/live/◆◆◆◆◆◆/fullchain.pem",
                            "keyFile": "/etc/letsencrypt/live/◆◆◆◆◆◆/privkey.pem"
                        }
                    ],
                    "minVersion": "1.2"
                }
            },
            "sniffing": {
                "enabled": true,
                "destOverride": [
                    "http",
                    "tls",
                    "quic"
                ]
            }
        }
    ],
    "outbounds": [
        {
            "protocol": "wireguard",
            "settings":{
                "secretKey": "◆◆◆◆◆◆",
                "address": ["10.0.8.255/32", "fd72:11c:d64d:ff::/128"],
                "peers": [
                    {
                        "publicKey": "◆◆◆◆◆◆",
                        "endpoint": "localhost:8107"
                    }
                ]
            },
            "tag": "outbound"
        },
        {
            "protocol": "blackhole",
            "tag": "block"
        },
        {
            "protocol": "wireguard",
            "settings": {
              "secretKey": "◆◆◆◆◆◆",
              "address": ["172.16.0.2/32", "◆◆◆◆◆◆"],
              "peers": [
                {
                  "publicKey": "bmXOC+F1FxEMF9dyiK2H5/1SUtzH0JuVo51h2wPfgyo=",
                  "endpoint": "engage.cloudflareclient.com:2408"
                }
              ]
            },
            "tag": "warp",
    "policy": {
        "levels": {
            "0": {
                "handshake": 3,
                "connIdle": 180
            }
        }
    }
}

Symptoms: All my connections cut out when TLS starts, by which I mean that when I use the Firefox or Edge dev console to look at my network packets I see that they cut out after the "establishing connection" stage. I think this is actually "progress" over a previous iteration of the configs, which just gave the sort of "invalid certificate" errors you'd expect from trying to use the certificates from one site at some other domain name -- an indication that REALITY is doing its job, to be sure, but leaving me very confused about what the fallbacks were (not?) doing; at least this way I can be sure that VLess is also doing its job and breaking the connection if it doesn't fit the protocol. But maybe it's actually a regression, and the way I had it the first time was better?

Regarding a few points where my configuration has been customized:

First, since my VPS is in Romania, I decided it'd be ~~funny~~ appropriate to "borrow" TLS handshakes from the Bank of Transylvania. I think it passes the requirements -- Edge tells me that while it prefers QUIC and HTTP/3, it still loads a number of resources over HTTP/2, and it certainly is using TLS 1.3 and OCSP -- but honestly, I'm pretty sure I'm not even getting that far before my connection breaks.
Secondly, the established behavior of my existing server was that it simply dropped unsecured HTTP connections; I've since updated that to automatically upgrade to HTTPS, but at any rate I'm trying to make the decoy server also auto-upgrade to HTTPS. I've found a couple of guides for that, but all of them reference XTLS at most, and have matching tlsSettings fields rather than a realitySettings field in their configs. Digging into the code, I saw that REALITY at least supports a certificates etc option in the Go side of its config, so I've crammed in the "extra" TLS settings in the hopes that they're more of an undocumented feature... ^.^;. xray -test doesn't complain, though?
Thirdly, my use case here is to connect a number of devices on the same Wireguard network that have been "stranded" this side of the GFW, to the outside world. As such, rather than opening either a tunnel for a single user or making a proxy server for multiple users, I'm focused mostly on reconnecting the Wireguard VPN on this side to the rest of the network outside. This is why I have no freedom/direct outbound and have a Wireguard VPN listed first. If this was an error, please let me know and I'll change it... though again, I don't think I'm getting anywhere near that far before the connection fails, so I doubt that's my immediate problem at least.
Lastly, I suppose I could drop some of the complexity here by using 自己偷自己, reducing this to just one set of certificates, but if at all possible, I'd prefer to understand what's wrong rather than blindly switching between presets until one works...

Thanks again for all your work; sorry for all the extra complexity; please advise!

XTLS / Xray-core

Help with fallbacks #3353