# Sentry: browser events vanish, server events arrive
## The symptom
Server-side issues flow normally. Client-side issues are undercounted or absent entirely, with no SDK errors. The gap is biggest among privacy-conscious users and in regions where filter lists are aggressive.
## The cause
Adblockers and privacy extensions block requests to known ingest hosts (`*.ingest.sentry.io`). Your SDK is working; the network never lets the envelope leave the browser. This also skews every client metric: error rates, web vitals, and replay counts all read low.
## The fix: tunnel through your server
```ts
// next.config.ts
withSentryConfig(nextConfig, {
tunnelRoute: "/sentry-tunnel",
});
```
The tunnel route makes event POSTs look first-party, which filter lists do not block. For non-Next.js apps, proxy `/sentry-tunnel` (or any path) to your ingest host at the edge or in your server framework, and point the SDK's tunnel option at it.
## Confirmation
Compare event counts with and without an adblocker in a test browser. If events arrive clean and vanish blocked, it is the filter list, not your code. Also check that the tunnel route itself is not behind auth middleware rejecting the POSTs, which produces the same symptom from the other direction.
## Related: extension noise
The reverse problem is browser extensions INJECTING errors into your stream. `denyUrls`/`allowUrls` filter by script origin, and `thirdPartyErrorFilterIntegration` (bundler builds only, needs the `applicationKey` build option) drops or tags errors from unmarked third-party frames. Use it when your issue stream is full of errors from code you did not ship.