When the network is the problem

01The errors, word for word

Four different lines, three different stories. The first two are transient CDN weather — a cache server timed out or dropped the connection mid-chunk. The third is a local TLS problem (section 05). The fourth is the interesting one: every reachable server was asked for a chunk and none had it (section 04). Knowing which story you're in saves the evening. (If there's no error at all — the run just sits frozen on a "Pre-allocating" line with the network idle — that isn't weather either; it's a stuck or corrupt download, a disk problem rather than a CDN one.)

A fifth family fails before any of those — failures reaching Steam's coordinator (CM) servers at all, which happens at startup, prior to the CDN:

These aren't CDN problems — the download never started. They mean the tool couldn't log in to Steam's servers: a firewall or VPN blocking the connection, Steam itself having an outage, or (on a headless box) no network route out. If one of these connection failures is instead followed by a hard crash or a .NET stack trace, that's the other half of the story — older builds could dereference a null session after a failed connect, decoded on the crashes & exceptions page. Most common on locked-down servers; the cheap moves in section 02 and the firewall note in section 05 apply, and if the Steam status pages show an outage, just wait. Distinct symptom worth naming: a manifest that fails with a "connection error" while your internet plainly works is often not networking at all — on recent builds an Access-Denied (401) can surface looking like a connection failure. If the rest of your downloads are fine and only one old manifest "can't connect," suspect the request-code gate, not your network.

02First moves — the cheap ones

• Just rerun it. Nine times out of ten this is all I do, and it's the single most effective fix for chunk timeouts, costing nothing: downloads resume chunk-wise, so a rerun picks up where the failure happened and very often lands a healthier server. DepotDownloader also remembers misbehaving content servers between runs, so attempt two is genuinely smarter than attempt one, not just luckier.
• Update the tool. CDN-side protocols shift, and several historical waves of "everyone's downloads broke" were fixed by a release. If your binary is months old and the errors started suddenly, update before debugging anything.
• Check whether it's Steam, not you. steamstat.us takes ten seconds. If the client's downloads are also struggling, no flag will out-engineer an outage.

03Slow is not broken

"My download crawls" is the most common network complaint, and most of the time nothing is wrong — you got assigned a tired cache server. The knobs below are the quick version; the full throughput playbook (every speed flag, ISP throttling, the old-build penalty) lives on the slow-downloads page. The knobs, in the order worth turning:

-max-downloads (default 8) sets parallel chunk fetches. On a fat home pipe, raising it to 16 or so often helps simply by spreading load over more connections; on Wi-Fi or shared uplinks, lowering it can paradoxically speed things up by stopping the connections from strangling each other. -cellid changes which regional server cluster you talk to — when your local cell is having a bad week, borrowing a neighbouring region's is the legitimate version of "change download region" from the Steam client's settings. It's experiment territory: cell IDs aren't documented, but SteamDB discussions list common ones, and two or three tries tell you whether geography was the issue.

About ISP throttling, honestly: some providers do deprioritize bulk CDN traffic at peak hours. The diagnostic (not the fix) is comparison — if speeds are fine at 7 a.m. and dire at 9 p.m., or a VPN suddenly triples throughput, you've met traffic management, and your options are the time of day, the VPN, or a chat with the ISP. And if the real problem is that you re-download the same depots to many machines on one LAN, stop hitting the internet at all: -use-lancache routes through a local Lancache and turns twenty downloads into one — the Lancache reference covers the setup.

04The chunk that isn't there

Failed to find any server with chunk… means the manifest you're downloading references a piece of data no reachable content server currently holds. For current builds this is rare and almost always transient — caches repopulate; retry in an hour, try another -cellid. For old manifests it's the quiet second front of the preservation problem: a historical manifest can still get a request code and yet point at chunks the CDN has let age out of circulation. Persistent missing-chunk failures on a years-old build, across regions and days, may mean that build is no longer fully retrievable — which is the same lesson the status page keeps teaching: the archive you can still take is the one worth taking today. Before concluding that, though, rule out the boring cause: a flaky connection produces the same line for chunks that exist — make sure plain retries and another cell genuinely fail first.

05SSL, firewalls & other local suspects

• "The SSL connection could not be established." Three usual culprits: an antivirus or corporate proxy doing TLS inspection (whitelist DepotDownloader or the Steam CDN domains), a badly wrong system clock (certificates won't validate — check the date), or a museum-grade OS without modern TLS. The tool talks ordinary HTTPS; anything that meddles with HTTPS can break it.
• Firewalls. DepotDownloader needs outbound connections — the Steam network plus HTTP(S) to CDN hosts. Windows users have hit the case where the firewall silently eats the connection (the "should I disable my firewall?" issue #306 energy). Don't disable it — add an allow rule for the executable. Same logic for strict routers and VPN kill switches.
• Corporate networks. Mandatory proxies that only speak HTTP CONNECT to port 443, blocked non-browser traffic, SNI filtering — if your office network breaks the Steam client, it breaks this tool identically. The honest answer there is a different network, not a different flag.

If the symptom survives all of the above — exact command, full output, your region and ISP into the issue tracker; network reports without those four facts mostly collect "cannot reproduce". And if the failure is a 401 rather than a timeout, you're on the wrong page — that's policy, not weather.