A network timeout means your device sent a request but got no reply within the allowed window. Fix it by isolating the failure point: test the local link, ping the gateway, run traceroute to the target, check DNS, then inspect firewall, MTU and Wi-Fi signal. The step that first fails tells you exactly what to repair.
Symptoms
- Connections hang for 30 to 120 seconds before returning ERR_TIMED_OUT or similar.
- Some sites load while others stall, or downloads restart repeatedly mid-transfer.
- Ping to 8.8.8.8 succeeds but ping by hostname fails, or vice versa.
- VPN tunnels drop after a few minutes of idle time.
- Traceroute shows asterisks or huge latency spikes after a specific hop.
Common Causes
Weak or congested Wi-Fi link
Poor RSSI, 2.4 GHz interference or an overloaded access point causes retransmits. Once retries exceed the TCP window, the session simply times out.
DNS resolution failure
If the resolver is unreachable or slow, the socket never opens. Users perceive this as a timeout even though the target host is fine.
MTU mismatch or PMTUD blackhole
When intermediate hops drop ICMP and the path MTU is smaller than 1500, large packets are silently discarded. Small pings work, big transfers hang.
Firewall, IDS or antivirus inspection
Deep packet inspection or an over-eager rule blocks specific ports (445, 3389, custom app ports) or slows connections until they exceed the app timeout.
Upstream ISP routing or peering issue
Packet loss at a specific hop outside your network stalls TCP retransmits. Traceroute reveals the failing router; only your ISP can fix it.
Step-by-Step Fix
- Reproduce the failure and capture exact error text
Note the application, target hostname, timestamp and error code. Try the same target from a second device on the same network. If both devices fail identically, the issue is upstream of the endpoint; if only one fails, focus on that host. - Test the local link and default gateway
Run ipconfig (Windows) or ip a (Linux/macOS) and confirm you have a valid IPv4 address, subnet mask and gateway. Ping the gateway 20 times. Loss above 1% or latency over 5 ms on a wired LAN points to a bad cable, port or Wi-Fi signal before anything else. - Separate DNS from transport with two pings
Ping 1.1.1.1 and then ping the hostname (for example cloudflare.com). If the IP works but the name fails, DNS is the culprit. Switch the adapter to 1.1.1.1 or 8.8.8.8 temporarily and flush the cache with ipconfig /flushdns or sudo resolvectl flush-caches. - Run traceroute to locate the failing hop
Use tracert on Windows or traceroute -n on Linux/macOS to the target host. Read the output top-down. The first hop showing sustained loss or asterisks is where packets die. Loss inside your LAN points to your router; loss beyond hop two or three is an ISP or peering problem. - Rule out Wi-Fi with a wired test
Plug into the router with Ethernet and repeat the failing action. If the timeout disappears, address the wireless side: move closer to the AP, switch to the 5 GHz SSID, change to a less crowded channel and update the wireless driver from the vendor site. - Check MTU and disable offloads if large transfers stall
If small pings succeed but SMB copies, VPN or HTTPS downloads freeze, test with ping -f -l 1472 <host> (Windows) or ping -M do -s 1472 (Linux). Lower the interface MTU to 1400 as a test. On problem NICs, disable Large Send Offload and TCP checksum offload in the adapter properties. - Bypass firewall, antivirus and VPN in a controlled test
Temporarily stop third-party firewall or endpoint protection and retry. If the timeout clears, add a specific rule for the affected port or application rather than leaving protection off. Disconnect any active VPN client to confirm the tunnel isn't dropping the route. - Update firmware, reset the stack, then escalate
Apply the latest firmware to your router or AP and reboot it cleanly (power off 60 seconds). On the client, run netsh int ip reset and netsh winsock reset, then restart. If traceroute still shows loss beyond your ISP's edge, open a ticket with the trace output attached.
Timeout symptom, likely cause and the first action to take
| Symptom | Likely cause | First action |
|---|---|---|
| Ping to IP works, hostname fails | DNS resolver down or misconfigured | Switch DNS to 1.1.1.1, flush cache |
| Small pings fine, large transfers hang | MTU or PMTUD blackhole | Test with ping -f -l 1472, lower MTU |
| Loss starts at hop 4+ | Upstream ISP routing issue | Capture traceroute, open ISP ticket |
| Only one app times out | Firewall, AV or port block | Check rules, test with protection paused |
| Timeouts only on Wi-Fi | Weak signal or channel congestion | Wired test, change channel, update driver |
| VPN drops after idle | Keepalive or NAT session timeout | Enable DPD/keepalive, shorten interval |
| Intermittent loss on LAN | Faulty cable or duplex mismatch | Swap cable, force auto-negotiate on both ends |
Prevention
- Set static DNS to a reliable resolver on the router so every client inherits it.
- Keep router, switch and NIC firmware or drivers current on a quarterly cycle.
- Monitor gateway latency with a lightweight pinger to catch degradation early.
- Segment guest, IoT and work traffic on separate SSIDs or VLANs to limit congestion.
FAQ
How do I tell if a network timeout is caused by my network or the remote server?
Run traceroute to the target and check where loss begins. If every hop inside your network responds cleanly and loss starts only at the destination, the remote server or its provider is the issue. Also test a second unrelated site; if that works, the problem is remote-specific.
Why does ping work but web pages still time out?
Ping uses ICMP, which many networks prioritise or allow, while HTTPS uses TCP on port 443. A firewall, proxy or DPI device can block or throttle TCP while letting ICMP through. DNS may also resolve slowly enough for the browser to give up before the packet ever leaves.
Is lowering MTU safe as a permanent fix?
Setting MTU to 1400 or 1420 is safe and common on PPPoE, GRE and VPN links where encapsulation eats header space. It slightly reduces throughput but eliminates fragmentation-related timeouts. Test the value that works, then apply it on the router so every client inherits it.
Contact our IT support team to diagnose persistent network timeouts on your infrastructure.