How to debug wget connections

When a wget request fails, the first useful answer is where it stopped. The --debug trace shows DNS resolution, TCP connection, TLS negotiation, the request block, and the server response so the failing layer can be isolated instead of guessed.

Current GNU Wget keeps --debug for full protocol tracing, --spider for checking a target without saving its body, and --output-file for moving the same trace into a log file. That combination is enough for most HTTP or HTTPS connection investigations without changing the target service.

Debug output can expose full URLs, redirect targets, proxy details, request headers, and certificate information. Save longer captures in a private directory, share only sanitized excerpts, and remove the logs after the root cause is documented.

1. Reproduce the failing request with --debug and --spider so wget prints the full connection trace without saving the response body.

   $ wget --debug --spider https://www.example.com/no-such-page
   Setting --spider (spider) to 1
   DEBUG output created by Wget 1.25.0.
   
   Spider mode enabled. Check if remote file exists.
   --2026-04-22--  https://www.example.com/no-such-page
   Resolving www.example.com (www.example.com)... 104.20.23.154, 172.66.147.243, ...
   Connecting to www.example.com (www.example.com)|104.20.23.154|:443... connected.
   Initiating SSL handshake.
   Handshake successful; connected socket 5 to SSL handle 0x0000000000000000
   certificate:
     subject: CN=example.com
     issuer:  CN=Cloudflare TLS Issuing ECC CA 1,O=CLOUDFLARE\, INC.,C=US
   X509 certificate successfully verified and matches host www.example.com
   ##### snipped #####
   HTTP request sent, awaiting response...
   ---response begin---
   HTTP/1.1 404 Not Found
   Content-Type: text/html
   Connection: keep-alive
   Server: cloudflare
   ---response end---
   404 Not Found
   Remote file does not exist -- broken link!!!

   If the trace stops before Connecting to, check name resolution or proxy setup. A failure after Initiating SSL handshake points to TLS or certificate handling, and a trace that reaches an HTTP status line means the network path already worked.

2. Create a private directory before saving diagnostic traces to disk.

   $ install -d -m 700 ~/wget-debug

   Restricted permissions reduce the chance of exposing internal URLs, tokens, or proxy details later.

3. Save the same trace to a log file when the terminal view is too noisy to keep or compare.

   $ wget --debug --output-file=~/wget-debug/example-404.log --spider https://www.example.com/no-such-page

   --output-file moves Wget's detailed messages out of terminal scrollback and into a file that can be reviewed after the run.

4. Re-run the request with the corrected URL, proxy, headers, or certificate path and confirm the trace now ends with the expected response.

   $ wget --debug --spider https://www.example.com/
   Setting --spider (spider) to 1
   DEBUG output created by Wget 1.25.0.
   
   Spider mode enabled. Check if remote file exists.
   --2026-04-22--  https://www.example.com/
   Resolving www.example.com (www.example.com)... 104.20.23.154, 172.66.147.243, ...
   Connecting to www.example.com (www.example.com)|104.20.23.154|:443... connected.
   Initiating SSL handshake.
   X509 certificate successfully verified and matches host www.example.com
   ##### snipped #####
   HTTP request sent, awaiting response...
   ---response begin---
   HTTP/1.1 200 OK
   Content-Type: text/html
   Connection: keep-alive
   Server: cloudflare
   ---response end---
   200 OK
   Remote file exists and could contain further links,
   but recursion is disabled -- not retrieving.

   A successful rerun that reaches 200 OK or the expected redirect proves the request path is working again.

5. Remove the saved trace after the diagnostic session is complete.

   $ rm -f ~/wget-debug/example-404.log

   Verbose traces can keep sensitive request and certificate details longer than needed if they are left in shared locations.