How to fix the “no data received” error in Google Chrome?

User-Side Fixes (Browser-Level Solutions)

Most cases of “no data received” / ERR_EMPTY_RESPONSE start inside Chrome itself — not the website or the internet connection. Chrome maintains a socket pool, cached TLS sessions, and protocol preferences that can become stale, especially after long uptime, a browser update, or switching networks (Wi-Fi ↔ hotspot). When these cached connections are out of sync, Chrome sends a request but fails to receive a response — resulting in an “empty response.”

Before changing network settings or blaming the website, you should reset Chrome’s local connection state. This fixes a large percentage of cases instantly.

1. Flush Chrome’s Socket Pool (Fastest Fix)

Chrome sometimes holds onto stale or broken TCP sessions.

Steps:

1. Visit: chrome://net-internals/#sockets

2. Click Flush socket pools

3. Reload the page

If the website loads immediately afterward → socket corruption was the cause.

2. Clear Only DNS Host Cache (Not full browser cache)

This forces Chrome to refresh domain routing info.

1. Go to: chrome://net-internals/#dns

2. Click Clear host cache

3. Try the website again

3. Disable (temporarily) Browser Extensions

Extensions can block fetch responses or interfere with cookies.

1. Open: chrome://extensions/

2. Disable all non-essential ones

3. Retry the page

Ad-blockers, privacy filters, and VPN extensions are the most common culprits.

4. Try Incognito Mode

Incognito bypasses corrupted session storage and extension interference.

• If it works in Incognito → issue is extension, cookies, or profile corruption.

5. Reset Chrome Profile (without reinstalling)

If only your Chrome user profile is damaged:

1. Go to: chrome://version

2. Note your profile path

3. Close Chrome

4. Rename the Default folder to Default_old

5. Restart Chrome

This creates a fresh profile without a full reinstall.

If none of these browser-side fixes solve the issue, the next most likely cause is the network layer — DNS, proxy/VPN, or HTTP3/QUIC interference.

Network-Level Fixes (DNS, Proxy, VPN, Router & QUIC Issues)

If the browser-side connection is clean but Chrome still shows “no data received” / ERR_EMPTY_RESPONSE, the next most common cause is a network path interruption. This happens when Chrome successfully reaches the server, but the response packets never complete the round trip. DNS routing issues, ISP filtering, VPN tunneling, or QUIC/HTTP3 conflicts can all drop the connection after it opens — which results in an “empty response” instead of a traditional timeout error.

A good indicator that the problem is network-level is when the same website works fine on mobile data but not Wi-Fi, or when switching VPN on/off changes the result. That means the browser isn’t the problem — the traffic path is.

1. Change Your DNS Resolver

Unstable DNS is a top cause of this error on specific websites.

Use a reliable DNS such as:

Then reload Chrome and test again.

2. Disable Proxy / Auto Proxy

Misconfigured or hijacked proxy settings often interrupt HTTPS connections.

Windows
Settings → Network & Internet → Proxy → Turn OFF “Use a proxy server”

macOS
System Settings → Network → Details → Proxies → Disable Manual/Auto proxy

3. Turn Off VPN (Temporarily)

Some VPNs rewrite headers or fail to forward data — which causes ERR_EMPTY_RESPONSE even when the connection opens successfully.

• If the site loads without VPN → VPN was blocking or timing out the response.

4. Disable QUIC (HTTP/3) in Chrome

QUIC uses UDP/443, and many routers/firewalls block or throttle it. When QUIC packets drop, Chrome never falls back gracefully — which leads to an empty response.

Steps:

1. Go to: chrome://flags/#enable-quic

2. Set to Disabled

3. Restart Chrome

5. Restart Router (to clear NAT/DNS cache)

Routers sometimes cache broken routes or MTU mismatches. A restart forces a clean handshake path.

If the problem persists across different networks, it’s not a connectivity issue — it’s likely a backend/server timeout or CDN/proxy fault.
That brings us to the Advanced / Deep Fixes section next.

Advanced Fixes (Socket-Level, MTU, HTTP/3/QUIC, and Backend Timeouts)

When user-side and network changes don’t solve the issue, the cause is typically a transport-layer or handshake-level failure — meaning Chrome establishes the TCP (or UDP) connection, but the response never arrives because the packet exchange is broken midstream. These are not “browser bugs” — they are low-level protocol issues.

1. Fix Stale TCP Sessions (Full Chrome Network Stack Reset)

A normal socket flush clears some open sessions, but Chrome also caches stale QUIC and TLS session tickets.

Steps:

1. Visit: chrome://net-internals/#events

2. Click “Clear Browsing Data → Cached images/files + Hosted app data”

3. Then re-flush socket pools (as done earlier)

This resets Chrome’s transport cache layer, not just HTTP cache.

2. Adjust MTU (Fixes “Response Dropped Mid-Route”)

On some ISPs and corporate networks, packets above a certain size are dropped silently, leading to an empty response.

Windows (PowerShell):

MTU issues are a major hidden cause of “site only half loads then ERR_EMPTY_RESPONSE.”

3. QUIC/HTTP3 Force Fallback

Even after disabling QUIC in flags, Chrome may still negotiate QUIC if cached at handshake level. You can force HTTP/2 fallback via launch params.

Advanced (optional power users):

This resolves cases where UDP/443 is unstable or filtered.

4. SSL/TLS Session Ticket Corruption

If the server rotates TLS keys and Chrome still holds an old session ticket, the browser completes handshake but the server rejects the resumed session silently — returning no data.

Fix:
A full TLS reset = Clear SSL state + clear DNS + flush sockets

5. CDN / Reverse Proxy Timeout (Server Receives Request But Sends Nothing)

If you’re only seeing this error on one specific site, and it persists on every network, then the cause is usually on the origin server — particularly with Nginx, Cloudflare, HAProxy, or Node upstream.

This is when:

• The server accepts the connection

• But upstream worker crashes or times out

• So the browser receives no HTTP header at all

That is exactly what triggers ERR_EMPTY_RESPONSE.

How to Confirm It’s a Server-Side Timeout

Run:

If no headers are returned → the server never responded.
That means it’s not your Chrome — it’s the site.

Server-Side Causes (When the Website Is Actually the Problem)

If the error happens across multiple devices and networks — and not just on your local Chrome — then the issue is not your browser. It is the server accepting the connection but failing to return a valid HTTP response. In these cases, Chrome receives an empty body (zero bytes), which triggers ERR_EMPTY_RESPONSE.

This is especially common with Nginx, Node.js, reverse proxies, or Cloudflare misconfiguration.

The Most Common Server-Side Causes

Chrome doesn’t show “500” or another HTTP code here — because the web server never sent a status line at all.

Fixes for Developers / Server Admins

• Increase reverse proxy / gateway timeout (Nginx/HAProxy/Cloudflare)

• Check that upstream app (Node/PHP/Python) returns headers before exit

• Fix missing return or res.send() in handlers (common in Node/Express)

• Restart or scale backend workers if they are crashing

• Ensure origin SSL certs aren’t expiring (CDN passthrough errors)

• Fix keep-alive misconfigurations on load balancers

• Rebuild full certificate chain if TLS handshake stalls completion

Diagnostic Commands for Developers

If headers never appear → upstream never replied.

Often reveals upstream timeout or worker crash.

If app restarts during request → empty response.

When It’s DEFINITELY Server-Side