Started with something dumb. Facebook wouldn’t load in Vivaldi or Firefox on the desktop. Worked fine on mobile. Figured it was a browser thing at first. Extension, cookies, the usual 💨 . Wasn’t that.

why i thought i might need ipv6

Ran a curl test forcing each protocol separately, just to rule stuff in or out:

curl -4 -I https://www.facebook.com
curl -6 -I https://www.facebook.com

IPv4 came back clean. HTTP/2 200, instant. IPv6 flat out refused to connect:

curl: (7) Failed to connect to www.facebook.com port 443 after 13 ms: Could not connect to server

13ms is not a timeout. That’s an instant reject. So my first thought was okay, maybe my browser’s trying IPv6 first, which is normal, “happy eyeballs” 👀 is supposed to fall back to v4 cleanly, and something about the v6 path on my end is broken badly enough that the fallback isn’t happening smooth. That felt like something worth fixing properly rather than papering over, since I run Tailscale, which does use its own IPv6 range for the mesh. So I didn’t want to just nuke IPv6 blind and break something I actually rely on.

what i actually found

Checked what IPv6 addresses I even had:

ip -6 addr show
ip -6 route show

inet6 fe80::10cf:d378:c811:22e7/64 scope link          link-local, not routable anywhere
inet6 fd7a:115c:a1e0::5937:ae6e/128 dev tailscale0      Tailscale's own private range

That’s it. No global IPv6 address. No default route out to the actual internet over v6. Confirmed it with:

ping6 -c 3 2a03:2880:f384:1:face:b00c:0:25de

ping6: connect: Network is unreachable

Not “unreachable” like a firewall’s blocking it. Unreachable like there’s genuinely no route to send the packet on in the first place. My ISP or router just isn’t handing out real IPv6 at all. Never was. So none of this was ever a “fix the routing” job. There was nothing broken to fix. I simply never had IPv6 internet access, only Tailscale’s private overlay range and useless link-local addressing that can’t go anywhere off this machine.

why i disabled it anyway

Once I knew that, keeping IPv6 “enabled” system-wide was just actively costing me time on every single connection. Every app that tries IPv6 first has to fail, wait, then fall back to IPv4. That’s exactly the 13ms then fallback pattern that was making Facebook, and probably other sites, slower or flakier to load than they needed to be.

Tailscale doesn’t care either way. It manages its own IPv6 range internally regardless of what the OS does with public-facing IPv6, so turning off the system’s attempt at real-world IPv6 doesn’t touch the mesh at all.

So, kill it at the sysctl level, system-wide:

sudo nano /etc/sysctl.d/99-disable-ipv6.conf

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1

Apply without a reboot:

sudo sysctl --system

Done. Every app on the box now goes straight to IPv4, first try, no dead end detour, no fallback delay.

turns out it was never ipv6 anyway

Here’s the kicker. After all that, Facebook still wouldn’t load. Turned out it wasn’t my box at all. Facebook itself was down. Got the “Account Temporarily Unavailable, your account is currently unavailable due to a site issue” message, same as everyone else. Checked their own status comments and there were people all over it at the same time, one guy saying “down for me to, website but not app,” another one saying it had been sitting like that for 30 minutes with no response. Classic Meta outage, nothing to do with me.

So two separate things were true at once. Facebook actually was broken for a while, and my box genuinely had no working IPv6 the entire time and never did. The IPv6 fix didn’t solve the Facebook problem, that one just fixed itself once Meta sorted their servers out. But it wasn’t wasted effort either. Every connection on this box is faster now because it’s not wasting 13ms trying a route that was never going to work in the first place.

If a site’s being weird in the browser and mobile’s fine, don’t assume it’s the site straight away, check both protocols with curl first. But also don’t assume it’s automatically your fault either. Sometimes it really is them, and you just happen to find a genuine problem on your own end while you’re in there looking. Worth fixing anyway.