This specific symptom containers booting perfectly healthy and listening on port 80, but showing absolutely zero Caddy access logs alongside a "service unavailable" error points directly to a disconnect between Railway's edge proxy and your containers.

Since this is affecting both api and api-v2 simultaneously in the ams region, here is exactly what is causing it and how to fix it:

1. Public Networking Port Misalignment (Most Likely)

Railway allows you to map specific domains to specific ports. Even if your container is internally listening on port 80, Railway’s public domain configuration for your service might be defaulting or expecting traffic on a different port (like 3000 or 8080). If the proxy maps to the wrong port, traffic hits a brick wall before reaching Caddy.

The Fix: Go to your service Settings -> Networking -> Public Networking. Click the Edit (pencil icon) on your domains and explicitly set the port to 80 to match your app. This applies instantly without needing a full redeploy.

1. Host Binding Issue (0.0.0.0 vs 127.0.0.1)

If your Caddy configuration or underlying app is binding to 127.0.0.1:80 (localhost), the container will report as healthy internally, but Railway's ingress network will be entirely blocked from routing traffic into it.

The Fix: Double-check your Caddyfile or startup script. Your server must listen on 0.0.0.0:80 so that Railway's internal private overlay network can forward external HTTP requests to the container.

1. Regional Private Mesh Desync (ams region)

Because this is hitting two separate services (api and api-v2) at the same time in the Amsterdam region, there is a high probability that Railway’s internal routing mesh (which connects their edge proxies to your specific underlying private network nodes) got hosed during a rolling platform update.

The Fix: Force a complete routing rebuild. Go to your variables, add a harmless dummy variable (like REBUILD_NET=1), and deploy. This forces Railway to provision your containers on potentially fresh host nodes and regenerates the internal network paths.

If your domain port mapping is definitely correct and you're binding to 0.0.0.0, this is an upstream infrastructure glitch on Railway's edge perimeters. Since you already have your Project and Deployment IDs handy, drop them in their Discord support or open a ticket so an engineer can manually kick the routing table for your project.