Sometimes the simplest command reveals the truth hiding beneath the surface. My Debian 13 environment inside WSL had been unusually slow for days.

Not broken, not throwing warnings, but hanging on apt update long enough for me to lose patience.

“Reading package lists…” would freeze, repository connections took forever, and every small task felt like it was wading through molasses.

I suspected DNS, but I’ve learned not to blame DNS until I see the evidence myself. So I reached for the most basic diagnostic tool,

ping.

I started with Cloudflare’s 1.1.1.1 to see if the outbound path was clean.

PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: time=39.1 ms
64 bytes from 1.1.1.1: time=27.7 ms
64 bytes from 1.1.1.1: time=34.9 ms
Code language: JavaScript (javascript)

Stable, no packet loss, nothing suspicious. Then I pinged the Debian Fastly mirror.

PING debian.map.fastlydns.net (***) 56(84) bytes of data.
64 bytes from ***: time=19.1 ms
64 bytes from ***: time=16.4 ms
64 bytes from ***: time=486 ms
Code language: JavaScript (javascript)

The story appears in the third packet, almost half a second of delay. That single blip told me everything that apt had been screaming silently.

The network inside the office wasn’t clean. Something,congestion, traffic shaping, SSL inspection, policy based routing, was introducing inconsistent latency.

For regular browsing nobody would notice, but package managers certainly do.

At this point the problem wasn’t Debian and it wasn’t WSL. It was the inconsistent outbound path to public mirrors.

But inconsistency doesn’t mean helplessness.

There are ways to minimize the damage, and that’s when I started adjusting the environment rather than fighting the network.

The first fix was preventing WSL from overwriting /etc/resolv.conf every time it starts.

WSL loves injecting Windows DNS resolvers, and in many corporate networks, those DNS servers are either filtered or slow.

Inside Debian I created

sudo nano /etc/wsl.conf

And added

[network]
generateResolvConf = false
Code language: JavaScript (javascript)

After shutting down WSL from Windows:

wsl --shutdown

I created my own resolver file:

sudo rm -f /etc/resolv.conf
sudo nano /etc/resolv.conf

And set Cloudflare manually:

nameserver 1.1.1.1
nameserver 1.0.0.1
options edns0
Code language: CSS (css)

Then I locked it so nothing, neither WSL nor a package, could silently revert it

sudo chattr +i /etc/resolv.conf

With DNS fixed, I turned my attention to the next silent culprit, IPv6.

Corporate networks often broadcast IPv6 routes that don’t actually work.

apt tries IPv6 first, fails silently, and gives the illusion of “stuck on reading headers.”

So I forced apt to use IPv4.

echo 'Acquire::ForceIPv4 "true";' | sudo tee /etc/apt/apt.conf.d/99force-ipv4
Code language: PHP (php)

After that, everything felt lighter. apt update flowed more smoothly, package installation no longer paused, and general network activity inside WSL became more predictable.

It didn’t magically bypass corporate constraints, but it turned an unusable system into a functional, stable environment.

What I love about this kind of debugging is how honest the system is if you listen carefully.

A single half-second ping spike can explain hours of inconsistent performance.

A resolver file quietly replaced by WSL can sabotage an entire session. An unused IPv6 route can stall apt without ever throwing an error.

All the clues were there, I just had to slow down enough to read them.

If you ever face slow Debian or Ubuntu inside WSL, especially in an office network, start simple.

Ping external DNS.

Ping your mirrors.

ook for jitter.

Then fix DNS, force IPv4, and regain control of /etc/resolv.conf.

Most of the time, the solution isn’t about changing Linux, it’s about understanding the path it must travel to reach the outside world.

And sometimes, truly, one ping is all you need to see the full picture.