How to use a SOCKS proxy with wget

A SOCKS path is useful when wget has to leave through an SSH tunnel, bastion, or other routed egress path instead of a normal HTTP proxy. The page job is to run wget through that SOCKS path and prove that the request really left through the proxy.

Current GNU Wget manuals and wget --help document native proxy controls for HTTP, HTTPS, and FTP, but not a SOCKS option. To use a SOCKS4 or SOCKS5 gateway, run wget inside a wrapper such as proxychains4, which intercepts the TCP connection and sends it to the proxy.

Treat the wrapper configuration as connection policy, not as a hidden default. Test one short request before you hand the command to cron or CI, and add proxy_dns to the wrapper config only when hostname lookups must also travel through the SOCKS path.

Steps to use a SOCKS proxy with wget:

  1. Confirm that the current wget build exposes native controls only for its standard proxy paths.
    $ wget --help
    GNU Wget 1.25.0, a non-interactive network retriever.
    Usage: wget [OPTION]... [URL]...
    
    ##### snipped #####
    
    Download:
      -w,  --wait=SECONDS              wait SECONDS between retrievals
           --no-proxy                  explicitly turn off proxy
    
    ##### snipped #####
    
    HTTP options:
           --proxy-user=USER           set USER as proxy username
           --proxy-password=PASS       set PASS as proxy password
    
    ##### snipped #####

    The current help output shows proxy controls for wget itself, but no native SOCKS flag. Use a wrapper for SOCKS transport.

  2. Start or confirm a reachable SOCKS endpoint before wrapping wget.
    $ ssh -N -D 127.0.0.1:1080 ops@bastion.ops.example.test

    Keep that SSH session open while wget runs. If you already have a SOCKS service, replace the host and port with that endpoint instead.

  3. Put the wrapper policy in a user-space config file so one job can define its own SOCKS path without touching a system-wide config.
    $ mkdir -p ~/.proxychains
    ~/.proxychains/wget-socks.conf
    dynamic_chain
    
    [ProxyList]
    socks5 127.0.0.1 1080

    Add proxy_dns above [ProxyList] only when DNS lookups must also go through the SOCKS path. With local DNS, wget resolves the host itself and the proxy only carries the TCP session.

  4. Run one short spider request through the wrapper and confirm that the chain line names the SOCKS hop.
    $ proxychains4 -f ~/.proxychains/wget-socks.conf wget --no-config -S --spider http://mirror.example.test/health
    Spider mode enabled. Check if remote file exists.
    --2026-04-22 11:24:41--  http://mirror.example.test/health
    Resolving mirror.example.test (mirror.example.test)... 198.51.100.24
    Connecting to mirror.example.test (mirror.example.test)|198.51.100.24|:80... [proxychains] Dynamic chain  ...  127.0.0.1:1080  ...  198.51.100.24:80  ...  OK
    connected.
    HTTP request sent, awaiting response...
      HTTP/1.1 200 OK
      Content-Type: text/plain
      Content-Length: 2
    Remote file exists.

    The decisive signal is the proxychains chain line. It shows that wget opened the TCP session through the SOCKS endpoint instead of the normal route.

  5. Run the real download through the same wrapper command instead of expecting wget to remember SOCKS settings 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 policy from http_proxy, https_proxy, or /$HOME/.wgetrc/. If you drop proxychains4, the request usually goes back to the direct network path.

  6. Use a short timeout probe for recurring checks so a dead tunnel or proxy fails fast.
    $ 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-04-22 11:24:42--  http://mirror.example.test/health
    Resolving mirror.example.test (mirror.example.test)... 198.51.100.24
    Connecting to mirror.example.test (mirror.example.test)|198.51.100.24|:80... [proxychains] Dynamic chain  ...  127.0.0.1:1080  ...  198.51.100.24:80  ...  OK
    connected.
    HTTP request sent, awaiting response... 200 OK
    Remote file exists.

    That short spider check is a clean health probe for scripts and schedulers. Related: How to set connection and read timeouts in wget