The One Checkbox That Made the Web Feel Broken

Every page that offered both a newer and an older address made my browser try the newer road first, and that road had a locked gate at the adapter, so the browser waited out one failed attempt before falling back to the older road that worked. A modern page asks for dozens of pieces, and each font, script, and picture paid that same wait again. Pages that used only one road loaded fine, which is why a few sites, including one music site I could reproduce it on at will, looked frozen while the rest of the web behaved normally. My first tests, which showed no packet loss in 30 checks and one slow reading of 106 milliseconds, sent me looking at the provider instead.

It started with a familiar kind of complaint: the internet felt unstable. A site would sit there, loading and loading, while other pages opened just fine. One music site made the problem easy to repeat, but it was not the only one. I could visit much of the web, then hit one of these pages and wait until my patience ran out.

So I did what most people would do. I checked whether the connection was dropping. It was not. I checked whether the computer could find website addresses quickly. It could. I checked whether it could make a basic connection to a secure website. That worked quickly too.

The tests gave me a clean report. There was no packet loss in a 30-check run. The connection speed jumped around more than I liked, with some checks taking as long as 106 milliseconds, but it was not actually losing traffic. That pointed toward the internet provider, or at least made it tempting to blame the provider. It was a real wrinkle, but not the reason a page would not finish loading.

That was the costly part. I spent time following a clue that sounded reasonable because the numbers looked unusual. More importantly, I kept treating the stalled pages as a vague outside problem instead of asking why my browser behaved differently from the small tests I had run.

The answer was IPv6, one of the newer ways computers are given an address on the internet. Think of it as a second road system. Many websites publish both an older address and a newer address, and a browser often tries both paths so it can use the one that gets there first.

That race has a cheerful technical name, Happy Eyeballs. It just means the browser tries two possible routes at nearly the same time rather than betting everything on one. When both roads work, nobody notices. In my case, the newer road was written down on the map, but the computer had no route onto it.

So each time the browser reached a website that offered both choices, it tried the unusable road first. The attempt went nowhere. Only after waiting for that failure did it fall back to the route that worked. One delay might be annoying but manageable. A modern page is not one request, though. It asks for many little pieces: pictures, fonts, scripts, buttons, and information from other places. Every piece paid the same wait-then-try-again cost. The page could look frozen even though the underlying internet connection was fine.

That explained why the earlier checks had missed it. I had tested the older road directly, and it was healthy. The browser was doing more work than my simple tests. It was choosing between roads again and again while building the page.

The next question was how my computer ended up in this half-working state. Years earlier, I had opened the network settings and unchecked a box that said I did not want the newer road on my Wi-Fi connection. I thought I had turned it off.

I had not. I had only closed one lane at the driveway.

The computer still saw the newer road listed in the map book. It still offered that road to the browser. But the adapter, the part that lets the computer talk over Wi-Fi or a cable, was no longer allowed to carry that traffic. It was like telling a delivery driver that a bridge exists, then putting a locked gate in front of it. The driver keeps trying the bridge, loses time at the gate, and eventually takes the other way around.

Four quick checks made the picture clear. Websites were still giving the computer the newer kind of address. The computer had no general route to reach those addresses. A test to a public address on that route failed. And the browser kept trying it before coming back to the route that worked. The fault was not the provider. It was a setting I had changed long ago without realizing that the checkbox only did half the job.

The repair was not to tear the newer road system out of the computer. That could break other things that use it inside a private network. Instead, I changed a Windows setting that tells the computer to prefer the older road for ordinary internet trips while leaving the newer one available when something specifically needs it. That setting only takes effect after a restart.

After the restart, the stalled pages opened normally. The change was small. Finding the right question took much longer.

The lesson is not that everyone needs to edit a Windows setting. Most people should not change network settings casually. It is that a green checkmark on one test does not settle a whole problem. A house can have working lights and still have one dead outlet. Both facts can be true.

Of the 30 checks I ran, the slowest took 106 milliseconds, and none of them measured the delay that froze the pages: one failed attempt on the newer road, paid again for every font, script, and picture before the browser fell back to the older one. The unchecked box had closed the gate at the adapter while the map still listed a bridge, so the browser kept driving to it first. Telling Windows to prefer the older road removed that repeated wait, and the pages that had hung began opening at once, with the provider’s line exactly as it was before.

dxdev LESSON · paste into your AI coding agent
LESSON: A green result on a narrow test doesn't rule out a browser doing more work than your test covers
SOURCE: dxdev.com/blog/2026-05-09_one-checkbox-that-made-the-web-feel
WHAT HAPPENED: Intermittent page hangs were traced past clean connectivity, DNS, and TLS tests to IPv6 Happy Eyeballs: a years-old unchecked Wi-Fi setting had left IPv6 addresses advertised but unroutable on the network adapter, so the browser, which races IPv6 and IPv4 in parallel per request, wasted a full timeout-then-retry cycle on every single asset on a page, invisible to the simple single-connection diagnostic tests that had been run and come back clean.
THE RULE: A clean result on a narrow diagnostic test, a single connection check, doesn't rule out the actual failure mode, because a browser loading a real page performs more complex, repeated connection logic, such as racing multiple protocols per asset, that a simple test never exercises. Reproduce the actual behavior, not a simplified proxy for it.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
  1. Any network or connectivity diagnostic that tests a single request or connection type when the real failure occurs during a browser's more complex per-asset connection logic, such as dual-stack racing.
  2. Any system setting, a checkbox or a toggle, assumed fully disabled based on its label, without verifying its actual effect at the protocol or routing level.
  3. Any intermittent performance issue blamed on an external party, such as an ISP, before confirming the local environment's connection behavior differs from what a simple test measured.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.