This whole thing started with a pretty dumb question: in which countries does YouTube not show ads?
The internet’s answer is almost unanimous, and it’s Albania. Connect a VPN to Albania and YouTube goes quiet. There’s even a viral claim going around that YouTube ads are “illegal” in Albania, which is false, and a fact-check already covers it. The boring explanation is that Albania just isn’t on Google’s list of YouTube monetized markets, so there’s nothing to sell there.
I actually already do this at home. I use a smart DNS service, and my YouTube rule points at its Albanian exit, and yes, no ads. (For anyone not familiar with smart DNS: it’s a DNS service that can also proxy specific domains through an exit in another country, so only YouTube goes out through Albania and everything else stays local.) I wanted a backup country in case Albania stopped working, so I set up an isolated test profile and started probing a handful of the exits the service offers.
I ended up finding out that, at least in my case, the Albania trick might not be about Albania at all.
The Setup
So here’s roughly how the redirection works. It’s an SNI proxy: you ask its DNS for www.youtube.com, it answers with one of its own proxy IPs, and when your TLS connection arrives, the proxy reads the hostname from the handshake and forwards the raw connection out through whatever exit you picked. Nothing gets decrypted along the way; the proxy splices the TCP connection as is. From YouTube’s side, the request comes from the service’s exit in that country.
I wrote a small script that, for each exit, sets a redirect rule for youtube.com and cloudflare.com on the test profile (nothing that touches my real devices), resolves both through that profile’s DNS-over-HTTPS endpoint, and pins the connection with curl --resolve. Then it asks Cloudflare where I am, since /cdn-cgi/trace gives you ip= and loc=, and loads a YouTube watch page to look for ad slots (adPlacements) in the player data.
Miami and Frankfurt were my controls, and both got ads, so the check works. Albania got no ads, and neither did a second European exit, which surprised me, because that country is on Google’s monetized list.
I almost wrote that up as “there’s my backup” and called it a day, but something about it kept bugging me.
The Clue: YouTube Says US
YouTube embeds a GL value in the page, which is the country it thinks you’re in. Frankfurt said DE and Miami said US, fine. Albania said US too, and so did the second European exit. And a South American exit, which I threw in as another control, also said US and also had no ads, and that country definitely has YouTube ads.
My first guess was that GL just falls back to US for countries without a YouTube locale, but the South American exit kills that theory pretty quickly.
The page also has a remoteHost field with the IP YouTube sees. It matched what Cloudflare saw for every exit, so the traffic really was going where I thought it was, and the proxy wasn’t the problem.
Decoding visitorData
YouTube gives signed-out visitors a visitorData token. It’s URL-safe base64, and inside there’s a protobuf. Google doesn’t publish the schema, so I decoded it raw, the same way protoc --decode_raw would. Here’s one I got from my home connection:
field 1 (string): 'XXXXXXXXXXX' visitor ID (11 characters, redacted)
field 5 (varint): 1792629540 2026-10-22 00:39 UTC, when the token was issued
field 6 (message):
field 1 (string): 'MX' two-letter country code
field 2 (message): { 3: '', 4: 45 } no idea
field 12 (message): ~300 opaque bytes
yt-dlp also parses this token, but only to pull out the 11-character visitor ID from field 1, so the country slot isn’t something any tool I know of documents. The labels above are mine, from comparing tokens.
(If you’re wondering why yt-dlp cares about the visitor ID at all: YouTube increasingly wants a PO token, short for Proof of Origin, before it hands out video stream URLs. It’s an anti-bot token that a real YouTube player generates by running Google’s attestation code, BotGuard on the web, and for signed-out visitors it’s tied to that visitor. yt-dlp uses the visitor ID as the key to cache those tokens, so it doesn’t have to generate a new one on every request.)
Through the exits, field 6’s country said US for Miami and DE for Frankfurt, and for the second European exit it gave that country’s real code, all matching everything else.
For Albania, it said IR, and so did the South American exit. IR is Iran.
Iran is under US sanctions, YouTube is blocked there, and it isn’t on Google’s monetized list either. So the “ad-free Albania” I’d been enjoying might be ad-free Iran.
Asking Google Directly
An undocumented byte in a protobuf isn’t really proof, so I checked two places where Google shows the location it detected in plain words. Google Search shows your detected location in the footer, something like “City - From your IP address”. And Google Maps, when you’re signed out, centers the map on wherever Google thinks your IP is, with the initial coordinates sitting right there in the page’s APP_INITIALIZATION_STATE.
The first try was in a real browser, routed through the same Albanian exit, and Search’s footer said:
Tehran, Tehran Province - From your IP address

Some of the search results came back in Farsi, too:

That browser was signed into a Google account, though, and a browser gives Google a lot more to go on than an IP address. There’s state: cookies, account history, saved locations. And there’s fingerprinting: the JavaScript on the page can look at your time zone, your language settings, your screen and a dozen other things, and Chrome sends Google some extra headers of its own. Any of that could have been the reason for Tehran instead of the IP.
So I repeated everything with curl-impersonate. It’s curl that copies Chrome’s TLS and HTTP/2 fingerprint, so at the connection level Google sees what looks like Chrome and doesn’t treat it as a random script. But it runs no JavaScript, sends no Chrome-only headers, uses a fresh cookie jar on every request, and has no account, history or location permissions. That leaves the IP address as basically the only thing Google has to work with. I also double-checked that Google was seeing the exit I expected each time, using its own /sorry page, which prints your address. Search itself just threw a CAPTCHA at curl, but Maps answered:
| Exit | Cloudflare says | Google Maps centers on | YouTube visitorData | YouTube ads |
|---|---|---|---|---|
| Albania | AL | Tehran | IR | none |
| Second European exit | its real country | Tehran | its real country | none |
| Miami | US | Miami | US | yes |
| Frankfurt | DE | redirect, no center | DE | yes |
I ran the Albanian, second European and Miami checks twice and got the same answer both times. The Miami control lands on Miami, so the method works, and Google Maps puts both the Albanian and the second European exit in Tehran.
Every other source I checked disagrees with Google. MaxMind GeoLite2 and DB-IP both put the Albanian and the second European exit in their real countries, and whois for the Albanian exit points at an Albanian network. Cloudflare agrees too: its /cdn-cgi/trace debug page, which any site behind Cloudflare serves, reports loc=AL for the Albanian exit and the real country for the other one. Only Google says Iran, and Google doesn’t even agree with itself, since YouTube’s token gives the second exit its real country while Maps says Tehran.
The Wild West of IP Geolocation
There’s no real authority for where an IP address “is.” Regional registries know who an IP block was assigned to, not where the packets end up. Networks can publish geofeeds (RFC 8805), basically a CSV that says “this prefix is in this city,” but that’s voluntary. MaxMind, DB-IP, ipinfo and the rest all build their own databases from those inputs plus their own measurements, and they disagree with each other a lot. I’ve run into this before, with some Kosovo ranges showing up as Albania in one database and as Kosovo in another.
Google doesn’t use any of those databases. It builds its own map from signals the database companies mostly don’t have, like the GPS and Wi-Fi locations that Android phones and Chrome browsers report. Some Hacker News commenters think it also looks at what language people use. If enough of the devices behind an IP are physically somewhere else, Google moves the IP there. Proton documents exactly this for its own servers, where a server in Malaysia can end up placed in the UAE depending on who’s using it.
What I Think Is Going On
Iran censors the internet heavily, and a lot of Iranians use VPNs and proxies to get around it. I doubt anyone there points their phone at the service I use directly, though. Its proxies only accept traffic from IPs you’ve authorized, and DNS inside Iran is heavily filtered anyway. My guess is something more layered: a phone in Tehran tunnels out with something like Xray (one of the popular tools for getting past Iran’s filtering) to a server outside the country, and that server uses a smart DNS service as its resolver, so for some domains the traffic leaves through these exits as the last hop. Whoever runs that middle server might do it to reach sites that block their datacenter’s IPs, or just to look like they’re somewhere else. From Google’s side, it all looks the same: lots of phones that are physically in Tehran, all showing up behind the same exit IP. So Google moves the IP to Tehran.
Someone on Hacker News described the same effect years ago, with Iranian-run VPNs on German datacenter IPs getting detected as Iranian and getting Farsi results.
For the Albanian exit, it doesn’t really matter which story is true. Albania isn’t a monetized market and neither is Iran, so you get no ads either way, and I can’t tell the two apart from YouTube’s side.
The second European exit is the better clue. Its country is on Google’s monetized list, so an IP there should get ads, but this one didn’t, and Google Maps puts it in Tehran. Iran is the only explanation I have for that. That would also mean YouTube’s own visitorData token, which gives the real country, isn’t what the ad system goes by.
This would also explain why the trick is so flaky online. People report Albania working, then not, then working again, and it often depends on which IP their VPN hands out. If what matters is Google’s crowdsourced guess about each specific IP, of course it changes over time and from one IP to the next.
Caveats
I have to mention a few limits. visitorData is undocumented; I’m confident about the country slot because it matches reality on every exit Google places correctly, but it isn’t official. All the YouTube checks were signed-out fetches of the web page, and the app, a TV, or a signed-in account bring in other signals. I only tested one service’s exits, so another provider’s Albanian servers could be placed in Albania, in Iran, or anywhere else. And being “in Iran” as far as Google is concerned could break other Google services through that exit. YouTube played fine, but I didn’t test much else.
So no, YouTube ads aren’t illegal in Albania. My Albanian exit just isn’t in Albania, at least not according to the one company whose opinion matters for YouTube.