Users running Linux package updates sometimes see the message apt-get update waiting for headers, which indicates that the command is stalled while waiting for server responses. This situation often points to network, repository, or client configuration issues that interrupt the early stage of the update process.
Below is a quick reference table that maps common causes, observable symptoms, and immediate remediation steps for apt-get update waiting for headers. Use it to triage the problem quickly before diving into deeper diagnostics.
| Category | Typical Cause | Observable Symptom | Quick Action |
|---|---|---|---|
| Network | Firewall, proxy, or MTU issues blocking HTTP/HTTPS | Hangs at 0% or after resolving repository hostnames | Test connectivity with curl or traceroute to the repository domain |
| Repository | Repository moved, renamed, or taken offline | Errors mentioning 404, 403, or connection timeout for a specific URI | Check repository status page or mirror list and switch to a working mirror |
| Client Configuration | Misplaced sources.list entries or invalid signing keys | Warnings about missing keys or malformed entries before the hang | Validate sources.list syntax and ensure required GPG keys are installed |
| Server Side | Repository server overloaded, misconfigured, or under DDoS | Consistent timeouts for many users at the same time | Retry later or switch to an alternative mirror or snapshot service |
Diagnosing apt-get update waiting for headers
When apt-get update stalls with the symptom apt-get update waiting for headers, the package manager is unable to receive the initial HTTP response headers from one or more configured repositories. Unlike a complete timeout, this symptom suggests that the TCP connection is established, but the server delays sending the first byte. Common network conditions such as high latency, asymmetric routing, or deep packet inspection can trigger this behavior.
You can begin diagnosis by enabling verbose mode with apt-get update -o Debug::Acquire::http=true, which prints detailed timing information for each repository request. Look for entries that show long DNS resolution or TCP connection times followed by a gap in timestamped receive events. If the delay occurs after DNS and connection setup, the issue is more likely on the network path or at the proxy rather than in the repository itself.
Network and proxy considerations
Corporate environments often use explicit proxy servers or PAC scripts that apt does not automatically respect. Without proper proxy configuration in /etc/apt/apt.conf or via environment variables, connections to repository domains can stall behind authentication gateways. Similarly, improperly tuned MTU sizes or VPN tunnels can fragment packets, causing TCP retransmissions that delay response headers.
To verify proxy behavior, try curling the exact repository URL with the same proxy settings used by apt, for example, curl -v --proxy http://proxy:port https://archive.ubuntu.com/ubuntu/dists/jammy/Release. If curl also hangs, the network path is the prime suspect. If curl succeeds while apt-get update fails, compare HTTP headers and check whether apt is missing required certificates or proxy authentication details.
Repository and mirror selection
Repositories sometimes move to new IP addresses, change TLS configurations, or throttle requests from aggressive clients. Geographic distance to a mirror can introduce high round-trip times that exacerbate header-wait symptoms, especially when client-side timeouts are low. Using official mirror lists and selecting geographically close, protocol-consistent mirrors can reduce latency-related stalls.
Snapshot services for major distributions provide stable URIs that redirect to healthy mirrors and often include built-in rate limiting and retry logic. If you rely on static URIs, consider switching to a redirect-based entry such as http://archive.ubuntu.com/ubuntu/ instead of hardcoding a specific mirror hostname. This allows the client to follow redirects more gracefully when upstream conditions change.
Client configuration and timing
Timeouts and retry settings in the APT client can be tuned to handle slow or unreliable mirrors. The options Acquire::http::Timeout and Acquire::Retries allow you to specify connection and response timeouts along with the number of retry attempts. Raising Acquire::http::Timeout to 30 and Acquire::Retries to 3 often resolves intermittent header delays without masking genuine repository failures.
In addition, ensure that DNS resolution is stable and predictable, as frequent DNS re-queries during a single update can introduce jitter. Prefer static entries in /etc/resolv.conf or a reliable managed resolver, and verify that IPv6 settings do not cause fallback delays when IPv4 responses are expected. Combining these adjustments usually shortens the waiting period and makes apt-get update more predictable.
Key recommendations for reliable apt-get update
- Verify proxy settings and test repository URLs with curl before running apt-get update
- Switch to redirect-based mirror URIs and prefer geographically close repositories
- Increase Acquire::http::Timeout and Acquire::Retries in APT configuration for unstable networks
- Monitor DNS resolution times and ensure stable /etc/resolv.conf or systemd-resolved settings
- Check repository status and rotate mirrors if specific hosts consistently cause header waits
FAQ
Reader questions
Why does apt-get update hang specifically at waiting for headers and not later in the process?
The hang at waiting for headers means the TCP handshake succeeded, but the server has not sent the first byte of the HTTP response. This usually indicates network latency, proxy interception, or server-side queuing rather than a problem with package file parsing, which occurs later in the update.
Can using HTTPS instead of HTTP make apt-get update waiting for headers more likely?
Yes, HTTPS adds TLS negotiation and certificate verification overhead, which can increase the time before headers appear. If intermediate devices inspect TLS traffic or if the system clock is skewed, the additional round trips and processing can cause noticeable delays at the header stage.
How does the choice of mirror or archive URI affect the waiting for headers symptom?
Geographically distant or overloaded mirrors introduce higher latency and lower timeouts, making header waits more frequent. Redirect-based URIs can reduce the issue by allowing clients to follow to a healthier endpoint, whereas hardcoded mirrors may persist with slow or misconfigured servers.
What role do DNS timeouts and IPv6 settings play in apt-get update waiting for headers?
Slow DNS resolution or IPv6 fallback delays can add seconds to connection setup, pushing the first-header timeout past default thresholds. Stabilizing DNS with local caching resolvers and ensuring consistent IP version behavior can reduce apparent header-wait times even when underlying network performance varies.