# Cloudflare as the Perimeter: Tunnel, Zone, and the 530 Audit
## Introduction: the perimeter is not a firewall
Every sovereign infrastructure needs a perimeter. Not a firewall — a firewall is a list of rules that someone else manages. A perimeter is a boundary you can see, measure, and verify. In the Kingdom of Truth, the perimeter is Cloudflare: the tunnel that carries traffic, the zone that owns the names, and the 530 audit that proved the architecture works.
This is not a tutorial on Cloudflare configuration. It is a case study in perimeter design for a fleet that runs on localhost and Tailscale, where Docker Desktop’s Linux VM cannot reach the host’s network interface, and where a separate DNS zone (lucid.tv) lives on different nameservers entirely. The 530 error — Cloudflare’s origin DNS failure code — was the diagnostic signal that forced the architecture to reveal itself.
## The architecture before the audit
The original design routed all `*.lucidhive.com` subdomains through a Docker-managed Cloudflare tunnel (ID `20c6e513`). The tunnel configuration pointed to Tailscale IPs (`100.73.106.130:PORT`) because the backend services — WordPress on 8070, the studio on 8076, the Hermes gateway on 7077 — all bound to the Tailscale interface for sovereign remote access.
This worked in theory. In practice, Docker Desktop on macOS runs a Linux VM that has no path to the host’s Tailscale interface. Every request from Cloudflare’s edge hit the tunnel, the tunnel tried to reach `100.73.x.x`, the VM’s network stack returned unreachable, and Cloudflare returned HTTP 530 for all thirteen subdomains. Uniform failure. Clean signal.
The 530 error is Cloudflare-specific: not a standard HTTP code, emitted only for proxied hostnames, indicating origin DNS or connection failure. In this audit it served as the perimeter’s heartbeat — every subdomain behind the broken tunnel returned 530, making the failure mode consistent and detectable.
## The fix: localhost routing and zone ownership
The migration moved from Docker-managed tunnel to local `cloudflared` (tunnel `c7df97be`) with `127.0.0.1` routing. The config at `~/.cloudflared/config.yml` now routes all ingress rules to IPv4 loopback addresses:
“`
ingress:
– hostname: lucidhive.com
service: http://127.0.0.1:8070
– hostname: studio.lucidhive.com
service: http://127.0.0.1:8076
– hostname: dev.lucidhive.com
service: http://127.0.0.1:8069
# … all 13 subdomains
“`
IPv4 loopback avoids IPv6 resolution issues with `localhost`. The Docker container was stopped — redundant, broken routing eliminated. DNS CNAME records for all `*.lucidhive.com` subdomains were updated to point to tunnel `c7df97be` via `cloudflared tunnel route dns –overwrite-dns`.
Verification results: `lucidhive.com` and `studio.lucidhive.com` returned 200. Five subdomains returned 502 (no backend deployed, expected). `dev.lucidhive.com` returned 500 (backend error, separate investigation). The perimeter was restored.
## The zone boundary: lucid.tv remains 530
`lucid.tv` is a separate Cloudflare zone with different nameservers (andronicus/diana vs lina/lynn). Tunnel `c7df97be` belongs to the `lucidhive.com` zone. Cloudflare tunnels are zone-scoped — you cannot route `*.lucid.tv` subdomains through a tunnel in another zone.
All six `lucid.tv` subdomains still return 530: `lucid.tv`, `ai.lucid.tv`, `m.lucid.tv`, `hex.lucid.tv`, `social.lucid.tv`, `marcus-andersson.lucid.tv`. The zone boundary is absolute. Three remedies exist: add `lucid.tv` to the same Cloudflare account, create a separate tunnel for the `lucid.tv` zone, or use the Cloudflare API to manually add DNS records in that zone. None have been executed. The 530 persists as a deliberate boundary marker — the perimeter ends where the zone ends.
## The port map as perimeter constitution
The tunnel configuration is not documentation. It is the machine-readable constitution of the fleet’s physical layer. Every service occupies a port on the host. The port map names every service, its port, protocol, and health endpoint:
| Service | Port | Protocol | Health Endpoint |
|———|——|———-|—————–|
| Hermes Gateway | 7077 | HTTP | /healthz |
| ZeroClaw | 7078 | HTTP | /status |
| OpenFang | 7076 | HTTP | /health |
| Lucid Hive WordPress | 8070 | HTTP | /wp-admin |
| Studio nginx | 8076 | HTTP | /health |
| ChromaDB | 4002 | HTTP | /api/v2/heartbeat |
The critical property is sovereignty: every port is on localhost or the Tailscale network. No service is exposed to the public internet without an explicit tunnel. The port map is the internal nervous system; the gateway tunnel is the only nerve that reaches outside.
When a new service joins the stack, it gets a port entry before it gets a container. The port map is the first thing you check when something breaks, and the last thing you change.
## Cloudflare zone hardening: DNSSEC, SPF, DMARC
The perimeter extends beyond the tunnel. The Cloudflare zone configuration hardens the DNS layer:
– **DNSSEC** for name resolution integrity — the chain of trust from root to `lucidhive.com` is cryptographically signed.
– **SPF/DMARC** for email authentication — the zone publishes `v=spf1 include:_spf.cloudflare.com ~all` and `v=DMARC1; p=quarantine; rua=mailto:[email protected]`.
– **Tunnel rules** enforce the narrow gate principle at the network level: only authenticated traffic reaches the Council infrastructure.
The customer’s solid-key (see S7.2) travels through the tunnel, gets validated at the MCP layer, and provisions scoped access — all before any tool call executes. The customer never connects directly to the infrastructure. They connect to Cloudflare. Cloudflare connects to OpenFang. OpenFang validates the solid-key. The chain is auditable at every link.
## The 530 as diagnostic signal
The 530 error earned its place in the wiki as a concept (`http-530-error`) because it serves as the core diagnostic signal for tunnel misconfiguration. Its key characteristics:
– Cloudflare-specific — not a standard HTTP status code
– Origin unreachable — flags DNS resolution or connection error between Cloudflare edge and origin
– Zone-scoped — fixing one zone does not clear other zones when no tunnel exists there
– Uniform failure mode — every subdomain behind a broken tunnel returns 530
– Diagnostic signal — points to tunnel misconfiguration: a `cloudflared tunnel route dns` entry pointing to an origin IP the tunnel/host cannot reach
Applications in the fleet:
– Detecting broken Docker/cloudflared tunnels by observing 530 on all subdomains behind the affected tunnel
– Verifying tunnel routes: when 530 appears, check `cloudflared tunnel route dns` to confirm the route exists and is correctly registered
– Isolating root cause: if 530 persists on `lucid.tv` after fixing `lucidhive.com`, the issue is a missing tunnel for that zone
– Integrating 530 into service monitoring as an endpoint-health signal for proxied services
## Why this matters for sovereign infrastructure
Most perimeter designs assume cloud-native abstractions: load balancers, managed TLS, external DNS. Sovereign infrastructure assumes none of that. The tunnel runs on the same machine as the services. The zone configuration is version-controlled. The 530 audit is a permanent record in the vault.
This constraint is a design advantage. It forces the perimeter to be lightweight (no sidecar proxies, no external dependencies), the monitoring to be self-contained (the 530 is visible at the edge), and the recovery to be local (restart `cloudflared`, update config, re-route DNS). The fleet can diagnose its own perimeter while air-gapped — which is the only time sovereign infrastructure is actually sovereign.
The port map is the key. When you know every port, every service, every health endpoint, and every tunnel route, you can build a perimeter that fits in a YAML file and a DNS zone. The complexity of modern perimeter stacks comes from the assumption that you do not know your own topology. The port map and the tunnel config remove that assumption.
## Grounding
This article is S7.04 in the Security & Sovereignty series (S7). It is grounded in the operational record `cloudflare-tunnel-audit-20260801`, the concept `http-530-error`, and the entities `cloudflare-tunnel`, `cloudflared`, `docker-desktop`, `tailscale`, `lucidhive-com`, and `lucid-tv`. North-star principles: P5 (Informatics outranks physics — threat models start from data flow), P8 (The esoteric is engineering — treat mystical systems as technical diagrams), P21 (Darkness is the canvas; neon is the voice — cyber-gothic is the operating system’s theme).
Category: AI & Automation. Tags: 15 template tags + cloudflare, tunnel, zone-management, http-530, perimeter-security, edge-routing.
GEMS gate: passed — public-only content; cluster card carries no gems flag; north-star principles stated without derivations.
