The old symptom was memorable: 0% [Connecting to archive.ubuntu.com (2001:…)] and no obvious progress. On one Ubuntu 16.04 laptop, preferring IPv4 happened to work. That does not make IPv6 the universal culprit. APT is simply showing the connection phase where it is waiting; the useful job is to isolate name resolution, each address family, proxying, TLS, repository state, and release lifecycle.

First, read the complete error

  • “Temporary failure resolving” points to DNS resolution.

  • “Network is unreachable,” a timeout, or a displayed IPv6 address suggests route/connectivity testing for that family.

  • “Connection refused” means the destination/proxy actively rejected the connection or nothing listened at the target.

  • Certificate verification or “not yet valid/expired” points to TLS interception, certificate chain, clock, or unsupported client/repository.

  • 404, missing Release file, or repository signature errors mean APT connected; repository/release configuration is the problem.

  • A dpkg lock error is local package-manager concurrency, not network connectivity.

Check the OS release and clock

Ubuntu shellbash
cat /etc/os-release
dpkg --print-architecture
date -Is
timedatectl status
PRETTY_NAME="Ubuntu 24.04.x LTS"
amd64
2026-08-14T...+05:30
System clock synchronized: yes

An old release changes the repository question

  • Record release/codename, architecture, and time before diagnosing URLs.

  • A badly wrong clock can break HTTPS certificate validation and signed metadata expectations.

  • Ubuntu 16.04 left standard support in April 2021 and ESM in April 2026; as of August 2026 it requires the paid Legacy add-on for continued Canonical security coverage.

  • Plan an upgrade to a supported release rather than treating a mirror edit as security maintenance.

  • Old 32-bit architectures may have different archive/support availability; confirm the release’s official architecture coverage.

Inspect active APT sources without editing them

Ubuntu shellbash
grep -RhsE '^[[:space:]]*(deb|Types:|URIs:|Suites:|Components:|Architectures:)' \
  /etc/apt/sources.list \
  /etc/apt/sources.list.d 2>/dev/null
Types: deb
URIs: http://archive.ubuntu.com/ubuntu
Suites: noble noble-updates noble-security
Components: main universe restricted multiverse

Repository syntax differs by Ubuntu generation

  • Ubuntu 24.04 commonly stores official sources in deb822 /etc/apt/sources.list.d/ubuntu.sources.

  • Older releases commonly use one-line deb entries in /etc/apt/sources.list.

  • Look for typos, duplicate/conflicting files, wrong codename, unsupported third-party repositories, CD-ROM entries, and unintended proxy/mirror hosts.

  • Do not replace every host with old-releases.ubuntu.com merely because a connection is slow; that is a lifecycle/archive decision, not a connectivity fix.

  • Back up source configuration before changing it and use supported release-upgrade guidance.

Resolve the repository host

Ubuntu shellbash
getent ahosts archive.ubuntu.com
resolvectl query archive.ubuntu.com
185.125... STREAM archive.ubuntu.com
...
2001:67c:... archive.ubuntu.com
...

DNS success is not route success

  • getent uses the system name-service configuration that applications normally consult.

  • resolvectl provides resolver/interface/cache detail on systemd-resolved systems; it may not exist on older/minimal releases.

  • An A record provides IPv4 candidates and AAAA provides IPv6 candidates; either can resolve while its network path is broken.

  • If resolution fails, inspect /etc/resolv.conf, NetworkManager/systemd-resolved state, VPN, DHCP, split DNS, local filtering, and the configured resolver.

  • Do not hard-code archive IPs in /etc/hosts; mirror/CDN addresses change and hostname-based TLS/routing matters.

Test basic routes and the exact endpoint

Ubuntu shellbash
ip -brief address
ip route
ip -6 route
curl -4 -sS -I --connect-timeout 10 http://archive.ubuntu.com/ubuntu/dists/
curl -6 -sS -I --connect-timeout 10 http://archive.ubuntu.com/ubuntu/dists/
... interface and routes ...
HTTP/1.1 200 OK
...
curl: (28) Failed to connect ... timeout

Compare address families with the same URL

  • curl -4 and curl -6 isolate connection families while retaining the hostname and HTTP request.

  • A working IPv4 request plus failed IPv6 request supports an IPv6 path diagnosis; it does not explain why IPv6 is broken.

  • Check global IPv6 address, default route, router advertisements, firewall, VPN, tunnel, provider support, MTU/PMTU, and upstream routing.

  • If both fail, investigate general connectivity, proxy/firewall/captive portal, destination, and DNS rather than forcing IPv4.

  • HTTP status can vary by mirror; the important evidence here is successful DNS/TCP/HTTP connectivity.

Run APT once with IPv4 forced

Ubuntu shellbash
sudo apt-get -o Acquire::ForceIPv4=true update
Hit:1 http://archive.ubuntu.com/ubuntu ... InRelease
...
Reading package lists... Done

This override is narrow and reversible

  • Acquire::ForceIPv4=true affects this APT invocation instead of changing system-wide address precedence.

  • Success strongly narrows the fault only when the normal run fails under otherwise identical conditions.

  • Capture normal, forced-IPv4, and if supported forced-IPv6 output with timestamps.

  • Use apt-get for scripted/diagnostic stability; interactive apt is intended for humans.

  • Fix network IPv6 rather than permanently masking it when IPv6 is expected to work.

Persist an APT-only IPv4 workaround temporarily

/etc/apt/apt.conf.d/99force-ipv4text
Acquire::ForceIPv4 "true";

Keep the workaround scoped and documented

  • Create this root-owned drop-in only after explicit IPv4/IPv6 tests identify the failure.

  • The setting affects APT downloads, not the entire operating system.

  • Record why it exists, the incident/link, owner, date, and a removal condition.

  • Remove it and retest after routing, firewall, VPN, ISP, or network configuration is repaired.

  • Validate syntax through apt-config dump and avoid conflicting drop-ins.

Why editing gai.conf is not the first fix

/etc/gai.conftext
# Historical workaround seen in older tutorials:
# precedence ::ffff:0:0/96  100

Address selection is system-wide behavior

  • gai.conf influences RFC 3484/6724-style destination address selection for many applications using getaddrinfo, not only APT.

  • Line numbers differ by release; never uncomment a “line 54” blindly.

  • Preferring IPv4 can hide a broken IPv6 network and alter browsers, services, monitoring, and applications.

  • An APT-only override is safer while diagnosing; repair the real IPv6 path or disable it deliberately through supported network policy if it is not provided.

  • If organization policy requires address-selection changes, test and document their whole-system effect.

Check proxies in two places

Ubuntu shellbash
env | grep -iE '^(http|https|no)_proxy=' || true
apt-config dump | grep -iE 'Acquire::(http|https)::Proxy' || true
https_proxy=http://proxy.example:3128
Acquire::http::Proxy "http://proxy.example:3128/";

sudo and APT configuration can see different proxies

  • APT can read proxy configuration from apt.conf drop-ins independent of shell environment.

  • sudo may drop environment variables; relying on a user-shell proxy can make behavior differ.

  • Check proxy hostname DNS, route, authentication, CA interception, allowlists, URL scheme, port, and no_proxy.

  • Never expose proxy credentials in command output, process lists, shell history, tickets, or world-readable configuration.

  • A captive portal can return HTML instead of signed repository metadata; authenticate through approved network flow, then retry.

Use APT debug output to locate the wait

Ubuntu shellbash
sudo apt-get \
  -o Debug::Acquire::http=true \
  -o Debug::Acquire::https=true \
  -o Acquire::http::Timeout=15 \
  -o Acquire::Retries=1 \
  update
... request, connection, response, and error diagnostics ...

Bounded diagnostics are easier to interpret

  • Debug output can reveal the actual URL/proxy/request/response stage and may expose infrastructure details; sanitize before sharing.

  • A timeout prevents indefinite waits during diagnosis but is not a performance fix.

  • Retries can mask intermittent failure and extend jobs; keep them bounded while investigating.

  • Option support/defaults vary by installed APT version; inspect apt.conf(5) and apt-config dump.

  • Do not use insecure certificate or repository-signature overrides to “prove” connectivity.

HTTPS and certificate failures

  • Confirm system time, CA certificates, proxy TLS interception, hostname, and certificate chain.

  • Use curl -Iv https://HOST/PATH and openssl s_client -connect HOST:443 -servername HOST for authorized diagnosis.

  • A corporate TLS proxy requires an organization-approved CA trust deployment, not Verify-Peer false.

  • Old releases may lack current CA roots/TLS compatibility and supported repositories; upgrading is the durable fix.

  • APT repository signature verification remains essential even over HTTPS; transport TLS and archive signing protect different boundaries.

Mirror and repository-specific failures

  • Test the exact URI from source configuration, not only archive.ubuntu.com.

  • Regional mirrors and third-party PPAs can be down, stale, moved, rate-limited, or no longer publish the release/architecture.

  • Use an official mirror for the correct supported release and architecture; do not copy random mirror commands.

  • A 404 or missing Release file indicates successful networking but incompatible repository path/suite.

  • Disable or update third-party repositories one at a time only after inventorying packages that depend on them.

  • Do not mix suites/releases to obtain a missing package; that can create an unsupported dependency system.

Special note for Ubuntu 16.04 in 2026

  • Take a tested backup/snapshot and inventory applications, repositories, architectures, boot/firmware, storage, and dependencies.

  • Confirm the supported sequential release-upgrade path or rebuild/migration plan using current Canonical documentation.

  • Do not jump suites by editing sources as a substitute for do-release-upgrade.

  • For a constrained legacy workload, obtain correct Legacy support and isolate/monitor the system while planning retirement.

  • Ubuntu 16.04 32-bit installations require particular architecture and application-migration scrutiny.

DNS diagnosis when resolution fails

systemd-resolved Ubuntu hostbash
resolvectl status
resolvectl query archive.ubuntu.com
systemctl status systemd-resolved --no-pager
journalctl -u systemd-resolved --since '15 minutes ago' --no-pager
... per-link DNS servers, search domains, protocols, and query results ...

Fix the source of resolver configuration

  • DNS servers may come from DHCP, NetworkManager, netplan, VPN, cloud-init, containers, or static configuration.

  • Editing the generated /etc/resolv.conf symlink target directly can be overwritten and create split-DNS/VPN failures.

  • Compare queries to the configured resolver and an approved independent resolver only when network policy permits.

  • Check DNSSEC validation, firewall port 53, TCP fallback, EDNS/MTU, VPN namespaces, and local caching.

  • Avoid changing to a public resolver if that bypasses corporate policy or internal zones.

Network edge cases

  • A VPN can install an IPv6 route without usable egress or intercept repository traffic.

  • A firewall may allow DNS but block TCP 80/443, IPv6, or proxy access.

  • Broken Path MTU discovery can make TCP/TLS stall after connecting; compare packet sizes and network paths carefully.

  • Wi-Fi captive portals require login and may intercept HTTP/DNS until authorized.

  • Containers/chroots can have separate DNS, proxy, route, certificate, and clock contexts.

  • Cloud security groups, egress gateways, NAT, and transparent proxies can differ between IPv4 and IPv6.

Do not use these shortcuts

  • Do not disable IPv6 globally because one APT attempt displayed an IPv6 address.

  • Do not edit /etc/gai.conf by copied line number.

  • Do not hard-code mirror IP addresses.

  • Do not disable TLS certificate or APT signature verification.

  • Do not copy an unsupported release to a random suite/mirror.

  • Do not delete APT/dpkg lock files when a separate package process is active.

  • Do not repeatedly clear package lists before proving they are corrupt; it adds downloads and removes evidence.

A concise diagnostic decision tree

  • Name fails to resolve → resolver/link/VPN/DNS diagnosis.

  • IPv4 succeeds, IPv6 fails → repair IPv6; use temporary APT ForceIPv4.

  • IPv6 succeeds, IPv4 fails → repair IPv4/NAT route; do not force IPv4.

  • Both families time out → firewall/proxy/captive portal/destination/general route.

  • TCP connects but TLS fails → clock, CA, interception, hostname, old client/repository.

  • HTTP returns 404/Release error → suite/path/mirror/release lifecycle.

  • Only one repository fails → isolate that mirror/PPA/provider.

  • All networking works but apt locks → package-manager concurrency, a different incident.

Verification after the fix

Ubuntu shellbash
sudo apt-get update
apt-cache policy
apt-get check
... all intended repositories fetched or hit without errors ...
... package priorities/origins ...
Reading package lists... Done
Building dependency tree... Done

A completed update is only one layer of proof

  • Review every warning/error; partial repository failure can leave stale indexes while returning useful-looking output.

  • apt-cache policy shows origins, suites, priorities, and candidates—check for unexpected repositories.

  • apt-get check checks dependency consistency.

  • Rerun without temporary ForceIPv4 after fixing the network.

  • Document root cause, workaround expiry, release-upgrade action, monitoring, and owner.

Primary references

  • The Ubuntu package-management documentation documents current source locations and apt/apt-get roles.

  • Ubuntu’s 16.04 lifecycle page states that Xenial left ESM in April 2026 and requires the Legacy add-on for continued coverage.

  • The Ubuntu release cycle explains standard, ESM, and Legacy maintenance periods.

  • Use the installed `apt.conf(5)` and apt-get(8) manuals for ForceIPv4/ForceIPv6, proxy, timeout, retry, and debug option behavior.

  • Use current NetworkManager, netplan, systemd-resolved, proxy, firewall, and release-upgrade documentation for the deployed Ubuntu version.