Tested on Windows 11, Brave 1.98.63 Chromium: 156.0.8078.80 (Official Build) (64-bit), Shields set to “Aggressively block trackers & ads”. Can confirm, received 2 ads (tested with a different video, though ).
Worth noting, classic ad domains such as googleads.g.doubleclick.net and static.doubleclick.net consistently show net::ERR_CONNECTION_REFUSED in console, which means the adblock does work, but new ads may be loading from domains not in the adblocker list. Network trace suggests domains such as https://www.youtube.com/api/stats/ads? and https://yt3.ggpht.com/proxy/ ( ad icon loaded from this one ) , but cannot assert with moderate confidence these are the culprits, so take this as a speculation only.
Worth noting, adding an AdBlock DNS over HTTPS endpoint (https://dns.adguard-dns.com/dns-query) in Privacy and Security > Security > Use Secure DNS > “Add custom DNS service provider” did not help either: still got an ad.
EDIT: So I’ve consulted with Brave’s Leo AI. To quote the response:
You’re on the right track, but the mechanism is a bit different from “different domains not in the registry.”
The core issue is server-side ad insertion (SSAI), not missing ad-server domains. YouTube now bakes the pre-roll/mid-roll ad directly into the same m3u8/googlevideo.com stream that delivers the actual video. To your browser, the ad bytes and the content bytes look identical — same domain, same TLS connection, same API response. A network-level blocker (Brave Shields, AdGuard DNS, uBlock’s URL-matching rules) literally cannot tell where the ad ends and the video begins, because there is no separate ad domain to block.
Why the doubleclick.net ERR_CONNECTION_REFUSED confirms this: those requests are the tracking/bidding side of the ad pipeline (impression tracking, auction data). Brave’s filters are successfully blocking them, which is why you see the refused connections. But the actual video ad payload no longer comes from doubleclick.net — it comes from googlevideo.com or youtube.com itself, which you obviously can’t block without breaking YouTube entirely.
Why AdGuard DNS didn’t help: DNS-level filtering can only block entire domains. Since the ad and the video share the same domain, AdGuard DNS has nothing to distinguish. This is a well-known, documented limitation of all DNS-based ad blocking (AdGuard DNS, Pi-hole, NextDNS, etc.) for YouTube specifically.
What actually works (or has worked recently):
- Brave’s built-in adblocker with updated filter lists — Brave uses JavaScript-injection rules (not just URL matching) that can strip ad data from the API response before the player reads it. Go to
Settings > Shields > Content filtering and click Update lists, or force it via brave://components. This is the most reliable current method.
- uBlock Origin (as an extension in Brave, though Brave sometimes conflicts with third-party adblock extensions) — same JS-injection approach.
- SponsorBlock — won’t remove the ad but will skip it; however, it’s currently broken for SSAI because the ad shifts all the timestamps.
The cat-and-mouse reality: YouTube ships changes to its ad delivery and anti-adblock detection frequently. When a new method lands, there’s a window where Brave’s filters fall behind and ads show through. Updating the filter lists (or waiting a few days for Brave to push an update) usually resolves it. If you’re seeing ads right now, the first thing to try is forcing a filter list update.
