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.
Current Fedora releases use DNF5, 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.
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
This guide uses
sudofor system-wide DNF changes. 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.
A preview run on Fedora 43 looks like this:
Updating and loading repositories: Fedora 43 - x86_64 100% | 619.0 B/s | 3.1 KiB | 00m05s Fedora 43 - x86_64 - Updates 100% | 2.2 KiB/s | 8.7 KiB | 00m04s Fedora 43 openh264 (From Cisco) - x86_ 100% | 1.1 KiB/s | 986.0 B | 00m01s Repositories loaded. Total size of inbound packages is 58 MiB. Need to download 58 MiB. Operation aborted by the user.
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.
DNF documents both tuning options in its configuration reference. Use this table as the quick version before applying them:
| DNF setting | Fedora 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. |
Fedora already gives DNF a list of working mirrors, so
fastestmirror=Trueis worth testing but not worth treating as gospel. If refreshes feel slower after enabling it, disable that option and keep parallel downloads.
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 43, 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 magic fix. Fedora already starts from a list of working mirrors, so this option is really a tiebreaker for your network path, not a guaranteed speed boost.
- 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.
If you want 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
DNF Still Shows the Default Values
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 the defaults below, 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) = '
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
Parallel Downloads Trigger Retries or Timeouts
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:
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.
Frequently Asked Questions
No. Fedora already starts from a list of working mirrors, so fastestmirror is a network-specific optimization rather than a guaranteed upgrade. It can help on some connections, but on VPNs, proxies, or high-latency links it may add more mirror probing time than it saves.
Parallel downloads only help when package downloads are the real bottleneck. Slow metadata refresh, mirror latency, proxy overhead, or an unstable connection can still dominate the transaction. In those cases, lowering max_parallel_downloads or disabling fastestmirror may work better.
Conclusion
DNF should no longer crawl through updates one package at a time. Keep max_parallel_downloads at the highest value your connection handles cleanly, treat fastestmirror as something to test instead of blindly trust, and use DNF5 install examples on Fedora, DNF5 system upgrades on Fedora, or DNF Automatic on Fedora when you want to push the rest of your package workflow further.
Formatting tips for your comment
You can use basic HTML to format your comment. Useful tags currently allowed:
<code>command</code>command<strong>bold</strong><em>italic</em><blockquote>quote</blockquote>