I wanted to remove IPv4 for one of my hobby apps and just use CNAME pointing at [myapp].fly.dev for my custom domain when I discovered that I cannot access fly.dev and my subdomain there. Here’s what I get from curl:
❯ curl -v https://typerust.fly.dev
* Host typerust.fly.dev:443 was resolved.
* IPv6: (none)
* IPv4: 213.188.210.27
* Trying 213.188.210.27:443...
* Connected to typerust.fly.dev (213.188.210.27) port 443
* ALPN: curl offers h2,http/1.1
* (304) (OUT), TLS handshake, Client hello (1):
* CAfile: /etc/ssl/cert.pem
* CApath: none
* LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to typerust.fly.dev:443
* Closing connection
curl: (35) LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to typerust.fly.dev:443
I have zero idea why. But I also asked some of my friends in another country to try and they couldn’t open fly.dev URLs too. I am currently in Japan.
Hi… This domain doesn’t actually resolve for me (from New York). Generally, you will need at least a freebie shared IPv4 address, 
, for the above URL to work.
Possibly I’m misunderstanding what you’re attempting, though…
What other ones have they tried, if any? debug.fly.dev is the best for this, since it rules out the possibility of it being your app that’s askew:
$ curl -i -H 'flyio-debug: doit' 'https://debug.fly.dev/'
The returned flyio-debug header has useful information about which edge you went through, which backend worker it contacted, etc., although the field names are rather cryptic.
If you can’t get through to that one at all, then posting mtr output can often help Fly.io infrastructure staff pinpoint where the exact network glitch is.
Hope this helps a little!
1 Like
Oh I didn’t know about debug.fly.dev, thanks! Here’s the output I get:
❯ curl -i -H 'flyio-debug: doit' 'https://debug.fly.dev/'
HTTP/2 200
fly-region: hkg
remote-addr: 172.16.146.138:50938
date: Sat, 10 May 2025 04:38:29 GMT
content-length: 461
content-type: text/plain; charset=utf-8
server: Fly/bbaf6ebad (2025-05-06)
via: 2 fly.io
fly-request-id: 01JTW7SKNMEPKEVTKB72VSKMBG-hkg
flyio-debug: {"n":"edge-cf-hkg1-5766","nr":"hkg","ra":"220.146.137.224","rf":"Verbatim","sr":"hkg","sdc":"hkg1","sid":"4d891eddf6d7d8","st":0,"nrtt":0,"bn":"worker-cf-hkg1-be08","mhn":null,"mrtt":null}
=== Headers ===
Host: debug.fly.dev
Accept: */*
X-Request-Start: t=1746851909300983
X-Forwarded-Port: 443
User-Agent: curl/8.7.1
X-Forwarded-Proto: https
X-Forwarded-Ssl: on
Fly-Forwarded-Port: 443
Fly-Region: hkg
X-Forwarded-For: <my ip>, 37.16.16.7
Fly-Forwarded-Proto: https
Fly-Client-Ip: <my ip>
Fly-Forwarded-Ssl: on
Fly-Request-Id: 01JTW7SKNMEPKEVTKB72VSKMBG-hkg
Via: 2 fly.io
2025-05-10 04:38:29.297569286 +0000 UTC m=+503984.390725562
I deleted static IP (which is what I wanted to do) and assigned a shared one. Still no change, although DNS resolves for me to this new shared IP. Other than that I get the same output as before.
For more context, the subdomain USED to work a year or more ago, I just didn’t care much about it.
Ok I found out that my configuration was probably too old and broken. Still no idea how that happened but I updated it to use http_service and now it’s working again.
1 Like