How to use an HTTP proxy with wget

An HTTP proxy gives wget one controlled egress path, which is useful when direct outbound traffic is blocked, logged, or routed through policy enforcement. The same proxy settings also make automated downloads easier to audit because every request follows the same intermediate hop instead of each client choosing its own route.

wget reads proxy settings from environment variables such as http_proxy, https_proxy, and no_proxy, and it can keep the same values in ~/.wgetrc with use_proxy enabled. When those settings are present, wget connects to the proxy first and asks it to forward the request to the target URL.

Proxy credentials and bypass lists deserve the same care as any other execution policy. Keep credentials out of shared shell history, use no_proxy only for approved internal destinations, and validate a short request before reusing the same settings in cron jobs or CI workers.

1. Capture the proxy host, port, and authentication requirements before changing the client environment.
2. Set the proxy variables in the active shell so the next command uses the intended gateway immediately.

   $ export http_proxy=http://proxy.example.net:3128
   $ export https_proxy=http://proxy.example.net:3128
   $ export no_proxy=localhost,127.0.0.1,.internal.example

   Use the same scheme and host format in every variable, and add uppercase aliases only when older tools in the same shell need them.

3. Run a lightweight request and confirm that wget connects to the proxy instead of the target directly.

   $ wget -S --spider http://example.com/
   Spider mode enabled. Check if remote file exists.
   Connecting to proxy.example.net:3128... connected.
   Proxy request sent, awaiting response...
     HTTP/1.1 200 OK
   Remote file exists and could contain further links,
   but recursion is disabled -- not retrieving.

   Use an HTTP URL for the first check when possible, because it proves the forwarding path without mixing in TLS tunnel or certificate troubleshooting.

4. Persist the same values in ~/.wgetrc only when repeated sessions should inherit the proxy policy automatically.

   ~/.wgetrc
   use_proxy = on
   http_proxy = http://proxy.example.net:3128/
   https_proxy = http://proxy.example.net:3128/
   no_proxy = localhost,127.0.0.1,.internal.example

   The startup file overrides environment values for wget itself, which is useful when the account needs one fixed proxy policy. Related: How to configure default options in ~/.wgetrc

5. Supply proxy credentials only when the proxy actually requires authentication.

   $ wget --proxy-user=alice --proxy-password='REDACTED' -S --spider http://example.com/

   Prefer runtime secret injection or a restricted startup file over hard-coding proxy passwords in reusable scripts.

6. Bypass the proxy explicitly for approved local destinations that should stay direct.

   $ wget --no-proxy http://intranet.internal.example/health
   Connecting to intranet.internal.example (intranet.internal.example)|192.0.2.40|:80... connected.

   Use --no-proxy for one command, or keep the destination in no_proxy when the same host range should always bypass the proxy.

7. Verify the persistent startup-file settings by removing the shell exports and re-running the same short request.

   $ env -u http_proxy -u https_proxy -u no_proxy wget -S --spider http://example.com/
   Spider mode enabled. Check if remote file exists.
   Connecting to proxy.example.net:3128... connected.
   Proxy request sent, awaiting response...
     HTTP/1.1 200 OK

   If this check still reaches the proxy, the account-level policy in ~/.wgetrc is active as intended. Related: How to debug wget connections