New Shared IPv4 Connection Reset by peer

I just followed the instructions to move my app from a dedicated IPv4 address to a shared address, and now the server wont respond via my CNAME.

➜ curl -i
HTTP/1.1 301 Moved Permanently
content-type: application/x-msdownload
content-length: 82
date: Fri, 05 Jan 2024 23:27:22 GMT
server: Fly/fd64846af (2024-01-05)
via: 1.1
fly-request-id: 01HKDZ7R96GV1F8X2QX5M2R7ZR-dfw

Redirecting to <a href=""></a>

This is the correct response (301).

Now, when I attempt with the CNAME:

➜ curl -i
curl: (56) Recv failure: Connection reset by peer

Check DNS:

➜ dig

; <<>> DiG 9.10.6 <<>>
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7064
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

; EDNS: version: 0, flags:; udp: 4096
;		IN	A


PING resolves to correct IP:

➜ ping
PING ( 56 data bytes
64 bytes from icmp_seq=0 ttl=46 time=37.528 ms

Try by IP:

( address works)

➜ curl -i -H "Host:"
HTTP/1.1 301 Moved Permanently

(cname fails)

➜ curl -i -H "Host:"
curl: (56) Recv failure: Connection reset by peer

Any suggestions would be appreciated.

1 Like

Hi @joshf

When your app is using a shared IP, fly-proxy has to know about all the custom domains you have for the app in order to properly route the requests to it (since there are many apps behind a single IP address).

You can tell fly-proxy about the custom domain by issuing a certificate for it:

$ fly certs add

Once the certificate is issued and propagated you should be able to access the app using

Great, thank you, that fixed it.

Shouldn’t this step be part of the migration guide? I re-read it and don’t see how I should have made the leap to needing this step. I did not specifically need a cert (was only accessing via http).

Thanks! It’s been added to the migration guide and also in the docs (Public Network Services · Fly Docs)

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.