Interactive Troubleshooter

Published: Sep 13, 2026

IPv4 vs IPv6 Conflict Causing Slow Websites: Fix

Time: 15 mins Level: Beginner

By StepDiag Engineering Team

Reviewed by Ibraheem Taofeeq Opeyemi

Comprehensive root-cause diagnostic decision tree to resolve dual-stack IPv4 and IPv6 routing conflicts, Happy Eyeballs algorithm fallbacks, DNS AAAA record timeouts, and path MTU discovery failures that introduce severe latency during web browsing.

Full Diagnostic Tree & Step-by-Step Overview

What specific loading behavior or network trace symptom occurs when attempting to access web pages?

Websites hang on 'Connecting...' or 'Resolving host...' for 5 to 21 seconds before suddenly loading normally.
Initial webpage HTML loads instantly, but large assets, images, or HTTPS media streams stall indefinitely or time out.
Dual-stack network has an active IPv6 address, but IPv6 traffic is partially routed or dropped entirely at the ISP/Gateway level.
Specific dual-stack websites fail completely in browsers, while pinging their IPv4 address works without packet loss.

When websites stall during initial connection or DNS resolution, what specific network behavior is observed?

Browser attempts IPv6 (AAAA) connection first, times out after TCP SYN retries, and falls back to IPv4 via Happy Eyeballs.
DNS server fails to respond to AAAA queries or returns EDNS0/AAAA timeout errors while A queries succeed immediately.
OS prefers an unroutable or stale global unicast IPv6 address over a fully functional native IPv4 connection.
Local network router distributes stateless IPv6 configuration (SLAAC) without valid DNS recursive name server (RDDNS) options.

Happy Eyeballs (RFC 8305) TCP SYN Connection Timeout & Fallback Delay

Solution:

Root Cause: Happy Eyeballs Connection Attempt Delay due to Broken IPv6 Route

Modern operating systems and web browsers implement the Happy Eyeballs algorithm (RFC 8305) to favor IPv6 while maintaining dual-stack usability. When a DNS query returns both AAAA (IPv6) and A (IPv4) records, the OS initiates a TCP SYN to the IPv6 address first. Standard Happy Eyeballs implementations wait approximately 250ms to 300ms before spawning a parallel IPv4 connection attempt. However, if an intermediate firewall silently drops outgoing TCP SYN packets (instead of sending an ICMPv6 Destination Unreachable), or if the default gateway holds a blackhole IPv6 route, the browser socket blocks until TCP retransmission timers expire (often up to 21 seconds) before aborting IPv6 and falling back to IPv4.

Diagnostic Verification:

Execute a PowerShell or terminal connection test to force an IPv6 socket connection:

Test-NetConnection -ComputerName target-website.com -Port 440 -Server IPv6

Observe if TcpTestSucceeded returns False after a prolonged delay, whereas standard pinging over IPv4 succeeds instantly:

ping -4 target-website.com

Inspect packet captures in Wireshark for repeated TCP SYN retransmissions sent to a 2001:: address without receiving SYN-ACK or ICMPv6 response packets.

Step-by-Step Fix:

1Reconfigure Windows Prefix Policy Table to Prefer IPv4 over IPv6:

Open Command Prompt as Administrator.

View current prefix policies:

netsh interface ipv6 show prefixpolicies

Increase IPv4 precedence above IPv6 by elevating ::ffff:0:0/96 precedence higher than ::/0:

netsh interface ipv6 set prefixpolicy ::ffff:0:0/96 60 4
netsh interface ipv6 set prefixpolicy ::/0 40 1

2Configure Linux Netconf Precedence (/etc/gai.conf):

Open the Name Service Switch configuration file:

sudo nano /etc/gai.conf

Uncomment or add the line to give IPv4 mapped addresses higher priority:

precedence ::ffff:0.0.0.0/96 100

3Flush Local DNS and Socket Caches:

Windows: ipconfig /flushdns

Linux: sudo resolvectl flush-caches

Prevention & Long-Term Monitoring:

Ensure edge firewalls drop invalid IPv6 traffic explicitly with ICMPv6 Destination Unreachable (Type 1, Code 3) instead of silently discarding (DROP) packets, allowing instant TCP socket rejection without waiting for timeouts.

Upstream Router / ISP DNS Resolver Failure on AAAA Queries

Solution:

Root Cause: DNS Server EDNS0 Handling Failure on AAAA Record Queries

When a dual-stack endpoint initiates a web request, the local stub resolver issues simultaneous DNS queries for both A (IPv4) and AAAA (IPv6) records. Certain legacy local home routers, misconfigured consumer ISP recursive resolvers, or firewalls enforcing strict UDP payload limits handle A records correctly but drop or time out on AAAA queries—especially when Extension Mechanisms for DNS (EDNS0) are used. The operating system's DNS client waits for the AAAA query timeout window (typically 2 to 5 seconds per configured DNS server) before completing the lookup process and presenting the A record response to the browser.

Diagnostic Verification:

Query local DNS server specifically for AAAA records using nslookup or dig:

nslookup -type=AAAA example.com

If the query times out or returns Server Failure (SERVFAIL) after several seconds, compare it against a reliable public dual-stack DNS server:

nslookup -type=AAAA example.com 1.1.1.1

Step-by-Step Fix:

1Bypass Router Internal DNS Proxy:

Open Windows Network Connections (ncpa.cpl).

Right-click active network interface, select Properties.

Select Internet Protocol Version 4 (TCP/IPv4) > Properties.

Switch from 'Obtain DNS server address automatically' to 'Use the following DNS server addresses'.

Set Primary: 1.1.1.1, Secondary: 8.8.8.8.

2Configure Static Dual-Stack DNS in IPv6 Properties:

Select Internet Protocol Version 6 (TCP/IPv6) > Properties.

Set Preferred DNS Server: 2606:4700:4700::1111

Set Alternate DNS Server: 2001:4860:4860::8888

3Verify DNS Response Speed via Terminal:

Measure query latency in PowerShell:

Measure-Command { Resolve-DnsName -Name example.com -Type AAAA }

Prevention & Long-Term Monitoring:

Avoid utilizing residential router gateways as local primary DNS proxies; distribute enterprise public or dedicated local recursive resolvers (e.g., Pi-hole, AdGuard Home, or Bind9) directly via DHCP option 6 / RDNSS.

Stale / Non-Routable Global Unicast Address (GUA) Binding

Solution:

Root Cause: Unsynchronized SLAAC / Dynamic Prefix Delegation Stale Address Latch

When an Internet Service Provider assigns dynamic IPv6 prefixes via DHCPv6 Prefix Delegation (DHCPv6-PD), router disconnects or WAN IP renegotiations update the upstream prefix. If the edge router fails to send Router Advertisement (RA) packets with a Deprecation Lifetime of zero for the old prefix, host operating systems maintain the old Global Unicast Address (GUA, e.g., starting with 2001: or 2600:) alongside the newly assigned GUA. The OS source address selection algorithm (RFC 6724) may choose the deprecated, non-routable IPv6 address as the source for outbound packets, leading to immediate routing blackholes and fallback delays.

Diagnostic Verification:

Run command to view assigned IPv6 addresses:

Windows: ipconfig /all

Linux: ip -6 addr show

Check if multiple GUA addresses exist on the main interface and verify if the primary GUA matches the router's active delegated prefix.

Test pinging an external IPv6 address specifying the primary interface address:

ping -6 -S [Your_GUA_Address] 2606:4700:4700::1111

Step-by-Step Fix:

1Release and Renew DHCPv6 & Re-evaluate Router Advertisements:

Windows Command Prompt (Admin):

ipconfig /release6
ipconfig /renew6

Linux (NetworkManager):

sudo nmcli connection reload
sudo nmcli networking off && sudo nmcli networking on

2Purge Stale IPv6 Neighbor Cache & Routes:

Windows:

netsh interface ipv6 delete neighbors
route -f

3Enable Preferred Lifetime Checks on Router:

Access router management console (e.g., 192.168.1.1).

Navigate to IPv6 LAN Settings.

Enable Send Adv-On-Link Flag and ensure Autonomous Flag (A-flag) lifetime is configured to short intervals (e.g., Preferred Lifetime: 1800s, Valid Lifetime: 3600s).

Prevention & Long-Term Monitoring:

Ensure the upstream ISP modem/router supports proper RFC 7699 IPv6 prefix deprecation handling upon WAN link reset.

Router Advertisement SLAAC Configuration without RDNSS Support

Solution:

Root Cause: Missing IPv6 Recursive DNS Server (RDNSS) in Router Advertisements

In stateless IPv6 configuration environments (SLAAC), host machines receive network prefixes directly from Router Advertisement (RA) messages sent by the local gateway. Older router firmwares generate RA messages providing IPv6 routing parameters but omit the RDNSS (RFC 8106) option containing IPv6 DNS server addresses. If the host operating system disables IPv4 or gives preference to IPv6 transport layers, the OS attempts to resolve all domain names over IPv6 DNS endpoints that do not physically exist, introducing severe query timeout delays before falling back to legacy IPv4 DHCP-provided DNS servers.

Diagnostic Verification:

Inspect local network parameters:

ipconfig /all

Verify if IPv6 Address is present, but DNS Servers list contains only IPv4 addresses (e.g., 192.168.1.1) or link-local fe80:: addresses that fail to answer port 53 UDP queries.

Test UDP port 53 reachability to local link-local gateway:

Test-NetConnection -ComputerName fe80::1%12 -Port 53

Step-by-Step Fix:

1Enable Stateless DHCPv6 or RDNSS on Router:

Under IPv6 Configuration, change LAN IPv6 assignment mode from *SLAAC Only* to Stateless DHCPv6 or SLAAC with RDNSS.

Specify reliable IPv6 DNS servers in the router pool (e.g., 2001:4860:4860::8888).

2Force Host Interface Re-configuration:

Disable and re-enable local network adapter via PowerShell:

Disable-NetAdapter -Name "Ethernet" -Confirm:$false
Enable-NetAdapter -Name "Ethernet"

Prevention & Long-Term Monitoring:

Consult official network guidance such as the Microsoft Official Windows Networking Documentation to properly align DHCPv6 and Router Advertisement flags across enterprise networks.

When web page assets, images, or HTTPS connections stall after the initial page load starts, what is the underlying network diagnostic pattern?

Path MTU Discovery (PMTUD) fails due to blocked ICMPv6 'Packet Too Big' messages (IPv6 MTU Black Hole).
IPv6 transition tunnel (6to4, Teredo, or ISATAP) introduces extreme encapsulation overhead and packet fragmentation.
Carrier-Grade NAT (CGNAT) or DS-Lite tunnel endpoint at ISP experiences port exhaustion or packet dropping.
TCP Window Scaling or TCP MSS clamping misconfiguration drops large IPv6 TCP packets across VPN interfaces.

Path MTU Discovery (PMTUD) Failure & ICMPv6 Packet Too Big Black Hole

Solution:

Root Cause: ICMPv6 Type 2 Filtering Creating an IPv6 MTU Black Hole

Unlike IPv4, IPv6 routers never perform packet fragmentation in transit. Every IPv6 packet exceeding a link's Maximum Transmission Unit (MTU) must be dropped by the intermediate router, which then sends an ICMPv6 Type 2 ("Packet Too Big") error message back to the sender containing the smaller allowable link MTU. If mid-path firewalls or security software block all ICMPv6 traffic, the sending web server never receives the Path MTU Discovery (PMTUD) signal. Small packets (like initial HTTP GET requests) pass through, but large data payloads (such as TLS certificates, images, or scripts) exceed the MTU, are silently dropped, and cause the connection to freeze indefinitely.

Diagnostic Verification:

Ping a dual-stack remote server with large payload sizes while enforcing non-fragmentation:

Windows: ping -6 -f -l 1400 example.com

Linux: ping -6 -M do -s 1400 example.com

If smaller sizes (e.g., 1200 bytes) succeed while 1400 bytes fails with 100% packet loss without returning an ICMP warning, an MTU Black Hole is present.

Step-by-Step Fix:

1Lower Local Adapter IPv6 MTU to Standard Conservative Size (1280 or 1350 bytes):

Open Command Prompt as Administrator.

Identify interface index number (Idx):

netsh interface ipv6 show subinterfaces

Set IPv6 MTU to 1280 (the absolute minimum valid MTU size guaranteed by IPv6 specs):

netsh interface ipv6 set subinterface "Ethernet" mtu=1280 store=persistent

2Configure Router ICMPv6 Firewall Rules:

Access firewall/router settings and ensure ICMPv6 is explicitly allowed.

Do NOT drop ICMPv6 globally; allow Type 1 (Destination Unreachable), Type 2 (Packet Too Big), Type 3 (Time Exceeded), and Type 133-136 (NDP).

3Linux Kernel MTU Probing Enablement:

Enable dynamic PLPMTUD (Packetization Layer Path MTU Discovery):

sudo sysctl -w net.ipv4.tcp_mtu_probing=1

Prevention & Long-Term Monitoring:

Never drop ICMPv6 messages indiscriminately on perimeter firewalls; ICMPv6 is vital for basic link-layer and transport operations.

Legacy IPv6 Transition Tunnel (Teredo / 6to4 / ISATAP) Latency & Overhead

Solution:

Root Cause: Encapsulated Tunnel Routing Loops & High Latency Relays

Legacy Windows installations or unmanaged network stacks frequently enable auto-tunneling mechanisms such as Teredo, 6to4, or ISATAP when a native IPv6 connection is unavailable. These protocols encapsulate IPv6 packets inside IPv4 UDP datagrams and route them through public relay servers. Because public Teredo/6to4 relays are largely deprecated or unmaintained, path latency often exceeds 300ms–500ms, with severe packet loss. Because the OS sees an active IPv6 interface, it attempts to route web traffic through the tunnel, causing severe loading delays.

Diagnostic Verification:

Check active interface state in Windows Command Prompt:

netsh interface teredo show state

Check if active IP addresses belong to Teredo (2001:0::/32) or 6to4 (2002::/16):

ipconfig /all

Step-by-Step Fix:

1Disable Teredo Tunnel Interface:

Run Command Prompt as Administrator:

netsh interface teredo set state disabled

2Disable 6to4 and ISATAP Tunneling Interfaces:

Run the following netsh commands:

netsh interface ipv6 6to4 set state disabled
netsh interface ipv6 isatap set state disabled

3Disable Transition Protocols via Group Policy / Registry:

To permanently disable all transitional tunneling via Registry (Admin Command Prompt):

reg add "HKLM\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters" /v "DisabledComponents" /t REG_DWORD /d 0x8 /f

Prevention & Long-Term Monitoring:

Ensure legacy transition mechanisms are turned off globally across enterprise endpoints via Group Policy (GPO) or MDM configurations.

Dual-Stack Lite (DS-Lite) Carrier-Grade NAT (CGNAT) Encapsulation Bottleneck

Solution:

Root Cause: ISP AFTR Gateway Port Exhaustion under DS-Lite Architecture

Under Dual-Stack Lite (DS-Lite) deployment models used by many telecommunications providers, the customer edge router is assigned a native IPv6 address, but legacy IPv4 traffic is encapsulated into IPv6 packets and sent across the ISP network to an Address Family Transition Router (AFTR) gateway. If the ISP's AFTR element experiences high load, CPU throttling, or NAT port allocation limits, native IPv6 web traffic functions smoothly while legacy IPv4 website elements encounter massive latency, packet retransmissions, or HTTP connection resets.

Diagnostic Verification:

Check router WAN connection status to confirm if WAN IPv4 address is in the CGNAT RFC 6598 range (100.64.0.0/10).

Trace route to a pure IPv4 host vs pure IPv6 host:

tracert -4 1.1.1.1 (shows extra encapsulation hop or high initial latency at ISP edge)

tracert -6 2606:4700:4700::1111 (passes cleanly without extra hops)

Step-by-Step Fix:

1Force Pure Native IPv6 Routing for Dual-Stack Endpoints:

Ensure local browser flags enforce modern HTTP/2 and HTTP/3 (QUIC) over native IPv6 endpoints, bypassing legacy IPv4 AFTR gateways.

2Enable MSS Clamping on Router for AFTR Tunnel Interface:

Access router advanced settings.

Enable TCP MSS Clamping on WAN interface and set TCP MSS value to 1420 (accounting for 40-byte IPv6 header overhead).

3Request True Dual-Stack / Static Public IPv4 Address from ISP:

Contact ISP technical support and request opt-out of DS-Lite / CGNAT, or request provision of a native dual-stack profile with a public IPv4 address.

Prevention & Long-Term Monitoring:

Monitor router system logs for AFTR resolution failed or CGNAT table full event triggers.

TCP MSS Clamping / MTU Misconfiguration across VPN Adapters

Solution:

Root Cause: Encapsulation Overhead Mismatch on Dual-Stack VPN Tunnels

Virtual Private Network (VPN) client software (such as OpenVPN, WireGuard, or IPsec) creates virtual adapter interfaces with lowered MTUs (e.g., 1420 or 1380 bytes) to accommodate tunnel headers. When a user navigates dual-stack websites while connected to a VPN that routes IPv4 inside the tunnel but leaks or drops IPv6 outside the tunnel, the maximum segment size (MSS) negotiated during the TCP 3-way handshake (MSS = MTU - 60 bytes for IPv6) causes oversized packets to hit physical interface queues, causing severe fragmentation or packet drops.

Diagnostic Verification:

Problem occurs strictly while an enterprise or consumer VPN connection is active.

Disconnecting the VPN restores immediate web page load speeds across all browsers.

Step-by-Step Fix:

1Disable IPv6 Leak / Force Native IPv6 Tunneling in VPN Client:

Open VPN Client Settings.

Enable IPv6 Leak Protection or turn on Enable IPv6 TUN/TAP Transport so that IPv6 traffic is cleanly routed inside the encrypted tunnel with proper MSS clamping.

2Adjust WireGuard / OpenVPN Interface MTU:

Edit WireGuard configuration file (.conf):

Under [Interface], add or modify:
MTU = 1360

3Force TCP MSS Clamping in Windows PowerShell (Admin):

Set TCP MSS target dynamically:

netsh interface ipv6 set subinterface "VPN - Connection" mtu=1360 store=persistent

Prevention & Long-Term Monitoring:

Always ensure deployed corporate VPN software supports complete dual-stack tunnel encapsulation rather than relying on host-level split-tunnel drops.

When IPv6 is enabled locally but IPv6 traffic is partially dropped or failing at the gateway level, what network configuration is active?

Local ISP provides native IPv6, but customer premises equipment (CPE) router runs outdated firmware with buggy IPv6 firewall rules.
Wi-Fi Access Point / Switch blocks or throttles IPv6 Multicast (ICMPv6 Neighbor Discovery / MLD Snooping failure).
Host machine possesses a valid Link-Local IPv6 address (`fe80::`), but no Global Unicast Address (`2001::` or `2600::`) is assigned.
Third-party security software / Antivirus SSL inspection engine corrupts IPv6 TCP socket handshakes.

Router Stateful IPv6 Firewall Misconfiguration & SPI Drops

Solution:

Root Cause: Incorrect Stateful Packet Inspection (SPI) Filtering on IPv6 Pinholes

Unlike IPv4 which relies heavily on Network Address Translation (NAT) as an implicit basic firewall layer, IPv6 gives every local device a globally routable IP address. Protection relies entirely on the router's Stateful Packet Inspection (SPI) firewall. Flawed router firmwares frequently drop established or related return traffic on IPv6 TCP connections, treating valid incoming SYN-ACK or ACK responses as unauthorized incoming connections. This causes outbound IPv6 connections to freeze after sending the initial SYN packet.

Diagnostic Verification:

Inspect router security log for entry flags such as IPv6 SPI Drop or Unsolicited incoming packet blocked corresponding to destination port 443.

Test IPv6 firewall reachability using online diagnostic tests or command terminal tests.

Step-by-Step Fix:

1Upgrade Gateway Router Firmware:

Access router administration portal.

Check for vendor firmware updates addressing IPv6 firewall or SPI bugs and apply the latest version.

2Reset IPv6 Firewall Rules to Default State:

Navigate to Security / Firewall > IPv6 Filtering.

Ensure default outbound policy is set to ALLOW.

Ensure state tracking allows Established, Related connections.

3Disable Hardware Acceleration / Offloading Glitches:

In some routers, NAT/LAN Hardware Acceleration corrupts IPv6 firewall state tables. Temporarily disable Flow Acceleration or CTF (Cut Through Forwarding) to verify stability.

Prevention & Long-Term Monitoring:

Test router IPv6 implementation against standardized diagnostic test suites periodically following any major firmware upgrade.

Wi-Fi Access Point / Managed Switch MLD Snooping & Multicast Drop

Solution:

Root Cause: Multicast Listener Discovery (MLD) Snooping Dropping Neighbor Discovery

IPv6 does not use broadcast messages; it relies exclusively on IPv6 Multicast and the Neighbor Discovery Protocol (NDP) via ICMPv6 to map IPv6 addresses to MAC addresses (replacing ARP in IPv4). Wi-Fi access points and managed Ethernet switches often enable IGMP / MLD Snooping to reduce wireless multicast traffic. If the switch or AP fails to properly process MLD queries, it drops ICMPv6 Neighbor Solicitations (NS) and Neighbor Advertisements (NA). As a result, hosts periodically lose their default gateway mapping, causing website loading to freeze until the neighbor cache is manually cleared or renegotiated.

Diagnostic Verification:

Check neighbor cache table when website slows down:

Windows: netsh interface ipv6 show neighbors

Linux: ip -6 neighbor

If gateway entry state shows INCOMPLETE, STALE, or FAILED, NDP packet loss over the wireless/switched media is occurring.

Step-by-Step Fix:

1Disable MLD Snooping on Managed Switches / APs:

Navigate to Multicast / IGMP / MLD Settings.

Set MLD Snooping to Disabled (or configure an explicit MLD Querier if required).

2Disable 'Wireless Multicast to Unicast' Conversion:

Disable features named *Multicast Enhancement*, *IGMP Proxy*, or *Airtime Fairness* if they interfere with ICMPv6 packets on Wi-Fi radios.

3Increase Host NDP Cache Lifetime (Optional Workaround):

Force static neighbor resolution for default gateway if hardware cannot be updated.

Prevention & Long-Term Monitoring:

Ensure enterprise switch network equipment supports MLDv2 snooping standards compliant with RFC 4541.

Link-Local Only Address Assignment & Missing Global Unicast Address

Solution:

Root Cause: Absence of Global Unicast Address (GUA) with Active IPv6 Protocol Stack

When IPv6 is enabled on a host operating system, the interface automatically self-assigns a Link-Local IPv6 address starting with fe80::/10. However, if the local router or ISP does not provide a valid Global Unicast Address (GUA) via SLAAC or DHCPv6, the host cannot route packets outside the local subnet. If applications attempt to initiate outbound IPv6 connections using the link-local interface address, the OS routing engine immediately fails, but software stack bugs in applications may delay switching back to IPv4.

Diagnostic Verification:

Inspect IP address configuration:

ipconfig

Observe if the IPv6 section displays only Link-local IPv6 Address . . . . . : fe80::... without a corresponding 2001: or 2600: Global Unicast Address.

Test external IPv6 routing:

ping -6 2001:4860:4860::8888 (returns Destination host unreachable).

Step-by-Step Fix:

1Verify ISP / Router IPv6 Capability:

If your ISP or local network does not support IPv6 WAN connectivity, turn off IPv6 auto-configuration on the host to avoid stack confusion, OR prefer IPv4 in OS policy.

2Disable IPv6 on Specific Interface (If non-functional network):

Open ncpa.cpl.

Right-click Network Adapter > Properties.

Uncheck Internet Protocol Version 6 (TCP/IPv6).

Click OK and restart adapter.

3Enable Native IPv6 on Router (If ISP supported):

Access router settings > WAN / Internet Settings.

Set IPv6 Connection Type to Native / DHCPv6 / SLAAC based on ISP specifications.

Prevention & Long-Term Monitoring:

Do not leave IPv6 enabled on corporate host endpoints if upstream network infrastructure lacks routable IPv6 WAN internet access.

Third-Party Antivirus / Security Suite SSL Inspection Filtering Bug

Solution:

Root Cause: Security Suite WFP Network Driver Socket Interception Failure

Third-party endpoint security suites (such as Avast, AVG, Bitdefender, or Kaspersky) install Windows Filtering Platform (WFP) network driver hooks to inspect encrypted HTTPS traffic. Many of these local proxy drivers intercept IPv4 sockets correctly but contain bugs handling dual-stack IPv6 socket hooks or SNI parsing over IPv6. When a browser opens a dual-stack TLS connection, the local security driver drops or corrupts the IPv6 TCP payload, stalling web requests until the browser driver resets the socket connection.

Diagnostic Verification:

Boot Windows into Safe Mode with Networking.

Test web browsing speed across dual-stack websites.

Alternatively, temporarily disable 'Web Protection', 'HTTPS Scanning', or 'Encrypted Connection Inspection' inside the antivirus software control panel and test if browsing lag vanishes immediately.

Step-by-Step Fix:

1Disable Web HTTPS Filtering / SSL Interception in Security Suite:

Open Antivirus Settings > Protection > Web Shield / Advanced Settings.

Uncheck Enable HTTPS Scanning or Scan Encrypted Connections.

2Reset Windows Filtering Platform (WFP) & Winsock Catalog:

Open Command Prompt as Administrator:

netsh winsock reset
netsh int ip reset

Reboot the computer.

3Uninstall / Reinstall Security Endpoint Software:

Reinstall the security software using the manufacturer's official cleanup tool to reset driver binding stack rules.

Prevention & Long-Term Monitoring:

Rely on modern browser-native sandboxing and native Windows Defender security layers rather than intrusive third-party TLS-intercepting network filter drivers.

When dual-stack websites fail completely in web browsers while IPv4 pings succeed, what OS or browser environment is active?

Web browser enforces Secure DNS (DNS-over-HTTPS / DoH) resolving AAAA records that local network cannot route.
Proxy server or PAC script returns IPv6 proxy endpoints while local network proxy port blocks IPv6 transport.
Windows Web Account Manager / WinHTTP proxy setting holds stale IPv6 proxy configurations.
Browser extension (Adblocker, VPN extension, or Privacy shield) forces IPv6 DNS lookups that fail internally.

Browser Secure DNS (DNS-over-HTTPS) Dual-Stack Resolution Mismatch

Solution:

Root Cause: DoH Resolver Bypassing System Split-DNS or IPv6 Fallback Rules

Modern web browsers (Google Chrome, Mozilla Firefox, Microsoft Edge) feature Secure DNS (DNS-over-HTTPS / DoH). When enabled, the browser bypasses local operating system DNS resolvers and queries external encrypted DoH providers (e.g., Cloudflare, Google) directly. The public DoH provider always returns AAAA records for dual-stack domains. If the local network ISP or router blocks IPv6 traffic outbound, the operating system's built-in fallback logic is bypassed by the browser's internal network stack, leading to complete connection failures or severe timeout hangs.

Diagnostic Verification:

Test website access in browser vs terminal ping:

Chrome/Edge: Displays ERR_ADDRESS_UNREACHABLE or ERR_TIMED_OUT.

Command Prompt: ping -4 website.com responds instantly.

Disabling Secure DNS in browser settings resolves the issue immediately.

Step-by-Step Fix:

1Reconfigure Browser Secure DNS Settings:

Google Chrome: Settings > Privacy and Security > Security > Scroll to 'Use Secure DNS'. Select With your current service provider (OS Fallback).

Mozilla Firefox: Settings > Privacy & Security > Scroll to 'DNS over HTTPS'. Set to Off or Default Protection.

Microsoft Edge: Settings > Privacy, search, and services > Scroll to 'Security' > Use Secure DNS. Select Use current service provider.

2Configure Upstream DoH Provider to Match Network Capability:

If DoH is required by enterprise policy, ensure the configured DoH endpoint supports proper client IP subnet ECS (EDNS Client Subnet) hints.

Prevention & Long-Term Monitoring:

Enforce browser configuration policies via Group Policy (.admx templates) across enterprise workstations to align DoH settings with corporate network topology.

PAC Script / Proxy Server IPv6 Destination Unreachable

Solution:

Root Cause: Proxy Auto-Configuration (PAC) Script Returning IPv6 Addresses to IPv4-Only Proxy

WinHTTP / System Web Proxy Stale IPv6 Binding

Solution:

Root Cause: WinHTTP Proxy Setting Holding Ghost IPv6 Endpoint Configuration

Certain core Windows OS components, update services, and web applications use the WinHTTP proxy stack rather than standard WinINET / user-level proxy settings. If a proxy or VPN software previously configured a system-wide IPv6 proxy address (e.g., [fe80::1]:8080 or [2001::1]:8080) and uninstalled cleanly without clearing the WinHTTP configuration table, WinHTTP background requests fail repeatedly while attempting to connect to the dead IPv6 proxy endpoint.

Diagnostic Verification:

Run command to check system WinHTTP proxy status:

netsh winhttp show proxy

Observe if 'Proxy Server(s)' lists an IPv6 address or stale hostname that fails to respond.

Step-by-Step Fix:

1Reset WinHTTP Proxy Settings to Direct Connection:

Open Command Prompt as Administrator:

netsh winhttp reset proxy

2Import Clean Internet Explorer / WinINET Settings:

Ensure standard Internet Options proxy is disabled or correct, then sync to WinHTTP:

netsh winhttp import proxy source=ie

3Flush Network Stack and Restart Web Services:

Restart the WinHTTP Web Proxy Auto-Discovery Service:

net-stop winhttpauto-proxysvc
net-start winhttpauto-proxysvc

Prevention & Long-Term Monitoring:

Always verify netsh winhttp show proxy state after removing enterprise security agents or VPN clients.

Browser Extension Socket Interception & IPv6 Resolution Failure

Solution:

Root Cause: Extension WebRequest API Interception & Socket Block

Ad-blocking, privacy shielding, or proxy-switching browser extensions use the chrome.webRequest or declarativeNetRequest APIs to inspect and modify outgoing HTTP traffic. Certain extensions contain bugs when modifying or redirecting requests for websites that return dual A/AAAA records, creating an internal loop where the extension attempts to proxy the request over an unsupported IPv6 socket layer, triggering browser-level request cancellations.

Diagnostic Verification:

Open browser in Incognito / Private Mode with all extensions disabled.

If websites load instantly without delay, an extension hook is causing the socket bottleneck.

Step-by-Step Fix:

1Isolate Malfunctioning Extension:

Open browser Extensions Manager (chrome://extensions or about:addons).

Disable all extensions.

Re-enable extensions one by one, testing dual-stack website loading speed after each activation.

2Disable 'WebRTC / IPv6 Leak Protection' Features inside Adblockers:

Open settings for extensions like uBlock Origin or Privacy Badger.

Uncheck options related to *Prevent WebRTC from leaking local IP addresses* or *Force IPv6 DNS proxying* if they interfere with native OS socket handling.

Prevention & Long-Term Monitoring:

Audit browser extensions regularly and restrict extension execution permissions to specific authorized domain targets.

Related Diagnostic Guides

Windows Update Error 0x80070002 Missing Files Diagnostic Guide

System Restore Failed 0x80070005 Antivirus Conflict Tree

Windows Photo Viewer Not Showing Thumbnails: Codec Diagnostic

Safe Mode Password Not Working With Microsoft Account Fix

Clipboard History Not Working Windows 11: Sync Service Tree

Subscribe to StepDiag

Embed Guide on Your Website