CORS Error When Accessing Deployed App Via Fly.io
Hey @kapa.ai - I carefully followed the guide to deploy my OpenSaas app to Fly.io using a custom domain, but when I navigate to my app in the browser via https://xyz.app, I get the following console errors:
Access to XMLHttpRequest at 'https://xyz-server.fly.dev/auth/me' from origin 'https://xyz.app' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.Understand this error
xyz-server.fly.dev/auth/me:1 Failed to load resource: net::ERR_FAILED
Can you provide me a troubleshooting checklist, including any deployment steps I might have missed that could cause this
14 Replies
Hi @SL8. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
----------------------
Certainly! Here’s a focused troubleshooting checklist for resolving CORS errors when accessing your Wasp (OpenSaas) app deployed on Fly.io with a custom domain:
---
1. Ensure WASP_WEB_CLIENT_URL is Set Correctly
- The backend server must know the exact URL of your frontend (custom domain) to set CORS headers properly.
- Set the environment variable on your server app:
This step is required for CORS to work with your custom domain. If you miss this, the server won’t allow requests from your frontend domain, resulting in the error you’re seeing.
Using a Custom Domain For Your App --- 2. Confirm DNS Records Are Set Up - Make sure you’ve added the correct A and AAAA records to your DNS provider as instructed by Fly.io. If DNS is not set up, your domain may not resolve or may not be recognized as a valid origin by the backend.
Using a Custom Domain For Your App --- 3. Verify CORS Middleware Configuration - By default, Wasp configures CORS using the value of
Improve our CORS + API story --- 6. Confirm Client is Pointing to the Correct Server - Your frontend should make requests to the correct backend URL (e.g.,
Using a Custom Domain For Your App --- 2. Confirm DNS Records Are Set Up - Make sure you’ve added the correct A and AAAA records to your DNS provider as instructed by Fly.io. If DNS is not set up, your domain may not resolve or may not be recognized as a valid origin by the backend.
Using a Custom Domain For Your App --- 3. Verify CORS Middleware Configuration - By default, Wasp configures CORS using the value of
WASP_WEB_CLIENT_URL
(or config.allowedCORSOrigins
). If you have customized middleware, ensure you haven’t accidentally overridden or removed the CORS middleware.
- You can customize or check the CORS origins in your serverMiddlewareFn
:
Customize Global Middleware
---
4. Redeploy After Changing Environment Variables
- If you update environment variables (like WASP_WEB_CLIENT_URL
), you must redeploy your server for changes to take effect.
---
5. Check for Preflight (OPTIONS) Handling
- CORS errors can occur if the server does not respond correctly to preflight (OPTIONS) requests. Wasp’s default CORS middleware should handle this, but if you have custom API endpoints or middleware, ensure OPTIONS requests are not blocked or ignored.Improve our CORS + API story --- 6. Confirm Client is Pointing to the Correct Server - Your frontend should make requests to the correct backend URL (e.g.,
<https://xyz-server.fly.dev
>). If you use environment variables like REACT_APP_API_URL
, ensure they are set to the deployed server’s URL.
---
7. Restart and Clear Cache
- After making changes, restart both client and server deployments. Clear your browser cache to avoid cached CORS headers.
---
8. Debugging
- Check server logs for CORS-related errors:
- Use browser dev tools to inspect the network request and response headers for Access-Control-Allow-Origin
.
---
If you follow these steps and the error persists, double-check that your custom domain is correctly set everywhere and that no custom middleware is interfering with CORS. If you’re using custom API endpoints, ensure they also have CORS enabled as described in the docs.
Let me know if you need more specific help with any of these steps!
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @SL8, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist:
Perhaps try again in 15mins?Re: your first suggestion - "Ensure WASP_WEB_CLIENT_URL is Set Correctly" - How does this work if I have configured CORS to allow my website to be assissible from https://www.xyz.app as well?
Wohooo @SL8, you just became a Waspeteer level 2!
@kapa.ai Re: your first suggestion - "Ensure WASP_WEB_CLIENT_URL is Set Correctly" - How does this work if I have configured CORS to allow my website to be assissible from https://www.xyz.app/ as well?
Let me check the knowledge base for you again. One moment! :books:
----------------------
If you want your Wasp app to be accessible from both https://xyz.app and https://www.xyz.app, you need to ensure that both origins are allowed by your CORS configuration.
By default, Wasp uses the value of the
- You still need to set
WASP_WEB_CLIENT_URL
environment variable to set the allowed CORS origin. This means only the exact value you set (e.g., <https://xyz.app
>) will be allowed. If you want to allow multiple origins (such as both <https://xyz.app
> and <https://www.xyz.app
>), you need to customize the CORS middleware in your Wasp app.
You can do this by providing a custom middlewareConfigFn
in your main.wasp
file and specifying all allowed origins in your server setup code. Here’s how you can do it:
main.wasp
src/serverSetup.js
In this example, config.frontendUrl
will be set from your WASP_WEB_CLIENT_URL
(e.g., <https://xyz.app
>), and you explicitly add <https://www.xyz.app
> as an additional allowed origin. This way, both domains will be accepted by your backend for CORS requests Customize Global Middleware.
Important:- You still need to set
WASP_WEB_CLIENT_URL
to one of your domains (e.g., <https://xyz.app
>) for other parts of the app that rely on this variable.
- If you want to allow even more domains, simply add them to the origin
array.
The knowledge sources do not mention a built-in way to set multiple allowed origins via environment variables alone; customizing the middleware as shown above is the recommended approach according to the documentation.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @SL8, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist:
Perhaps try again in 15mins?@kapa.ai One thing to note: I see this error when I deploy with fly - "WARNING The app is not listening on the expected address and will not be reachable by fly-proxy.
You can fix this by configuring your app to listen on the following addresses:
- 0.0.0.0:8080"
Do you think it's related?
Let me check the knowledge base for you again. One moment! :books:
----------------------
Yes, this warning is very likely related to your issue.
When deploying to Fly.io, your Wasp server must listen on the address
0.0.0.0:8080
for Fly's proxy to route traffic correctly. If your app is not listening on this address and port, Fly.io will not be able to forward requests to your server, which can result in failed requests and CORS errors in the browser, since the server is effectively unreachable.
How to fix:
You need to ensure that your server is configured to listen on port 8080
and on all interfaces (0.0.0.0
). In Wasp, you do this by setting the PORT
environment variable to 8080
when deploying:
This is explicitly mentioned in the manual deployment guide for Fly.io:
Next, let's add a few more environment variables:Fly.io Manual Deployment Guide After setting this, redeploy your server. This should resolve the warning and may also fix your CORS issue, since the server will now be reachable by Fly's proxy and able to respond to requests from your frontend. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @SL8, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist: Perhaps try again in 15mins?
@kapa.ai I manually set the server PORT env variable to 8080, which resolved the "WARNING The app is not listening on the expected address and will not be reachable by fly-proxy" error in my server logs. I also manually set the server env variable WASP_WEB_CLIENT_URL=https://xyz.app, but I am still getting the error. What other suggestions do you have?
Let me check the knowledge base for you again. One moment! :books:
----------------------
Given that you have already set
Customize Global Middleware --- 2. Redeploy After Changing Environment Variables - After updating environment variables, make sure you redeploy your server so the changes take effect. This is required for the new CORS settings to be applied Environment Variables. --- 3. Check for Custom Middleware or API Endpoints - If you have custom API endpoints, ensure that CORS is enabled for them. APIs in Wasp do not use the default middleware unless you explicitly configure it. You may need to use
PORT=8080
and WASP_WEB_CLIENT_URL=<https://xyz.app
> on your server, but are still experiencing CORS errors, here are the next steps and checks based on the official Wasp documentation and community discussions:
---
1. Double-Check WASP_WEB_CLIENT_URL Value
- Ensure there are no typos and that the value matches exactly the origin from which your frontend is served (including protocol, and whether or not you use www
). If your frontend is accessible from both <https://xyz.app
> and <https://www.xyz.app
,> you need to allow both origins in your CORS configuration. By default, Wasp only allows the value set in WASP_WEB_CLIENT_URL
. To allow multiple origins, you must customize the CORS middleware as described here:
Customize Global Middleware --- 2. Redeploy After Changing Environment Variables - After updating environment variables, make sure you redeploy your server so the changes take effect. This is required for the new CORS settings to be applied Environment Variables. --- 3. Check for Custom Middleware or API Endpoints - If you have custom API endpoints, ensure that CORS is enabled for them. APIs in Wasp do not use the default middleware unless you explicitly configure it. You may need to use
apiNamespace
and a middlewareConfigFn
to ensure CORS is applied to your custom endpoints Making Sure CORS Works.
---
4. Inspect Server Logs and Network Requests
- Use flyctl logs
to check for any errors or warnings related to CORS or incoming requests.
- In your browser, inspect the network requests and check the response headers. The response from your server should include an Access-Control-Allow-Origin
header matching your frontend's origin.
---
5. Confirm Client Requests Target the Correct Server
- Ensure your frontend is making requests to the correct backend URL (e.g., <https://xyz-server.fly.dev
>). If you have environment variables or configuration in your frontend, verify they are set correctly.
---
6. Preflight (OPTIONS) Requests
- If your requests use methods other than GET/POST or custom headers, browsers will send a preflight OPTIONS request. Make sure your server responds to these correctly. Wasp's default CORS middleware should handle this, but custom middleware or endpoints may require additional configuration Making Sure CORS Works.
---
If you have checked all of the above and the issue persists, please provide more details about your middleware configuration or any custom API endpoints you have. The knowledge sources do not mention other common causes for persistent CORS errors beyond these points.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @SL8, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist:
Perhaps try again in 15mins?Hey @SL8, tag us if you end up needing human help here.
For now, I'll say that cors errors often aren't really cors errors
Explanation: https://discord.com/channels/686873244791210014/1374012707099115550/1374505937548873838
So that might be something worth looking into
@Carlos Another one for you if it gets reactivated
@Filip @Carlos Thanks for the follow up! Also, that info about CORS errors is very helpful, thank you. I ended up nuking my Fly machines and starting over, which surprisingly worked to get things running on the non-www custom domain. I did have to update the server PORT var to 8080 manually though. Now everything is working as expected on http://xyz.app, but I'm getting a similar error when I try https://www.xyz.app:
Access to XMLHttpRequest at 'https://xyz.app/auth/me' from origin 'https://www.xyz.app' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
GET https://xyz.app/auth/me net::ERR_FAILED 200 (OK)
I followed the instructions here (https://wasp.sh/docs/deployment/deployment-methods/cli) and added the www CNAME record to my DNS settings.
Below is my serverSettings.ts file:
I ended up giving up for now because tbh I don't really care if the www subdomain is working for the time being 🙂It’s not advisable to respond to both www and the root domain, in any case. Better to set up a permanent redirect rule for requests to www instead
@genyus appreciate the tip!
If you're still wanting to debug this, we can try to do it together! Shelving this otherwise