QA - data completeness
Why does Amplitude fail to load with ERR_BLOCKED_BY_CLIENT, and how much of my traffic does that cost me?
The fix, why it happens, and how to confirm it actually worked in your own instance.
The fix, in short
ERR_BLOCKED_BY_CLIENT on a request to Amplitude's domains means a browser extension (an ad blocker or privacy tool) intercepted and killed the request before it ever left the browser - it's not a bug in your integration, and no amount of retry logic on your end fixes a request the browser itself refused to send. The mitigations are proxying the SDK's traffic through your own first-party domain, or accepting and sizing the resulting gap rather than chasing a client-side error that isn't yours to fix directly.
Why this happens
Ad blockers and privacy extensions (uBlock Origin, Privacy Badger, and similar) work from filter lists (EasyList, EasyPrivacy, and others) that block known third-party analytics and advertising domains by pattern. Amplitude's ingestion domains have been added to some of these lists precisely because analytics traffic is what such lists are designed to catch - being blocked isn't a misconfiguration on your end, it's the extension doing exactly what its list tells it to do.
`ERR_BLOCKED_BY_CLIENT` specifically means the block happened inside the browser, before the request reached the network at all - which is why it shows up as a network-level error in devtools rather than an HTTP error response, and why nothing your JavaScript does after the fact (retries, error handlers) can recover that specific request. The browser refused to send it.
The share of traffic this affects isn't uniform: ad-blocker adoption varies heavily by audience (developer- and privacy-conscious audiences run them far more than average consumer traffic), by region, and by device (desktop browser extensions are common; most mobile browsers and native apps have no equivalent extension ecosystem). That means the size of your specific gap is a measurement question for your own traffic, not a number that transfers from someone else's numbers.
Fix it
Measure the gap first
- Compare a client-side Amplitude event count against an independent, server-side count for the same action over the same window - a server log line for "order placed," a database row count for "account created." The percentage gap between the two is your actual client-side tracking loss, ad blockers included alongside any other client-side failure mode.
- If you have any server-rendered or server-logged signal at all, this comparison is worth doing before investing in a proxy - it tells you whether the gap is large enough to justify the engineering cost of a first-party proxy, versus small enough to document and accept.
First-party proxy (the durable fix)
- Set up a reverse proxy on your own domain (e.g. a path under your existing site, or a dedicated first-party subdomain) that forwards requests through to Amplitude's ingestion endpoint server-side. Because the browser now talks to your own domain rather than an amplitude.com host, domain-pattern-based blocklists have nothing recognizable to match against.
- Update the SDK's configured server URL/host option to point at your proxy path instead of Amplitude's default endpoint - both the Browser SDK and the HTTP API support a configurable ingestion URL for exactly this kind of setup.
- Keep the proxy a thin pass-through (forward the request body and headers Amplitude expects, return its response) rather than adding business logic to it, so it doesn't become a second thing that can silently fail.
- Re-run the client-vs-server comparison from the measurement step after the proxy is live - a shrinking (not necessarily zero, since some blockers filter on request-body content, not just domain) gap confirms it's working.
Accept and document (lower effort)
- If the measured gap is small relative to your decision-making needs, document the known blind spot explicitly wherever the affected metric is reported (a dashboard footnote, a wiki note) so nobody mistakes a slightly undercounted number for a precise one.
- Prioritize server-side tracking for any event that's a hard business requirement (revenue, conversions you're accountable for) over client-side-only tracking, specifically because server-side events never pass through a browser extension that could block them.
How to verify it worked
- Reproduce the block deliberately: install uBlock Origin (or enable an existing one) in a test browser profile, load your site, and confirm you can see the ERR_BLOCKED_BY_CLIENT request in devtools' Network tab before you start fixing anything - this confirms you're actually looking at the failure mode this page describes.
- After implementing a proxy, repeat the exact same test with the same extension enabled and confirm the request now succeeds (200 response) against your own domain instead of being blocked.
- Check Amplitude's Events explorer for the test event sent through the proxy and confirm it arrived with the same event name and properties it would have carried going direct - a proxy that mangles the payload shows up here as a malformed or missing event, not as a network error.
- Re-run your client-vs-server volume comparison a week after the proxy ships and compare the new gap percentage against the pre-fix baseline you measured earlier.
Related: Why does Amplitude intermittently throw "Invalid apiKey" or a runQueuedFunctions error? · Why doesn't the Amplitude snippet load with Next.js's Script component, or why do events go missing right after a redirect?
Frequently asked questions
Will a first-party proxy fix this for every ad blocker, permanently?+
It defeats domain-based blocking, which is the most common mechanism, but some blockers also filter by request pattern or payload content regardless of domain, and blocklists are updated over time - so expect a proxy to substantially shrink the gap, not guarantee zero loss forever. Re-measure periodically rather than treating it as solved once.
Is it ethical or against Amplitude's terms to proxy around ad blockers?+
Analytics measurement of your own product's usage, on your own domain, is a routine and widely used practice, distinct from circumventing a paywall or ad-serving block - check Amplitude's current terms of service for any explicit conditions on ingestion routing before building a proxy, since terms can be updated independently of this page.
Still stuck, or want it checked properly?
The free scored audit reads your Amplitude instance across ten dimensions - taxonomy health, identity resolution, revenue tracking, and more - and hands back the three highest-payoff fixes. No commitment, 48-hour turnaround.
Request the free audit