When DNF feels slow on Fedora, the wait usually comes from two places: conservative download behavior and mirror selection that does not match your network path well. To increase DNF speed on Fedora, enable parallel downloads and test fastestmirror so large updates and multi-package installs spend less time waiting on one package at a time.
Fedora 44 and Fedora 43 use DNF5 through the standard dnf command, and the cleanest way to change these options is with dnf config-manager setopt instead of opening /etc/dnf/dnf.conf in an editor first. That keeps the change repeatable, shows the active runtime values clearly, and makes it easy to lower max_parallel_downloads or turn fastestmirror=True back off later.
Know What DNF Speed Settings Change on Fedora
These settings tune package downloads, not every part of Fedora performance. max_parallel_downloads changes how many packages DNF can fetch at once, while fastestmirror changes how DNF chooses from the mirror list during a transaction. They will not fix browser downloads, Wi-Fi problems, or general internet speed outside DNF.
They can shorten normal update downloads and the download phase of a release upgrade, but they do not make dependency solving, RPM scriptlets, offline reboot work, or SELinux relabeling faster. If you are trying to estimate how long a Fedora system upgrade takes, treat these settings as download tuning only.
fastestmirror=True also does not pin Fedora to one permanent mirror. Fedora repository files normally use metalink or mirrorlist data; fastestmirror only changes the mirror choice for the current repository set. Systems that must use an internal mirror need repository configuration, not a generic speed tweak.
DNF and APT are not useful one-to-one benchmarks here. Perceived package-manager speed usually comes from metadata size, mirror latency, transaction size, enabled repositories, and how many packages can download at once.
Configure Faster DNF Downloads on Fedora
Start with a safe refresh so you can compare later runs against current metadata. The --assumeno flag previews the transaction and exits before DNF installs anything:
sudo dnf upgrade --refresh --assumeno
System-wide DNF configuration changes need
sudo. If your Fedora account is not configured for it yet, follow the guide on adding a user to sudoers on Fedora or run the commands as root.
DNF should refresh repository metadata, calculate the transaction, and stop before installation. Seeing Operation aborted by the user is expected with --assumeno, because the flag declines the transaction after the preview.
On Fedora, DNF defaults to max_parallel_downloads=3 and fastestmirror=False. That is safe and predictable, but it can leave obvious download speed on the table when your connection is stable and the mirror path is decent.
DNF5 documents both tuning options in its configuration reference, and the config-manager reference documents the setopt and unsetopt workflow for persistent config changes. The two settings to change are:
| DNF setting | DNF5 default | Good starting value | What it changes |
|---|---|---|---|
max_parallel_downloads | 3 | 10 | Lets DNF fetch multiple packages at the same time. |
fastestmirror | False | True | Tests mirror latency and prefers low-latency mirrors for that transaction. |
Use
max_parallel_downloads=10as a starting point, not a benchmark target. If downloads retry, time out, or make a weak connection feel worse, lower the value before changing anything else.
Apply both settings in one DNF5-native command:
sudo dnf config-manager setopt max_parallel_downloads=10 fastestmirror=True
This writes the values to your main configuration file at /etc/dnf/dnf.conf. If you inspect the file afterward, you should see these lines under [main]:
[main] fastestmirror=True max_parallel_downloads=10
Now verify the active runtime values instead of only checking the file contents:
dnf --dump-main-config | grep -E '^(fastestmirror|max_parallel_downloads) = '
On Fedora 44, enabled values appear like this:
fastestmirror = 1 max_parallel_downloads = 10
The runtime dump shows booleans as 1 and 0, so fastestmirror = 1 means the option is enabled even though /etc/dnf/dnf.conf stores it as True.
Decide Whether fastestmirror Helps DNF on Fedora
fastestmirror is worth trying, but do not treat it like a guaranteed fix. Fedora repository configuration already points DNF at mirror metadata, so this option is really a tiebreaker for your network path, not a guaranteed speed boost.
DNF5 bases fastestmirror on TCP socket latency, not a measured package download benchmark. A mirror can respond quickly and still deliver large packages slowly, which is why the setting needs a few real update-cycle tests on your connection.
- Usually worth trying: home broadband, wired desktops, or systems where package downloads are clearly the slow part of the transaction.
- Often not worth it: VPNs, corporate proxies, and high-latency links where mirror probing adds more delay than it saves.
The blunt version is simple: keep fastestmirror=True only if a few real update runs feel faster. If it slows metadata refresh or makes no visible difference, turn it back off and keep the parallel download change.
Tune max_parallel_downloads for DNF on Fedora
DNF caps max_parallel_downloads at 20, but higher is not automatically better. Start with 10, run a few normal update cycles, and change only if your connection and mirror path clearly benefit from it.
- 5: Good fallback for unstable Wi-Fi, VPN links, or metered connections that start retrying when too many downloads open at once.
- 10: Best starting point for most Fedora desktops and small servers.
- 15: Worth testing on fast, low-latency connections that keep DNF busy during large updates.
- 20: DNF’s maximum value. Use it only if repeated update runs actually finish faster and your connection stays stable.
To tune only the parallel download count without touching mirror selection again, run:
sudo dnf config-manager setopt max_parallel_downloads=15
Then re-run the runtime check to confirm DNF is using the new value:
dnf --dump-main-config | grep '^max_parallel_downloads = '
max_parallel_downloads = 15
Troubleshoot Slow DNF Downloads on Fedora
Fedora Release Upgrades Still Take a Long Time
Parallel downloads can only affect the package download part of a Fedora release upgrade. The offline reboot still has to install packages, run scriptlets, rebuild caches, and sometimes relabel SELinux contexts, so these settings are not a promise that the whole version upgrade will finish quickly.
DNF Still Shows Default Values on Fedora
If DNF still behaves like nothing changed, check the active main configuration first instead of reopening the file:
dnf --dump-main-config | grep -E '^(fastestmirror|max_parallel_downloads) = '
If you still see these defaults, DNF is not using your overrides yet:
fastestmirror = 0 max_parallel_downloads = 3
Reapply both settings and verify again:
sudo dnf config-manager setopt max_parallel_downloads=10 fastestmirror=True
dnf --dump-main-config | grep -E '^(fastestmirror|max_parallel_downloads) = '
DNF config-manager Is Missing on Fedora
Current Fedora systems usually include the DNF5 plugin commands, but stripped-down installs can miss config-manager. Install dnf5-plugins, then check that DNF lists the plugin commands before retrying the tuning step:
sudo dnf install dnf5-plugins
dnf config-manager --help
Relevant output includes the setopt and unsetopt subcommands:
Usage: dnf5 [GLOBAL OPTIONS] config-manager <COMMAND> ... Commands: setopt unsetopt
Keep dnf5-plugins installed if you want to manage DNF options with config-manager.
fastestmirror Makes Fedora Metadata Refreshes Slower
If sudo dnf upgrade --refresh spends longer probing mirrors than it saves during downloads, turn off only fastestmirror and keep the parallel download change:
sudo dnf config-manager unsetopt fastestmirror
dnf --dump-main-config | grep -E '^(fastestmirror|max_parallel_downloads) = '
You should see fastestmirror return to the default while max_parallel_downloads stays in place:
fastestmirror = 0 max_parallel_downloads = 10
DNF Parallel Downloads Trigger Retries on Fedora
If your connection starts retrying packages or feels less stable after increasing the download count, lower it and test again on the next update:
sudo dnf config-manager setopt max_parallel_downloads=5
dnf --dump-main-config | grep '^max_parallel_downloads = '
A lower value should appear immediately:
max_parallel_downloads = 5
Reset DNF Download Settings on Fedora
If the tuning does not help on your network, remove both overrides and let DNF fall back to its defaults:
sudo dnf config-manager unsetopt max_parallel_downloads fastestmirror
Then verify that DNF is back on the stock Fedora values:
If config-manager says an option is not present, that only means the override was already absent from the main config file. The runtime check is the proof that DNF is back on its default values.
dnf --dump-main-config | grep -E '^(fastestmirror|max_parallel_downloads) = '
fastestmirror = 0 max_parallel_downloads = 3
If you added the lines manually in /etc/dnf/dnf.conf instead of using config-manager, remove those two lines from the file and run the same verification command again.
Conclusion
DNF is now set to fetch more packages in parallel, with mirror probing available only when it helps your network. Keep the download count at a stable value, disable fastestmirror if refreshes slow down, and use DNF5 install examples on Fedora or DNF Automatic on Fedora for the rest of your package workflow.


Formatting tips for your comment
You can use basic HTML to format your comment. Useful tags currently allowed in published comments:
<code>command</code>command<strong>bold</strong><em>italic</em><blockquote>quote</blockquote>