net::ERR_BLOCKED_BY_CLIENT

Chrome: Ctrl+Shift+N (Cmd+Shift+N on macOS)
// reload the same page — if the request now succeeds, an
// extension/ad-blocker was the cause, not your server

What you're seeing

Failed to load resource: net::ERR_BLOCKED_BY_CLIENT

// often accompanied by a fetch() rejection in your own code:
Uncaught (in promise) TypeError: Failed to fetch

This is the one net:: error in the entire family that doesn't describe a network condition at all. Every other error covered in this reference — timeouts, refused connections, certificate failures, redirect loops — describes something that happened to a request after it left the browser. ERR_BLOCKED_BY_CLIENT means the opposite: the request was intercepted and cancelled inside the browser process itself, before a single packet was sent. Nothing about your server, your DNS, or your network is relevant to this error at all — the cause is entirely local to the visitor's browser.

Fix 1 — ad-blocker filter-list false positive (the most common cause)

When: the blocked URL's path, filename, or query string contains words that merely look ad/tracking-related.

// these are all real filter-list trigger patterns from EasyList/
// EasyPrivacy — none of them require actual advertising intent:
/analytics/collect
/track?event=click
/pixel.gif
/ads/config.json          // even config/metadata paths get caught
?ad_campaign=summer        // query params alone can trigger a rule

// check exactly which filter rule matched — Chrome DevTools:
// Network tab → click the failed request → "Blocked by" column,
// or uBlock Origin's own logger (uBO icon → "Show all" → the entry
// shows the specific filter list + rule text that matched)

Ad blockers don't understand the semantic purpose of a request — they match its URL (and sometimes response headers) against enormous, community-maintained text-pattern filter lists like EasyList and EasyPrivacy, which are optimized for broad coverage of known ad/tracking networks rather than precision on arbitrary first-party sites. A path segment, filename, or even a query-string key that merely resembles an advertising or analytics convention (ads, track, pixel, analytics, banner) can match a rule regardless of what the endpoint actually does. This is why a completely legitimate, first-party API endpoint or asset can get blocked purely because of what it happens to be named — the filter list has no way to know your /api/track-order-status endpoint has nothing to do with advertising.

Fix 2 — isolate which extension is responsible

When: the problem only happens in your own browser profile, not for other people testing the same site.

// Chrome: chrome://extensions → toggle each ad-blocker/privacy
// extension off one at a time, reloading the page after each toggle,
// until the request succeeds — that's the responsible extension

// or disable all extensions at once as a faster first check:
chrome://extensions → toggle the top-level "Developer mode" aside,
// or simply flip each extension's switch off

Beyond dedicated ad blockers, a surprising range of extension categories intercept and cancel requests as part of their normal function: privacy/tracker blockers, "focus mode" productivity extensions, some password managers' form-protection features, and corporate endpoint-security browser extensions can all trigger this identical error. Because Incognito mode disables extensions by default (unless the user has explicitly opted an extension in for Incognito use), testing there is the fastest single elimination step; going further to identify exactly *which* extension requires the one-at-a-time toggle approach, since multiple installed extensions can each independently match and block the same request.

Fix 3 — a managed/corporate device's content filter

When: the failure only reproduces on a work or school network, or a company-managed laptop, and not on a personal device/network.

# confirm it's environment-specific — test the same URL from a
# personal device on a different network entirely (mobile hotspot):
curl -v https://example.com/analytics/collect
# if this succeeds from outside the corporate network/device, the
# block is enforced by that organization's policy, not your server

Enterprise environments frequently deploy browser-management policies, endpoint security agents, or DNS-based content filters (Cisco Umbrella, corporate proxy extensions, mobile device management profiles) that inject blocking behavior at the same layer a browser extension would, and Chrome reports the result identically as ERR_BLOCKED_BY_CLIENT regardless of whether an ad blocker, a corporate policy, or an MDM-pushed extension caused it. There is no fix available from the website's side in this case — the resolution, if one is needed, belongs to whoever administers that network or device's security policy, and the most useful thing a site owner can do is confirm (via a personal device/network) that the site itself is not the problem.

Fix 4 — rename your own analytics/tracking endpoint

When: you control the endpoint being blocked and it's genuinely first-party analytics, not third-party advertising.

// ❌ triggers common filter-list patterns even for first-party use:
fetch("/api/analytics/track", { method: "POST", body: payload });

// ✅ a name that doesn't pattern-match common ad/tracking filter rules:
fetch("/api/metrics/ingest", { method: "POST", body: payload });
// same server-side logic, different path — meaningfully reduces
// false-positive blocking without changing what the endpoint does

Since filter lists match on URL text, not intent, a first-party endpoint that happens to be named with common tracking-adjacent words can be renamed to a functionally identical path that simply doesn't match known filter patterns. This is a standard, widely used mitigation (not a deception — the endpoint still does exactly what it did before) for legitimate product analytics, error reporting, or feature-usage telemetry that keeps getting caught in ad-blocker crossfire meant for third-party advertising networks. It's worth being explicit that this is harm reduction, not a permanent guarantee: filter lists are community-maintained and updated continuously, so a newly common word could eventually get caught again.

Why this happens: the browser is enforcing someone else's policy, not reporting a fault

It's worth framing this error correctly, because it's easy to instinctively debug it like every other network error — checking server logs, DNS, TLS configuration — none of which will show anything wrong, because nothing on those layers is actually broken. ERR_BLOCKED_BY_CLIENT exists specifically to represent a deliberate policy decision made *inside* the browser, on behalf of the user (an installed ad blocker), an organization (a managed device's security policy), or occasionally the browser vendor itself (a built-in tracking-protection feature). The request was correctly formed, the server would have handled it correctly, and the network path was fine — the browser simply chose, per its configured policy, not to send it. Recognizing this framing early saves significant debugging time: the fix is never in your server code or infrastructure, only in understanding and, where possible, working around the client-side policy that intercepted the request.

Common causes at a glance

Debugging checklist

• ✓ Reload in a fresh Incognito window to instantly confirm/rule out a client-side block
• ✓ Check DevTools Network tab's "Blocked by" column, or an ad blocker's own request logger, for the specific matched rule
• ✓ Disable extensions one at a time if it only fails in your own profile
• ✓ Test from a personal device/network if it only fails on a managed/corporate one
• ✓ If it's your own endpoint, consider whether its path/filename resembles common ad/tracking patterns