2 months ago
I'm encountering a persistent CORS issue with my Django backend deployed on Railway. Specifically, preflight OPTIONS requests sent from my React frontend are receiving a 404 Not Found response, and these requests appear to be handled by railway-edge without reaching my application.
Here are the details:
Frontend URL:https://energetic-peace-production.up.railway.app
Backend Service Name/URL (where the API endpoint is hosted):elysium-backend-production.up.railway.app
Specific API Endpoint: /api/check-availability/ (so the full URL is https://elysium-backend-production.up.railway.app/api/check-availability/)
When my frontend attempts a cross-origin POST request to this endpoint, the preceding OPTIONS (preflight) request fails.
Observations from Browser Developer Tools (for the OPTIONS request):
Request URL:https://elysium-backend-production.up.railway.app/api/check-availability/
Request Method: OPTIONS
Status Code: 404 Not Found
Relevant Response Headers:
server: railway-edge
x-railway-edge: railway/us-east4 (or similar, based on my region)
x-railway-fallback: true
content-type: application/json (for the 404 response)
Backend Application Logs (Django/Gunicorn):
There are no entries whatsoever in my Django application's runtime logs for these OPTIONS requests. This strongly suggests they are not reaching my Gunicorn server or Django application. My logs do show other requests (e.g., if I try to access an endpoint directly via GET in the browser).
Troubleshooting Done on My End:
I have configured django-cors-headers in my Django settings.py.
CORS_ALLOWED_ORIGINS is correctly set to ['https://energetic-peace-production.up.railway.app'].
CORS_ALLOW_CREDENTIALS = True.
corsheaders.middleware.CorsMiddleware is placed at the top of my MIDDLEWARE list.
CORS_ALLOW_METHODS includes 'OPTIONS'.
CORS_ALLOW_HEADERS is set to allow common headers (and I've also tested with ['*']).
My Question/Request for the Railway Team:
Can you please investigate how OPTIONS requests are handled and routed by the railway-edge network for my backend service (elysium-backend-production.up.railway.app)?
This is my first Railway project. Is there any specific platform-level configuration required on Railway to ensure OPTIONS requests for specific paths are correctly forwarded to the application server?
What does the x-railway-fallback: true header signify in the context of a 404 response from the edge for an OPTIONS request?
Are there any known scenarios where OPTIONS requests might be blocked or mishandled by the edge layer before reaching the user's application?
Please let me know if you need any further information or logs from my end.
Thanks for your help!
Best regards,
Mike
9 Replies
2 months ago
Hello,
You are getting a 404 because there is no running application for that domain, aka Application not found.
Given that you do not own the project where that domain is in use, you will need to contact the workspace owner and ask them to upgrade to a paid plan so that they can bring the service back online.
Best,
Brody
brody
Hello,You are getting a 404 because there is no running application for that domain, aka Application not found.Given that you do not own the project where that domain is in use, you will need to contact the workspace owner and ask them to upgrade to a paid plan so that they can bring the service back online.Best,Brody
2 months ago
It's just me - I'm the workspace owner. I've set everything up for this workspace. If it helps, the project ID I'm working on is fffc8d26-853b-430d-80a9-d48a13d82a87
2 months ago
Here's a screenshot of my workspace users just to confirm that I'm the only one on it
Attachments
2 months ago
For the backend domain you gave me, you are not the owner, you are simply a member of someone else's project.
The owner will need to maintain a paid plan to bring the backend back online.
brody
For the backend domain you gave me, you are not the owner, you are simply a member of someone else's project.The owner will need to maintain a paid plan to bring the backend back online.
2 months ago
I'm a contributor to a different project, but the one I'm working on now is functional other than the issue I brought up. This is the front end: https://energetic-peace-production.up.railway.app/signup
I've attached screenshots of what I see when I open the project in Railway. I'm confused how I'm not being seen as the owner.
Attachments
2 months ago
The domain you provided me in your root message as your backend domain is not the same domain listed on either of those services, you are looking at the wrong project.
The project that contains the service with the backend domain you provided, is owned by someone else, you are a project member, but you are not the owner.
2 months ago
Got it. It looks like I entered that incorrectly from the beginning! I just updated it.
I've updated the backend hostname to the correct: elysium-qhp-production.up.railway.app
and redeployed both the backend and the front end and I still get this error in the browser when trying to get the app to function:
Access to XMLHttpRequest at 'https://elysium-backend-production.up.railway.app/api/check-availability/' from origin 'https://energetic-peace-production.up.railway.app' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. Understand this error
index-C2aIshI9.js:51
POST https://elysium-backend-production.up.railway.app/api/check-availability/ net::ERR_FAILED
This is what I have in my deploy logs for by backend service now:
→ Using PostgreSQL configuration
DEBUG: Raw RAILWAY_FRONTEND_HOSTNAME: 'energetic-peace-production.up.railway.app'
DEBUG: Cleaned RAILWAY_FRONTEND_HOSTNAME: 'energetic-peace-production.up.railway.app'
DEBUG: Raw RAILWAY_BACKEND_HOSTNAME: 'https://elysium-qhp-production.up.railway.app/';
DEBUG: Cleaned RAILWAY_BACKEND_HOSTNAME: 'https://elysium-qhp-production.up.railway.app/';
INFO: Production - Added frontend origin to CORS_ALLOWED_ORIGINS and CSRF_TRUSTED_ORIGINS: https://energetic-peace-production.up.railway.app
INFO: Final CORS_ALLOWED_ORIGINS: ['https://energetic-peace-production.up.railway.app';]
INFO: Final CSRF_TRUSTED_ORIGINS: ['https://energetic-peace-production.up.railway.app';]
Is there anywhere that might be grabbing that incorrect backend URL? I've updated the service variables everywhere I know about in the Railway interface and don't have it hardcoded anywhere in my setup.
2 months ago
Gotcha, thank you for clarifying.
The service behind that domain is online and is accessible over the public network.
Since the team can only provide support for the Railway platform or product itself, I will let the community involve themselves in this thread to help you as this is an application level or configuration issue on your side.
Best,
Brody
24 days ago
Why don't you try return a manual http response on that /api/check-availability/ with CORS headers you already know for debugging? Share what you see to help