A custom domain in our staging environment has been stuck at verified: false for several

hours, even though both required DNS records are correctly configured and propagated, and the

TLS certificate was issued successfully. The edge returns 404 with x-railway-fallback: true,

so no route is ever created for the hostname.

The same project has an identical setup in production that works, which makes this a clean

A/B comparison — same project, same edge, same target port, same DNS provider, same record

shape. The only field that differs is verified.

Affected resource

| | |

| ------------- | ------------------------------------------------------------ |

| Project | blueberry-analyzer-v2 — a9ef73ac-3cd0-4f83-8f59-33f692ab9267 |

| Service | analyzer-web — 07a0904c-d7c3-4fbc-99e7-784c0bfab0a1 |

| Environment | homologacao — a3696d6e-ee18-4467-9ef3-a24454a673ed |

| Custom domain | analise-hml.blueberry.app.br — d634bc3b-aace-4680-894b-07f52897e80f |

| Edge | edge-500b32d4e9aaa4d3ff91d6ebb54285cd |

DNS state (verified from authoritative nameservers, not a cache)

The zone blueberry.app.br is hosted at Registro.br (b.sec.dns.br, c.sec.dns.br).

$ dig +short CNAME analise-hml.blueberry.app.br
frfm2khe.up.railway.app.

$ dig +short TXT _railway-verify.analise-hml.blueberry.app.br @b.sec.dns.br
"railway-verify=bf5afcf135ece22284c6943e86a5c4f978e189fe1b76b85ea366909c9010231e"

$ dig +short TXT _railway-verify.analise-hml.blueberry.app.br @8.8.8.8
"railway-verify=bf5afcf135ece22284c6943e86a5c4f978e189fe1b76b85ea366909c9010231e"

The TXT value matches status.verificationToken returned by the API exactly, and the host

matches status.verificationDnsHost (_railway-verify.analise-hml).

Response headers from the broken domain

HTTP/2 404
server: railway-hikari
x-railway-fallback: true
x-railway-edge: mia1
content-type: application/json

For contrast, the production domain on the same edge returns HTTP/2 200 with

x-powered-by: Next.js — the request reaches the app.

What we already tried (none changed verified)

1. customDomainIssueCertificate — returns true. This did fix a separate problem: the

   certificate was previously stuck at CERTIFICATE_STATUS_TYPE_VALIDATING_OWNERSHIP and moved

   to VALID after this call. It had no effect on verified.

2. customDomainUpdate with targetPort 8080 → null → 3000 → 8080. The 404 and

   x-railway-fallback are identical at every value, so the target port is not the cause. The

   port is now back to 8080, matching production.

3. Service redeploy (analyzer-web, homologacao) — completed SUCCESS, no change.

4. Waiting — the TXT record has been propagated for over 2 hours with no transition.

Questions

1. Is there a documented or internal way to re-trigger ownership verification for an existing

   custom domain? The public GraphQL API exposes only customDomainCreate, customDomainDelete,

   customDomainUpdate and customDomainIssueCertificate — none of which re-run verification.

2. Why would verified stay false when the verification TXT record matches

   verificationToken exactly and is propagated globally?

3. Is syncStatus: ACTIVE with verified: false an expected combination? It reads as

   contradictory from the outside — the domain appears synced to an edge that has no route for it.

We would rather not delete and recreate the domain: that mints a new verification token and

possibly a new CNAME target, forcing a second round of DNS changes at Registro.br — and if the

verifier is what is failing, the recreated domain would likely land in the same state.