YouTube’s “Sign in to confirm you’re not a bot”: what it actually means
Updated 2026-09-26
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. Seeing it at home, in SmartTube, JDownloader, Stacher or yt-dlp? It is the same check, and there is a section for you below.
- 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.
In SmartTube, JDownloader, Stacher or yt-dlp at home
The wording is YouTube’s, not the app’s: SmartTube on a TV, JDownloader, Stacher and yt-dlp all show the answer YouTube sent them, so the diagnosis above applies — with one difference. At home your address is usually residential, so the trigger is more often something on your side that makes the traffic look automated.
Turn off the VPN or proxy first. Most VPN exits sit in datacenters, the kind of address this check is aimed at. If the message goes away with the VPN off, that was it; if you need the VPN, try another exit location.
Update the app. YouTube changes how its player talks to apps every few weeks, and these tools ship fixes in step. For yt-dlp that is yt-dlp -U (we run the nightly channel: yt-dlp --update-to nightly), plus a JavaScript runtime such as Deno: current yt-dlp uses one for YouTube, and without it quietly falls back to fewer formats — we measured it. Stacher runs yt-dlp underneath, so updating the yt-dlp it uses is the fix there too.
Slow down. A whole playlist or channel at once, or many downloads side by side, looks like exactly the automated traffic this check exists to stop. Queue fewer at a time.
Sign in only as a last resort. Apps that let you add a Google account can usually get past the message, and yt-dlp’s own error suggests --cookies-from-browser. It works because every request is then tied to your account — which is also the risk, as the first question below explains.
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.
Why does SmartTube say “Sign in to confirm you’re not a bot”?
SmartTube shows the message YouTube sent it — the same check as everywhere else. Turn off any VPN on the TV or the router, update SmartTube, and give it a few minutes. Signing in to a Google account in the app usually clears it too, with the trade-off described above.
How do I fix it in yt-dlp?
Update first — yt-dlp -U, or yt-dlp --update-to nightly — and install Deno so yt-dlp can run YouTube’s player code. If it persists on a home connection, slow down and try without a VPN. From a server it is almost always the IP address: see “What we measured” above.
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.