Symptom: every request to the public URL returns 502 with headers:

server: railway-edge

x-railway-edge: railway/us-west2

x-railway-fallback: true

x-railway-request-id:

body: {"status":"error","code":502,"message":"Application failed to respond"}

This has persisted across multiple deploys over several months. Current active deploy (commit 4923db0) shows ACTIVE in the dashboard with healthcheck passing.

The service itself is healthy:

/health returns 200 from uvicorn when probed via Tailscale Funnel (https://vantage-prod.tail7b72ef.ts.net/health)

/health/commit returns the current git SHA

Tailscale Funnel forwards to localhost:${PORT:-8080} and reaches uvicorn fine

Dashboard shows deploy as ACTIVE, healthchecks passing

Setup:

railway.toml: healthcheckPath = "/health", healthcheckTimeout = 120

Domain vantagelist-production.up.railway.app mapped to Port 8000 in Networking

start.sh runs uvicorn serve:app --host 0.0.0.0 --port "${PORT:-8000}"

$PORT is set by Railway (not visible in Variables tab) to a value apparently ≠ 8000

What we tested today:

Pinning uvicorn to literal --port 8000 → failure mode changed from 40ms fast-fallback 502 to 15s slow 502 (signal: edge IS now forwarding, but the TCP connect to the container fails).

Adding --host '::' (IPv6) on uvicorn → broke healthcheck, deploy went FAILED.

Both changes since reverted; service is back to original state.

Two questions:

Why is vantagelist-production.up.railway.app stuck at x-railway-fallback=true 502 when the dashboard shows the deploy as healthy and active?

Does Railway's edge router connect to the container via IPv6? If so, what's the recommended pattern for a Python/uvicorn app to accept IPv6 traffic without breaking the IPv4 healthcheck path?

Recent debugging commits: e9a2e69, 0c2b2f3 (since reverted to 4923db0).