a month ago
Project: nazdrow (44da4b59-9822-47cd-be88-1e3adc8496c3)
Environment: production (57da0af8-1f1e-4b5a-9719-5cad0f12408c)
Service: nazdrow-web (3a72708a-87e5-43aa-9b03-aef283579824)
Custom domain: www.nazdrow.pl (id dae2783f-ebe3-4aa7-a16e-1fc9860f211d)
PROBLEM: every request to www.nazdrow.pl returns 404 with x-railway-fallback: true (railway-hikari, edge waw1), because status.verified stays false — even though everything else is green per your own API:
- dnsRecords: DNS_RECORD_STATUS_PROPAGATED (CNAME www.nazdrow.pl -> edmlgjv6.up.railway.app)
- certificateStatus: VALID, certificateStatusDetailed: COMPLETE (issued 2026-07-16 via customDomainIssueCertificate; TLS handshake on the domain already serves the correct cert)
- syncStatus: ACTIVE, edgeId edge-6705e5cc5ae5e82ae931d2b1f900f08f
- verificationToken matches the published TXT byte-for-byte: _railway-verify.www.nazdrow.pl = "railway-verify=3961b96f18f92267955dddc3d1ab8877ce3c6dc87a748054b46baa9f56887c8f", visible on the authoritative nameservers (Google Cloud DNS / Squarespace) and public resolvers for 12+ hours
- no CAA records, DNSSEC valid, no AAAA/conflicting records
- the service itself is healthy: nazdrow-web-production-50c0.up.railway.app returns 200
ALREADY TRIED (no effect on verified): repeated customDomain status re-checks over several hours; customDomainIssueCertificate (worked — cert went VALID); full redeploy (SUCCESS); customDomainUpdate touch. There is no API mutation to re-trigger ownership verification, so we are stuck.
Possibly relevant: CT logs show Let's Encrypt certs for nazdrow.pl / www.nazdrow.pl issued 2026-05-14 — if a stale prior registration of this domain exists somewhere on Railway, it may be blocking ownership verification.
ASK: please re-run / force ownership verification on your side. BOTH domains show status.verified=false despite byte-for-byte matching TXT records that have been publicly visible for 10+ hours (verified against your authoritative expectations: www expects railway-verify=3961b96f... at _railway-verify.www, apex expects railway-verify=7ba6026c... at _railway-verify — both match exactly, single TXT answer each, no quoting issues, DNSSEC valid). This rules out every cause from the recently solved threads with this symptom (missing TXT, wrong host, proxied records). Domain ids: www dae2783f-ebe3-4aa7-a16e-1fc9860f211d, apex 349ee106-4bba-4269-838e-ea167993a931. Please do NOT delete/re-create the domains.
Pinned Solution
a month ago
I'd try removing and readding the domain. Railway doesn't usually manually re-run verfication.
The LE rate limit is 5 certs per week per hostname. Unless you're repeatedly readding the domain, you'll be fine.
4 Replies
a month ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • about 1 month ago
a month ago
It may take up to a few hours (maybe even a day) for Railway to validate the DNS and issue certificates. If one isn't issued by then, try removing the domain from Railway and add it back after ~10-15 mins. Update DNS records as necessary.
a month ago
Update after 17+ hours: still stuck. status.verified remains false on BOTH domains, while for www.nazdrow.pl everything else is green: certificateStatus VALID (cert issued 2026-07-16 and correctly served on TLS handshake), DNS PROPAGATED, syncStatus ACTIVE, and both TXT records still match status.verificationToken byte-for-byte. So this is not cert issuance latency — ownership verification never completes despite correct records for ~24 hours.
Removing/re-adding the domains would rotate the CNAME target and verification token (our DNS TTL is 4h) and risks Let's Encrypt duplicate-cert limits, so a server-side fix is strongly preferred. Could someone from the team re-run ownership verification for domain ids dae2783f-ebe3-4aa7-a16e-1fc9860f211d (www.nazdrow.pl) and 349ee106-4bba-4269-838e-ea167993a931 (nazdrow.pl)?
Possibly relevant: CT logs show Let's Encrypt certs for these exact hostnames issued 2026-05-14 — if a stale/ghost registration from that period exists somewhere on Railway, it may be what blocks verification (and re-adding on our side would not fix that).
a month ago
I'd try removing and readding the domain. Railway doesn't usually manually re-run verfication.
The LE rate limit is 5 certs per week per hostname. Unless you're repeatedly readding the domain, you'll be fine.
a month ago
Resolved. Deleted both stuck domains, waited 15 min, re-added www.nazdrow.pl — status.verified flipped to true within ~2 minutes on the exact same DNS records, cert VALID, site serving 200. So the old domain record was indeed in an unrecoverable verification state server-side. Thanks!
Status changed to Solved vanya2003best • about 1 month ago