wget reads a proxy from four places, checked in a fixed order. Command-line flags override a .wgetrc file, which overrides the http_proxy/https_proxy environment variables — get the precedence wrong and a proxy you think is active gets silently overridden.
Proxy authentication is one flag pair, verified live in this guide.--proxy-user= and --proxy-password= authenticate with HTTP Basic auth; tested against a real proxy, correct credentials returned 200 and wrong ones returned Proxy Authentication Required.
wget has no native SOCKS5 support — confirmed by reproducing the exact failure. Pointing http_proxy at a socks5h:// URL fails immediately with Unsupported scheme; a SOCKS proxy needs a local HTTP-to-SOCKS bridge in front of wget, not a wget flag.
wget does not retry a refused proxy connection by default. A live test shows exactly one connection attempt on Connection refused unless --retry-connrefused is also passed — a detail most wget-proxy guides skip.
no_proxy exempts specific hosts without touching the rest of the config. It's a comma-separated list of domains that bypass whatever proxy is otherwise configured, checked before wget dials out.
wget has no concept of proxy rotation. It dials exactly one configured proxy per run; anything resembling IP rotation has to come from a shell loop, a rotating gateway, or an external tool wrapped around wget.
Introduction: pointing a single-purpose downloader through a proxy
wget is a command-line tool for retrieving files over HTTP, HTTPS, and FTP, and by default it connects straight to whatever host is in the URL — routing that connection through a proxy means telling wget about the proxy through one of exactly four surfaces: a command-line flag, a per-user ~/.wgetrc, a system-wide /etc/wgetrc, or the http_proxy/https_proxy environment variables. Each surface is documented in the official GNU Wget manual, and each one is demonstrated below against a real, running proxy rather than described from memory.
This guide verifies every claim it makes: proxy authentication is tested against a real 401/407 exchange, the retry behavior is tested against a real refused connection, and the SOCKS5 limitation is reproduced as an actual error message rather than repeated secondhand. Where wget itself can't do something — rotate IPs, speak SOCKS5 natively — that's stated plainly rather than glossed over.
Install wget
wget ships preinstalled on most Linux distributions and is available through the standard package managers everywhere else.
Confirm the install and check the version before relying on flags introduced in newer releases (this guide's examples were verified against GNU Wget 1.21.4):
wget--version
Take a Quick Look
A single proxy in front of wget still means every download comes from one IP — Nstproxy's rotating residential gateway gives wget a single host:port to point at while the exit IP changes server-side, without adding rotation logic to your download script.
Run against a real local proxy (basic-auth enabled) with no_proxy unset, this exact pattern returned a real HTTP/1.1 200 OK and downloaded the target file; the same command with an unreachable proxy address failed with Connection refused, confirming the proxy setting is genuinely in the request path rather than silently ignored.
For a setting that should persist across sessions without exporting shell variables every time, the per-user ~/.wgetrc file uses different (lowercase, underscore-separated) keyword names than the environment variables, and needs use_proxy = on to activate them:
This exact file, loaded via WGETRC=~/.wgetrc wget ..., was tested against the same local proxy and produced the same successful 200 response with no other flags or environment variables set — confirming these are the working keyword names, not just plausible-looking ones. A system-wide /etc/wgetrc (root-owned, applies to every user on the machine) uses the identical keyword syntax; the only difference is scope.
Command-line flags take precedence over both files, which makes them the right choice for a one-off override without touching any persistent config:
wget --no-proxy https://example.com/file.zip
Authenticate the proxy and exempt specific hosts
--proxy-user= and --proxy-password= set proxy credentials directly on the command line, and wget encodes them with HTTP Basic authentication before sending them to the proxy:
Tested against a real authenticated proxy, correct credentials produced a normal 200 response and a full file download; the identical command with the wrong password failed immediately with Proxy tunneling failed: Proxy Authentication Required — the real 407 exchange, not a description of one. If a proxy password contains characters that are special in a shell ($, !, spaces), quote the whole flag value rather than embedding the raw password in the URL form, since an unescaped character there is a common source of an authentication failure that looks like a wrong password but is actually a parsing problem.
no_proxy exempts specific domains from whatever proxy is configured, independent of which of the four surfaces set that proxy:
Requests to hosts matching that list connect directly, bypassing the proxy entirely — useful for routing external downloads through a proxy while leaving internal or already-fast endpoints alone.
Advanced patterns: retries, timeouts, and what SOCKS5 actually requires
wget's default retry behavior is easy to get wrong: --tries=N sets how many attempts to make, but a connection that fails with "Connection refused" is not retried by default at all — tested live, a refused connection made exactly one attempt and gave up, even with --tries=3 set. Getting retries on a refused connection requires --retry-connrefused explicitly:
With that flag added, the same refused-connection scenario produced three labeled attempts ("(try: 2)", "(try: 3)") with a "Retrying." message and a --waitretry backoff between them before giving up — the behavior most guides assume is the default, when it isn't. --timeout=SECONDS (or the more specific --connect-timeout/--read-timeout) bounds how long any single attempt waits, which matters for a proxy that hangs rather than actively refusing.
SOCKS5 is the one case wget can't handle on its own: pointing http_proxy at a socks5h:// URL fails immediately with Error parsing proxy URL socks5h://...: Unsupported scheme. — wget's proxy support is HTTP/HTTPS/FTP only, confirmed by reproducing that exact error rather than repeating the claim from another article. Routing wget through a SOCKS5 proxy means running a local tool that exposes a SOCKS backend as a plain HTTP proxy (or a SOCKS-capable wrapper like tsocks/proxychains) and pointing wget's http_proxy at that local bridge instead of at the SOCKS proxy directly.
Nstproxy is a proxy infrastructure provider whose gateway supports HTTP, HTTPS, and SOCKS5 on the same channel, which sidesteps the wget-SOCKS5 gap entirely for anyone who can choose HTTP mode at the gateway rather than SOCKS5 at the wget layer. Its Residential Lite line fits recurring or bulk wget downloads that need to avoid a single IP building up a block or throttling history: prepaid packages starting at 10GB for $10 (about $1.00/GB), backed by a pool the provider states at 50M+ residential IPs across 200+ countries and regions with a stated 99.5% success rate, with no subscription auto-renewal. The tradeoff to weigh before adopting it: Residential Lite is priced for sustained, cost-sensitive download volume rather than the lowest possible per-request latency, so a workload built around a handful of latency-critical fetches should compare it against a premium residential or datacenter line instead.
One gateway address instead of a rotation script — wget itself has no rotation logic, so a fixed gateway host:port that rotates exit IPs server-side removes the need to wrap wget in a shell loop over an IP list.
HTTP mode avoids the SOCKS5 gap entirely — since the same channel serves HTTP, HTTPS, and SOCKS5, choosing HTTP mode plugs directly into wget's native http_proxy/https_proxy support with no bridge tool required.
Works with all four wget proxy surfaces — the same gateway credentials drop into environment variables, .wgetrc, or --proxy-user/--proxy-password exactly like any other authenticated HTTP proxy.
Honest limits of wget's proxy support
wget has no native SOCKS5 support and no built-in rotation, and both are real gaps rather than configuration options waiting to be discovered — the workarounds above (a SOCKS bridge, an external gateway or shell loop) are genuinely external to wget, not hidden flags. wget also does not manage a cookie jar per request the way a browser or a requests.Session() does automatically; a login-gated download needs --load-cookies/--save-cookies set up explicitly, proxy or not. Finally, a proxy that performs TLS interception (common on some corporate or security proxies) can break --no-check-certificate-free HTTPS downloads in ways that look identical to an unrelated SSL misconfiguration, so ruling the proxy in or out early — by testing the same URL without the proxy — saves time over debugging certificate errors first.
Troubleshooting common wget proxy errors
A Proxy tunneling failed: Proxy Authentication Required message is the direct result of wrong or missing proxy credentials, confirmed above by intentionally sending the wrong password and getting exactly this message back — check --proxy-user/--proxy-password (or the .wgetrc/environment equivalents) for typos or unescaped shell characters first. A bare Connection refused on the proxy host itself means wget never reached the proxy at all — wrong host, wrong port, or the proxy service is down — and, per the retry behavior verified above, wget will not automatically retry that specific failure unless --retry-connrefused is set, so a script that appears to "give up instantly" on a flaky proxy is behaving exactly as documented, not malfunctioning. An Unsupported scheme error naming socks5h:// or socks5:// means a SOCKS proxy URL was handed to a flag or variable that only accepts HTTP/HTTPS/FTP; the fix is a local HTTP bridge in front of the SOCKS proxy, not a different wget flag. An SSL/certificate error through a proxy that doesn't occur without the proxy usually points at TLS interception on the proxy's side rather than at the target site — testing the direct connection is the fastest way to isolate which side the certificate problem is actually on.
Conclusion
Getting wget to use a proxy is one flag, one environment variable pair, or one .wgetrc block — the harder part is knowing which of the four surfaces takes precedence, that authentication is a Basic-auth flag pair away, and that two specific things (SOCKS5, IP rotation) are real gaps rather than missing knowledge. Every claim above was checked against a live proxy or the installed binary rather than repeated from another guide, including the two behaviors — the no-retry-on-refusal default and the SOCKS5 error — that are the easiest to get wrong.
No — wget's built-in proxy support only recognizes HTTP, HTTPS, and FTP proxy URLs, and pointing it at a socks5h:// address fails immediately with an "Unsupported scheme" error, so a SOCKS5 proxy needs a local HTTP-to-SOCKS bridge or a SOCKS-aware wrapper tool in front of wget.
Q: How do I make wget skip the proxy for certain sites?
Set the no_proxy environment variable to a comma-separated list of domains, such as no_proxy="internal.example.com,.corp.example.com", and wget connects directly to any host matching that list regardless of which proxy is otherwise configured.
Q: Why does wget fail with a proxy authentication error?
A Proxy tunneling failed: Proxy Authentication Required message means the proxy rejected the credentials passed via --proxy-user/--proxy-password (or their .wgetrc/environment-variable equivalents) — check for typos or shell-unescaped special characters in the password first.
Q: Does wget retry automatically if the proxy connection is refused?
No by default — a connection refused by the proxy host gets exactly one attempt unless --retry-connrefused is explicitly added alongside --tries, which is a common source of scripts that appear to give up instantly on a temporarily unreachable proxy.
Q: Which takes priority: a command-line proxy flag or the http_proxy environment variable?
Command-line flags win, followed by a .wgetrc file, with the http_proxy/https_proxy environment variables applied last — so a flag like --no-proxy on the command line overrides a proxy set in the environment for that one run without needing to unset the variable.
Q: Can wget rotate between multiple proxies on its own?
No — wget dials exactly one configured proxy per invocation and has no built-in rotation logic, so rotating IPs across multiple wget calls requires either a wrapping shell script that cycles through a proxy list or a provider gateway that rotates the exit IP server-side behind a single fixed address.
Marcus Chen
Aug. 6th 2026
110M+ real IPs with 99.9% access success
Blazing-fast average response ~0.5s for high-concurrency tasks
From only $0.1/GB
Get immediate access to premium residential, datacenter, IPv6 and ISP proxy pools.
