The Ten-Second Wait That Came From a Shortcut

The first useful answer took 18 milliseconds, and it was still bad news. The page was not working yet. But after spending the evening watching it sit silent for a full ten seconds, that fast failure felt like progress.

Earlier that day, I had changed a setting on a Windows computer because some outside websites were hanging before they loaded. The change made those pages behave. I thought I had put one small annoyance behind me.

By that evening, a different site had become slow in a much more obvious way. Every visit from the public side waited ten seconds before giving up. Yet when I tried the application directly on the same computer, it answered immediately. That is the sort of contrast that can make a person doubt their own eyes. The thing was clearly alive, but it was still acting unreachable.

There was one bit of jargon behind this: IPv6. It is simply a newer way computers can choose an address when they are trying to talk to each other. My morning change told this computer to prefer the older route in most cases. That solved the original problem, but it also changed how a hidden bad path behaved. Before, the bad path failed quickly. Afterward, it waited in silence.

The site did not go straight from a visitor to the application. It passed through a few handoffs, like a phone call being transferred from the front desk to a back office and then to the person who can actually answer the question. A delay at any handoff can feel, to the visitor, like the whole place has disappeared.

I did not want to guess which handoff was at fault. I used a small timed check that asked each stop for a response and printed only two things: whether it got one, and how long it took. Starting at the application itself, I got a quick answer. That ruled out the innermost part.

The next check found a service that was listening only on one kind of local route. It rejected the other kind almost immediately, in about 37 milliseconds. That looked like the culprit, so I changed its settings to make the route explicit. It was sensible cleanup. It was also not the fix.

That wrong turn cost more than a few minutes. It cost the kind of patience that drains away when you have a neat explanation, make a neat repair, and see the exact same ten-second wait afterward. The most tempting answer had been real, just not relevant to the page that was actually slow.

The actual problem was a short line in the site’s forwarding instructions. It used a familiar computer shortcut that sounds like one place, the way “home” sounds like one address. On this computer, though, it was really a list of possible routes. The forwarding step tried the first one. The application was listening on the other one.

Before the morning setting change, that first try was refused quickly, so the computer moved on to the next route and the page loaded. After the change, the first try did not say no. It just disappeared into a dead end and used the whole ten-second allowance before the computer tried the route that worked.

Nothing had to be wrong with the page itself for the page to feel broken. Nothing had to be wrong with the written instructions, either. The shortcut was spelled correctly. The application was running. The public-facing part of the site was doing its job. The trouble was in the gap between two things that each looked reasonable on their own.

The repair was almost comically small. I replaced the ambiguous shortcut with the specific local route the application was actually using. Then I restarted the public-facing service so it would read the changed instruction.

That is when the 18-millisecond response arrived. It was a temporary unavailable message caused by the restart, not a finished page, but its speed mattered. The ten-second dead end was gone. After a separate cleanup of the restarted application process, the page loaded normally in about 50 milliseconds.

This was the lesson I had to earn the slow way: speed is information. A quick failure and a long silence are not the same problem wearing different clothes. One tells you that a door is shut. The other tells you that you may be waiting at the wrong door with no one there to answer.

The wasted repair, the loopback setting change, cost more than the ten seconds it never fixed: it cost an evening spent trusting a 37-millisecond refusal that had nothing to do with the page. What actually broke the silence was one word in a forwarding rule resolving to two routes instead of one, and the fact that the working fix collapsed a ten-second wait into a roughly 50-millisecond load is the only proof that matters. Timing was never a symptom here; it was the whole diagnosis, and it stayed the diagnosis right up until the moment the second route disappeared from the instructions for good.

dxdev LESSON · paste into your AI coding agent
LESSON: When something feels slow, time each handoff separately, because a quick refusal and a long silence are different problems
SOURCE: dxdev.com/blog/2026-05-07_ten-second-wait-that-came-from-a
WHAT HAPPENED: Earlier in the day a setting on a Windows computer was changed to prefer the older route over IPv6 because some outside websites were hanging. By evening every public visit to a different site waited ten seconds, while the application answered instantly when tried directly on the same computer. The site passed through a few handoffs, and a small timed check per stop showed the application was fast. A service listening on only one kind of local route rejected the other kind in about 37 milliseconds, and changing it was sensible cleanup but not the fix. The real cause was a shortcut name in the forwarding instructions that is really a list of possible routes: the forwarding step tried the first one, the application listened on the other, and after the morning change the first try no longer refused quickly but hung for the full ten second allowance. Replacing the shortcut with the specific route the application used, and restarting the public facing service, removed the wait.
THE RULE: Speed is information. Time each handoff separately, treat a fast refusal and a long silence as different failures, and use explicit addresses in forwarding rules instead of shortcut names that resolve to a list of routes.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
  1. Any proxy, forwarding, or upstream setting that uses a name like localhost instead of the explicit address and port the application listens on.
  2. Any system network setting changed to fix one site with no re-timing of the other services on the same machine afterward.
  3. Any slow page diagnosis with no per hop timing for the application, each proxy or forwarder, and the public front end.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.