Cloudflare DNS Helper

Use this guide when the Route Catalog shows a direct hostname or verified E2EE hostname in configure state. The goal is to publish stable public hostnames without guessing which wildcard records and server flags NFLTR expects.

What You Are Configuring

Catalog Entry	Purpose	Key Setting
Direct Hostname	Stable public route like `agent.example.com` that maps to the relay's normal HTTP path.	`http.share_domain` + `http.direct_agent_subdomains=true`
Verified E2EE Hostname	Blind-relay hostname like `agent.secure.example.com` for TLS passthrough / verified mode.	`e2ee.tls_passthrough.base_domain`

Both patterns rely on wildcard DNS. Cloudflare only needs to point the wildcard name at the relay. NFLTR handles routing based on the requested hostname after that.

Prerequisites

Your NFLTR server is already reachable on a public hostname or IP.
You control the target zone in Cloudflare.
The relay is serving HTTPS, or you intentionally want plain HTTP for a private lab.
You know which base domain you want to dedicate to normal public routes and which one you want to dedicate to verified E2EE routes.

Recommended layout

Use one wildcard for public relay-visible routes such as *.apps.example.com, and a separate wildcard for verified E2EE routes such as *.secure.example.com. That keeps the trust model obvious for operators and end users.

Direct Hostname Setup

Create a wildcard DNS record in Cloudflare. Example: *.apps.example.com → your relay load balancer hostname.
Set the server flag http.share_domain=apps.example.com.
Enable direct agent subdomains with http.direct_agent_subdomains=true.
Restart the server or reload the config.

# example server flags
--http.share_domain=apps.example.com
--http.direct_agent_subdomains=true

After that, an agent with ID orders-api appears in the Route Catalog as https://orders-api.apps.example.com/.

Verified E2EE Hostname Setup

Create a second wildcard DNS record. Example: *.secure.example.com → the same relay endpoint.
Set e2ee.tls_passthrough.base_domain=secure.example.com on the server.
Run the agent in verified mode, for example nfltr http --e2ee or nfltr http --mode verified.
Open the Route Catalog or the Proof panel to confirm the verified hostname and proof bundle are available.

# example server flag
--e2ee.tls_passthrough.base_domain=secure.example.com

# example agent command
nfltr http 3000 --mode verified

Important

The verified hostname only appears when the agent is actually running in blind-relay mode. If the tunnel is inspectable, the hostname stays in available state because the trust model is different.

Cloudflare Proxy Mode

In most deployments you should keep the record proxied so Cloudflare continues to front the relay. If you need raw end-to-end certificate visibility for debugging, temporarily switch the record to DNS-only while you validate the tunnel chain.

Cloudflare mode	Use when	Tradeoff
Proxied	Normal production routing and DDoS protection.	Cloudflare sits in front of the relay, so certificate debugging is one hop further removed.
DNS only	Low-level TLS debugging or lab setups.	You lose Cloudflare edge protections and caching for that record.

How to Read the Route Catalog

ready means the URL can be used immediately.
available means the server is prepared for that route pattern, but the current agent mode does not expose it yet.
configure means the missing step is server or DNS configuration, not an agent bug.
TLS state tells you whether the catalog entry is a normal edge TLS route, a transparency-logged blind-relay route, or still in ACME provisioning / fingerprint-pinning territory.

Troubleshooting

Symptom	Likely cause	Fix
Direct Hostname stays in configure	`http.share_domain` is empty or `http.direct_agent_subdomains` is still false.	Set both flags and restart the server.
Verified hostname never appears	The agent is not running in verified mode or the E2EE base domain is unset.	Use `nfltr http --mode verified` and configure `e2ee.tls_passthrough.base_domain`.
Hostname resolves but traffic fails	Wildcard DNS points to the wrong relay endpoint or TLS termination path.	Verify the wildcard record target and confirm the relay is listening on the expected port.
Traffic Inspector stays empty	The tunnel is working exactly as verified mode intends.	Restart the tunnel with `--mode inspectable` when you need relay-visible HTTP capture.