Back to blog
FILE 0x96·WHEN THE UPSTREAM CDN JUST ISN'T REACHABLE FROM YOUR HOUSE

When the upstream CDN just isn't reachable from your house

April 30, 2026 · networking, windows

I needed to download Windows 11 25H2 ISO bits via the UUP build flow. Aria2c started fine, pulled the small metadata files (a few hundred KB total), and then sat at zero on the actual ESDs.

What was happening

aria2c showed CN:0 DL:0B for the bigger files. The small files (the manifest XMLs and a handful of language packs) had finished within seconds. Anything larger than a couple of MB was just stuck.

$ ss -tnp | grep SYN-SENT
SYN-SENT 0 1 <lan-ip>:55012 199.232.214.172:443
SYN-SENT 0 1 <lan-ip>:55013 23.48.246.138:443

Those IPs belong to Fastly and Akamai. Both edges that Microsoft uses for big-blob delivery on UUP. Both stuck in SYN-SENT — TCP handshake going out, no response coming back.

What I found

I tried it from three different machines on the same network: the Mac mini, a Linux LXC, an old laptop. All three did exactly the same thing — small files fine, large files at zero. The Mac mini in particular got past the first 10 minutes with zero bytes on the ESDs and was clearly going nowhere.

So I ran the same downloads through a Tinyproxy instance I had elsewhere on my network. Tinyproxy itself was healthy. It successfully forwarded the requests upstream. The upstream connections from Tinyproxy also stuck in SYN-SENT to the same Fastly and Akamai IPs.

That's the giveaway. The bottleneck isn't my router, my Mac, the proxy, or any LXC. It's upstream of all of those — my ISP's peering arrangement with Fastly and Akamai for those specific edge POPs isn't working. Small files came from a different POP that did peer cleanly. Large files were sharded across the broken POPs.

You can confirm by trying the exact same URLs from a completely different network. I tried later from a coffee shop and the same aria2c config pulled all 5 GB in about six minutes. Home network: zero bytes after an hour.

The fix

There isn't one I can apply locally. ISP peering issues are not a thing you fix at the customer side. The realistic options were:

  1. Wait for upstream peering to recover (it did, about three days later).
  2. Run the same download from a different network and copy the result home.
  3. Use a VPN exit on a network that did peer cleanly — but this defeats the point if you're downloading something where the source IP matters, and it's slower than just driving the file home.

I went with option 2. Pulled the ESDs from a hotspot, dumped them to a USB drive, walked them inside.

What I'd do differently

The diagnostic flow here is the keeper. When a download "just doesn't work" against a CDN, the question to answer first is: does it work against the same edge IPs from a different network? If yes, it's upstream peering and there's nothing to debug locally. If no, the problem is on your end. I burned about a day before I ran the test on a different network, which would have eliminated half my hypotheses immediately.

# is it just me, or is it Fastly?
curl -v --resolve dl.example.com:443:199.232.214.172 \
  https://dl.example.com/big.bin -o /dev/null
# then run the same from a phone hotspot. if it works there, you're done debugging.