There are no issues with our edge proxy at the moment. Any error you encounter would be coming from your application.

Refer to https://docs.railway.com/reference/errors/application-failed-to-respond.

I am writing to follow up on my previous request. Despite extensive debugging, my service continues to fail with a 502 Bad Gateway error, but only for requests to the /plan/ path. Requests to the root path (/) work correctly.

The evidence now strongly indicates this is a platform-level issue, as requests to the failing path never reach my application's logs.

Service Details:

• Project Name: zealous-truth

• Service Name: planner-api

• Public Domain: planner-api-production.up.railway.app

How to Reproduce the Error:

The issue can be reproduced instantly with the following curl command, which sends a perfectly formed pre-flight request:

Bash

curl -i -X OPTIONS https://planner-api-production.up.railway.app/plan/ -H "Origin: https://www.freetour.pro" -H "Access-Control-Request-Method: POST" -H "Access-Control-Request-Headers: X-API-Key"

Result: The command consistently fails with a 502 Bad Gateway from railway-edge after a ~10-second timeout. The application container does not log this request.

Debugging Steps Already Taken:

We have methodically ruled out all application-level causes:

1. CORS Configuration: We configured the FastAPI CORSMiddleware to be completely open for debugging (allow_origins=["*"], allow_methods=["*"], allow_headers=["*"]). The issue persisted.

2. Dependency Bugs: To rule out known bugs in underlying libraries, we pinned the exact versions known to be stable and have fixes for CORS-related hangs. The requirements.txt was updated with:

   • fastapi==0.111.0

   • starlette==0.37.2

   • httptools==0.6.1

   • uvicorn==0.29.0 The issue persisted even with these specific versions.

3. Minimal Application: We deployed a minimal "hello world" FastAPI application with only the / and /plan/ routes. The / route worked, but the /plan/ route failed in the exact same way.

Conclusion:

Since a perfectly formed curl request fails to reach an application running known-stable dependencies, the problem cannot be with the application code itself. The evidence points to an issue within the Railway platform's routing or proxy layer that is specific to the /plan/ path for this service.

Could you please escalate this for an investigation into the platform-level routing for my service?

Thank you for your time and help.

Railway doesn't currently expose fine-grained control over the edge proxy config (like NGINX or Envoy settings), so if a specific path like /plan/ is failing before it hits your app, only Railway engineers can really debug that.

Since your FastAPI app works fine on /, but /plan/ fails with a 502 before even reaching your app, it's almost certainly a routing issue on Railway's end and not something in your code. You've already ruled out all the app level stuffs.

As a temporary workaround, you could just try renaming the /plan/ route to something like /planner/ or /plan-v1/ to see if it might help dodge whatever's breaking on their edge.

This is not an issue on our side, this is an application level issue.

Hi Railway Team, This is an urgent escalation regarding our planner-api service. The issue has significantly worsened, and our application is now **completely inaccessible from the internet** via the Railway Edge. **Current Critical Status:** * Our FastAPI container successfully logs "Application startup complete." and appears active within the Railway dashboard. * Internal curl tests (from inside the container) confirm the application is fully functional and responsive to requests (e.g., OPTIONS http://127.0.0.1:8080/plan/ returns 204 No Content). * **Railway's own logs confirm INFO: Uvicorn running on http://0.0.0.0:8080,** which means the application is correctly listening on all network interfaces. **However, ALL external requests are now failing with a 502 Bad Gateway:** 1. **External OPTIONS /plan/ and OPTIONS /planner/ requests:** These requests continue to return 502 Bad Gateway from railway-edge with X-Railway-Fallback: true. Our application logs show no record of these attempts. * Latest Request-IDs for OPTIONS (from previous tests): dmyLjxBFReelO6kt0-QtfA (for /plan/), zy4BEIxcSjm6s2Pc0-QtfA (for /planner/). 2. **External GET / request is also failing:** Previously, GET / was working. Now, even a simple GET / request to our public domain planner-api-production.up.railway.app returns a 502 Bad Gateway. This confirms a complete loss of external connectivity to our application. **Curl Command for GET /:** ```bash curl -i https://planner-api-production.up.railway.app/ ``` **Full Output for GET / (from last test):** ``` HTTP/1.1 502 Bad Gateway Content-Length: 109 Content-Type: application/json Server: railway-edge X-Railway-Edge: railway/europe-west4-drams3a X-Railway-Fallback: true X-Railway-Request-Id: aQIp9U2fSEeZcpLXYqdHTg Date: Mon, 07 Jul 2025 09:35:12 GMT {"status":"error","code":502,"message":"Application failed to respond","request_id":"aQIp9U2fSEeZcpLXYqdHTg"} ``` *Timestamp: Mon, 07 Jul 2025 12:35:12 EEST* *Request ID: aQIp9U2fSEeZcpLXYqdHTg* **Conclusion:** Given that the container is healthy, our application is explicitly confirmed by Railway's own logs to be listening on 0.0.0.0:8080, and it responds perfectly to internal requests, the consistent 502 Bad Gateway for all external traffic with X-Railway-Fallback: true **unequivocally indicates that the Railway Edge proxy is unable to establish a connection with our healthy container.** This is a critical network or routing issue on Railway's infrastructure side, completely independent of our application code or configuration. Our service is experiencing a full outage. We kindly request immediate escalation to your highest priority networking/infrastructure engineering team for urgent investigation and resolution. Project ID: e687ae11-fdf2-4e4e-bdc8-ce6d5bada296 Service ID: ba53c260-e29c-4b5a-b0f0-d4cf7932d5d8 Public Domain: planner-api-production.up.railway.app **Attached:** * Full curl -v log for GET / (from last test). * Full curl -v logs for OPTIONS /plan/ and OPTIONS /planner/ (from previous tests). * Screenshot/text of railway logs showing "Application startup complete." and "Uvicorn running on http://0.0.0.0:8080". Thank you for your immediate attention.

Hello Railway Support Team,

I'm experiencing an issue with a service in my project that continuously restarts despite deploying and starting up successfully.

• Project ID:d687ae11-fdf2-4e4e-bdd8-ce6d3aada296

• Service Name:planner-api

• Environment ID:1097f8a1-a5d4-4132-ada8-d9fc4c09e976

Observed Behavior:

1. The service starts successfully, and the logs show Application startup complete and Uvicorn running.

2. It immediately passes the health check (GET / returns a 200 OK status).

3. Approximately 5-10 seconds later, the platform stops the container (the log shows Stopping Container).

4. This cycle repeats endlessly.

What I've already checked:

• Metrics: There are no memory or CPU spikes. Resource usage is minimal.

• Logs: The deploy logs are clean and show no errors or exceptions.

• Code: The application is not crashing. It's being gracefully shut down by the platform.

Could you please check the internal platform logs to see why a stop signal is being sent to my healthy container?

Thank you for your help.

The container was shut down because you redeployed it, in doing so we sent a shutdown signal to the old container.

Your target port is set incorrectly.

https://docs.railway.com/reference/errors/application-failed-to-respond#target-port-set-to-the-incorrect-value

Your docs suck. Add Video based example helps for the users to understand. The Issue of @vanguard is quite basic and is caused by his developers who don't know how to debug. Its not on railway side. Still railway docs suck.

Thank you for the feedback!