Deployment behind Cloudfront

I have an app on Fly that I want to put behind Cloudfront distribution (for domain fronting purposes).
It doesn’t seem to work, issuing a request to should go to, but instead it’s issuing a 301 and redirects back to creating an endless loop.

Any suggestions?

Thanks in advance!

My first step to debug that would be to see where the 301 redirect is being generated

Is it being generated by Cloudfront before it even gets to your app (which would point to an issue with its origin group/path/routing which you would fix in the AWS console) or is the 301 being generated by your Fly app (for whatever reason, like it thinks it’s non-https or some such). In which case you would need to look at your app’s code and its routing to see how requests to /health are handled.

Two possible ways to check would be:

  1. Run fly logs and then call the page, and see if you see your request appear (in which case it must have hit Fly, and the app is where you need to debug it)
  2. Look in a browser, in the network tab of developer tools (F12) and see the response headers to the request. Do those response headers have any fly-x things in? Like a fly-region header, or a via header (from Again the presence of those would show the request is hitting the app, and that’s where your focus should be.

Update: or … the issue may be that Cloudfront is passing the hostname of to Fly’s proxy. And of course Fly doesn’t know what to do with that. And so it could be returning a 301, as Fly’s proxy/edge would not know which app to send that request on to. Since under this set up you have a proxy in front of a proxy. Anyway, see what results from 1/2 above first. That was another random thought I had. If that is the cause you would need to make sure that Cloudfront is sending the hostname to Fly. As the hostname is the only information Fly has to know which app the request should be handled by. Which would involve doing this: Configure CloudFront to forward the Host header to the origin

thanks @greg , apparently for me the issue was that cloudfront expected the target domain to respond on http and not https.
setting force_https = false in fly.toml fixed the problem