[the_biot]

If only they could keep their website reachable, that would be the icing on the cake. Like every time I see them linked on HN, I click and cannot connect to their website.

Last time somebody from fly said they'd look into it, but alas. It was related to IPv6 on their end, was as far as I could tell.

[mrkurt]

We have been chasing this down for weeks and can't find the actual bug/workaround here. It's definitely IPv6 related, we think having something to do with weird MTUs. Are you using an IPv6 tunnel or connecting via a vpn by chance?

[scottlamb]

Weird MTUs: DSL with PPPoE encapsulation, maybe? iirc they tend to use 1492 or 1452 rather than the usual 1500.

[synicalx]

Wow that's a trip down memory lane!

It would be 1492 to allow for another 8 bytes of PPPoE overhead, there are some scenarios where 1508 byte frames might be floating around but I don't really know if anyone adopted that standard.

[the_biot]

That is exactly what I have.

[mwcampbell]

According to Fly's latest logbook post [1], they now have a workaround for this.

[1]: https://fly.io/blog/logbook-2022-05-13/

[the_biot]

Nope.

[baisq]

Disable ipv6 like everybody does.

[the_biot]

Can we cut this shit out? It's 2022, IPv6 has worked fine for decades, and Google is seeing 40% IPv6 usage on their services:

https://pulse.internetsociety.org/blog/ipv6-deployment-passe...

[magicalhippo]

If only IPv6 "just worked". It's better, but still not quite there.

I've been running IPv6 at home for a couple of years now after replacing my pfSense router with OpenWRT. It mostly works. Every now and then there's an issue and, guess what, disabling IPv6 makes things work again.

Latest one would be Android ignoring IPv4 DHCP DNS setting if Android device has a IPv6 address.

[nik736]

Which are mostly bots scanning serp results to prevent rate limits.