“Sign in to confirm you’re not a bot” — what it actually means
Updated 2026-08-12
If you have hit this message from a server, a script or a VPS, the advice you will find is almost always “pass cookies” or “use a PO token”. We run a video downloader in production and measured what actually happens over three weeks. The short version: this is a judgement about the IP address making the request, and most of the popular fixes do not address that.
- 1Work out whether it is your IP
Try the exact same request from a home internet connection. If it succeeds there and fails from your server with identical software, the problem is the IP address, not your configuration — and no amount of client tweaking will change that.
- 2Stop retrying immediately
Retrying in a tight loop makes it worse and can extend the block. Back off, and treat the failure as a persistent state rather than a transient one.
- 3Route the request through a different network
The only reliable fix is to make the request from an address YouTube does not distrust. That means a residential connection or a proxy on one — not another datacenter.
What we measured
Over three weeks on a Hetzner server in Helsinki, YouTube extraction succeeded 2 times out of 34 attempts — roughly 6% — with each failure taking about 7.6 seconds before the gate appeared. The same software, same version, same request, from a Danish shared host succeeded 17 out of 17 times, averaging 1.4 seconds.
Nothing about the client changed between those two sets of numbers. The only variable was which network the request came from. That is the whole finding, and it is why client-side fixes tend to disappoint.
Things that did not work, and why
**Switching to IPv6.** We tested both stacks on the same machine and got the identical gate. The reputation attaches to the address range, not the individual address, so a second address in the same datacenter block inherits it.
**PO tokens.** These come up constantly, but check which client you are actually using: yt-dlp's own documentation lists android_vr and web_embedded as clients that do not require a PO token at all. If you are already on one of those, adding a token changes nothing — and current guidance is explicit that PO tokens no longer clear the bot check in most cases anyway.
**Changing the client.** Worth one attempt, since which clients are trusted shifts over time. But in our case android_vr was already first in the fallback order and was the exact client succeeding from the other network while failing from ours.
**Cookies from a logged-in account.** This can work, and we deliberately do not do it. Session cookies expire faster when Google sees them used from a datacenter IP, and you are putting a real account at risk of being flagged. For anything multi-tenant or public-facing that trade is bad.
What actually fixed it for us
We kept extraction on a host in a different country and on a different kind of connection, and fell back to it automatically when the main server was gated. Latency for that step went from roughly 9.6 seconds to 1.5.
One detail that surprised us and is worth knowing: YouTube's signed media URLs embed the IP that requested them. You cannot extract the URL on one machine and download it from another — the second machine gets a 403. Whatever does the extraction has to do the download too, or hand the bytes across itself.
If you are just trying to save one video
None of the above matters. The gate appears because a server asked, not because you did. Use a tool that already handles the routing, or download from your own connection.
FAQ
Does signing in actually fix it?
It often clears the immediate message, but it ties the request to a real account that can then be rate-limited or flagged, and the session tends to expire quickly when used from a server. We consider that a bad trade for anything public-facing.
Is a VPN enough?
Usually not. Most commercial VPN exit nodes are hosted in datacenters and carry the same reputation problem. A residential connection is what makes the difference.
Will waiting fix it?
Sometimes, briefly. In our data the gate was effectively permanent for that host — 2 successes in 34 attempts across three weeks, with the last success weeks before the rest of the failures.
Does this affect ordinary viewers?
No. This is about automated or server-side requests. Watching YouTube normally in a browser on a home connection is unaffected.