Race the mirrors before you commit to a 4 GB download

I needed a 4.3 GB Xiaomi fastboot ROM. Found it on the official Xiaomi CDN at bigota.d.miui.com, verified the URL was alive (HTTP/1.1 200 OK, correct Content-Length), kicked off curl in the background, walked back two minutes later:

0 4080M    0 1981k    0     0  21796   0 54:32:03

22 KB/s. 54 hours to download a single ROM. The CDN had decided I wasn’t important today.

Instinct said “try a different mirror,” but Xiaomi has a half-dozen *.d.miui.com endpoints (bigota, cdnorg, hugeota, bn, etc.) plus an Aliyuncs OSS bucket in Singapore, and I had no idea which would be fast from where I was. Picking one at random and waiting two minutes per attempt would burn the afternoon.

So I raced them. A small loop hitting each mirror with a 5-second curl --max-time 5 -o /dev/null and grabbing the reported speed:

for url in "${MIRRORS[@]}"; do
  speed=$(curl -sL --max-time 5 -o /dev/null \
    -w "%{speed_download}" "$url")
  echo "$url -> ${speed} B/s"
done

Five seconds per mirror, full picture in 30 seconds. Results:

The Singapore OSS bucket was ~2000× faster than what I’d been waiting on. Killed the slow curl, restarted on the fast mirror, and the whole 4 GB came down in 90 seconds. MD5 matched the published one on the first try.

The takeaway is dumb and should be obvious: for any download big enough that you’d notice it failing, race the mirrors first. The 30-second probe pays for itself the moment one of the candidates is throttled, geo-routed badly, or just having a bad day. I knew this in principle and still defaulted to “the official one will be fine.” It usually is. Until it isn’t, and 22 KB/s is technically progress, so nothing alerts you — you just wait.

Now in the repo as a habit, not a one-off.