How to Use wget With a Proxy: Setup, Auth & SOCKS (2026)

Using wget with a proxy is simple once you know the basics. You can configure it from the command line, save the settings in a config file like ~/.wgetrc, or use environment variables. Which method you pick depends on whether you need a quick one-off command or a setup that persists across sessions.

In this guide, I'll show you how to make wget use a proxy server, handle authentication, work around the SOCKS5 limitation, and troubleshoot common errors. Whether you're behind a corporate firewall or just want extra privacy, this covers what you need.

Key takeaways

• Fastest setup: Use command-line options like wget -e use_proxy=yes -e http_proxy=http://HOST:PORT https://example.com when you need a proxy for a single command.
• Persistent setup: Save your proxy settings in ~/.wgetrc (per user) or /etc/wgetrc (system-wide). Command-line options override configuration files, and configuration files override environment variables.
• Know the limits: wget supports only Basic proxy authentication and has no native SOCKS support. Use proxychains4 or curl if you need SOCKS, NTLM, or Kerberos.
• Skip the proxy for internal hosts: Use no_proxy to exclude specific domains (localhost, .internal.local) from proxy routing. For production rotation without managing your own pool, a managed endpoint like ScrapingBee handles IPs, geo-targeting, and uptime automatically.

What is wget?

wget is a small command-line tool for downloading multiple files, web pages, and even entire directories from the internet. When you set up a wget proxy, you're simply telling it how to reach the internet when there's a firewall, corporate gateway, or privacy requirement in the way.

It supports HTTP, HTTPS, and FTP, and it doesn't give up easily. If a download gets interrupted or the connection starts acting up, wget will retry, resume where it left off, and keep plugging away until the job gets done.

GNU Wget 1.25.0 is the latest stable release of the original wget utility. Wget2 (currently 2.2.1) is a newer implementation, offering multi-threading, HTTP/2 support, parallel connections, and other performance improvements. It already ships as the default wget implementation in Fedora 40 and newer.

What wget supports (and what it doesn't)

wget supports HTTP, HTTPS, and FTP proxies through the corresponding http_proxy, https_proxy, and ftp_proxy environment variables. So, if you need a wget https proxy setup or just a basic proxy wget workflow, it'll work out of the box.

What it doesn't support is SOCKS proxies. If you need SOCKS, the "Using a SOCKS5 proxy with wget" section below covers the practical workaround.

cURL also handles SOCKS proxies like a champ. Learn how to download files with curl in our tutorial.

There's also the no_proxy environment variable. It tells wget to bypass the proxy for specific hosts or domains. Just add the domains you want to exclude, and wget will connect to them directly.

Short version: HTTP/HTTPS/FTP — yes. SOCKS5 — nope.

Prerequisites and installation

Before you mess with any proxy settings, make sure you install wget on your system. Most Linux distros ship with it, but not all — and macOS/Windows usually need a manual install.

Linux (Debian/Ubuntu)

sudo apt install wget

Linux (RHEL/CentOS/Fedora)

sudo dnf install wget

(Use yum instead of dnf on older systems.)

macOS (Homebrew)

brew install wget

Windows

Grab a prebuilt binary from the GNU project or install it through something like Chocolatey:

choco install wget

Once it's in place, you're good to go. Check if wget is installed using the following command:

wget -V

Setting up a wget proxy or any proxy-related config only works if the tool is installed and visible in your PATH.

wget commands

Here are the core wget commands so you don't have to Google them every time.

Download a single file

wget https://example.com/file.zip

wget saves the file into the current directory with the same name as on the server (file.zip in the example above).

Download a file to a specific directory

If you want the file somewhere else, just cd there first or use -P to point wget to a folder:

wget -P /path/to/dir https://example.com/file.zip

Learn how to automate file downloads with Python and wget in our tutorial.

Rename a downloaded file

If the remote filename is ugly or you want something cleaner:

wget -O newname.zip https://example.com/file.zip

The -O parameter always overwrites, so pick the name wisely.

Define yourself as User-Agent

Some servers get picky about the client you're using. If you need to pretend to be a browser, set a custom user agent header:

wget --user-agent="Mozilla/5.0" https://example.com/page.html

Useful when the default wget user agent gets blocked, although it won't bypass every restriction.

You can also mimic Googlebot to see how a page responds to Google's crawler:

wget --user-agent="Googlebot/2.1 (+http://www.google.com/bot.html)" https://example.com

This is helpful for testing or debugging, but use it responsibly since some servers treat Googlebot requests differently.

Mirroring single webpages

When you're pulling down a page for offline viewing, you don't want half the links still pointing to the live website. That's where --convert-links comes in. After the download finishes, wget rewrites links to point to the local copies instead of the original URLs.

To download a single page along with everything it depends on, use this combination:

wget --page-requisites --html-extension --convert-links https://example.com/page

Each flag has a specific job:

• --page-requisites downloads the page's required assets, including images, CSS, and JavaScript.
• --html-extension saves the page with a .html extension so browsers open it normally.
• --convert-links rewrites links so the page uses your local copies instead of the live website.

This gives you an offline copy of the page that looks and behaves much like the original.

Extract multiple URLs

If you've got a list of URLs in a file:

wget -i urls.txt

wget will chew through the list one line at a time, downloading each URL as it goes. Perfect for batch grabs.

Example urls.txt:

https://example.com/file1.pdf
https://example.com/images/pic.png
https://example.com/archive.zip

How to configure a proxy with wget

By default, wget connects straight to the target server. That's fine until you hit something annoying like blocked pages, rate limits, geo restrictions, or when you just want your current IP address to stay hidden. Using a proxy fixes all that.

With ScrapingBee, you get two ways to do it: the super-simple API call, or the more traditional proxy mode. And if you're not using ScrapingBee, the same four proxy methods still apply to any normal proxy.

Step 1 - ScrapingBee setup

ScrapingBee can be used in two flavors:

• API mode — the easiest. You don't configure any proxy at all; you just call their API and they handle everything.
• Proxy mode — looks like a normal HTTP proxy, perfect if you already know your way around wget.

Both ways work fine; use whatever matches your workflow.

Before proceeding, make sure to grab your free trial at app.scrapingbee.com/account/register with 1,000 credits as a gift (plenty for testing!).

Option A: API mode (simplest, no proxy config)

Just call the API directly with your specified URL and API key. The API key can be found in your ScrapingBee dashboard.

wget "https://app.scrapingbee.com/api/v1/?api_key=YOUR_API_KEY&url=https://example.com"

Option B: Proxy mode (recommended for wget power users)

ScrapingBee exposes regular HTTP/HTTPS proxy endpoints:

• HTTP: http://proxy.scrapingbee.com:8886
• HTTPS: https://proxy.scrapingbee.com:8887
• SOCKS5: socks5://socks.scrapingbee.com:8888, if you ever need it in other projects (wget does not support it)

Authentication and parameters: ScrapingBee uses the proxy URL itself to pass both your API key and any extra settings.

• Username — your API key
• Password — your parameters (everything after the colon)
• Parameters are written as a query-string: render_js=False&premium_proxy=True&country=us

Here's what the complete proxy URL looks like:

https://YOUR_API_KEY:render_js=False&premium_proxy=True@proxy.scrapingbee.com:8887

Step 2 - One-off test via command flags

This is the fastest way to confirm the proxy works without config files or any additional setup. Just run the following command and see it fetch through the proxy.

wget -e use_proxy=yes \
  -e http_proxy=http://proxy.scrapingbee.com:8886 \
  --proxy-user="YOUR_API_KEY" \
  --proxy-password="premium_proxy=True" \
  https://example.com

To verify the proxy is actually active, print your exit IP:

wget -qO- -e use_proxy=yes \
  -e http_proxy=http://proxy.scrapingbee.com:8886 \
  --proxy-user="YOUR_API_KEY" \
  --proxy-password="premium_proxy=True" \
  https://api.ipify.org

If the IP address is different from your real one — good, you're tunneling through ScrapingBee properly.

Step 3 - Persistent user config (~/.wgetrc)

If you don't want to type flags every time, drop your proxy settings into ~/.wgetrc. After that, every wget command automatically goes through ScrapingBee.

Example:

use_proxy = on
http_proxy = http://proxy.scrapingbee.com:8886
https_proxy = https://proxy.scrapingbee.com:8887
proxy_user = YOUR_API_KEY
proxy_password = premium_proxy=True
no_proxy = localhost,127.0.0.1,.internal.local

Heads-up: ~/.wgetrc is plain text, so anyone with access to your machine can see your API key. Use with care.

Step 4 - Use and adjust features

Once everything's configured, you run wget like normal. ScrapingBee handles proxy rotation, JS rendering, premium IP pools, all behind the scenes.

Basic download using your saved proxy:

wget https://example.com

To switch features, modify the password string in your config or command:

• render_js=True — turn on JS rendering
• premium_proxy=True — use higher-quality IPs
• country_code=US — geo-target the request (premium required)

Combine them like this:

render_js=True&premium_proxy=True&country_code=US

Alternative: Generic 4 methods (any proxy provider)

These setups work with any normal proxy: residential, datacenter, ISP, corporate gateway, whatever. Just swap in your own HOST, PORT, USERNAME, and PASSWORD. No provider-specific magic here.

If you configure a wget proxy server in more than one place, wget applies settings in this order: command-line options override ~/.wgetrc, ~/.wgetrc overrides /etc/wgetrc, and both configuration files override environment variables. Understanding this wget proxy configuration order makes it much easier to troubleshoot unexpected wget proxy config behavior.

Method 1 – Command flags (one-off proxy)

This routes a single command through your specified proxy server. Quick, disposable, perfect for testing:

wget -e use_proxy=yes -e http_proxy=http://HOST:PORT https://example.com

With authentication:

wget -e use_proxy=yes \
  -e http_proxy=http://HOST:PORT \
  --proxy-user=USERNAME \
  --proxy-password=PASSWORD \
  https://example.com

Verify the proxy is active:

wget -qO- \
  -e use_proxy=yes \
  -e http_proxy=http://HOST:PORT \
  --proxy-user="USERNAME" \
  --proxy-password="PASSWORD" \
  https://api.ipify.org

Method 2 - User config (~/.wgetrc)

This is your personal wget config — settings here apply only to the current user, not the whole system. Perfect when you want persistent proxy settings without touching system-wide files.

Where to put it:

• Linux / macOS — Create a file named .wgetrc in your home directory: ~/.wgetrc.
• Windows — Try either C:/Users/<USERNAME>\.wgetrc or C:/Users/<USERNAME>/_wgetrc file (might depend on your wget build).

Here's the example config:

use_proxy = on

http_proxy = http://HOST:PORT
https_proxy = https://HOST:PORT

proxy_user = USERNAME
proxy_password = PASSWORD

no_proxy = example.com,.internal.local

After saving this file, every wget command automatically uses your proxy settings.

Heads-up: This file is plain text, so anyone with access to your account can read your credentials. Handle with care.

Method 3 - System config (/etc/wgetrc)

For every user on the system to use the same proxy settings, configure the system-wide wgetrc file. Open the file and add:

use_proxy = on
http_proxy = http://HOST:PORT
https_proxy = http://HOST:PORT

This method requires root access, so you'll need administrator privileges to edit the file. Don't put passwords here unless you know what you're doing.

Note: On Unix-like systems, the system-wide configuration is typically stored in /etc/wgetrc. On Windows, the location depends on your wget build and is often found alongside the wget executable.

Method 4 - Environment variables

This approach is useful for scripts, containers, and temporary sessions. Instead of configuring each application separately, you set environment variables once, and wget automatically uses them for every request. The supported variables are http_proxy, https_proxy, ftp_proxy, and no_proxy.

For most proxy servers, both http_proxy and https_proxy use the http:// scheme. Although the destination website may use HTTPS, wget first connects to the proxy over HTTP and then establishes a secure HTTPS tunnel using the HTTP CONNECT method.

Linux/macOS:

export http_proxy=http://HOST:PORT
export https_proxy=http://HOST:PORT

Windows (CMD):

set http_proxy=http://HOST:PORT
set https_proxy=http://HOST:PORT

If your proxy provider offers a true HTTPS proxy endpoint (for example, ScrapingBee's :8887 endpoint), you can use https://HOST:PORT.

export https_proxy=https://USER:PASS@proxy.scrapingbee.com:8887

If you no longer want wget to use a proxy, remove the environment variables.

Disable on Linux/macOS:

unset http_proxy
unset https_proxy

Disable on Windows:

set http_proxy=
set https_proxy=

Common wget proxy errors

Proxy not used

If wget connects directly without your proxy:

• Make sure use_proxy = on is enabled if you're using a wgetrc file.
• Check for typos in http_proxy and https_proxy.
• If you're using no_proxy, separate domains with commas and don't include spaces (for example, example.com,.internal.local).
• Check for leftover environment variables. Existing http_proxy or https_proxy values can silently override the proxy settings you're expecting to use.

407 Proxy Authentication Required

If you see "407 Proxy Authentication Required" or "Proxy tunneling failed: Proxy Authentication Required", verify that your proxy username and password are correct.

If the credentials are correct but the error persists, your proxy may require NTLM or Kerberos authentication. wget supports only Basic proxy authentication, so you'll need a tool such as cURL or a local authentication bridge that handles those schemes.

400 Bad Request

This usually means the proxy host or port is incorrect, or the proxy URL is malformed. You might also have leftover http_proxy or https_proxy environment variables getting in the way. Clear them and try the command again.

SSL errors

Verify that your CA certificates are up to date and that you're using the correct proxy endpoint. Avoid --no-check-certificate unless you're just testing; it's unsafe for real use as it disables certificate validation.

Authenticated proxies

For wget proxy authentication, you have three options: pass your authentication details with command-line flags, save them in ~/.wgetrc, or include them directly in the proxy URL (http://USER:PASS@HOST:PORT). All three let you run wget with proxy, so the right choice depends on whether you need a one-off command or a persistent setup.

Note that wget supports only Basic proxy authentication. If your corporate proxy requires NTLM or Kerberos, you'll keep getting "407 Proxy Authentication Required" no matter what wget proxy user or password you provide. In that case, wget isn't the right tool for the job. Switch to curl, which supports those authentication schemes, or put a local authentication bridge in front of wget.

Using command flags (quick and temporary)

This is the safest option for local use because the password isn't stored on disk:

wget -e use_proxy=yes \
  -e http_proxy=http://HOST:PORT \
  --proxy-user="USERNAME" \
  --proxy-password="PASSWORD" \
  https://example.com

If your password contains characters like @, :, &, $, or spaces, wrap it in quotes. Some shells may require escaping for &, $, @. On Windows CMD, escaping rules differ, and quoting is usually enough.

Example with escaping:

--proxy-password="p@ssw0rd\&more"

To confirm the proxy is really being used:

wget -qO- \
  -e use_proxy=yes \
  -e http_proxy=http://HOST:PORT \
  --proxy-user="USERNAME" \
  --proxy-password="PASSWORD" \
  https://api.ipify.org

If you see the proxy's exit IP, you're good.

Using ~/.wgetrc (persistent config)

If you run wget constantly and don't want to repeat flags, drop everything into your user config:

use_proxy = on

http_proxy = http://HOST:PORT
https_proxy = https://HOST:PORT

proxy_user = USERNAME
proxy_password = PASSWORD

This makes every request go through the authenticated proxy unless you override it.

Once again, don't forget that on Windows wget config typically lives in C:/Users/<username>/.wgetrc.

Handling credentials safely (CI, automation, shared systems)

If you're scripting or running in CI/CD:

• Inject creds via environment variables. Example:

export PROXY_PASS="PASSWORD"
wget --proxy-password="$PROXY_PASS" ...

• Use a password manager to generate a temp token and store it only in memory.
• Avoid committing ~/.wgetrc into containers or images; build it at runtime instead.

Short version:

• Flags — safest for ad-hoc use
• ~/.wgetrc — convenient for day-to-day work
• CI — environment injection

Authenticated proxies work cleanly with wget if you quote passwords properly and avoid leaving secrets lying around.

Using a SOCKS5 proxy with wget (the workaround)

wget does not natively support SOCKS5 proxies, even settings like socks_proxy or socks5://HOST:PORT won't help because wget only understands HTTP-style proxying.

The simplest workaround is proxychains4. It intercepts a program's network calls at the OS level and routes them through a SOCKS proxy, without the program itself needing to know SOCKS exists.

Add your proxy to the ProxyList section of your proxychains4 configuration file:

[ProxyList]
socks5 HOST PORT

If your proxy requires authentication, use:

[ProxyList]
socks5 HOST PORT USERNAME PASSWORD

Then run wget through proxychains4:

proxychains4 wget https://example.com

That's it. wget works as usual, while proxychains4 handles the SOCKS tunneling underneath. You can use the same wrapper with any other wget flags:

proxychains4 wget --tries=10 https://example.com

Routing through Tor

If you're routing traffic through the Tor network, use torsocks instead. It's designed specifically for Tor and works with Tor's SOCKS proxy out of the box.

torsocks wget https://example.com

If SOCKS is a regular requirement, use cURL instead

If your workflow depends on SOCKS proxies, cURL is usually the better fit. It supports SOCKS4, SOCKS5, NTLM proxy authentication, and HTTPS-to-proxy connections natively, so you don't need wrappers.

See our guide to using cURL with a proxy: https://www.scrapingbee.com/blog/curl-proxy/

Rate limiting, retries, and no-proxy rules

When you're running wget via proxy, it's smart to control how hard you hit the target site and decide which hosts should skip the proxy entirely. wget has a few simple flags for this, and they make a big difference in reliability.

Limit download speed

If you don't want to blast the proxy or the website, cap your speed:

wget --limit-rate=200k https://example.com/file.zip

--limit-rate slows wget down by capping the maximum download speed. It prevents you from hammering the proxy or the target site and keeps your traffic smooth and predictable.

You can use k or m units (e.g., 200k, 2m).

Add retries and backoff

When a proxy or target server flakes out, these help avoid pointless failures:

wget --tries=10 --waitretry=10 https://example.com/data.json

• --tries=10 — maximum number of attempts for this download.
• --waitretry=10 — wait 10 seconds between failed requests, and increase the delay if failures keep happening.

These options only kick in when something goes wrong: connection timeouts, DNS hiccups, dropped connections, or certain HTTP errors from the server (like 5xx / rate limiting). If the file downloads fine on the first try, wget doesn't wait or retry at all.

If the problem is permanent (wrong URL, hard block, real 404), retries will just run until they hit the limit and then give up.

Using the no_proxy rule

Sometimes you want wget no proxy behavior for certain hosts like internal services, local dev machines, VPN-only domains, etc. The no_proxy variable handles that:

On Linux and macOS:

export no_proxy="localhost,127.0.0.1,.internal.local"

On Windows (CMD):

set no_proxy=localhost,127.0.0.1,.internal.local

Notice that the no_proxy entries are separated by commas, with no spaces. For example, .internal.local matches any host ending with internal.local, so wget connects to those hosts directly instead of using the proxy.

If you only want to disable the proxy for a single download, use the --no-proxy flag:

wget --no-proxy https://example.com/file.zip

You can also combine a proxy with no_proxy:

export http_proxy=http://HOST:PORT
export no_proxy="localhost,127.0.0.1,.corp"

With this setup, requests to the hosts in no_proxy go directly, while everything else uses your configured proxy.

Rotating proxies with wget

If you want to run wget through proxy servers that rotate on every request, the simplest DIY method is a plain text list plus a small shell loop. It's not fancy, but it works, especially for quick experiments. For anything serious, though, maintaining your own rotation becomes a grind fast.

If you're comparing rotating and residential proxies, our guide explains the tradeoffs and when each approach makes sense.

Basic shell rotation (proxies.txt + shuf)

Create a file with one proxy per line:

http://USER:PASS@PROXY1:PORT
http://USER:PASS@PROXY2:PORT
http://USER:PASS@PROXY3:PORT

Then pick a random one before each request:

PROXY=$(shuf -n 1 proxies.txt)

wget -e use_proxy=yes \
  -e http_proxy="$PROXY" \
  https://example.com

Windows (CMD) version:

for /f %%p in ('powershell -NoProfile -Command "(Get-Content proxies.txt) | Get-Random"') do (
    wget -e use_proxy=yes -e http_proxy="%%p" https://example.com
)

Loop it if you have multiple URLs. Linux version:

while read -r url; do
  PROXY=$(shuf -n 1 proxies.txt)
  wget -e use_proxy=yes -e http_proxy="$PROXY" "$url"
done < urls.txt

Windows (CMD) version:

for /f %%u in (urls.txt) do (
    for /f %%p in ('powershell -NoProfile -Command "(Get-Content proxies.txt) | Get-Random"') do (
        wget -e use_proxy=yes -e http_proxy="%%p" "%%u"
    )
)

This gives you basic wget proxy rotation without extra tools.

Downsides of DIY rotation

A rotating free or scraped proxy list has the usual issues:

• Most free proxies die constantly — Half your list goes offline within hours.
• High ban rate — Public proxies are usually overused and already blocked by many sites.
• Credential headache — If each proxy has different creds, keeping them updated becomes a mess.
• Maintenance burden — You end up babysitting the list instead of actually doing your scraping or mirroring.

When to avoid self-managed rotation

If you're doing any real scraping, backups, or site mirroring, rolling your own rotation gets painful. Managed services handle:

• automatic IP rotation
• residential or premium pools
• geolocation targeting
• ban handling and retries
• consistent uptime

DIY works for testing. For production, use proper managed rotation so you can focus on the actual task, not fixing dead proxies every hour.

Choosing the right approach

There's no single "best" wget proxy setup as it depends on how you work. Here's the quick decision guide so you don't overthink it and don't end up duct-taping random configs together.

One-off test

Use command flags. Fast, clean, nothing saved on disk.

wget -e use_proxy=yes -e http_proxy=http://HOST:PORT https://example.com

Perfect for trying a proxy without changing your wget configuration.

Regular local use or CI pipelines

Use ~/.wgetrc. Your user or job gets consistent proxy behavior, no repeated flags, and scripts stay clean.

Great for: dev machines, cron jobs, CI runners where you want predictable behavior per user.

Fleet, containers, or shared servers

Use /etc/wgetrc (unless you're on Windows, duh). Machine-wide defaults keep everything aligned. Every container, user, or automated job uses the same proxy rules.

Useful when you have multiple services calling wget and want the same routing everywhere. Containers can also use ENV-based proxy settings (often easier than baking configs into images).

Need rotation, geolocation, or JS rendering

Use ScrapingBee API or proxy mode. That's the simplest path — no juggling dead proxies, no maintaining lists, no weird rotation logic.

• API mode — easiest (no proxy config at all).
• Proxy mode — behaves like a normal proxy but gives rotation, geo, and JS behind the scenes.

Short version

• Flags for quick checks
• ~/.wgetrc for personal or CI use
• /etc/wgetrc for shared systems
• ScrapingBee when you want real proxy features without messing with DIY infrastructure.

Skip the proxy babysitting with ScrapingBee

If you want your wget proxy setup to just work (no dead IPs, no constant list updates, no weird failures) ScrapingBee gives you rotation, premium IP pools, and optional geolocation without any maintenance pain. You can run wget through proxy mode like a normal HTTP proxy, or skip proxy config entirely and hit a single API URL. Either way, you get stable, managed traffic.

If you're ready to make downloads cleaner and scraping more reliable, start using ScrapingBee today.

wget proxy FAQs

How do I use a proxy with wget for a single command?

Use the -e use_proxy=yes flag and point http_proxy to your server. This is the fastest way to run wget with proxy once without changing your system config.

Example:

wget -e use_proxy=yes -e http_proxy=http://HOST:PORT https://example.com

How can I set an authenticated proxy for wget without exposing credentials in my shell history?

Use environment variables or a temporary script instead of typing the password directly. For example, export PROXY_PASS and pass it with --proxy-password="$PROXY_PASS". You can also use --ask-password for interactive runs if your system supports it.

This keeps your wget proxy credentials out of history and logs.

Does wget support SOCKS5 proxies?

No. wget has no native SOCKS5 support. It only handles HTTP, HTTPS, and FTP proxies. For SOCKS5, the "Using a SOCKS5 proxy with wget (the workaround)" section in this article covers how to use proxychains4 to route wget through a SOCKS proxy. It also explains when curl is the better option.

What's the difference between setting http_proxy env vars and .wgetrc?

Environment variables apply only to the current shell or script, while .wgetrc gives you a persistent configuration for every call. On Windows the user config lives in C:/Users/<user>/.wgetrc instead of ~/.wgetrc.

Use env vars for temporary changes and .wgetrc for long-term setups where you always want wget set proxy rules applied.

How do I bypass the proxy for specific domains with wget (no_proxy)?

Set the no_proxy variable with a comma-separated list like localhost,.internal.local. wget will connect directly to those domains even when a global proxy is configured. This is the clean way to do wget no proxy routing for internal services.

What's the simplest way to get rotating/geolocated IPs with wget?

Use a managed provider like ScrapingBee in API or proxy mode. This gives you rotation, geo-targeting, and premium IP pools without maintaining lists. It's the easiest reliable method to run wget through proxy setups at scale.

Does the proxy setup work with BusyBox wget (Alpine, Docker)?

BusyBox wget supports basic proxy configuration through the http_proxy and https_proxy environment variables, but it leaves out many features available in GNU wget. That means options like --proxy-user and -e aren't available. For authenticated proxies, use a proxy URL like http://USER:PASS@HOST:PORT, or install the full GNU wget package in Alpine with apk add wget if you need the complete feature set.