Yep, if you set that app.fly.dev as a CNAME record, they will pull from that using https.
My issue was getting random 525s (when behind Cloudflare, which I wanted to do to get its geo-ip header). But it did work 99% of the time.
Not sure from @Loonb if they are consistently getting a 525 or randomly, like me. I solved it by handing TLS in-app but given all the changes to the proxy/routing since then, that may not be needed as I’ve not tried reverting back.
I’ve set up my app to handle SSL and it all works, but I’m still getting random 525 errors that last 5 - 10 minutes.
I’m clutching at straws trying to figure out what I’m missing to stop these errors.
This might be a n00b question, but if I’ve added the origin certs to my app, do I still need the fly created SSL certificate and _acme-challenge DNS record? Could having those in place be causing my random 525 errors?
Our ciphers are more limited than Cloudflare’s. This is because we’re using a different TLS library that only supports TLSv1.2 and TLSv1.3 with modern ciphers. Even with a shorter list of ciphers, we still support the vast majority of clients. Clients that don’t support any of these are considered insecure.
(I would certainly respect that offering & maintaining more deployment styles would increase your support costs, but I have to think this kind of ‘operational parity’ would make it easier to conquest existing e.g. Heroku customers. If that’s a goal…)
“Unsupported” for us just means we can’t do much to help. Cloud Flare’s error pages seem more designed to deflect blame than to help people debug these types of problems. We need a lot more information than they provide to prevent these errors. We wouldn’t do anything to intentionally disable it, though.
You can do what you’re asking though!. fly ips allocate-v4 --region <region> will route the way you want. You should be able to point anything you want to those.
One other thought about Cloudflare 525s: that code can be a bit misleading. It may not actually be caused by an SSL issue. I recently got a random 525 error page, after not touching anything, and noticed a vm in the app had been recently replaced by Fly (maybe capacity, region-load, hardware etc - have to allow for those kind of things). And so Cloudflare would have been briefly unable to connect. It reported that as a 525. Not e.g a 500 or some other 50x code.
CF has an enormous set of products and features which would take a lot of resources to develop. I would expect Fly to focus on being a rock solid PaaS first, before going after more of these ‘higher level’ products. (You’re definitely right that Fly’s position as an SSL-terminating reverse proxy makes it possible, tho…)
We get enough demand for WAF that we’ll ultimately end up doing it. But you’re right, we have no interest in building another CDN. Our big bet is that people don’t really need CDNs if you give them enough flexibility about where their app runs.
It might still make sense for some apps to run behind third party DDoS protection and similar features. At least for the near future.
I’m getting some 522 errors (not 525) when using my Fly app with a CF Worker.
It’s very weird.
The Worker serves an MP3 file from a subdomain of my main domain media.domain.com/audio.mp3. When directly calling the URL, like say in the browser address, it works fine. But if an HTML in another subdomain like app.domain.com calls the MP3, I get the 522 error.
The app is hosted on Fly and proxied by CF using A and AAAA records.
If instead of using my subdomain for the Worker I use the one provided by CF like something.something.workers.dev it works fine.
Since both media.domain.com and app.domain.com are on the same domain, it shouldn’t be a referrer policy issue. Right?