Feature Request: Decouple REALITY handshake TLS from fallback forwarding

[ayzbcr]

Feature Request: Decouple REALITY handshake TLS from fallback forwarding

Problem Description

In the current REALITY implementation, the handshake configuration serves two coupled purposes:

1. TLS handshake template: sing-box connects to the handshake server, completes a real TLS handshake, and uses the obtained certificate, session ticket, and key exchange parameters to masquerade the connection to REALITY clients.
2. Fallback forwarding: Unauthenticated connections (those without a valid UUID) are transparently forwarded to the handshake server.

This coupling has led to real-world incidents. One user recently reported (source) that his DMIT VPS was suspended for "stealing OpenAI and Cloudflare's resources." His VLESS-REALITY configuration had handshake.server pointing to cdn.microsoftxxxx.net (a Microsoft CDN domain) and listened on 0.0.0.0. Unauthenticated connections were being forwarded to the CDN, making DMIT's network monitoring detect that his server was being used as an anonymous relay to access third-party services — even though he never intended this.

This is not an isolated case. Any sing-box instance with REALITY enabled and a public-facing inbound port effectively becomes an open relay: anyone who can reach the port can use the server as a gateway to access the handshake server's origin. Hosting providers (DMIT, Oracle Cloud, and others adopting behavioral detection) may flag or suspend such instances.

Proposed Solution

Decouple the two responsibilities by introducing a separate fallback field (or a simple reject_on_auth_fail boolean), allowing users to control how unauthenticated connections are handled independently from the certificate source.

Option A — Minimal change: reject_fallback boolean

"reality": {
    "enabled": true,
    "handshake": {
        "server": "example.com",
        "server_port": 443
    },
    "reject_fallback": true   // new: drop unauthenticated connections instead of forwarding
}

Option B — Full decoupling: separate cert_source and fallback

"reality": {
    "enabled": true,
    "cert_source": {
        "server": "example.com",
        "server_port": 443    // only used for TLS handshake to obtain certificate parameters
    },
    "fallback": null           // null = reject; or point to a local/trusted server
}

Use Case

• Users want to use a public HTTPS service as the TLS masquerade target (e.g., a CDN domain or their own domain hosted elsewhere)
• Users do NOT want unauthenticated connections to be forwarded anywhere outside the local machine
• The goal: preserve REALITY's traffic obfuscation while eliminating the open-relay risk

Limitations of Current Workarounds

Workaround	Problem
Point handshake to a local HTTPS service with a self-signed cert	Poor masquerade; client traffic is easily identifiable as non-standard
Point handshake to another server you own	Fallback traffic still exits the VPS; the provider can still detect outbound forwarding behavior
Use iptables to restrict inbound source IPs	Not practical for mobile clients or multi-IP environments

Additional Context

This is not an edge case. As more VPS providers adopt behavioral detection for proxy/abuse monitoring, REALITY users are increasingly caught between the protocol's need for a realistic handshake target and the security risk of running an open forwarder. A reject_fallback option would resolve this tension with minimal implementation effort.

Thank you for considering this.