ERR_CONNECTION_TIMED_OUT Hatası Nasıl Düzeltilir: Eksiksiz Teknik Kılavuz

The ERR_CONNECTION_TIMED_OUT error means your browser sent a connection request to a remote server but received no response within the allotted time window — typically 30 seconds in Chromium-based browsers. The TCP handshake never completes, so the browser abandons the attempt and surfaces this error instead of a loaded page.

This is not a single-cause failure. It can originate from the client side (your machine, your network, your browser), from intermediate infrastructure (DNS resolvers, proxies, firewalls), or from the server side (overloaded origin, misconfigured web server, expired SSL, or upstream routing failure). Diagnosing it correctly requires working through each layer systematically.

What Actually Happens During a Connection Timeout

When you type a URL and press Enter, your browser executes a precise sequence: DNS resolution, TCP connection (SYN / SYN-ACK / ACK), optional TLS handshake, then the HTTP request/response cycle. A timeout error means the process stalled somewhere in that chain — most commonly at the TCP connection stage, before any HTTP data is exchanged.

Understanding which stage failed tells you where to focus your fix. A DNS failure produces a different error code (`ERR_NAME_NOT_RESOLVED`). A TLS failure produces `ERR_SSL_PROTOCOL_ERROR`. When you see `ERR_CONNECTION_TIMED_OUT` specifically, the DNS lookup succeeded, but the TCP socket never received a SYN-ACK from the target IP. That narrows the field considerably.

Root Causes: Why This Error Occurs

Method 1: Verify Your Internet Connection at the Network Layer

Do not just "check if the internet is working." Run a structured test:

• Ping the gateway: Open Command Prompt and run `ping 192.168.1.1` (or your router's IP). If this fails, the issue is between your machine and the router.
• Ping a public IP directly: Run `ping 8.8.8.8`. If this succeeds but websites fail, the problem is DNS, not connectivity.
• Run a traceroute: `tracert google.com` on Windows or `traceroute google.com` on Linux/macOS. Look for where the hops stop responding — that identifies the failing network segment.
• Restart your router: Power-cycle it for 30 seconds. This forces a fresh DHCP lease and re-establishes the PPPoE/PPPoA session with your ISP.
• Test on a mobile hotspot: If the site loads over LTE but not your home broadband, the fault is upstream of your router — likely your ISP or a specific routing path they use.

Method 2: Flush and Rebuild the DNS Cache

A poisoned or stale DNS cache can store an old, unreachable IP address for a domain, causing every connection attempt to time out against a server that no longer exists at that address.

On Windows:

“`

ipconfig /flushdns

ipconfig /registerdns

“`

On macOS (Ventura / Sonoma):

“`

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

“`

On Linux (systemd-resolved):

“`

sudo systemd-resolve –flush-caches

“`

After flushing, verify the cache is clear on Windows with `ipconfig /displaydns` — the output should be minimal. Then attempt the connection again before making any other changes, so you can isolate whether DNS cache was the sole cause.

Method 3: Switch to a Reliable Public DNS Resolver

Your ISP's default DNS resolver can be slow, unreliable, or subject to geographic filtering. Replacing it with a fast, public resolver often resolves timeout errors caused by DNS lookup failures that silently return incorrect or no records.

On Windows (IPv4):

1. Open Control Panel > Network and Internet > Network and Sharing Center > Change adapter settings.
2. Right-click your active adapter and select Properties.
3. Select Internet Protocol Version 4 (TCP/IPv4) and click Properties.
4. Select Use the following DNS server addresses and enter your preferred resolver.

Recommended public DNS resolvers:

Critical edge case: If you recently migrated your website to a new server or changed its A record, DNS propagation can take up to 48 hours. During this window, some users will be directed to the old IP. Running `nslookup yourdomain.com 8.8.8.8` versus `nslookup yourdomain.com 1.1.1.1` lets you compare what different resolvers return — if the IPs differ, you are in a propagation window, not a true timeout error.

Method 4: Clear Browser Cache, Cookies, and Extensions

Chrome and other Chromium-based browsers cache DNS responses independently of the OS-level DNS cache. This browser-internal DNS cache can hold stale records even after you flush the system cache.

Clear Chrome's internal DNS cache directly:

1. Navigate to `chrome://net-internals/#dns`
2. Click Clear host cache
3. Navigate to `chrome://net-internals/#sockets`
4. Click Flush socket pools

Clear browsing data:

1. Open Chrome and press `Ctrl + Shift + Delete`
2. Set time range to All time
3. Check Cookies and other site data and Cached images and files
4. Click Clear data

Test in an Incognito window first. If the site loads in Incognito but not in a normal window, a browser extension is the culprit. Disable all extensions via `chrome://extensions/` and re-enable them one at a time to identify the offender. Ad blockers, VPN extensions, and security tools are the most common sources of interference.

Method 5: Disable Proxy Settings

A misconfigured or stale proxy configuration is one of the most frequently overlooked causes of this error, particularly on corporate machines or after uninstalling VPN software that left proxy settings behind.

Via Chrome:

1. Go to Settings > System > Open your computer's proxy settings
2. Under Manual proxy setup, ensure Use a proxy server is toggled Off
3. Under Automatic proxy setup, ensure Use setup script is toggled Off unless you intentionally use a PAC file

Via Windows Settings directly:

1. Open Settings > Network & Internet > Proxy
2. Disable all manual proxy entries
3. Enable Automatically detect settings only if your network requires it

Via Command Prompt (fastest method):

“`

netsh winhttp reset proxy

“`

This resets WinHTTP proxy settings to direct connection, bypassing any system-wide proxy that may have been set by software.

Method 6: Reset the TCP/IP Stack and Winsock Catalog

Corruption in the Winsock catalog — Windows' implementation of the Berkeley sockets API — can cause intermittent or persistent connection failures that look identical to server-side timeouts. This is particularly common after malware removal, failed network driver updates, or aggressive antivirus activity.

Open Command Prompt as Administrator and run these commands sequentially:

“`

netsh winsock reset

netsh int ip reset resetlog.txt

ipconfig /release

ipconfig /flushdns

ipconfig /renew

“`

Restart your machine after running all commands. The `resetlog.txt` file will be created in your working directory and logs every registry key that was reset — useful for auditing what was corrupted.

On Linux, the equivalent for resetting network state is:

“`

sudo systemctl restart NetworkManager

sudo ip route flush cache

“`

Method 7: Audit Firewall and Antivirus Rules

Windows Defender Firewall and third-party security suites can silently block outbound connections to specific ports, IP ranges, or domains. The block does not produce an immediate "connection refused" error — instead, the packets are dropped, and the browser waits until its timeout threshold is reached.

Temporary diagnostic test:

1. Go to Control Panel > System and Security > Windows Defender Firewall
2. Click Turn Windows Defender Firewall on or off
3. Temporarily disable it for both private and public networks
4. Attempt the connection

If the site loads with the firewall disabled, re-enable it immediately and then create a specific outbound rule to allow traffic to the affected domain or IP rather than leaving the firewall off. Navigate to Advanced Settings > Outbound Rules > New Rule to configure this precisely.

For antivirus software: Most modern suites include an HTTPS inspection or "web shield" feature that performs a man-in-the-middle intercept of TLS traffic. This can break connections if the antivirus's root certificate is not trusted by the browser, or if the antivirus incorrectly flags the target server. Temporarily disabling the web shield component (not the entire antivirus) is a more surgical test than disabling all protection.

Method 8: Reset Chrome's Flags and Network Predictor

Chrome's experimental flags and network prediction features can occasionally cause connection issues, especially after browser updates that change how these features behave.

Disable network prediction:

1. Go to Settings > Privacy and security > Cookies and other site data
2. Scroll to Preload pages for faster browsing and searching and disable it

Reset all Chrome flags to default:

1. Navigate to `chrome://flags`
2. Click Reset all in the top-right corner
3. Relaunch Chrome

Reset Chrome's entire network stack settings:

1. Go to Settings > Advanced > Reset and clean up > Restore settings to their original defaults

This does not delete bookmarks or passwords but resets startup pages, new tab settings, pinned tabs, content settings, cookies, and extensions — effectively giving you a clean network configuration baseline.

Method 9: Increase the TCP Connection Timeout (Advanced)

By default, Windows waits approximately 21 seconds before declaring a TCP connection attempt failed (based on the `TcpMaxConnectRetransmissions` registry value, which defaults to 2 retransmissions with exponential backoff). On slow or congested networks, this may be too short.

Adjust via Registry Editor (Windows):

1. Open `regedit`
2. Navigate to `HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters`
3. Find or create a DWORD value named `TcpMaxConnectRetransmissions`
4. Set it to `3` or `4` (hexadecimal) to allow more retransmission attempts

Important: This increases the time Windows will wait before giving up on a TCP connection. It does not fix the underlying cause — it simply gives more time for slow servers or congested routes to respond. Use this only as a diagnostic tool or for specific use cases like connecting to geographically distant servers.

Method 10: Verify the Server Is Actually Reachable

Before spending more time on client-side fixes, confirm whether the problem is on the server side. A website can be completely unreachable due to a suspended hosting account, a server-side firewall rule, or a misconfigured web server — none of which you can fix from your browser.

Tools to check server reachability from external vantage points:

• downforeveryoneorjustme.com — Simple up/down check from a single location
• downdetector.com — Aggregates user reports for major services
• tools.pingdom.com — Tests response time from multiple global locations
• mxtoolbox.com/SuperTool — Tests DNS, HTTP headers, and connectivity
• check-host.net — Pings and HTTP checks from dozens of geographic nodes simultaneously

Run `curl -v https://yourdomain.com` from a terminal to see the exact point of failure — whether the TCP connection is refused, times out, or succeeds but returns an HTTP error code. This single command tells you more than any GUI tool.

Server-Side Causes: What to Check If You Own the Website

If you are the website owner and your visitors are reporting `ERR_CONNECTION_TIMED_OUT`, the problem is almost certainly on your infrastructure. The most common server-side causes are:

Web server connection queue exhaustion:

In Apache, the `MaxClients` (or `MaxRequestWorkers` in Apache 2.4+) directive limits simultaneous connections. When this limit is hit, new connections queue up and eventually time out. Check your current configuration:

“`

apache2ctl -V | grep -i mpm

grep -i maxrequestworkers /etc/apache2/apache2.conf

“`

In Nginx, the equivalent is `worker_connections` in the `events` block and `worker_processes`. A common misconfiguration is setting `worker_processes` to `1` on a multi-core server, creating a bottleneck.

Firewall blocking incoming traffic on port 80/443:

If you manage a VPS Hosting environment, check your iptables or nftables rules:

“`

iptables -L INPUT -n -v | grep -E "80|443"

“`

A missing ACCEPT rule for ports 80 and 443 will cause all browser connections to time out silently. Also verify that your hosting control panel's firewall (CSF, UFW, or Firewalld) has not inadvertently blocked these ports after a security update.

SSL certificate issues causing TLS handshake timeouts:

An expired or misconfigured SSL certificate can cause the TLS handshake to stall, which manifests as a connection timeout rather than a certificate error in some edge cases — particularly when using older TLS versions or misconfigured cipher suites. Verify your certificate with:

“`

openssl s_client -connect yourdomain.com:443 -servername yourdomain.com

“`

Resource exhaustion on the server:

High CPU or RAM usage can cause the web server process to become unresponsive. On a Linux server, check:

“`

top -b -n 1 | head -20

free -h

ss -s

“`

The `ss -s` command shows the summary of socket states — a large number of connections in `TIME-WAIT` or `CLOSE-WAIT` state indicates connection handling problems that will cause new connections to time out.

DNS misconfiguration after server migration:

If you recently moved your site to a Dedicated Server or changed your hosting provider, verify that your domain's A record points to the correct IP address and that the TTL has expired on old records. Use `dig yourdomain.com +trace` to follow the full DNS resolution chain from root servers down.

Comparing ERR_CONNECTION_TIMED_OUT With Similar Browser Errors

Understanding this table is operationally important: if you are troubleshooting your own server, the specific error your users see tells you exactly which layer of the stack to investigate first.

Practical Decision Matrix: Which Fix to Apply First

Use this sequence to minimize diagnostic time:

1. Can you reach other websites? No — fix your local network or ISP connection first (Methods 1, 6). Yes — proceed to step 2.
2. Does the site load on a different device or network? Yes — the problem is client-side (Methods 2, 3, 4, 5, 7). No — the problem is likely server-side or DNS propagation.
3. Does an external checker (check-host.net) show the site as down from multiple locations? Yes — contact the server administrator or your hosting provider. No — the issue is regional routing or your specific ISP.
4. Does the site load in Incognito mode? Yes — a browser extension or cached data is the cause (Method 4). No — proceed to DNS and network-level fixes.
5. Did you recently change DNS records or migrate servers? Yes — wait for DNS propagation and verify records with `dig` or `nslookup`. No — check server-side firewall and web server configuration.

If you are running your own server infrastructure — whether on a VPS with cPanel or a bare-metal environment — always check server logs before spending time on client-side fixes. The Apache error log (`/var/log/apache2/error.log`) and Nginx error log (`/var/log/nginx/error.log`) will contain explicit records of connection failures, resource exhaustion events, and configuration errors.

For teams managing multiple domains, keeping Domain Registration and DNS management centralized under a single provider significantly reduces the risk of propagation-related timeout errors caused by split DNS configurations or expired domain registrations.

Key Technical Takeaways

• `ERR_CONNECTION_TIMED_OUT` specifically indicates a TCP-level failure — the SYN packet was sent but no SYN-ACK was received. This distinguishes it from DNS errors, TLS errors, and HTTP-level errors.
• Always test from an external vantage point (check-host.net, curl from a remote server) before assuming the problem is on your local machine.
• Chrome maintains its own internal DNS cache separate from the OS. Flushing only the OS cache via `ipconfig /flushdns` is insufficient — you must also clear `chrome://net-internals/#dns`.
• On the server side, silent packet drops from firewall rules are the single most common cause of this specific error. A connection refused (`RST`) would produce a different error code.
• DNS propagation delays after server migrations are frequently misdiagnosed as timeout errors. Always verify with `nslookup` against multiple resolvers before investigating further.
• For production web servers, monitor `ss -s` output regularly. A growing `CLOSE-WAIT` count indicates application-level socket handling bugs that will eventually cause connection timeouts under load.

Frequently Asked Questions

Why does ERR_CONNECTION_TIMED_OUT appear only on one specific website but not others?

This almost always means the target server is unreachable from your network specifically — either the server is down, its IP has changed due to DNS propagation, or a firewall rule on the server is blocking your IP range. Use an external checker like check-host.net to confirm whether the site is globally unreachable or only unreachable from your location.

Does flushing DNS cache fix ERR_CONNECTION_TIMED_OUT?

It can, but only if the cause is a stale DNS record pointing to an old server IP. If the DNS record is correct and the server is genuinely unreachable, flushing the cache will not help. Always verify what IP address the domain resolves to using `nslookup` before and after flushing.

Can a VPN cause ERR_CONNECTION_TIMED_OUT?

Yes. A VPN routes your traffic through its own servers and DNS resolvers. If the VPN server is overloaded, geographically distant, or has a routing issue to the target site, you will see timeout errors. Disconnect the VPN and test directly. Conversely, some sites block VPN exit node IP ranges at the firewall level, which will also produce this error.

How do I fix ERR_CONNECTION_TIMED_OUT on a server I manage?

Check in this order: (1) confirm the web server process is running (`systemctl status nginx` or `apache2`), (2) verify ports 80 and 443 are open in your firewall (`iptables -L` or `ufw status`), (3) check server resource usage with `top` and `free -h`, (4) review the web server error log for connection refusals or worker exhaustion messages, (5) confirm your SSL certificate is valid and not expired.

Is ERR_CONNECTION_TIMED_OUT the same as a 504 Gateway Timeout?

No. A 504 Gateway Timeout is an HTTP-level error returned by a reverse proxy (such as Nginx or a CDN) when it cannot get a response from the upstream origin server within its configured timeout. `ERR_CONNECTION_TIMED_OUT` is a browser-level error that occurs before any HTTP response is received — the TCP connection itself never completes. Both indicate a timeout, but at different layers of the network stack.