We can remove the domain for you, but we need to verify the ownership first.

Please add a _railway.verify TXT record for tastelab.recipes with the value k7xm3r9w.

Once done, please let us know and then we will verify, after verification we will remove the domain for you.

Done! YOu can check

Those domains are not in our system. Since they are still pointing to a Railway service, that would be something on your end within Cloudflare. We would not be able to assist with that, unfortunately.

Thanks for checking. To be clear about what I've verified on our end, since you mentioned this would be something within our Cloudflare setup:

• Our DNS is clean — tastelab.recipes and www.tastelab.recipes are CNAMEs pointing directly to our own Cloudflare Tunnel, not to Railway.
• No Cloudflare Worker Routes reference Railway or this domain.
• No Origin Rules, Redirect Rules, or Page Rules override the origin for this hostname.
• Our actual origin server (which the tunnel routes to) returns clean responses with no Railway headers when hit directly.

Despite all of that, requests to https://tastelab.recipes are still coming back with X-Railway-Edge and X-Railway-Request-Id response headers. Those are headers your edge adds — they can't be originating from our zone or our origin server, since neither references Railway anywhere.

This suggests there's still an active Custom Hostname / TLS binding for tastelab.recipes on Railway's Cloudflare-for-SaaS layer that wasn't fully removed — separate from whatever shows in the project's Domains tab (which I understand is now empty on your side). Could someone check the Cloudflare-for-SaaS custom hostname / edge certificate records directly for tastelab.recipes, rather than just the service-level domain list? That binding is the only thing left that could explain traffic still routing to your infrastructure.

Happy to provide fresh curl -v output showing the headers if that helps your investigation.

Your diagnosis is correct, and it's confirmed by Cloudflare's own docs. This can only be fixed by Railway (or Cloudflare support) — nothing in your zone can override it.

Why "not in our system" and your symptoms are both true: Railway's service-level domain list and the custom_hostname objects in Railway's Cloudflare-for-SaaS zone are separate stores. Deleting the domain record doesn't always cascade the Cloudflare API delete — especially through an orphan → re-adopt → delete path like yours. The domain is gone from Railway's DB but still active in their Cloudflare SaaS zone.

Why you can't route around it: Cloudflare's hostname priority puts an active SaaS-provider custom hostname above the DNS record in the domain owner's own zone for exact matches. And the Cloudflare for SaaS churn docs say explicitly: "if the churned customer changes the DNS target to point away from your SaaS zone but you have not removed it, the custom hostname will continue to route to your service." Your proxied CNAME to the tunnel loses that priority contest every time.

Hard proof you can attach: check which TLS cert the edge presents:

echo | openssl s_client -connect tastelab.recipes:443 -servername tastelab.recipes 2>/dev/null \

| openssl x509 -noout -issuer -ext subjectAltName

Your own zone's Universal SSL cert would cover tastelab.recipes + *.tastelab.recipes. A cert covering only the specific hostname is the per-custom-hostname cert from Railway's SaaS zone — proof the binding is still active there.

For Railway staff: please don't check the service/project domain tables — query your Cloudflare SaaS zone directly:

GET /zones/{railway_saas_zone_id}/custom_hostnames?hostname=tastelab.recipes

GET /zones/{railway_saas_zone_id}/custom_hostnames?hostname=www.tastelab.recipes

and DELETE the two entries that come back.

If Railway won't act: Cloudflare's docs direct domain owners to have their account's Super Administrator contact Cloudflare Support to dispute/remove a custom hostname claim on a domain you can prove you own. Cloudflare can force-deactivate it from their side.

(Also worth re-checking the TXT record from earlier in this thread: Railway's edge verification normally lives at _railway-verify.tastelab.recipes with value railway-verify= — not _railway.verify — so that verification step may have silently failed.)