reality-wireguard-relaylisted

# REALITY → WireGuard relay/landing chain Build the topology: ``` Client ──VLESS/XHTTP/REALITY──▶ Relay (中转, reachable entry) │ └──WireGuard──▶ Landing (落地) ──NAT──▶ Internet exit IP = landing's public IP(s) ``` The **relay** terminates REALITY and forwards proxied traffic into a WireGuard tunnel. The **landing** does the real egress. Keep the landing as a **pure kernel WireGuard forward + NAT** with **no userspace proxy** — that is the lowest-overhead design and should be the default. Only run xray/socks on the landing if the user has a concrete reason. This skill assumes SSH root access to both ends. It drives the boxes over SSH and is non-interactive. Work one phase at a time and **verify each phase before moving on** — silent misconfig here looks like "线路不通" later and is expensive to chase. ## Before anything: settle the design (read references/architecture.md) Four decisions shape everything. Resolve them up front; don't guess: 1. **Which relay address can clients actually reach?** A relay's IPv4 is often GFW-blocked while its IPv6 still works (or vice-versa). The client link must point at the *reachable* family, and **the client must have that same IP family**. Confirm this — it is the #1 real-world cause of "connects on the server but not for me". 2. **What IP family does the WireGuard backhaul use?** Whatever the *landing* has. If th