1. Confirm the service is actually running — a stopped service can't respond
2. Re-generate the domain: in Settings → Networking → Public Networking, delete the domain and generate it again; verify the domain's target port matches your PORT env var
3. Rule out local caching/network: incognito window, clear browser cache, dig your domain, try a different network (one case turned out to be the user's own VPN)
4. Wait — certificate issuance and DNS propagation can take up to 72h
5. If none of that works, @ Railway staff in the thread

That 403 page isn't a DNS or SSL error — it's Railway's edge fallback response, thrown when a request hits an edge node whose routing table has no entry (or a stale one) for that hostname. It doesn't care whether the domain is Railway-provided or custom; the edge treats every hostname the same way once traffic reaches it, which is why you got the "point your DNS at a .up.railway.app CNAME" message even though your DNS was never the problem.

Here's the part that explains "no deployment change" causing it: even a no-diff redeploy still creates a brand new deployment, and Railway's edge has to re-point your domain's route to that new deployment's origin as part of the rollout. That re-association isn't instant everywhere — Railway's edge is a globally distributed fleet of nodes, and the route update has to propagate to all of them. If that propagation stalls or partially fails on a subset of nodes, whoever gets load-balanced to one of those stale nodes sees the 403, while everyone else routes fine — which lines up exactly with "some people" seeing it instead of everyone.

What to do:

Check if it's still happening. If it already cleared up on its own, this was just a slow/partial route propagation on that deploy and nothing's actually broken now.

If it's still happening, trigger another redeploy. This forces a fresh route install for your domain, which is the same fix Railway staff have applied manually in other cases where a domain's edge route got orphaned after a deploy.

Check status.railway.com for that time window. Railway posts edge/routing incidents there (they've had region-specific proxy routing issues before), so it's worth confirming whether this was a known blip rather than something isolated to your service.

If a redeploy doesn't clear it, this needs Railway to manually re-trigger the route install for your service on their backend — it's the same category of fix as cases where edge traffic routes were never (re)installed for a hostname despite everything else (DNS, cert, deployment health) being fine. Open a thread on Central Station with your project ID, service ID, the exact deploy timestamp, and note that only a subset of visitors were affected — that detail matters for them to find which edge nodes had the stale entry.