12 days ago
Hi,
My service (Next.js 16, deployed via Nixpacks) is returning a generic Internal Server Error (plain text, no HTML) on every route behind my custom domain, including fully static files generated at build time (/robots.txt, /manifest.webmanifest). This has been happening since today.
What I've already ruled out:
Not a code issue — I rolled back to a commit that was working fine earlier today, and it fails identically. Two different commits, same 500 on everything.
Not a build failure — both deployments show "Success" in the Deployments tab.
Not a crash loop — the deploy logs show a single, clean startup with no restarts:
Starting Container
▲ Next.js 16.2.6
- Local: http://localhost:3000
- Network: http://10.x.x.x:3000
✓ Ready in 79ms
After this, no further log lines ever appear — not even for the healthcheck configured at healthcheckPath: "/" in my railway.toml, even though I've made dozens of requests over several minutes.
Not the database — my Turso database is reported as active, and I regenerated and replaced TURSO_AUTH_TOKEN — no change in behavior.
Not the custom domain config — onrejoue.fr shows as verified/active (green check) in Settings → Networking, and the configured target port (3000) matches what the app actually listens on.
Symptom from outside:
$ curl -sv https://onrejoue.fr/robots.txt
< HTTP/2 500
< content-type: text/plain; charset=UTF-8
< date: ...
Internal Server Error
No other response headers at all (no x-powered-by, no Next.js-specific headers), which makes me think this 500 is being generated by the edge/proxy layer rather than by my Next.js app itself — since the app's own logs show zero incoming requests after startup.
Given the same symptom persists across two different commits/deployments, this looks like a routing issue between the edge and my container, or some other platform-side state, rather than something in my application.
Could you check the routing/edge logs for this service and domain? Happy to provide the project/service ID and deployment IDs if useful.
Thanks!
3 Replies
12 days ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • 12 days ago
12 days ago
IIRC your NextJS service should be listening on 0.0.0.0 instead of localhost.
0x5b62656e5d
IIRC your NextJS service should be listening on `0.0.0.0` instead of `localhost`.
12 days ago
Thanks a lot but nothing changed.
12 days ago
Follow-up on my earlier message about onrejoue.fr returning 500 on every route.
Update: I tried removing and re-adding the custom domain (onrejoue.fr) on the service, hoping it would refresh a stale binding. This didn't fix the 500 — but it revealed something important.
The DNS A record for onrejoue.fr has never changed (still 151.101.2.15, confirmed via dig before, during, and after the incident). So before the outage, my apex domain must have been routed to my service via some internal Railway mapping (Host header → service) that did not require a CNAME at the DNS level — since a literal CNAME at my domain's root is impossible (I have existing MX + TXT/SPF records there, and OVH, my DNS host, correctly refuses to let me add a CNAME at the apex alongside them, per standard DNS rules).
After deleting and re-adding the domain, the new attachment flow now asks me to add:
A TXT record at _railway-verify.onrejoue.fr (added successfully, no conflict)
A CNAME at the root of onrejoue.fr pointing to f4v6c5ds.up.railway.app (impossible — OVH rejects it because of the existing MX/TXT records at that same name)
So it looks like the new self-service domain-attachment flow only supports CNAME-based verification, while my domain was apparently working before through a different mechanism that didn't hit this constraint.
Could you either:
Manually restore whatever internal binding/verification method onrejoue.fr had before (so the apex keeps working without a CNAME), or
Confirm there's no way around the CNAME requirement for apex domains with existing MX records, so I know to migrate to a www-based setup instead.
For reference, the service's Railway-provided domain (claude-projets-production.up.railway.app) works perfectly (200, normal Next.js response headers) — confirming the service itself is healthy and the issue is purely the custom domain attachment.
Thanks for your help!