Wi-Fi & Network

IPv6 is breaking sites or slowing them

Some sites hang or load slowly, or a VPN leaks? Find out whether IPv6 is actually the cause, fix the real fault, and know when disabling it is just a band-aid.

Problem summary

Most 'IPv6 problems' are a broken IPv6 path (MTU black-hole or slow dual-stack fallback) or a VPN leaking over IPv6 — not IPv6 itself. Prove whether IPv6 is the cause, fix the actual fault, and treat disabling IPv6 as a temporary diagnostic, not the fix.

Operator snapshotEvidence first

First proof

Compare the two stacks to the same site: curl -6 / ping -6 vs curl -4 / ping -4, and run test-ipv6.com.

Screen to open

curl -6 -m 5 https://example.com ; curl -4 -m 5 https://example.com

Expected signal

IPv4 works while IPv6 fails or is much slower.

Stop boundary

Never blanket-block ICMPv6 to 'lock down' IPv6 — it breaks neighbor discovery and PMTUD.

Layer path

1Most 'IPv6 is broken' reports are really a broken IPv6 PATH on an otherwise-fine dual-stack network — not a reason to turn IPv6 off.

2The usual culprits are a PMTUD black-hole (ICMPv6 'Packet Too Big' filtered) or slow dual-stack fallback (Happy Eyeballs), a VPN that only tunnels IPv4 so IPv6 leaks around it, or a device that's unreachable because the firewall is correctly blocking unsolicited inbound IPv6.

3The fast split is: compare IPv6 vs IPv4 to the same destination. If IPv4 is fine and IPv6 fails/slows, you've isolated the layer and you fix the path — disabling IPv6 is only a temporary diagnostic.

4Disabling IPv6 outright is discouraged (Microsoft says it can break Windows components); 'prefer IPv4' is the softer lever if you must de-prioritize it.

Runbook

Step-by-step runbook

Start here. Do each check in order, compare it to the expected result, and stop when the evidence explains the failure or the safe stop point applies.

Confirm it's IPv6, not everything

Check: Run curl -6 vs curl -4 to the same site and test-ipv6.com.

Expected result: IPv4 is healthy while IPv6 fails or is slow.

If not: If both fail, stop — treat it as general connectivity/DNS, not IPv6.

Classify the symptom

Check: Decide whether it's a hang-then-load (MTU/fallback), a VPN leak, an inbound-unreachable host, or all-IPv6-slow.

Expected result: You know which fault class you're in.

If not: Mixed symptoms? Handle each separately and re-test between.

Fix MTU / ICMPv6 for hangs

Check: Stop filtering ICMPv6 'Packet Too Big' on the router/host, or clamp MTU/MSS (~1400) on the link.

Expected result: The hang disappears and large IPv6 transfers complete.

If not: If it persists, verify the broken hop with a -6 traceroute before changing more.

Stop VPN IPv6 leaks at the VPN, not the OS

Check: In the VPN client, enable IPv6 handling or have it block IPv6 while connected.

Expected result: IPv6 no longer escapes the tunnel.

If not: Avoid a permanent system-wide IPv6 disable just to plug a VPN leak.

Treat unreachable-inbound as firewall, not breakage

Check: If a device is unreachable over IPv6 from outside, recognize the stateful firewall is blocking unsolicited inbound (no NAT in IPv6); add a narrow allow only to expose it intentionally.

Expected result: You either accept the protection or expose just that one address/port.

If not: Never blanket-block all ICMPv6 to 'secure' IPv6 — it breaks NDP/PMTUD.

If you must de-prioritize IPv6, prefer IPv4 (don't disable)

Check: On Windows set 'prefer IPv4 over IPv6' (DisabledComponents=0x20) rather than unbinding IPv6; re-enable normal behavior after fixing the root cause.

Expected result: The immediate symptom eases without breaking IPv6-dependent components.

If not: If you disabled IPv6 to test, turn it back on once the path is fixed.

Decision tree

If: IPv4 fine, IPv6 to the same site fails or is slow.

Then: It's an IPv6 path problem, not IPv6 itself.

Action: Fix the path (ICMPv6/MTU, route, prefix); use disable-IPv6 only as a temporary confirmation test.

If: Sites hang briefly then load.

Then: Slow dual-stack fallback or a PMTUD black-hole.

Action: Stop filtering ICMPv6 'Packet Too Big', or clamp MTU/MSS (~1400); don't blanket-block ICMPv6.

If: IPv6 leaks past a connected VPN.

Then: The VPN only tunnels IPv4.

Action: Configure the VPN for IPv6 or have it block IPv6 while connected — not a permanent system-wide IPv6 disable.

If: One device unreachable inbound over IPv6.

Then: The stateful firewall is correctly blocking unsolicited inbound (no NAT in IPv6).

Action: Add a narrow inbound allow to that device's address if you actually want it exposed; otherwise leave it.

Safe stop: Never blanket-block ICMPv6 to 'lock down' IPv6 — it breaks neighbor discovery and PMTUD.

If: You need a quick workaround on Windows right now.

Then: Disabling is risky/discouraged; preferring IPv4 is safer.

Action: Set 'prefer IPv4 over IPv6' rather than unbinding IPv6, then fix the underlying path.

Evidence

Evidence table

Symptom	Evidence to collect	Likely layer	Next action
Some sites hang then load.	curl -6 vs -4 timing; whether large transfers stall; ICMPv6 filtering.	PMTUD black-hole / fallback	Allow ICMPv6 Packet-Too-Big or clamp MSS; re-test.
VPN connected but IPv6 shows real ISP address.	IPv6 address at a what-is-my-ip site with VPN up.	IPv6 leak around IPv4-only VPN	Configure/Block IPv6 in the VPN client, not a system disable.
One host unreachable inbound over IPv6.	Outbound-works/inbound-blocked test; router firewall rules.	Firewall (working as designed)	Add a specific inbound allow only if exposing it intentionally.
All IPv6 slow or failing.	Router IPv6/prefix-delegation status; RA/DNS advertised.	Route / prefix / RA	Check the router's IPv6 WAN + prefix; fix the misconfigured advertisement.

Reference

Commands and settings paths

IPv6 vs IPv4 to the same site

curl -6 -m 5 https://example.com ; curl -4 -m 5 https://example.com

Where: On the affected device.

Expected: Both succeed quickly; if -6 hangs/fails while -4 is fine, IPv6 is the layer.

Failure means: A slow/failed -6 with a fine -4 isolates the problem to the IPv6 path.

Safe next step: Pursue MTU/ICMPv6 (hangs) or route/prefix (hard fail) — not a permanent disable.

Browser-level IPv6 health

Open https://test-ipv6.com

Where: On the affected device's browser.

Expected: A high score with no warnings; a low score or 'no IPv6' flags the fault area.

Failure means: Specific warnings (e.g. large-packet/MTU) point straight at the cause.

Safe next step: Address the flagged item (MTU, no DNS, broken route) rather than disabling IPv6.

Windows: prefer IPv4 (softer than disabling)

netsh interface ipv6 show prefixpolicies (verify before/after a prefer-IPv4 change)

Where: On a Windows host where IPv6 is misbehaving.

Expected: Prefix policies reflect your intended IPv4/IPv6 preference.

Failure means: If you change it, use the documented DisabledComponents=0x20 (prefer IPv4), never 0xFFFFFFFF.

Safe next step: Re-enable normal behavior once the underlying path is fixed.

Check the router's IPv6/prefix state

Router admin > WAN/Internet > IPv6 status (prefix delegation / RA)

Where: In the router admin UI.

Expected: The router has a valid IPv6 prefix and is advertising a sane RA/DNS.

Failure means: No prefix or a rogue RA/DNS explains all-IPv6-slow or DNS issues.

Safe next step: Fix the prefix-delegation/RA settings or contact the ISP if the WAN has no IPv6.

Hardware boundary

Hardware and platform boundary

Change only when

Replace or reconfigure a router that can't pass IPv6 cleanly (no working prefix delegation, can't stop filtering ICMPv6) if your ISP is IPv6-mostly and IPv4 is increasingly behind CGNAT.

Evidence that matters

A router with proper DHCPv6-PD/SLAAC support, a sane default IPv6 firewall (blocks unsolicited inbound, allows established + ICMPv6), and the ability to hand out the right DNS over RA/DHCPv6.

Evidence that does not matter

Turning IPv6 off as a 'feature' — modern OSes expect it, and IPv6 is what gives clean end-to-end reachability where CGNAT broke IPv4.

Avoid

Blanket-blocking ICMPv6, unbinding IPv6 from the adapter (unsupported on Windows), or using DisabledComponents=0xFFFFFFFF (causes a startup delay).

Related tool/checklist

Use the linked tool when you need a guided plan from your exact symptoms instead of a static checklist.

Device setup troubleshooter

Last reviewed

2026-06-02 · Reviewed by HomeTechOps. Built from June-2026 research verified against Microsoft's IPv6-configuration guidance (don't disable; prefer-IPv4 alternative), RFC 8305 (Happy Eyeballs), and NIST SP 800-119 (NAT is not the security control). Frames disabling IPv6 as a temporary diagnostic, not a fix, and treats inbound-unreachable as the firewall working as designed.

Sources/assumptions

Assumes a dual-stack home (your ISP hands out both IPv4 and IPv6) and a modern OS where IPv6 is on by default.
Microsoft advises against disabling IPv6 in Windows; prefer the 'prefer IPv4' setting over unbinding it — disabling can break components.
Specific behaviors (Happy Eyeballs fallback timing, CLAT support) differ by OS; verify against first-party docs for your platform.

Source-backed checks

HomeTechOps turns official docs and conservative safety rules into a shorter runbook. These links are the source trail for the page direction.

Apple Support: Wi-Fi and internet troubleshooting on MacUsed for safe first checks around Wi-Fi status, diagnostics, VPN/security software, and external network devices.Microsoft Support: Fix network connection issues in WindowsUsed for Windows network baseline checks before changing router-wide settings.Microsoft Learn: Guidance for configuring IPv6 in WindowsUsed for Microsoft's first-party stance against disabling IPv6, the 'prefer IPv4' DisabledComponents=0x20 alternative, and the 0xFF-not-0xFFFFFFFF caveat.RFC 8305: Happy Eyeballs Version 2Used for the dual-stack race/fallback behavior and why a broken IPv6 path or PMTUD black-hole shows up as slow/hanging sites.NIST SP 800-119: Guidelines for the Secure Deployment of IPv6Used for the principle that NAT was never a security control and a stateful firewall (plus required ICMPv6) is what protects IPv6 hosts.FCC: Home network tipsUsed for router placement, congestion, and baseline home-network troubleshooting guidance.

Diagnostic rule

1. Check the simplest signal first.
2. Change one thing at a time.
3. Avoid unsafe electrical or data-loss steps.
4. Stop when the evidence says the risk moved.

FAQ

Should I just disable IPv6 to fix this?

Usually no — that masks the problem instead of fixing it, and Microsoft explicitly recommends against disabling IPv6 in Windows (it can break components). Disabling is fine as a *temporary* test to confirm the fault is on the IPv6 path; then re-enable it and fix the root cause. If you genuinely need to de-prioritize it, set Windows to 'prefer IPv4 over IPv6' rather than turning IPv6 off. See should you disable IPv6.

Why do some sites hang for a few seconds then load?

That's the classic broken-IPv6-path signature. Modern OSes race IPv6 and IPv4 (Happy Eyeballs) and normally fail over fast, but Windows/Linux fall back slower than Apple devices, so a broken IPv6 route — or a PMTUD 'black hole' where ICMPv6 'Packet Too Big' messages are filtered — shows up as a hang. The fix is to repair the IPv6 path (don't blanket-block ICMPv6) or clamp MTU/MSS, not to kill IPv6.

My VPN seems to leak — is IPv6 the cause?

It can be: if the VPN only tunnels IPv4 and your network is dual-stack, IPv6 traffic can bypass the tunnel. The correct fix is to configure the VPN to handle IPv6 (or explicitly block IPv6 while connected in the VPN client), not to permanently disable IPv6 for the whole machine. See VPN breaks local network access for the related local-access angle.

How do I even tell if a problem is IPv6?

Compare the two stacks directly: `ping -6` / `curl -6` a site versus `ping -4` / `curl -4`, and run a browser test at test-ipv6.com. If IPv4 is fine and IPv6 fails or is slow, you've isolated it to the IPv6 path. Then check your router's IPv6/prefix status and whether ICMPv6 is being filtered before you touch anything.