Cloudflare Update Notes
A public, identifier-free checklist for adding a hostname to an existing Cloudflare Tunnel without republishing live account material.
These notes intentionally omit real account numbers, tunnel IDs, zone IDs, and domains. Use example.com, <TUNNEL_ID>, and <ZONE_ID> as stand-ins.
Overview
When a tunnel is already running, a new hostname usually needs three coordinated changes: a DNS CNAME in Cloudflare, an ingress entry in the local tunnel config, and a clean restart or reload of the tunnel process.
Working Assumptions
Step 1: Create DNS
Add a proxied CNAME for the new subdomain that points at the tunnel endpoint. Prefer the Cloudflare API when available; otherwise create the record in the dashboard.
POST /zones/<ZONE_ID>/dns_records
{
"type": "CNAME",
"name": "app",
"content": "<TUNNEL_ID>.cfargotunnel.com",
"proxied": true,
"ttl": 1
}
Step 2: Update Ingress
Edit the tunnel config and insert the new hostname before the catch-all rule. Keep indentation exact.
tunnel: <TUNNEL_ID>
ingress:
- hostname: app.example.com
- service: http_status:404
Step 3: Restart And Verify
- Restart or reload the tunnel process so the new ingress rule is active.
- Confirm the process registers healthy tunnel connections.
- Request
https://app.example.comand confirm a sensible HTTP response and Cloudflare headers.
Troubleshooting Themes
- DNS lag — wait briefly, then re-check that the CNAME target matches
<TUNNEL_ID>.cfargotunnel.com. - Bad gateway responses — confirm the upstream behind the hostname is reachable and that the ingress hostname matches the DNS name.
- Config ignored — verify YAML structure, save the file, and restart the tunnel process.
- Tunnel won't start — re-check tunnel ID, config syntax, and that the process was restarted after the last edit.
Operating Reminder
Always keep the catch-all http_status:404 rule last. Keep private identifiers out of public notes — this page uses only example.com, <TUNNEL_ID>, and <ZONE_ID>.