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
Steps to use a SOCKS proxy with wget:
- 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.
- 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.
- 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.
- 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.
- 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.
- 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
Mohd Shakir Zakaria is a cloud architect with deep roots in software development and open-source advocacy. Certified in AWS, Red Hat, VMware, ITIL, and Linux, he specializes in designing and managing robust cloud and on-premises infrastructures.
