24 days ago
Hi everyone,
We are seeing a custom-domain-specific cache/routing issue on our production Next.js/Payload app.
Issue:
We made some updates, and cached users are having issue on mobile. On some returning mobile browsers/devices that previously visited the site, loads the homepage, then refreshes/reloads during hydration/loading, and eventually browser shows errors like:
- iOS Safari: “A problem repeatedly occurred on website.com(placeholder on purpose)”
- Chrome mobile: “This page can’t be opened / restart Chrome or device”
- Earlier we also saw stale old asset/domain errors in logs.
However, the same affected device can open the Railway generated domain(blablabla.up.railway.app) without issues.
That suggests the app/build itself is healthy, but the custom domain may have stale edge/cache/domain routing or stale assets associated with it.
Current checks:
Both domains return HTTP 200 and appear to serve the same deployment/build from curl:
custom domain:
HTTP/2 200
server: railway-edge
x-nextjs-cache: HIT
x-nextjs-prerender: 1
etag: "s39vs51fu31eg8t"
content-length: 2355455
blablabla.up.railway.app:
HTTP/2 200
server: railway-edge
x-nextjs-cache: HIT
x-nextjs-prerender: 1
etag: "s39vs51fu31eg8t"
content-length: 2355455
We do not want to remove/re-add the custom domain because we are worried about downtime or certificate/DNS disruption.
Can you please help about:
- Purge/refresh any Railway edge/cache/custom-domain routing?
- Let us know if there is a safe zero-downtime way to refresh the custom domain association?
Context:
This is a Next.js 16 + Payload CMS app. We found that Railway’s persisted .next build cache can cause route hangs unless we run a clean build, so our build command currently includes:
rm -rf .next || true; DATABASE_URI= pnpm run build
We are trying to avoid client-wide Clear-Site-Data headers because it made the site very slow for users.
Probably some JS chunk is causing it but when i try to use rm -rf.next as build command, it did not solve issue for me.
1 Replies
24 days ago
This thread has been marked as public for community involvement, as it does not contain any sensitive or personal information. Any further activity in this thread will be visible to everyone.
Status changed to Open Railway • 24 days ago
24 days ago
From the symptoms, I’m not convinced this is a Railway edge-cache or custom-domain routing issue yet.
A few things stand out:
- Both the custom domain and the Railway-generated domain appear to be serving the same deployment (same ETag, content length, Next.js cache headers, etc.).
- The issue seems to affect returning mobile users who have visited before.
- The Railway domain works on the same device where the custom domain fails.
That pattern is often caused by origin-scoped browser state (service workers, cached JS chunks, IndexedDB/local storage state, or stale Next.js assets) rather than the platform serving different content.
A few checks I’d run:
- Compare build manifests on both domains:
curl https://your-domain.com/_next/build-manifest.json
curl https://your-app.up.railway.app/_next/build-manifest.json
- Compare the _next/static/... asset references in the HTML served by each domain and verify they are identical.
- Check whether a service worker is registered on the custom domain (/sw.js, /service-worker.js, Workbox, next-pwa, etc.). Since service workers are scoped per origin, a stale worker could explain why the custom domain fails while the Railway domain works.
- Remote-inspect an affected device and look for:
- ChunkLoadError
- Failed dynamic imports
- Hydration errors
- “Loading chunk … failed”
- Unexpected token < in JS assets
One other thing I noticed: the homepage HTML is ~2.3 MB. On mobile Safari especially, large pages combined with hydration issues can sometimes trigger repeated reload/crash behavior.
If the build manifest, chunk hashes, and asset references are identical across both domains, I’d investigate service-worker/browser cache state before assuming a Railway edge-cache problem.