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.
Related: How to use an HTTP proxy with wget
$ 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.
$ 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.
$ 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.
$ 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.
$ 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.
$ 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