How to set connection and read timeouts in wget

A stalled wget transfer can sit long enough to block the next job even when the remote host is never going to respond usefully. Explicit connection and read timeouts stop that wait at a predictable point so retries, alerts, or fallback logic can start sooner.

GNU wget provides --connect-timeout for the socket setup phase and --read-timeout for idle time while waiting for more data after the connection is open. Current GNU Wget also keeps --timeout as a shorthand that sets DNS, connect, and read timers together, and the only timeout enabled by default is a 900-second read timeout.

Timeout values need enough room for the slowest healthy path but not so much room that broken routes hang for minutes. Use --tries=1 while tuning the numbers so the first timeout is easy to see, then save the chosen values in ~/.wgetrc only after the command-line behavior matches the intended failure window.

Related: How to configure default options in ~/.wgetrc
Related: How to retry downloads automatically using wget
Related: How to debug wget connections

Steps to set connection and read timeouts in wget:

  1. Apply one shared network budget when every phase should fail within the same window. 
    $ wget --tries=1 --timeout=15 --spider https://downloads.example.net/releases/platform-agent-2026.04.22.tar.xz
Spider mode enabled. Check if remote file exists.
Resolving downloads.example.net (downloads.example.net)... 203.0.113.24
Connecting to downloads.example.net (downloads.example.net)|203.0.113.24|:443... connected.
HTTP request sent, awaiting response... 200 OK

    --timeout sets the DNS, connect, and read timers together for that one command.

  2. Split the timers when the route should connect quickly but the server may pause between responses. 
    $ wget --tries=1 --connect-timeout=3 --read-timeout=15 --spider https://downloads.example.net/exports/hourly-metrics-2026-04-22.csv.gz
Spider mode enabled. Check if remote file exists.
Resolving downloads.example.net (downloads.example.net)... 203.0.113.24
Connecting to downloads.example.net (downloads.example.net)|203.0.113.24|:443... connected.
HTTP request sent, awaiting response... 200 OK

    Connect timeout controls how long wget waits for the TCP session to open, while read timeout measures idle time between received bytes instead of the full download length.

  3. Save the tested defaults in ~/.wgetrc when the same account should reuse them automatically. 
    ~/.wgetrc
connect_timeout = 3
read_timeout = 15

    Add timeout = 15 instead when a single shared limit is easier to reason about than separate timers.

  4. Validate the read timeout against a test listener that accepts the socket and then stops before sending headers. 
    $ wget --tries=1 --read-timeout=2 -O - http://127.0.0.1:18825/
Connecting to 127.0.0.1:18825... connected.
HTTP request sent, awaiting response... Read error (Operation timed out) in headers.
Giving up.

    Read timeout is idle-time based, so the failure can happen before headers arrive or later in the transfer when a live server stops sending data.

  5. Validate the connect timeout against an unreachable lab address before relying on it in automation. 
    $ wget --tries=1 --connect-timeout=2 --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 address or a spare lab host for this check so the timeout test does not create noise against a real service.