🚨 Linux Error Guide: 'Failed to fetch ... getaddrinfo ENOTFOUND' — Fix Extension and Repo Fetch Failures

Overview

Fetching an editor extension or a new package repository fails at the network layer far more often than at the application layer. In VS Code or code-server, installing an extension behind a proxy fails with a DNS lookup error:

Failed to fetch extension. Error: getaddrinfo ENOTFOUND marketplace.visualstudio.com

The apt equivalent, when add-apt-repository or apt update cannot reach a repository host, is:

Err:1 https://packages.example.com/apt stable InRelease
  Could not resolve 'packages.example.com'
E: Failed to fetch https://packages.example.com/apt/dists/stable/InRelease  Temporary failure resolving 'packages.example.com'

Both are the same class of problem: the client resolved-or-failed-to-resolve a hostname, or was blocked by a proxy or TLS interceptor, before any extension or package data was transferred.

Symptoms

• VS Code / code-server extension install spins then fails with getaddrinfo ENOTFOUND or ETIMEDOUT.
• apt update shows Could not resolve or Failed to fetch for one or all repositories.
• curl to the same host fails with Could not resolve host (exit 6) or hangs then times out (exit 28).
• The failure only happens on a corporate network, VPN, or inside a container — but works from a laptop.
• TLS errors like self-signed certificate in certificate chain appear when a proxy re-signs HTTPS.

Common Root Causes

• DNS not configured or broken — getaddrinfo ENOTFOUND / Could not resolve means the name never resolved; bad /etc/resolv.conf, missing internal resolver, or split-horizon DNS on VPN.
• Corporate HTTP(S) proxy required — the host only reaches the internet through a proxy, but the editor/apt has no proxy configured, so connections to marketplace.visualstudio.com or the repo time out.
• Proxy env vars set but not exported to the app — http_proxy works in the shell but code-server/apt run under systemd or a container that never received it.
• TLS interception — a proxy re-signs HTTPS with a corporate CA that the client does not trust, causing self-signed certificate errors.
• Marketplace or repo outage / regional block — the remote is genuinely down or geo-blocked; code-server also cannot use the Microsoft marketplace by default and needs Open VSX.
• Air-gapped host — no egress at all; extensions must be side-loaded.

Diagnostic Workflow

Separate DNS from connectivity from TLS. Start with name resolution:

getent hosts marketplace.visualstudio.com
dig +short marketplace.visualstudio.com
cat /etc/resolv.conf

Test raw reachability and TLS, honoring any proxy:

curl -vI https://marketplace.visualstudio.com/ 2>&1 | head -n 20
curl -x "$https_proxy" -vI https://packages.example.com/apt/ 2>&1 | head -n 20

Check whether proxy variables are actually present in the failing context:

env | grep -i proxy
sudo systemctl show code-server --property=Environment   # for systemd-run services

For apt specifically, inspect its own proxy config and repo list:

grep -ri proxy /etc/apt/apt.conf.d/ /etc/environment
cat /etc/apt/sources.list.d/*.list
sudo apt-get update -o Debug::Acquire::http=true 2>&1 | head -n 40

For code-server, confirm which marketplace it targets (it does not use the MS marketplace by default):

grep -i 'EXTENSIONS_GALLERY\|proxy' ~/.config/code-server/config.yaml /etc/environment

Example Root Cause Analysis

A developer runs code-server on a bastion host inside a corporate network. Extension installs fail with getaddrinfo ENOTFOUND open-vsx.org, yet curl https://open-vsx.org from their SSH session succeeds. The discrepancy is the clue: the shell has http_proxy and https_proxy set from /etc/profile.d/proxy.sh, but code-server runs as a systemd service that never sourced that profile, so the Node process resolves DNS directly — and direct DNS egress is blocked by the firewall.

The fix was to add the proxy to the service environment rather than the login shell:

sudo systemctl edit code-server
# [Service]
# Environment=HTTPS_PROXY=http://proxy.corp:3128
# Environment=HTTP_PROXY=http://proxy.corp:3128
# Environment=NO_PROXY=localhost,127.0.0.1
sudo systemctl restart code-server

After restart, the Node HTTP client routed extension fetches through the proxy and getaddrinfo succeeded. The takeaway: getaddrinfo ENOTFOUND is a resolution failure inside the application’s process, and environment that works in your shell does not automatically reach a daemon.

Prevention Best Practices

• Configure proxy settings where the service runs, not just in the shell: systemd Environment=, container env, and /etc/apt/apt.conf.d/95proxy for apt.
• Point code-server at Open VSX (or a self-hosted registry) explicitly via EXTENSIONS_GALLERY; the Microsoft marketplace is licensed for MS products only.
• Install the corporate CA into the system trust store (/usr/local/share/ca-certificates/ + update-ca-certificates) and Node’s NODE_EXTRA_CA_CERTS so TLS interception does not break fetches.
• Verify DNS on every new host and container with getent hosts before assuming an outage.
• For air-gapped hosts, host an internal apt mirror and side-load .vsix extensions with code --install-extension file.vsix.

Quick Command Reference

getent hosts <host>                         # does DNS resolve at all?
curl -vI https://<host>/                    # reachability + TLS
curl -x "$https_proxy" -vI https://<host>/  # test through the proxy
env | grep -i proxy                         # proxy vars in this context
sudo systemctl show <svc> -p Environment    # env the daemon actually has
code --install-extension name.vsix          # offline/side-load an extension
sudo apt-get update -o Debug::Acquire::http=true   # verbose apt fetch

Conclusion

‘Failed to fetch’ while pulling extensions or repositories is almost never the marketplace’s fault — it is DNS, a missing proxy, or TLS interception between you and the remote. Diagnose in layers: prove name resolution with getent, prove reachability and certificates with curl -v, and confirm the proxy environment exists in the exact process that is failing (a systemd service or container, not your login shell). Set proxy and CA configuration where the service runs, point code-server at a marketplace it is allowed to use, and keep an offline install path for air-gapped hosts.