How to set connection and read timeouts in wget

A stalled wget job is hard to distinguish from a slow but healthy download until it consumes enough wall time to block the next task. Explicit connect and read timeouts put an upper bound on that waiting so scripts fail quickly enough to retry, alert, or move on.

wget can apply one shared ceiling with --timeout or split the behavior with --connect-timeout and --read-timeout. The shared setting maps to DNS, connect, and read timeouts together, while the read timeout measures idle time during a transfer rather than total transfer duration.

Timeouts need to match the network you actually run on. If you set them too low, slow but valid transfers fail; if you set them too high, broken routes still hold the job open longer than necessary. Start with conservative values and validate them against a representative fast target plus one intentionally failing target.

Steps to set connection and read timeouts in wget:

  1. Confirm the available timeout flags on the current build before applying them in scripts or startup files.
    $ wget --help | rg -n 'timeout|dns-timeout|connect-timeout|read-timeout'
    49:  -T,  --timeout=SECONDS           set all timeout values to SECONDS
    50:       --dns-timeout=SECS          set the DNS lookup timeout to SECS
    51:       --connect-timeout=SECS      set the connect timeout to SECS
    52:       --read-timeout=SECS         set the read timeout to SECS
  2. Apply one shared ceiling when you want every network phase to fail within the same budget.
    $ wget --tries=1 --timeout=20 --spider https://example.com/
    Spider mode enabled. Check if remote file exists.
    Connecting to example.com (example.com)|104.18.26.120|:443... connected.
    HTTP request sent, awaiting response... 200 OK
    Remote file exists and could contain further links,
    but recursion is disabled -- not retrieving.

    --timeout is equivalent to setting DNS, connect, and read timeouts together for that command.

  3. Split connect and read behavior when the route is fast to establish but the payload or upstream response can pause intermittently.
    $ wget --tries=1 --connect-timeout=4 --read-timeout=20 --spider https://downloads.example.net/data.bin
    Spider mode enabled. Check if remote file exists.
    Connecting to downloads.example.net (downloads.example.net)|203.0.113.50|:443... connected.
    HTTP request sent, awaiting response... 200 OK

    Keep the connect timeout tight enough to fail unreachable hosts quickly, and give the read timeout more room when a valid server can go idle between chunks.

  4. Persist the chosen defaults in ~/.wgetrc only when the same account should inherit them for repeated jobs.
    ~/.wgetrc
    timeout = 20
    connect_timeout = 4
    read_timeout = 20

    Use the startup file for repeated automation and keep one set of documented values instead of repeating the same flags everywhere. Related: How to configure default options in ~/.wgetrc

  5. Validate the read timeout against a deliberately slow endpoint so you know the error looks exactly like a stalled response.
    $ wget --tries=1 --read-timeout=2 -O - http://slow.example.net/
    Connecting to slow.example.net:80... connected.
    HTTP request sent, awaiting response... Read error (Operation timed out) in headers.
    Giving up.

    Read timeout measures idle time, so it is most useful against connections that establish successfully and then stop sending data.

  6. Validate the connect timeout against an unreachable address so route failures stop on your expected schedule.
    $ wget --tries=1 --connect-timeout=3 --spider http://198.51.100.1:81/
    Spider mode enabled. Check if remote file exists.
    Connecting to 198.51.100.1:81... failed: Operation timed out.
    Giving up.

    Use a non-production unreachable test address for this check so you do not create noise against a real service. Related: How to debug wget connections