How to Use a Proxy With wget (and Wget2): Variables, Flags and What Is Sent

wget takes a proxy from lowercase environment variables, from -e on the command line, or from a .wgetrc file. Three traps catch people. Capitals in the variable name are ignored. SOCKS is not supported at all. And on Fedora 40 and later, wget is Wget2, where the usual -e use_proxy recipe stops with an error.

We checked each method against a stub proxy on our own machine on October 22, 2026, with GNU Wget 1.21.4 on Ubuntu 24.04 and GNU Wget2 2.2.1 on Fedora 44. The proxy recorded what each one sent. Nothing left the machine.

How do you use a proxy with wget?

Export the proxy into the variables wget reads, then use wget as normal:

export https_proxy="http://203.0.113.7:8080"
export http_proxy="http://203.0.113.7:8080"
wget https://example.com/file.zip

The variable name follows the scheme of the URL you fetch. https_proxy handles https:// downloads and http_proxy handles http:// ones. A plain HTTP proxy carries HTTPS through a CONNECT tunnel, so https_proxy pointing at an http:// proxy is the normal setup. In our run, both wget versions sent the stub CONNECT 127.0.0.1:18443 for an https:// URL.

How common is wget?

wget sits on almost every Linux machine that reports to Debian's popularity contest. On October 22, 2026, 288,363 reporting systems had it installed, against 214,745 for curl. The most installed package of all, adduser, counts 293,420.

Installed and used are different things, though. Popcon also counts regular use, and there curl leads, 73,330 systems to wget's 52,769. Either way, wget is what a script finds when it lands on a fresh server.

Write the variables in lowercase

The GNU manual names http_proxy, https_proxy, ftp_proxy and no_proxy, all in lowercase. We tested what happens with capitals. With only HTTP_PROXY set, Wget 1.21.4 and Wget2 2.2.1 both fetched the target directly, and the stub proxy logged nothing. With lowercase http_proxy, both sent the proxy GET http://127.0.0.1:18081/a, the full URL that a forward proxy expects.

So a capitalized variable fails without a word, and the download goes out on your own address. Many other tools accept both cases, which is how the mistake travels into wget scripts.

One command only: -e on Wget, flags on Wget2

To proxy a single run without touching the shell, Wget 1.x takes -e, which runs a .wgetrc command:

wget -e use_proxy=yes -e https_proxy=http://203.0.113.7:8080 https://example.com/file.zip

The manual says a command given this way runs after the ones in .wgetrc, "thus taking precedence over them". Our stub received the request through this form, and -e use_proxy=off sent the same request direct.

Wget2 rejects that recipe. On Fedora 44, where /usr/sbin/wget is a link to wget2, our run stopped with "Unknown option 'use_proxy'" and exit code 2. Wget2 has its own flags instead:

# Wget2 (Fedora 40 and later): the proxy as a flag
wget2 --https-proxy=http://203.0.113.7:8080 https://example.com/file.zip

Both --http-proxy and --https-proxy reached the stub in our run. Check which one you have with wget --version: the first line reads either "GNU Wget 1.x" or "GNU Wget2 2.x".

A permanent setting: .wgetrc

For every run of one user, put the settings in ~/.wgetrc. For the whole machine, use /etc/wgetrc, the global startup file:

use_proxy = on
http_proxy = http://203.0.113.7:8080
https_proxy = http://203.0.113.7:8080
no_proxy = localhost,127.0.0.1

The manual describes these startup file variables as a way to "override the proxy settings specified by the environment". Keep the file readable only by you once it holds a password.

Proxy authentication

The GNU manual is short on this: "For proxy authorization only the Basic authentication scheme is currently implemented." Wget 1.x takes the login in two ways, which put the same bytes on the wire in our run:

# flags, which keep the password out of the URL
wget --proxy-user=myuser --proxy-password='p@ss:word' \
     -e use_proxy=yes -e https_proxy=http://203.0.113.7:8080 https://example.com/file.zip

# or inside the proxy URL
export https_proxy="http://myuser:secret@203.0.113.7:8080"

One detail surprised us. Our stub answered the first request with a 407 challenge, as a real proxy would. Wget 1.21.4 never needed it, because it sent the Basic login with the very first request, before the proxy asked.

Wget2 behaves differently. It has no --proxy-user, and its own manual marks that option "Not implemented, use --http-proxy-password". With --http-proxy-user and --http-proxy-password, Wget2 waited for the 407 and then sent the right login. With the credentials inside the proxy URL, it answered the 407 with an empty login, Base64 Og==. On Wget2 2.2.1, use the flags.

A rejected login comes back as HTTP 407 Proxy Authentication Required. That error at least proves the proxy is alive.

What wget sends to the proxy

Our test script ran nine methods against the same stub proxy and stub target. The terminal below prints the result for both versions.

Skip the proxy: no_proxy and --no-proxy

no_proxy lists the hosts that should go direct, as domain endings:

export no_proxy="localhost,127.0.0.1,.internal.example.com"

The manual's example is .mit.edu, which keeps every MIT address off the proxy. --no-proxy drops the proxy for one whole run. Both sent our test request straight to the target in both versions.

Wget2's manual says --no-proxy also takes a list of exceptions. Version 2.2.1 disagreed: --no-proxy=127.0.0.1 printed "Invalid boolean value '127.0.0.1'", and the request went direct anyway. Use the variable for lists.

A broad no_proxy entry is also the classic reason a download leaves on your own address. When a proxied wget shows your real IP, read no_proxy first.

wget has no SOCKS

Neither version speaks SOCKS. Wget 1.21.4 stopped with "Error parsing proxy URL socks5://127.0.0.1:1080: Unsupported scheme." Wget2 2.2.1 printed "Failed to set https proxies". Some guides show a socks_proxy setting for wget. Wget 1.21.4 answered it with "Invalid --execute command", and Wget2 with "Unknown option 'socks_proxy'".

Two ways around it work:

• A wrapper that redirects wget's connections, such as proxychains: proxychains4 wget https://example.com/file.zip. Our guide to proxychains covers the setup. Few systems carry one: popcon counts proxychains4 on 587 Debian systems and torsocks on 1,944.
• curl, which speaks SOCKS5 natively: curl -x socks5h://host:port -O URL. Our curl proxy guide has the details.

Rotating across a pool

wget has no built-in rotation, but a shell loop does the job. It picks a fresh proxy per attempt and moves on when one fails:

#!/bin/bash
mapfile -t POOL < <(curl -s "https://hproxy.com/api/proxy-list?format=txt&protocol=http&recent=true&limit=50")

fetch() {
  local url="$1" tries=4
  for _ in $(seq "$tries"); do
    local p="${POOL[RANDOM % ${#POOL[@]}]}"
    if https_proxy="http://$p" wget -q -O "$(basename "$url")" "$url"; then
      return 0
    fi
  done
  echo "all $tries proxies failed for $url" >&2
  return 1
}

fetch "https://example.com/file.zip"

The loop sets the variable per attempt, so it runs on Wget and Wget2 alike. The pool comes from our free proxy API as plain text, with no key.

wget with a residential gateway

A residential gateway is one host and port with home addresses behind it, so the wget side stays one variable. Since wget has no SOCKS, use the HTTP ports. Our dashboard generates the login, which carries your targeting:

# Residential Lite, HTTP
export https_proxy="http://YOUR-LOGIN:YOUR-PASSWORD@gw.hproxy.com:6969"

# Residential Premium, HTTP: 9000 rotates, 10000 and up hold a sticky session
export https_proxy="http://YOUR-LOGIN:YOUR-PASSWORD@premium.hproxy.com:9000"

wget -qO- https://icanhazip.com

On Wget2, pass the same login with --http-proxy-user and --http-proxy-password in place of the URL. Lite costs $0.50/GB for one GB, falling to $0.44/GB at 2,000 GB+, and targets countries. Premium costs $1.49/GB for one GB and $1.00/GB at 1,000 GB+, with state, city, network (ASN) and device targeting. The residential proxies page has the rest.

Verify the exit IP

Confirm the download really went through the proxy. wget -qO- prints the body to the terminal, so an IP echo is a one-liner:

https_proxy=http://203.0.113.7:8080 wget -qO- https://httpbin.org/ip

If it prints your own address, the proxy was skipped: check the case of the variable, use_proxy, and no_proxy. wget --debug shows the connection wget made. Our proxy checker reports the exit IP, country, latency and anonymity grade in one paste.

What this page could not check

• We measured against stubs on one machine. The page is exact about what wget sends and general about how a real proxy answers.
• No proxy network was tested, ours included.
• Two builds only: Wget 1.21.4 and Wget2 2.2.1. The GNU manual describes Wget 1.25.0.
• Popcon counts only the systems that opt in to report.
• We will check this page again by December 22, 2026.

Sources

• GNU Wget manual, Proxies (version 1.25.0), read October 22, 2026, and the wget(1) manual page of Wget 1.21.4 on Ubuntu 24.04.
• wget2(1) manual page and wget2 --help, GNU Wget2 2.2.1 on Fedora 44, read October 22, 2026.
• Debian Popularity Contest, installs by package, file of October 22, 2026.
• HProxy, stub proxy runs of Wget 1.21.4 and Wget2 2.2.1, October 22, 2026, on 127.0.0.1 only.