The custom domain is reaching Railway and the route is no longer returning a gateway error from an external request.

Current external result for https://auth.spacearena.net/artearena:

HTTP/2 200
server: railway-edge
x-railway-edge: railway/asia-southeast1-eqsg3a
content-type: text/html

The DNS path also points to Railway:

auth.spacearena.net CNAME ztf0epr1.up.railway.app
auth.spacearena.net A 66.33.22.178

That means the basic Railway edge to service route is working now. If the auth app is still unusable in the browser, split the next check into frontend route loading versus backend/API calls:

1. Open DevTools Network on the failing browser session and reload /artearena.
2. Check whether the document request itself is still 200.
3. If the document is 200, look for failing JS chunk, API, websocket, OAuth callback, or cookie/session requests after the page loads.
4. If an API request is failing, test that exact API URL directly with curl -i and compare the response headers and status with the browser result.
5. If the document request sometimes flips back to 502, capture the failing x-railway-request-id, timestamp, region, and deployment id before redeploying. That is the packet support needs to trace the edge request.
6. If only the app's client-side auth flow fails while the document stays 200, focus on app config: callback URL, allowed origin, cookie domain, secure cookie settings, reverse proxy trust, and any base path handling for /artearena.

For the Railway-side settings, keep the basics tight:

• Public Networking port must match the process listener.
• The app should bind to 0.0.0.0 or ::, not localhost.
• There should be one active custom-domain binding for auth.spacearena.net.
• Do not keep redeploying while collecting a failure sample, because each deploy replaces the request context support would need.

At the moment, this does not look like a generic "Railway is not routing packets to the container" failure. The public route is returning the app shell through Railway edge. The next useful evidence is the first failing subrequest from the browser, or a fresh x-railway-request-id from a reproduced 502 on the document request.

Thanks for checking. The important detail is that the issue is still reproducible from the browser despite the edge now occasionally returning HTTP 200 for the document request.

At this point the failure appears intermittent or subrequest-specific rather than a pure DNS issue.

Observations:

• The custom domain resolves correctly to Railway.
• The edge sometimes serves the app shell successfully.
• The deployment logs remain clean.
• The application process itself does not report crashes or startup failures.
• The auth flow remains unusable from the browser.

This suggests one of the following:

• intermittent edge → container forwarding failures,
• path/base-path routing problems under /artearena,
• websocket/session upgrade failures,
• reverse proxy trust/header issues,
• or failing backend/API subrequests behind the initial HTML response.

The key issue is that the application becomes unusable even when the document request itself returns 200.

check:

1. whether Railway edge is consistently forwarding requests for the /artearena base path,
2. whether there are upstream timeout/reset events between edge and container,
3. whether websocket or keepalive upgrades are failing,
4. and whether any 502s are being generated internally before reaching the application logs.

One additional observation: redeploying changes behavior temporarily but does not permanently resolve the issue, which may indicate an edge cache, routing-state, or upstream connection issue rather than an application startup failure.