This is the settings half of a Usenet setup, and it is where most “slow” complaints actually come from: too few connections for the line, an article cache sized for a 2015 connection, or post-processing fighting the download for disk. None of that is the provider’s fault, and all of it is a five-minute fix.

Pick your client, your line speed and your provider below, and this builds a sane starting config — the connection count to use, the server settings, the cache, and the PAR2/unpack options. Everything it produces is explained underneath, so you know why each number is what it is.

Treat the output as a starting point, not a guarantee. It removes the common self-inflicted bottlenecks; it cannot fix a backbone or a route.

What each setting does

Connections

Each Usenet connection is a single TCP stream to your provider. One stream rarely saturates a fast line on its own — a well-peered connection typically sustains roughly 10–25 Mbit/s depending on the backbone and your route, so saturating a gigabit line takes somewhere in the region of 36–75 streams. Too few connections is the single most common cause of "my provider is slow", and the fix costs nothing. Set the suggested figure as a floor, then test and raise it only if you still are not reaching line speed.

Port 563 and SSL

563 is the standard encrypted Usenet port. Leaving SSL on is not optional on a UK line: unencrypted Usenet traffic is both visible in transit and, on some ISPs, shaped. Every provider worth using supports 563.

Article cache

The client pulls articles from the network and hands them to disk. The article cache holds them in memory between those two steps. On fast lines it is what stops the disk becoming the bottleneck: with too small a cache, hundreds of Mbit/s of articles queue up waiting on disk writes. Gigabit lines generally want 512 MB–1 GB.

PAR2 verification and repair

Run PAR2 check and repair automatically after each download. If a provider is missing a few articles, the repair blocks in the release fix it — but only if the client actually runs the repair. Skipping it means you find out at extraction that a file is broken, by which point the article is long gone. See the PAR2 repair guide for the underlying mechanics.

Direct unpack

Where the client supports it (NZBGet's DirectWrite/Direct unpack, SABnzbd's direct unpack), it unpacks while downloading rather than after it, cutting the post-processing wait on large releases. It only pays off when the download is healthy and completes, so it is safe to leave on.

Frequently asked questions

How many connections should I set?

Enough to saturate your line, and no more. A well-peered Usenet connection typically sustains roughly 10–25 Mbit/s depending on the backbone and your route, so a 900 Mbit/s line generally needs somewhere in the region of 36–75 connections. Set the number the tool suggests as a floor, then raise it only if you are not reaching line speed.

Why port 563 and SSL?

Port 563 is the standard SSL port for Usenet. Unencrypted Usenet traffic is both slower on some UK ISPs and visible in transit; encrypted port-563 connections are the single best defence against ISP traffic shaping. Leave SSL on unless your provider specifically tells you otherwise.

What article cache should I use?

Higher cache smooths out large transfers on fast lines by keeping articles in memory rather than hammering the disk. On a gigabit line, 512 MB–1 GB is a reasonable range. As a general rule, the faster your line and the more concurrent downloads, the larger the cache you want.

Do these settings guarantee full line speed?

No. Throughput depends on your provider's backbone, your route to it, and your client's post-processing. These settings remove the common self-inflicted bottlenecks — too few connections, a tiny cache, PAR2 run at the wrong time — but the backbone and routing are the provider's side of the deal.

Comparing downloaders first? Read SABnzbd vs NZBGet. Full setup, step by step: the 2026 setup guide. No provider yet? Use the provider finder.