yt-dlp with a proxy: syntax, which proxies actually work against YouTube, and what it costs

By Tunelio team·Published Sep 7, 2026

yt-dlp --proxy socks5://user:pass@host:port URL sends every request through the proxy. The syntax is the easy part. The hard part is that YouTube scores the proxy’s IP exactly like it scores your server’s: cheap datacenter proxies inherit the same bot checks and 403s, residential or mobile exits work but route the whole video through them, and a PO token is still required. This guide covers all of it from running an extraction fleet ourselves.

Syntax

yt-dlp --proxy "http://user:pass@proxy.example.com:8080" "URL"
yt-dlp --proxy "socks5://user:pass@proxy.example.com:1080" "URL"     # SOCKS5, DNS resolved locally
yt-dlp --proxy "socks5h://user:pass@proxy.example.com:1080" "URL"    # SOCKS5, DNS resolved by the proxy
yt-dlp --proxy "" "URL"                                             # bypass any HTTP_PROXY env var

yt-dlp also honours the HTTP_PROXY, HTTPS_PROXY and NO_PROXY environment variables. SOCKS support needs the pysocks/urllib3 socks extras, which are included in the official binaries and in pip install "yt-dlp[default]". Put the flag in your config file to make it permanent.

What the proxy does and does not do

• Everything goes through it: the watch/player requests and the media download. A 200 MB video means 200 MB of proxy traffic — with per-GB residential proxies that is the dominant cost.
• It changes the IP YouTube sees, and therefore the reputation score. It does not change the client fingerprint, the missing PO token or an outdated yt-dlp — those still cause 403s and bot checks.
• --geo-bypass and --geo-verification-proxy are different tools: they only affect the initial metadata request for region-locked content, not the media download.

Which proxies work against YouTube

Datacenter proxies: usually not

YouTube classifies IP ranges by owner. A proxy hosted at a cloud provider or a bulk-IP reseller is in the same “likely automation” bucket as your VPS, so rotating through a hundred of them mostly rotates through a hundred flagged addresses. They can still be useful for geo-unblocking metadata, rarely for sustained downloads.

Residential and mobile proxies: yes, at a price

Exits on consumer ISP or mobile-carrier ranges score like home users, which is why they clear bot checks that datacenter IPs cannot. The price is bandwidth: most providers bill per GB, and every byte of video goes through the exit. Sticky sessions (same exit for several minutes) work better than per-request rotation, which looks like a botnet.

IPv6 and the /64 trap

Many proxy and VPN products hand out IPv6 exits because they are cheap. YouTube scores a whole IPv6 /64 as one address, so one abusive neighbour flags the block, and a “million IPs” offer inside a single /64 is one reputation unit. On our own fleet in August 2026, about three in ten extractions returned a media host that refused IPv6 but served the same URL over IPv4. Force IPv4 with -4 unless you know the IPv6 exits are clean.

Bandwidth math

Metadata is cheap and media is not. In our measurements a full yt-dlp extraction (player page, player JS, API calls) moves roughly 1 MB through the proxy; the video itself is 20–500 MB. If you pay per GB, the proxy bill is set entirely by the videos you download, not by how many you look up. Two ways to contain it: request smaller formats (-S "res:720") and cap throughput (--limit-rate) so a runaway job cannot burn a month’s allowance in an hour.

Recipes

Residential exit, IPv4 only, gentle pacing

yt-dlp -4 --proxy "socks5h://user:pass@residential.example:1080" \
  --sleep-requests 1 --sleep-interval 3 --max-sleep-interval 8 \
  -S "res:720,ext:mp4" "URL"

Proxy plus cookies

yt-dlp --proxy "socks5h://…" --cookies cookies.txt -4 "URL"

Keep the cookie jar and the exit country consistent: a session logged in from one country used through an exit in another is itself a bot signal. See the cookies guide for the safe export procedure.

Test whether the proxy is the problem

yt-dlp -v --proxy "socks5h://…" -4 -F "URL" 2>&1 | grep -iE "sign in|403|player_client|WARNING"

Common errors

• “Unable to connect to proxy” / “Connection refused” → wrong host/port, or an HTTP proxy configured as SOCKS (or vice versa).
• “Missing dependencies for SOCKS support” → install yt-dlp[default] or pip install pysocks.
• Bot check or 403 through the proxy → the exit is flagged; switch to a residential/mobile exit and force IPv4. Also make sure yt-dlp is current and a JS runtime is installed.
• Very slow downloads → residential exits are slower than your server’s link; add --concurrent-fragments 4 and accept the ceiling, or download smaller formats.
• Works once, fails on the next video → per-request rotation; ask the provider for sticky sessions.

When you should not run proxies at all

If you are proxying because a bot, an app or a pipeline keeps hitting YouTube’s wall, you are about to operate a proxy budget, sticky-session logic, PO-token minting and cookie rotation — the same fleet we run. A hosted API keeps all of that server-side and returns a download URL per request; the media streams from our edge, not through a metered proxy on your side. Tunelio is our own service, so weigh the pitch; for a few personal downloads, -4 and a decent exit are enough. New accounts get 100 free credits.

Sources

• yt-dlp README — Network options (--proxy, --source-address, -4/-6), Geo-restriction options.
• yt-dlp wiki — FAQ on bot checks and IP reputation.
• Our own measurements (Tunelio extraction fleet, August 2026): IPv6 media-host refusals, bytes per extraction through a proxy.