The app name is azezment region iad with a cert on *.azezment.com.
I have another app called azezment-dev in dfw with it’s own cert on dev.azezment.com
Here are some examples of issues:
Users are having connectivity issues, Connection closed errors on browser as they redirect from Google Gmail oAuth2 workflow.
Some users are reporting browser errors: “This site can’t provide a secure connection www.azezment.com sent an invalid response. ERR_SSL_PROTOCOL_ERROR.
I’ve gotten the same error, infrequently, but it goes away.
summary: Intermittent, it works for me most of the time, but not others real-time in trouble-shooting. All in NY Metropolital area (any casting to ewr) problem fixes itself while trouble-shooting.
app: single machine , single region app azezment originally deployed in ewr, but I moved it to iad on 12/5/25.
deployed new certificate “*.azezment.com” 2 weeks old.
put header in app:
curl -I ``https://azezment.com`` | grep -i “fly-prefer-region” % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 31 0 0 0 0 0 0 --:–:-- --:–:-- --:–:-- 0 fly-prefer-region: iad
Hi again… I don’t know the certificates side, but the fly-prefer-region header is being used incorrectly there. It’s the clients that would need to set that, given that it’s a request header.
Anyway, it’s not clear to me that you really need to override anything in terms of regions. I tried a request to azezment.com from a location in the greater NYC area, and it did connect to an iad Machine of yours.
Perhaps you’re misunderstanding the -ewr suffix on the fly-request-id? That only shows where the Fly.io infrastucture received the request initially, before forwarding it on to your actual Machine, and you don’t really have control over that first connection.
The way to see which server region the ultimately responding Machine is in is via the flyio-debug: doit header on the client side. Look in the sr field of the returned JSON blob.
I just got another person calling me to report an outage from their network ( Fios ), and it’s the same issue. They happen to live in Port Washington, Long Island NY.
Notice the ERR_SSL_PROTOCOL_ERROR , which might be a certificate issue.
Can you please help ? or have someone in the proxy/certs area look into it please ?
I see “no hits” coming to the application when the ERR_SSL_PROTOCOL_ERROR happens, so it can’t be the application or my setup. Or if it is, I’m at a dead end and can only hope fly . io can fix it on their side and point me in the right direction .
Hm… Is it strictly necessary to have the dev.azezment.com domain? I’m suspicious of the overlap between that and the *.azezment.com wildcard, but I don’t know for sure that’s a problem…
(The second, failing screenshot shows www.azezment.com, which would fall under the wildcard, whereas the working azezment.com does not, if I remember correctly.)
I don’t work at Fly.io, but, in my opinion, if you have lots of users relying on your service, then you probably want at least the basic Support Plan.
Is it possible to try a curl -v from an IP that does not work (i.e. seeing this SSL protocol error)? Usually if this is intermittent, it is not a certificate issue but rather our edge proxies not finding your app somehow. This could be due to a variety of reasons, and curling with verbose output could help here.
The AAAA record on www.azezment.com (NOT the one without www.) resolves to a different IPv6 address that doesn’t seem to correspond to any app here. The correct IPv6 for your app is 2a09:8280:1::b7:abf7:0 and your bare domain azezment.com resolves correctly:
Depending on whether you have IPv6 connectivity or whether IPv6 is preferred on each of them, you may end up getting resolved to that wrong IPv6 and your website would not work in that case.
FIXED.
I removed some extra apps I had created before.
not sure why the proxy got confused, but this fixed it.
~ 13:39 % fly app destroy fly-builder-white-snow-433
Destroying an app is not reversible.
? Destroy app fly-builder-white-snow-433? Yes
Destroyed app fly-builder-white-snow-433
~ 13:39 % fly app destroy azezment-damp-grass-2453
Destroying an app is not reversible.
? Destroy app azezment-damp-grass-2453? Yes
Destroyed app azezment-damp-grass-2453
======= here’s my issue before I found the FIX ================
Thanks,
Good catch.
I corrected it on DNS and verified it. But still not working, Proxy doesn’t seem to see it, cause I don’t even get any traffic on the machine.
I tried the visit the app at https://azezment.fly.dev/ , which should work, but it doesn’t either. Doesn’t make sense.
