How to use a SOCKS proxy with wget

A SOCKS route is useful when downloads need to traverse a jump host, a local tunnel, or a policy path that is not exposed as a normal HTTP proxy. wget can still handle the transfer itself, but the SOCKS transport has to be supplied by a wrapper around the wget process.

wget exposes built-in proxy controls for HTTP, HTTPS, and FTP, but it does not provide native SOCKS flags. A wrapper such as proxychains4 intercepts the TCP connection from the launched command and forwards it through a SOCKS4a or SOCKS5 endpoint, which keeps the wget invocation familiar while moving transport details into the wrapper configuration.

The wrapper and the proxy have to agree on protocol version, address, and DNS behavior before the result is trustworthy. Keep the configuration in user space when possible, enable proxy_dns if hostnames should resolve through the SOCKS path, and test with a short request before using the wrapper in automation.

1. Confirm that the current wget build does not expose a native SOCKS option before choosing a wrapper.

   $ wget --help | grep -n 'proxy\|socks'
   59:       --no-proxy                  explicitly turn off proxy
   102:      --proxy-user=USER           set USER as proxy username
   103:      --proxy-password=PASS       set PASS as proxy password

   The built-in proxy switches cover direct proxy handling, so a SOCKS workflow needs an external wrapper such as proxychains4.

2. Provide a reachable SOCKS endpoint before wrapping wget.

   $ ssh -N -D 1080 ops@bastion.ops.example.test

   Bind the tunnel to 127.0.0.1 unless another host truly needs to share the local SOCKS port.

3. Keep the wrapper configuration in user space so one job can define its own SOCKS policy without rewriting a system-wide file.

   $ mkdir -p ~/.proxychains

   ~/.proxychains/wget-socks.conf
   dynamic_chain
   proxy_dns
   
   [ProxyList]
   socks5 127.0.0.1 1080

   Switch the last line to socks4 or socks4a only when that matches the real endpoint.

4. Run a short request through the wrapper and confirm that the chain report shows the SOCKS hop.

   $ proxychains4 -f ~/.proxychains/wget-socks.conf wget -S --spider http://mirror.example.test/health
   Spider mode enabled. Check if remote file exists.
   --2026-03-29 09:15:11--  http://mirror.example.test/health
   Connecting to mirror.example.test (mirror.example.test)|198.51.100.24|:80... [proxychains] Dynamic chain  ...  127.0.0.1:1080  ...  mirror.example.test:80  ...  OK
   connected.
   HTTP request sent, awaiting response...
     HTTP/1.1 200 OK
     Content-Type: text/plain
     Content-Length: 2
   Remote file exists.

   The proxychains chain line is the decisive signal that wget left through the SOCKS endpoint instead of the normal route.

5. Reuse the same wrapper command in scripts instead of assuming wget will remember the SOCKS policy on its own.

   $ proxychains4 -f ~/.proxychains/wget-socks.conf wget -O asset-index.xml http://mirror.example.test/releases/asset-index.xml

   wget does not read SOCKS settings from http_proxy or /$HOME/.wgetrc/, so dropping the wrapper usually sends traffic back to the direct network path.

6. Probe the wrapped path with short timeout values so proxy failures stop quickly.

   $ proxychains4 -f ~/.proxychains/wget-socks.conf wget --tries=1 --timeout=10 --spider http://mirror.example.test/health
   Spider mode enabled. Check if remote file exists.
   --2026-03-29 09:15:12--  http://mirror.example.test/health
   Connecting to mirror.example.test (mirror.example.test)|198.51.100.24|:80... [proxychains] Dynamic chain  ...  127.0.0.1:1080  ...  mirror.example.test:80  ...  OK
   connected.
   HTTP request sent, awaiting response... 200 OK
   Remote file exists.

   Short spider checks are the safest recurring health probe for a SOCKS-wrapped wget job. Related: How to set connection and read timeouts in wget