How to debug wget connections

When wget only reports a timeout, TLS failure, or HTTP error, the first job is separating the layer that failed from the symptom that surfaced last. A debug trace exposes DNS resolution, socket setup, certificate handling, redirects, and the final response so the next fix can be targeted instead of guessed.

The --debug option expands Wget logging with connection-state and protocol details, and pairing it with --output-file keeps the trace in a durable log instead of terminal scrollback. Adding --spider exercises the request path without saving the payload, which keeps the capture short and easier to inspect.

Verbose traces often contain full URLs, headers, redirects, proxy details, and internal hostnames. Capture them in a private directory, replace environment-specific identifiers before sharing excerpts, and remove the logs after the root cause is documented so the diagnostic data does not linger in shared locations.

1. Create a private directory for debug captures before collecting any connection details.

   $ mkdir -p "$HOME/wget-debug"
   $ chmod 700 "$HOME/wget-debug"

   Restricted permissions reduce the chance of exposing headers, URLs, or other diagnostic material to unrelated users.

2. Capture one focused trace with --debug, --output-file, and --spider so the request path is logged without saving a payload.

   $ wget --debug --output-file="$HOME/wget-debug/wget-403.log" --spider https://downloads.example.net/restricted/package.tar.gz

   A short representative URL keeps the log readable and makes later comparison with a success case much easier.

3. Check resolution, connection, and first response lines before changing certificates, proxies, or retry logic.

   $ rg -n 'Resolving|Connecting to|HTTP request sent|awaiting response' "$HOME/wget-debug/wget-403.log"
   8:Resolving downloads.example.net (downloads.example.net)... 203.0.113.24, 203.0.113.25
   10:Connecting to downloads.example.net (downloads.example.net)|203.0.113.24|:443... connected.
   29:HTTP request sent, awaiting response...

   Missing or broken Resolving lines point toward DNS problems, while failures after Connecting to usually belong to TLS or HTTP handling.

   Related: How to check DNS resolution in Linux

4. Inspect the TLS section separately so transport failures are not confused with application-layer rejection.

   $ rg -n 'TLS|SSL|certificate|handshake' "$HOME/wget-debug/wget-403.log"
   13:Initiating SSL handshake.
   15:certificate:
   17:  issuer: CN=Example Issuing CA,O=Example Trust Services,C=US
   18:X509 certificate successfully verified and matches host downloads.example.net

   Successful handshake and certificate lines prove that the transport layer completed before the server made an application decision.

   Use --no-check-certificate only as a temporary diagnostic on controlled systems because it disables server identity verification.

   Related: How to ignore SSL certificate errors in wget

5. Review the exact request block and the returned status code to decide whether the problem is transport or policy.

   $ sed -n '/---request begin---/,/---request end---/p' "$HOME/wget-debug/wget-403.log"
   ---request begin---
   HEAD /restricted/package.tar.gz HTTP/1.1
   Host: downloads.example.net
   User-Agent: Wget/1.25.0
   Accept: */*
   Accept-Encoding: identity
   Connection: Keep-Alive
   
   ---request end---
   
   $ rg -n 'HTTP/1.1 403|Location:' "$HOME/wget-debug/wget-403.log"
   31:HTTP/1.1 403 Forbidden

   A visible 403 or redirect chain usually points to URL, authentication, or header policy rather than raw network reachability.

6. Re-run the corrected command against a small public payload and confirm that a real file is saved normally.

   $ wget --debug --output-file="$HOME/wget-debug/wget-ok.log" https://downloads.example.net/public/sample-archive.tar.gz -O "$HOME/wget-debug/debug-ok.bin"
   $ ls -lh "$HOME/wget-debug/debug-ok.bin"
   -rw-------  1 user  user    64K Mar 29 11:18 /home/user/wget-debug/debug-ok.bin

   Keep the success test small so the second trace stays easy to compare with the failing run.

7. Remove or rotate the debug logs once the root cause is recorded elsewhere.

   $ rm -f "$HOME/wget-debug/wget-403.log" "$HOME/wget-debug/wget-ok.log" "$HOME/wget-debug/debug-ok.bin"

   Leaving verbose logs on disk increases the chance of exposing internal URLs, tokens, or request metadata later.