The issue isn’t DNS or the service itself — the Railway edge router hasn’t completed domain ownership verification. The *.up.railway.app CNAME targets used for custom domains only start routing once verification finishes and the edge binding is created. Because the certificate is stuck in VALIDATING_OWNERSHIP, the edge router returns Application not found. Removing the custom domain, waiting for the edge record to clear, and re-adding it (which generates a new CNAME target) forces Railway to recreate the edge binding and allows the certificate to be issued.

I already removed and re-added the custom domain on March 4, 2026, so this is not the original stale binding.

I also checked the live Railway API again today, March 8, 2026, and for this domain Railway is only requiring one DNS record: CNAME infer.chrisshaw.me -> v3l6449i.up.railway.app with currentValue matching requiredValue, proxy off, and syncStatus=ACTIVE.

The issue is still that curl -sk https://v3l6449i.up.railway.app/health returns {"status":"error","code":404,"message":"Application not found"} while curl -sk https://codex-gateway-production-835e.up.railway.app/health returns {"status":"ok","nodeId":"railway"}.

Since Railway is not asking for any TXT record here and the CNAME target itself is not routing, could someone from Railway inspect the edge binding / certificate issuance directly for customDomainID=a68b8469-64fc-4cef-b952-42edad990f97 on service 287e54ee-63b5-420e-a7dc-1330ee5bbfdd?

Based on the diagnostics you posted, DNS and Cloudflare are not the problem. The key signal is this:

• codex-gateway-production-835e.up.railway.app → works
• v3l6449i.up.railway.app → "Application not found"

That error comes from the Railway edge router, not your app. It means the edge cannot map the request to a running service instance.

A few things to check that commonly cause this exact situation:

1⃣ Port detection mismatch

Even if targetPort: 4100 is set, Railway will still route to the port your container actually binds to.

Verify your app is binding like this:

0.0.0.0:4100

Not:

localhost:4100

If it binds only to localhost, the edge cannot route traffic to it.

Example fix (Node):

app.listen(4100, "0.0.0.0")

2️⃣ Confirm the service exposes the correct port

Inside the container logs you should see something like:

Listening on 0.0.0.0:4100

If Railway detects a different port (e.g., 3000), the edge mapping will break.

3⃣ Force Railway to rebuild the edge binding

Sometimes the edge binding gets stuck even when syncStatus=ACTIVE.

The fastest fix is:

1. Remove the custom domain
2. Deploy a new service revision
3. Wait ~2–3 minutes
4. Add the custom domain again

This forces Railway to regenerate:

• edge binding
• certificate order
• routing rule

4⃣ Test routing directly

Run:

curl -I https://v3l6449i.up.railway.app

If it still returns:

404 Application not found

then the edge has not attached the CNAME target to the deployment yet.

5⃣ Check Railway environment isolation

If the domain was added under production, but the deployment is attached to another environment, the router will return "Application not found" even though the service works.

Make sure the custom domain is attached to the same environment as:

codex-gateway-production-835e.up.railway.app

TL;DR

Your DNS is correct. The issue is almost certainly:

• container binding to localhost instead of 0.0.0.0

• Railway detecting a different port than targetPort

• edge binding stuck on an old deployment revision

Fixing the port binding or forcing a fresh edge binding usually resolves the "Application not found" routing error.

It looks like this domain is no longer configured on Railway and is being served elsewhere. If you still need help setting it up on Railway, feel free to reopen this thread.