Learn Aria2 - Multi-connection & Multi-source

#Introduction

Up to episode 3, all your downloads ran with aria2's default settings. As it turns out, those defaults are deliberately "braked": -x (connections per server) is 1 and -s (number of segments) is only 5. This episode is about releasing the brakes — tapping into aria2's real power: multi-connection and multi-source.

Imagine two delivery routes: one truck carrying everything down a single toll lane, and a convoy of trucks where each vehicle carries part of the load across several lanes at once. For large files, the convoy is clearly faster. This episode teaches you to build that convoy — and to choose when it's worth doing.

#Why One Connection Is Not Enough

A single TCP connection works like a one-lane toll road. No matter how much road (bandwidth) is available, one vehicle never uses it fully — especially on connections with high latency, like cross-continental networks or VPNs. Every "request and wait for the answer" cycle takes time, and a single connection can't send the next chunk of data before receiving confirmation of the previous one. That's where parallel connections win: while one segment waits, other connections keep sending — the road gets fully utilized.

#Releasing the Brakes: `-x`, `-s`, and `-k`

These three options are the main control knobs of multi-connection:

Option	Long Name	Default	Purpose
`-x`	`--max-connection-per-server`	1	Maximum connections per server
`-s`	`--split`	5	Maximum number of segments
`-k`	`--min-split-size`	20M	Minimum size per segment for the file to be split

How the three work together closely:

-x opens the door to parallel connections to the server — without it, segments are only downloaded sequentially.
-s determines how many segments the file has. The actual segment count won't exceed -s.
-k is the minimum threshold: aria2 only splits the file if the file size divided by the segment count is still larger than -k. Small files therefore aren't split — the connection overhead would be more wasteful.

The most common combination:

16 connections, 16 segments - the popular combination

aria2c -x 16 -s 16 https://example.com/ubuntu.iso

Tip

Notice the synergy: -x 16 opens 16 connections, -s 16 splits the file into 16 segments — so each connection carries one segment in parallel. If you only use -x 16 without raising -s, the segment count stays at 5 and the extra connections aren't used optimally.

The long form is equivalent — aria2c --max-connection-per-server=16 --split=16 URL — so pick whichever reads better. Or put it in the config file so it applies to all sessions:

~/.aria2/aria2.conf snippet for multi-connection

max-connection-per-server=16
split=16
min-split-size=20M

#Multi-Source: Many Mirrors at Once

Multi-connection boosts speed from one server. Multi-source boosts speed — and resilience — by fetching the same file from many servers at once. If one mirror is slow or down, the segments assigned to it are moved to other mirrors. Like a convoy that can pick up goods from several warehouses at once.

The way to tell aria2 about several mirrors is an input file with -i. Write all mirror URLs on a single line separated by TAB characters:

mirrors.txt - one file, three mirrors (tab-separated)

https://mirror-1.example.com/ubuntu.iso	https://mirror-2.example.com/ubuntu.iso	https://mirror-3.example.com/ubuntu.iso

Then run:

Download from three mirrors with 4 connections per server

aria2c -i mirrors.txt -x 4 -s 16

Because all three URLs point to the same file, aria2 distributes the segments among the three servers — up to 12 parallel connections in total. If one mirror fails, the download doesn't abort: its segments are thrown to other mirrors.

Warning

The important rule of multi-source: all URLs on one line must point to the same file. A line containing different files will make the download fail. To download different files, use separate lines. This TAB format is also the basis of Metalink, which we'll cover automatically in episode 12.

One extra option often paired with it: --http-accept-gzip=true — makes aria2 accept gzip-compressed responses from servers that support them, saving bandwidth on text-based files. It doesn't apply to every file, but it costs nothing to enable.

#When to Use It: Use Cases

Multi-connection and multi-source have the biggest impact in these scenarios:

Scenario	Benefit
Large ISO downloads (Linux distros)	Uses many mirrors at once, far faster than a single source
Build artifacts from CI/CD	Large artifacts are fetched quickly without blocking the pipeline
Datasets on high-latency connections	Parallel segments maximize the use of available bandwidth
Repeated downloads from servers with per-connection rate limits	Several connections together use the available quota

But not every file needs splitting. The rule of thumb: files under tens of MB don't need large -x and -s — connection overhead just wastes time. Save the compute and bandwidth for files that are genuinely large.

#Common Pitfalls

Raising -x without raising -s. Extra connections aren't used optimally if the segment count stays low. Balance both.
-k larger than the file size. The file won't be split at all. Set -k below the size of the files you want to split.
The server doesn't support Range requests. Without Range support (206 Partial Content), the file can't be split — that's a server limitation, not an aria2 bug.
Multi-source with different files on one line. All URLs on a line must point to the same file, or the download fails.

#Closing

In episode 4 you released aria2's brakes: understanding why one connection isn't enough, mastering -x (connections per server), -s (number of segments), and -k (minimum segment size), and downloading from many mirrors at once via a multi-source input file and --http-accept-gzip.

Key takeaways:

The default -x = 1 is the "brake" that keeps downloads on one connection; -x 16 -s 16 releases it.
-k (default 20M) sets the file-splitting threshold — small files don't need splitting.
Multi-source: mirror URLs on one line (TAB-separated) = one file from many servers.
Use multi-connection/multi-source for large files; don't for small ones.

In the next episode, episode 5, we'll cover resume, continue & download control — resuming interrupted downloads with -c and the role of the .aria2 control file, throttling speed with --max-download-limit, limiting concurrent downloads with --max-concurrent-downloads, and an introduction to pause-resume via RPC. See you in episode 5!