How to fix W: Failed to fetch URL Connection timed out in APT

APTBEGINNERMEDIUMUpdated Jun 24, 2026· 660 views

The 'W: Failed to fetch URL Connection timed out' warning appears when APT cannot reach a repository within its timeout, usually due to network issues, slow or dead mirrors, or DNS problems.

Quick fix

Fixes W: Failed to fetch URL Connection timed out

# Test connectivity to a public DNS
ping -c 3 8.8.8.8

# Test connectivity to a major site
ping -c 3 google.com

# Test HTTPS connectivity to a repository
curl -v https://archive.ubuntu.com/ubuntu/dists/jammy/Release
  1. Test your internet connection
  2. Clean the APT cache
  3. Switch to a faster APT mirror
  4. Increase APT timeout value
apt — error
# Test connectivity to a public DNS
ping -c 3 8.8.8.8
# Test connectivity to a major site
ping -c 3 google.com
# Test HTTPS connectivity to a repository
curl -v https://archive.ubuntu.com/ubuntu/dists/jammy/Release
W: Failed to fetch URL Connection timed out

What this error means

The "W: Failed to fetch URL Connection timed out" warning in APT indicates that the package manager attempted to connect to a repository server but the connection took longer than the configured timeout value. APT uses this timeout to prevent the update process from hanging indefinitely on unreachable servers. This warning typically appears during `apt update` or `apt install` operations when APT tries to fetch package lists, metadata, or actual package files from a mirror server. While APT can usually continue with other mirrors or retries, repeated timeout warnings suggest network instability or that the configured mirror is slow or unreachable. The error includes the full URL of the repository that timed out, which helps identify whether the issue is with a specific mirror or affects all repositories globally.

Typical symptoms

  • apt update command shows 'W: Failed to fetch URL Connection timed out' warning messages
  • apt install hangs for extended periods before showing timeout errors
  • Only some repository URLs fail to fetch while others succeed
  • The timeout warning appears multiple times during a single apt command
  • apt upgrade or apt full-upgrade takes significantly longer than normal
  • Updates work sometimes but frequently fail, suggesting intermittent connectivity
  • The error message includes specific repository URLs like archive.ubuntu.com or security.debian.org

Common causes

  1. Selected APT mirror is geographically distant or slow to respond
  2. Network connectivity issues - unstable WiFi, VPN disconnections, or routing problems
  3. Repository server is temporarily unavailable or under heavy load
  4. Firewall or corporate proxy blocking or rate-limiting repository access
  5. DNS resolution delays when looking up repository mirror hostnames
  6. APT timeout is too aggressive for slow or high-latency network connections
  7. Mirror URL in sources.list points to a dead or deprecated server
  8. Network path MTU issues causing packet fragmentation and retransmissions

How to fix "W: Failed to fetch URL Connection timed out"

1Test your internet connection

First, verify that your system has basic network connectivity:

bash
# Test connectivity to a public DNS
ping -c 3 8.8.8.8

# Test connectivity to a major site
ping -c 3 google.com

# Test HTTPS connectivity to a repository
curl -v https://archive.ubuntu.com/ubuntu/dists/jammy/Release

If these basic tests fail, the issue is with your network connection rather than APT specifically.

2Clean the APT cache

Corrupted or partial cache files can cause fetch failures. Start with the gentle, non-destructive cleanup and re-run the update:

bash
# Remove cached .deb files (safe, packages re-download as needed)
sudo apt clean

# Refresh package lists
sudo apt update

If apt update still fails after apt clean, escalate to clearing the downloaded package lists so APT re-fetches all metadata from scratch:

bash
# Remove cached package lists (forces a full metadata refresh)
sudo rm -rf /var/lib/apt/lists/*
sudo mkdir -p /var/lib/apt/lists/partial

sudo apt update

Delete the lists directory only as a second step; apt clean alone resolves most cache-related fetch problems.

3Switch to a faster APT mirror

The default mirror may be slow or geographically distant. Select a mirror closer to your location:

bash
# Edit sources.list
sudo nano /etc/apt/sources.list

Replace the mirror domain with a faster alternative. For example, if using Ubuntu:

- Change archive.ubuntu.com to your country code mirror: us.archive.ubuntu.com, eu.archive.ubuntu.com, etc.
- Or try a mirror from your ISP or local mirror service

For Debian, check https://www.debian.org/mirror/list for nearby mirrors.

Save and try updating:

bash
sudo apt update

If you're unsure which mirror to choose, test connectivity first:

bash
# Test a specific mirror
curl -I https://us.archive.ubuntu.com/ubuntu/
4Increase APT timeout value

Configure APT to wait longer before timing out connections:

bash
# Create a timeout configuration
sudo nano /etc/apt/apt.conf.d/99timeout

Add these lines to increase timeout values:

bash
Acquire::http::Timeout "300";
Acquire::https::Timeout "300";
Acquire::ftp::Timeout "300";
Acquire::Retries "3";

These settings give APT 5 minutes (300 seconds) to establish connections and retry up to 3 times. Save and test:

bash
sudo apt update

Adjust the timeout value (in seconds) based on your network speed. For slow connections, 600 seconds (10 minutes) may be appropriate.

5Fix DNS resolution issues

Slow or unreliable DNS can cause timeout errors. On modern Ubuntu and Debian systems, /etc/resolv.conf is usually a managed symlink (to systemd-resolved or NetworkManager) that gets regenerated on the next reboot or network change. Editing it directly is non-persistent, so configure DNS through the resolver service first.

Persistent fix (systemd-resolved):

bash
# Edit the systemd-resolved configuration
sudo nano /etc/systemd/resolved.conf

Under the [Resolve] section, set:

bash
DNS=8.8.8.8 8.8.4.4 1.1.1.1 1.0.0.1
FallbackDNS=9.9.9.9

Restart the service so the change takes effect, then test:

bash
sudo systemctl restart systemd-resolved
sudo apt update

Verify the active resolvers with resolvectl status.

If your system manages DNS through NetworkManager, set the DNS on the active connection instead so it survives reboots:

bash
sudo nmcli connection modify "<connection-name>" ipv4.dns "8.8.8.8 1.1.1.1"
sudo nmcli connection modify "<connection-name>" ipv4.ignore-auto-dns yes
sudo nmcli connection up "<connection-name>"

Temporary test only (non-persistent): On a system without a DNS manager (or just to confirm DNS is the culprit before applying a persistent fix), you can edit /etc/resolv.conf directly. Be aware this is overwritten on the next reboot or network change:

bash
sudo nano /etc/resolv.conf
bash
nameserver 8.8.8.8
nameserver 1.1.1.1

If this resolves the timeouts, apply the persistent method above to make it stick.

6Force IPv4 if IPv6 is causing issues

In some environments, IPv6 connectivity is broken or slower than IPv4. Force APT to use only IPv4:

bash
# One-time IPv4-only update
sudo apt -o Acquire::ForceIPv4=true update

To make this permanent:

bash
# Create APT configuration
sudo nano /etc/apt/apt.conf.d/99force-ipv4

Add:

bash
Acquire::ForceIPv4 "true";

Save and test:

bash
sudo apt update
7Check firewall and proxy settings

If you're behind a corporate firewall or proxy, ensure APT can connect:

bash
# Test connection to repository directly
curl -v http://archive.ubuntu.com/ubuntu/dists/jammy/Release

If connections are blocked, configure your proxy:

bash
# Create proxy configuration
sudo nano /etc/apt/apt.conf.d/99proxy

Add your proxy settings:

bash
Acquire::http::Proxy "http://proxy.example.com:8080";
Acquire::https::Proxy "http://proxy.example.com:8080";

Then test:

bash
sudo apt update

For authenticated proxies, embedding credentials in the URL writes them in plaintext to a world-readable config file. Prefer to keep credentials out of the URL where possible; if you must use them, restrict permissions on the file (sudo chmod 600 /etc/apt/apt.conf.d/99proxy):

bash
Acquire::http::Proxy "http://username:password@proxy.example.com:8080";
8Verify repository URLs are valid

Check that your sources.list contains valid repository URLs that haven't been deprecated:

bash
# View current sources
cat /etc/apt/sources.list
ls -la /etc/apt/sources.list.d/

Look for:
- Outdated domain names (e.g., old Ubuntu release mirrors)
- Typos in URLs
- Repositories that no longer exist

For Ubuntu LTS releases that have reached end-of-life, archive mirrors may be required:

bash
# For end-of-life Ubuntu releases
sudo sed -i 's/archive.ubuntu.com/old-releases.ubuntu.com/g' /etc/apt/sources.list
sudo sed -i 's/security.ubuntu.com/old-releases.ubuntu.com/g' /etc/apt/sources.list

sudo apt update

For currently supported releases, verify you're using the correct mirror URLs from the official Ubuntu or Debian mirror lists.

9Update and retry with verbose output

Enable verbose logging to see exactly where the timeout is occurring:

bash
# Run apt update with debug output
sudo apt update -V

# Or with even more verbose output
sudo apt -o Debug::Acquire::http=true update

The verbose output shows:
- Which specific URLs are timing out
- How long each connection attempt takes
- Which mirrors succeed and which fail

This helps identify if the issue is with a specific mirror or all mirrors. If only one mirror times out while others work, consider removing that mirror from your sources.list.

Advanced notes

### Handling Intermittent Timeouts

If timeouts occur sporadically, the issue may be transient (temporary network fluctuations, server load spikes, etc.). APT is configured to retry, so you can:

bash
# Retry the update multiple times
for i in {1..3}; do
  sudo apt update && break
  sleep 5
done

### Repository-Specific Timeouts

If only certain repositories timeout while others work fine, you have two options:

1. Temporarily disable the problematic repository:

bash
# Comment out lines in sources.list
sudo nano /etc/apt/sources.list.d/problematic-repo.list
# Or use: sudo add-apt-repository --remove ppa:username/ppa

2. Switch that repository to a different mirror if available

### WSL2 (Windows Subsystem for Linux) Specific Issues

On WSL2, DNS resolution can degrade over time, causing timeouts:

powershell
# In PowerShell as Administrator
wsl --shutdown

Then restart WSL and try apt update again.

### Performance Tuning for Slow Networks

For systems on very slow or unreliable connections:

bash
# Create comprehensive timeout configuration
sudo nano /etc/apt/apt.conf.d/99-slow-network

Add:

bash
Acquire::http::Timeout "600";
Acquire::https::Timeout "600";
Acquire::ftp::Timeout "600";
Acquire::Retries "5";
Acquire::Queue-Mode "access";

The Queue-Mode "access" setting reduces parallel requests, which helps on slow connections.

### Monitoring APT Timeout Issues

Keep track of which repositories cause timeouts:

bash
# Save update output to a log file
sudo apt update 2>&1 | tee /tmp/apt-update.log

# Search for timeout errors
grep -i timeout /tmp/apt-update.log

If you see patterns (e.g., same mirror always times out), investigate that mirror specifically.

Frequently asked questions

What does "W: Failed to fetch URL Connection timed out" mean?
The "W: Failed to fetch URL Connection timed out" warning in APT indicates that the package manager attempted to connect to a repository server but the connection took longer than the configured timeout value. APT uses this timeout to prevent the update process from hanging indefinitely on unreachable servers. This warning typically appears during apt update or apt install operations when APT tries to fetch package lists, metadata, or actual package files from a mirror server.
How do I fix "W: Failed to fetch URL Connection timed out"?
The 'W: Failed to fetch URL Connection timed out' warning appears when APT cannot reach a repository within its timeout, usually due to network issues, slow or dead mirrors, or DNS problems.
What causes "W: Failed to fetch URL Connection timed out"?
Selected APT mirror is geographically distant or slow to respond Network connectivity issues - unstable WiFi, VPN disconnections, or routing problems Repository server is temporarily unavailable or under heavy load
Is the "W: Failed to fetch URL Connection timed out" error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading