The 37 Millisecond Refusal That Fixed Nothing

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

The morning change that set it up

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

By evening, a different site had gone slow in a much more obvious way. Every visit from the public side waited ten seconds before giving up. Yet when we tried the application directly on the same computer, it answered immediately. The thing was clearly alive, but it was acting unreachable.

Behind this was one piece of jargon: IPv6. It is a newer way computers can choose an address when they talk to each other. Our 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.

Timing each handoff

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

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

The repair that fixed nothing

The next check found a service listening on only one kind of local route. It rejected the other kind almost immediately, in about 37 milliseconds. That looked like the culprit, so we 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. We had a neat explanation, made a neat repair, and saw the exact same ten-second wait afterward. The 37-millisecond refusal was real. It just had nothing to do with the page that was slow, and we spent an evening trusting it.

One word in a forwarding rule

The 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 a list of possible routes. The forwarding step tried the first one. The application was listening on the other.

Before the morning 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 disappeared into a dead end and used the whole ten-second allowance before the computer tried the route that worked.

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

The fix, and the 18 milliseconds

The repair was small. We replaced the ambiguous shortcut with the specific local route the application was using. Then we 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.

A quick failure and a long silence are different problems. One tells you a door is shut. The other tells you that you may be waiting at the wrong door with no one there to answer. The drop from a ten-second wait to a load of about 50 milliseconds was the only proof that mattered, and timing was the whole diagnosis.

After any network setting change, re-test the sites that depend on that machine, because a change that fixes one problem can turn a fast failure elsewhere into a ten-second wait. When something is slow, ask for timings at each handoff before accepting an explanation.

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/everyday-ai/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.