Thanks for the pointers. Already tried removing/re-adding the domain once (deleted and recreated propgear.io as a custom domain) — same result. Here's the clean comparison, each domain tested with its own matching Origin header this time:

propgear.io (custom domain) — fails

curl -sD - -o /dev/null -H "Origin: https://propgear.io" https://propgear.io/assets/vendor-react-CzQz7p-h.js

HTTP/1.1 500 Internal Server Error
x-railway-request-id: -_OWfo6-SBKxEkZf0ubPiw
x-railway-edge: mia1
x-hikari-trace: mia1.0twb

propgear.up.railway.app (Railway-generated domain, same service) — works

curl -sD - -o /dev/null -H "Origin: https://propgear.up.railway.app" https://propgear.up.railway.app/assets/vendor-react-CzQz7p-h.js

HTTP/1.1 200 OK
x-railway-request-id: 90-TLCpSS9CDagEqmrpb1w
x-railway-edge: mia1
x-hikari-trace: mia1.0twb

inmersion.altura-propiedades.com (a different custom domain on the same account, works fine) — control

curl -sD - -o /dev/null -H "Origin: https://inmersion.altura-propiedades.com" https://inmersion.altura-propiedades.com/assets/vendor-react-CzQz7p-h.js

HTTP/1.1 200 OK
x-railway-request-id: HkS7ZJVzTEKVPgY3DcO5xA
x-railway-edge: mia1
x-hikari-trace: mia1.nv6z

Notable: propgear.io and propgear.up.railway.app share the same x-hikari-trace (mia1.0twb) since they're the same container/service — but only propgear.io returns the 500. That points at the edge routing config for that specific custom domain, not the service itself. The 500 body is a generic Hikari error page (content-security-policy: default-src 'none', plain "Internal Server Error" HTML) — it never reaches my app (my server never logs the request).

For staff: request ID -_OWfo6-SBKxEkZf0ubPiw (trace mia1.0twb) is the failing one to inspect.

Sometimes, irregular DNS resolution at the apex can cause edge proxies to misinterpret host headers and origin evaluations.

Ensure you are using Railway's recommended A / AAAA records (or an ALIAS/ANAME record if your registrar supports it) rather than trying to force a CNAME at the apex (CNAME flattening).

c

Looks like you might have accidentally pasted a local file path/command instead of your reply!

Tested that theory too — rules it out. I moved off the apex entirely: added www.propgear.io as a fresh custom domain (deleted the apex one), pointed a real CNAME www -> lanjjpgi.up.railway.app (no ALIAS/flattening involved, verified via dig/public resolvers that it resolves as a plain CNAME chain). Domain shows Verified: yes, Certificate status: VALID. Same bug, identical signature:

curl -sD - -o /dev/null -H "Origin: https://www.propgear.io" https://www.propgear.io/assets/vendor-react-CzQz7p-h.js

HTTP/1.1 500 Internal Server Error
x-railway-request-id: ACptDWaATeKl3vC0JH0Vcg
x-railway-edge: mia1
x-hikari-trace: mia1.0twb

So it's not apex CNAME flattening, and it's not a stale route (tried delete+wait 15min+recreate too, same result). Three different DNS configurations, all pointing at the same service, all failing identically only when an Origin header is present — while propgear.up.railway.app (Railway-generated domain, same service) and inmersion.altura-propiedades.com (a different custom domain, same account) both work fine with the same header. At this point I think this really needs someone from Railway staff to look at the Hikari route entry itself for this domain — happy to send any request ID they need.

no is that

#1/#2/#4 (Hostinger/Cloudflare proxy, forced HTTPS, WAF injecting/altering the request): There's no proxy in the path at all. The domain's nameservers are Hostinger's own DNS-only nameservers (horizon.dns-parking.com / orbit.dns-parking.com) — not Cloudflare, no orange-cloud/CDN toggle exists for this setup. The CNAME resolves directly to Railway's own hostname (lanjjpgi.up.railway.app), TLS is terminated by Railway itself (cert shows CERTIFICATE_STATUS_TYPE_VALID, issued through Railway's own automation), and every response — including the 500 — comes back with Server: railway-hikari directly. There's no intermediate hop to strip/duplicate headers.

#3 (casing/whitespace in the domain): Checked via railway domain status www.propgear.io --json — stored as "domain": "www.propgear.io", clean lowercase, no trailing whitespace.

Subdomain test: Already did exactly this before your message — added www.propgear.io as a fresh custom domain, pure CNAME www -> lanjjpgi.up.railway.app, no apex involved at all. Verified, cert valid. Same 500 with the exact same signature (x-hikari-trace: mia1.0twb).

So at this point: no proxy, no encoding issue, no apex/flattening — it's a clean same-service, same-account, same-header comparison where only this one custom domain 500s on the Railway edge itself. I think it really is something specific to this domain's Hikari route entry that only Railway staff can see/fix from their side.

i cant

propgear.io returns a 404 because you have not actually added it to any Railway service at this time.