YouTube "Sign in to Confirm You're Not a Bot": Fixes in the Browser and in yt-dlp

The message is short and a little insulting: "Sign in to confirm you're not a bot. This helps protect our community." It replaces the video, offers a Sign in button, and gives no other way through. In a browser it tends to appear on a VPN, on a work network, in a private window, or on a machine in a data centre. In yt-dlp it appears as an error line that ends with a link to the project's wiki, and it has become the most common reason the tool "stops working".

Both versions come from the same decision. YouTube looked at the request, weighed where it came from and what it carried, and decided it could not tell a person was behind it. The address is the largest part of that judgement, cookies are the second, and the rate of requests is the third. That ordering explains why the wall lands on VPN users who have done nothing, why yt-dlp on a server meets it almost by default, and why the fixes differ between the browser and the tool.

What YouTube is actually checking

YouTube, like the rest of Google, keeps a running estimate of whether traffic from an address looks human. Some kinds of address start with a bad score before anyone does anything: cloud and hosting ranges, VPN exits shared by thousands, Tor, and public proxies whose addresses have been used for exactly this a million times. On such an address, a request that also carries no cookies, or a browser that sends no history of being a viewer, is close to the definition of a bot. yt-dlp's own tracker documented YouTube blocking whole datacenter networks at the ASN level through 2024, which is why the error arrived for so many people at once and why it correlates with where the tool runs rather than with how it is used.

The message asks you to sign in because a signed-in session is the cheapest way for YouTube to attach an identity to the traffic. It is not the only way through, but it is the one YouTube built.

In a browser

Sign in. It is the fix the page names, and it works. If the account you are signed into is the reason you do not want to, a second account for watching is enough.

Turn off the VPN or proxy and reload. If the wall disappears, the exit address was the cause. Reconnecting to a different VPN server helps for a while, until that server, too, accumulates enough abusive neighbours. Where proxy settings live, for a proxy you did not set on purpose, is in how to turn off a proxy.

Switch networks. Play the same video from a phone on mobile data. If it plays there and not on the current connection, the address of the current connection is the problem, whether that is a VPN, an office gateway, or a home address your ISP shares.

Fix the session. A private window with no cookies, a browser extension that blocks YouTube's scripts, or a user-agent spoofer all remove the signals YouTube uses to recognise a viewer. Open a normal window, allow YouTube's scripts, and let cookies exist for the site.

Wait, when it is the rate. An address that has been hammering YouTube, from your machine or from a neighbour's, gets the wall as a rate limit. It lifts on its own; solving it faster means finding the traffic, which our guide on Google's unusual traffic message walks through.

In yt-dlp

The error reads, in full, something like: ERROR: [youtube] dQw4w9WgXcQ: Sign in to confirm you're not a bot. Use --cookies-from-browser or --cookies for the authentication. followed by two links into the yt-dlp wiki. Work through the fixes in this order, because each one is cheaper than the next.

1. Update yt-dlp

YouTube changes its player and its checks constantly, and the yt-dlp maintainers ship matching changes within days. An old build fails in ways that look exactly like the bot wall. Run yt-dlp -U, or update through pip or your package manager, before anything else.

2. Run it from an address YouTube trusts

If yt-dlp runs on a VPS, a cloud instance, or a server at work, the address is the problem, and the wiki's cookie advice only papers over it. YouTube has blocked hosting networks wholesale. Two ways out: run the tool on a home connection, or route it through a residential address with the --proxy option:

yt-dlp --proxy "http://user:pass@gateway.example:8080" "https://www.youtube.com/watch?v=VIDEO_ID"

Use one exit for the whole session, not a new address per request. YouTube's session state, including the cookies from step 3, is expected to arrive from a stable address, and an exit that changes mid-download is another automated-traffic signal. Sticky versus rotating sessions explains how a session id keeps one address. Do not use a free proxy for this: free addresses are datacenter ranges that thousands of other yt-dlp users already burned, and most fail the wall on the first request. Our YouTube proxy guide covers the setup in full.

3. Pass cookies, the way the wiki says

Cookies give YouTube a session to attach the request to. yt-dlp's wiki is specific about how to export them, because a careless export breaks within minutes when the browser rotates the session:

1. Open a private or incognito window and sign in to YouTube.
2. In the same tab, open https://www.youtube.com/robots.txt.
3. Export cookies for youtube.com with a cookie-export extension to a cookies.txt file.
4. Close the private window immediately, so the browser does not rotate the cookies you exported.
5. Run yt-dlp --cookies cookies.txt URL.

Two warnings from the same wiki page. Using your account with yt-dlp "runs the risk of it being banned (temporarily or permanently)", so use an account you can afford to lose. And do not pass --cookies and --cookies-from-browser together; the second reads your normal browser profile and misses the private session you just prepared.

4. Slow down

YouTube's per-address limits are separate from the bot wall, and yt-dlp's wiki puts them at roughly 300 videos per hour for a guest session and around 2,000 per hour with an account, with "This content isn't available, try again later" as the message when you cross them. The wiki's advice is 5 to 10 seconds between downloads. yt-dlp has options for exactly that:

yt-dlp --sleep-requests 2 --sleep-interval 5 --max-sleep-interval 10 "URL"

Fewer parallel downloads from the same address does more than any other single change for a long batch.

5. Know about the PO Token

For some of YouTube's player clients, the wiki now states that a PO Token is required and that yt-dlp cannot generate one itself; it has to be supplied from outside, through a provider plugin, using the mweb client. If updating, cookies, pacing, and a residential address all fail and the log mentions a PO Token, the wiki's PO Token guide is the next stop. This part of YouTube changes often, so treat the wiki as the source of truth rather than any blog post, including this one.

What a proxy does and does not do here

A proxy changes exactly one of the three inputs: the address. That is a large change, because the address is the heaviest input and because yt-dlp on a server has the worst possible one. A residential exit turns a request that looks like a data centre into one that looks like a household, and for most server-side yt-dlp users that alone clears the wall.

It does not do the rest. A session with no cookies is still a session with no cookies. An account that YouTube has flagged is still flagged. And a per-address rate limit applies to the proxy's address as it did to yours, so pacing still matters. The setups that hold up combine all three: a stable residential exit, cookies exported the right way, and sleep options between requests. Our residential proxies support session ids in the username for the stable exit, and the YouTube guide shows how to size the rate.

In one line each

In a browser: sign in, or turn the VPN off. In yt-dlp: update, run from a residential address, pass cookies exported from a private window, and slow down. And when the wiki says the client needs a PO Token, follow the wiki.