ERR_CONNECTION_TIMED_OUT

DIRECT ANSWER

`ERR_CONNECTION_TIMED_OUT` means the browser waited for the destination server or an intermediary to respond, but no usable response arrived before the connection timeout. Common causes include an unreachable or overloaded server, a firewall silently dropping traffic, incorrect DNS, a broken network route, or a CDN or proxy that cannot reach the origin. Test from another network first, then check DNS, infrastructure health, firewall rules, and resource usage.

Key takeaways

A timeout differs from ERR_CONNECTION_REFUSED: a refusal usually returns an immediate rejection, while a timeout means no usable response arrived in time.
Test from a second network before changing the server. This helps separate a visitor-side VPN, proxy, firewall, ISP, or routing issue from a broader outage.
Check DNS results, provider health, cloud security rules, host firewall rules, and resource usage in that order.
Check both IPv4 and IPv6 records. An incorrect or unreachable IPv6 destination can affect users whose networks prefer IPv6.
A failed ping does not prove the server is down because ICMP may be blocked even when HTTPS works.
If the provider reports a healthy host but external connections still time out, escalate with timestamps, DNS results, test-network details, and connection output.

Reviewed 2026-09-25 HTTP & Server Errors

Site Administrator

Last reviewed: September 25, 2026

What this error means & how to recognize it

The browser displays a message such as “This site can’t be reached” with ERR_CONNECTION_TIMED_OUT.
The failure appears after a noticeable wait rather than immediately.
The hostname works from one network but times out from another.
Requests to the server’s public address can also time out while the hosting console still shows the instance as running.
The problem affects many visitors when the host, network interface, route, or upstream network is unavailable.
A server under severe CPU, memory, process, or connection pressure may remain powered on but fail to complete new connections promptly.
A CDN, reverse proxy, or load balancer may be reachable while its connection to the origin times out.

Root causes, ordered by likelihood

The host or network interface is unreachable — the server, VM, network interface, route, or upstream network may be unavailable.
A firewall or security group silently drops traffic — a drop rule commonly causes a timeout, whereas an explicit reject generally fails faster.
The server is overloaded — resource exhaustion, process limits, or too many open connections can prevent the TCP handshake or application response from completing.
DNS points to the wrong destination — the hostname may resolve to an old address, an unreachable address, or infrastructure that no longer serves the site.
The visitor’s network path is broken — an ISP routing problem, VPN, proxy, local firewall, or filtering device may block access from one network.
IPv6 is configured incorrectly — an unusable AAAA record can cause failures for networks that prefer IPv6 even when the IPv4 service works.
A CDN, reverse proxy, load balancer, or upstream protection layer is misconfigured — the front end may be unable to reach the origin even though the origin itself is running.

How to fix it

Diagnostic flow at a glance — full detail in the steps below.

1. Test from a second network

Open the site using mobile data or another unrelated connection. If a VPN or proxy is active, test without it when permitted.

Works on the second network: investigate the original Wi-Fi, ISP route, local firewall, VPN, proxy, or filtering device.
Times out everywhere: continue with DNS, server, firewall, and hosting-provider checks.

Do not assume that one successful test proves the site is healthy for every user; routing and address-family problems can affect only some networks.

2. Check DNS and both address families

Use a DNS lookup tool such as nslookup or dig to identify the IPv4 and IPv6 addresses returned for the hostname. Compare every returned address with the server, load balancer, CDN, or other service that should receive traffic.

Look for an obsolete address, an unexpected record, or an IPv6 destination that is not configured. If DNS changed recently, check the authoritative records and allow for the configured caching period before judging the change from one network.

3. Test the service without relying on the browser

From a network that should be able to reach the site, run a read-only request such as:

text

curl -v --connect-timeout 10 https://[your hostname]

The verbose output helps show whether the failure occurs during hostname resolution, TCP connection establishment, or HTTPS negotiation. Test the actual service port and protocol. A failed ping alone is not conclusive because ICMP may be blocked.

If you administer the service, compare IPv4 and IPv6 connection behavior separately using appropriate read-only tests. A failure on only one address family narrows the investigation to that route, listener, firewall policy, or DNS record.

4. Check the hosting provider’s console

Use the provider dashboard or out-of-band console rather than relying on SSH when network access is failing. Confirm that the instance is running, the network interface is attached, the public address is correct, and provider health checks show no failure.

If the console shows that the host is unresponsive, use an authorized recovery procedure. A restart or power cycle is an operational change: confirm permission, understand the effect on active users and unsaved work, and follow the provider’s documented recovery process.

5. Review cloud and host firewall rules

Check security groups, network ACLs, and provider firewall policies for the expected inbound service port, normally HTTP or HTTPS as configured. Then review the operating system firewall, such as ufw or iptables, if console access is available.

Check rules introduced during a hardening change, deployment, address update, or migration. Confirm that traffic is allowed from the relevant source ranges and that the rule applies to the correct interface and address family. Do not broadly disable protection; make only the smallest authorized change and document it.

6. Check for resource exhaustion

From the provider console or an existing administrative session, inspect CPU, memory, disk pressure, process limits, listening sockets, and connection counts. A machine can appear powered on while being too saturated to accept new connections.

Compare current readings with normal levels and review logs around the first failure. If a service is exhausted, follow the approved capacity or recovery procedure rather than repeatedly restarting it. A restart can interrupt active traffic and conceal the underlying load problem.

7. Check a proxy, CDN, or load balancer

If DNS points to a CDN, reverse proxy, or load balancer, verify that the front end can reach the origin on the configured port. Check the origin address, health-check status, TLS settings, network route, and allowlists.

A healthy origin does not rule out a broken policy or route between the front end and origin. Conversely, a healthy front end does not prove that the origin is accepting connections.

8. Escalate with useful evidence

Record the affected hostname, approximate time and time zone, client network, resolved IPv4 and IPv6 addresses, whether each address family behaves differently, verbose connection output, and the provider-console health state. This evidence helps distinguish DNS, routing, filtering, host, and intermediary failures.

Prevention & how to verify the fix

Monitor the site from multiple external locations and alert on connection timeouts separately from HTTP status failures.
Keep DNS records, public addresses, CDN origins, and IPv4/IPv6 configuration documented and review them after migrations.
Test firewall and security-group changes through a controlled process with a recovery path through the provider console.
Maintain CPU, memory, file-descriptor, process, and connection headroom so traffic spikes do not prevent new connections.
Monitor origin health separately from CDN or load-balancer health.
Include second-network testing and connection-timeout evidence in the incident checklist.
Use clear, intentional firewall behavior for legitimate service ports while preserving the environment’s required security policy.

When to get outside help

Contact the hosting provider or network team when the provider console reports a healthy instance but external connections still time out, or when the failure affects multiple unrelated networks. Escalate promptly if DNS is correct and permitted firewall rules appear correct, yet both direct-origin and front-end connections fail. Provide timestamps, affected addresses, test networks, DNS results, connection output, and provider health information. Avoid repeatedly restarting a production server without an approved recovery plan.

Run a website check

Frequently asked questions

What does ERR_CONNECTION_TIMED_OUT mean?

It means the browser did not receive a usable response while trying to establish or complete the connection before its timeout expired. The message does not identify one specific cause; the problem may be on the client network, the route, a firewall, the destination host, or an intermediary such as a load balancer.

How is ERR_CONNECTION_TIMED_OUT different from ERR_CONNECTION_REFUSED?

A timeout means the connection attempt received no timely usable response. A refused connection is usually an immediate response from the destination or an intermediary indicating that the connection was rejected, often because nothing is listening on the port or a policy actively refuses it.

Can a firewall cause ERR_CONNECTION_TIMED_OUT?

Yes. A firewall rule that silently drops packets can make the browser wait until its timeout expires. Review both cloud security controls and the host firewall, and distinguish a deliberate drop from an explicit reject.

Why does the site work on mobile data but not Wi-Fi?

That pattern points toward the Wi-Fi network, its ISP route, a local firewall, VPN, proxy, or filtering device. It does not prove that the server is healthy, but it makes a destination-wide outage less likely.

Does a failed ping prove that the server is down?

No. ICMP may be blocked even when TCP and HTTPS are available. Test the actual service port and check the hosting console; treat ping as supporting evidence only.

Can DNS cause a connection timeout?

Yes. If the hostname resolves to an old, unreachable, or incorrectly configured address, the browser may wait for a response that never arrives. Check every returned address, including IPv6, against the infrastructure that should serve the hostname.

Further documentation

For authoritative implementation details, consult the documentation for the relevant browser’s network-error behavior, the hosting provider’s instance and network-health tools, the DNS service’s record-management guidance, and the operating system or cloud platform’s firewall and security-group documentation. If a CDN, reverse proxy, or load balancer is involved, also consult that product’s origin-health, routing, TLS, and access-control documentation.