Live · as-built (checked 2026-06-12). Deployed to chat.xbbapp.com on Alibaba Cloud ECS (Singapore, 2 vCPU / 4 GiB, Ubuntu 22.04), tracking main (single-trunk). This page records what's running, not a plan.
Cloudflare is registrar + DNS only. The data path never touches Cloudflare's edge — deliberate, because its free edge is degraded inside mainland China. The make-or-break setting is the DNS record: A chat.xbbapp.com → 47.236.15.147 must be grey-cloud (DNS only), not the proxied default.
A China browser resolves chat.xbbapp.com via Cloudflare's authoritative DNS, then connects directly to the Alibaba Cloud Singapore IP across the GFW. On the box, Caddy terminates TLS (and compresses zstd + gzip), then reverse-proxies to uvicorn / run_room.py on localhost — which serves the shell minified (rjsmin/rcssmin in the venv; ~514 KB source → ~140 KB wire) — the app handles its own login and serves every front-end asset same-origin (incl. the vendored render libs — KaTeX, highlight.js, DOMPurify — under /katex, /hljs, /dompurify.min.js), so the page load depends on no CDN and nothing China-degraded. The server's outbound calls reach Anthropic (Singapore allowed; HK/CN are not) — for the panel and the @Web Searchweb_search dispatch — and DeepSeek (reachable anywhere). That egress is the whole reason the box lives in Singapore.
① DNS China ISP resolver ↔ Cloudflare authoritative NS. Returns the Ali-SG IP. Grey-cloud means CF answers the name and nothing else — it stays off the traffic path.
② Data Browser → GFW → Ali-SG IP, directly. Cloudflare's China-degraded edge is bypassed; Alibaba SG's China peering decides whether it's fast or flaky.
③ Outbound ECS → Anthropic (Singapore allowed — HK & mainland blocked): the panel turn and the @Web Searchweb_search dispatch (Haiku). Plus DeepSeek (reachable anywhere). The persona builder adds egress to Gemini, Serper, Brave & Bocha (its gather + audit) — all clean from Singapore; the GFW only constrains China→box, never box→internet. This egress is why the box sits in Singapore.
the four moving parts — as configured
Cloudflare DNS — A chat.xbbapp.com → 47.236.15.147, cloud set to grey (DNS only).
Ali Security Group — inbound allow 443, 80 (cert issuance), 22 (SSH, ideally your IP only). Deny everything else.
Caddy — auto-TLS (HTTP-01) for chat.xbbapp.com + reverse_proxy 127.0.0.1:8000; auth lives in the app.
uvicorn — bind 127.0.0.1 (only Caddy faces the internet), single worker (in-memory rooms + per-room locks forbid multi-worker).
Cloudflare touches nothing but DNS for chat. Proxy/WAF/Access stay off this path; switch on Access or the orange cloud and traffic returns through the China-degraded edge. (By contrast, the admin docs on room2.xbbapp.com sit behind CF Access — there the edge hop is fine.)
/var/lib/mad is the only state (app.db + rooms/ + personas/), on the ECS local disk — no Google-Sync safety net. Covered by a daily auto-snapshot (mad-daily, 7-day retention). personas/ is the app-built persona root (MAD_PERSONAS_DIR) — where the persona builder writes, kept out of the repo tree so git pull deploys stay clean; repo personas win slug collisions.
The persona builder's box footprint (added 2026-07-05): three search keys in .env (SERPER/BRAVE/BOCHA; Gemini was already present for Seen), MAD_PERSONAS_DIR=/var/lib/mad/personas, and trafilatura in the venv. A code pull alone doesn't add these — the deploy script does git-pull + restart; env/dep changes are a separate one-time step (SSH, or Cloud Assistant if :22 is GFW-cooling). See Studio.
Managing it from China. SSH (port 22) works direct — add the box IP as a DIRECT rule in the side-router (Nikki / Mihomo): IP-CIDR,47.236.15.147/32,DIRECT — do not route it through a proxy node. Alibaba Cloud Assistant (control-plane, GFW-immune) is the fallback if the hop blips.
China path validated — reached no-VPN from a phone on China Mobile 4G (proxy off), the testers' real path. Re-check latency + packet loss anytime with itdog.cn or 17ce.com (trust authoritative DNS like dns.google JSON over a scraped 17ce table for the true A record).