--downloader-args<\/code>.<\/p>\nyt-dlp --proxy \"http:\/\/USER:PASS@proxy.example.com:8080\" \\\n --downloader aria2c \\\n --downloader-args \"aria2c:-x 4 -s 4 --connect-timeout=15 --timeout=30 --max-tries=5\" \\\n \"https:\/\/www.youtube.com\/watch?v=VIDEO_ID\"<\/code><\/pre>\nThree caveats:<\/p>\n
\n- HTTP proxies only.<\/strong> The aria2 manual gives the proxy format as
[http:\/\/][USER:PASSWORD@]HOST[:PORT]<\/code>. aria2c doesn't speak SOCKS. With a SOCKS proxy, use the native downloader. (ffmpeg has the same limitation: yt-dlp warns that it \"does not support SOCKS proxies\".)<\/li>\n- 16 connections per file.<\/strong> On a per-connection rotating proxy, each segment may come from a different IP, which brings back the 403 problem. Use a sticky session and fewer connections (
-x 4<\/code>), or skip aria2c.<\/li>\n- aria2c reads proxy environment variables itself. Only an explicit
--proxy<\/code> is forwarded by yt-dlp, so test the exact configuration you deploy.<\/li>\n<\/ul>\nAdd -v<\/code> to see the final command line ([debug] aria2c command line: ...<\/code>) and confirm which arguments took effect.<\/p>\nTimeouts and retries<\/h2>\n
\n\n\n| Flag (API key)<\/th>\n | Default<\/th>\n | What it does<\/th>\n<\/tr>\n<\/thead>\n |
\n\n--socket-timeout<\/code> (socket_timeout<\/code>)<\/td>\n20 s (DEFAULT_TIMEOUT<\/code> in the networking layer)<\/td>\n| How long to wait on an unresponsive connection. Raise it to 30\u201360 s for slow residential exits.<\/td>\n<\/tr>\n | \n-R, --retries<\/code> (retries<\/code>)<\/td>\n| 10 CLI \/ 0 API<\/td>\n | Retries for the download on expected network errors. Accepts infinite<\/code>.<\/td>\n<\/tr>\n\n--fragment-retries<\/code> (fragment_retries<\/code>)<\/td>\n| 10 CLI \/ 0 API<\/td>\n | Retries per fragment for DASH, hlsnative and ISM.<\/td>\n<\/tr>\n | \n--retry-sleep [TYPE:]EXPR<\/code><\/td>\n| none<\/td>\n | Backoff between retries, e.g. --retry-sleep exp=1:30<\/code> or --retry-sleep fragment:linear=1::2<\/code>.<\/td>\n<\/tr>\n\n--extractor-retries<\/code><\/td>\n| 3<\/td>\n | Retries for known extractor errors.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Retries go through the same proxy URL. If that URL is a sticky session, they reuse the same IP, which is what you want for a transient error. For a hard block (repeated 403 or 429), retrying on the same IP rarely helps. Fail fast, record the video, and requeue it on a fresh session.<\/p>\n Choosing a proxy type for this workload<\/h2>\nVideo collection is unusual among proxy workloads: few requests, lots of bytes. That changes the trade-offs.<\/p>\n \n\n\n| Type<\/th>\n | Strengths<\/th>\n | Weaknesses for yt-dlp<\/th>\n<\/tr>\n<\/thead>\n | \n\n| Datacenter (shared)<\/td>\n | Cheap, fast, stable IPs<\/td>\n | Cloud and hosting ranges are the most likely to get bot checks and 403s from YouTube. Shared IPs inherit other users' reputation.<\/td>\n<\/tr>\n | \n| Residential (rotating)<\/td>\n | IPs look like home users, many locations<\/td>\n | Usually billed per GB, which gets expensive at video volumes. Bandwidth and latency vary by peer. Sessions can drop mid-download.<\/td>\n<\/tr>\n | \n| ISP \/ static residential<\/td>\n | Residential-registered IPs on datacenter hardware. Stable, so naturally sticky<\/td>\n | Fewer IPs per dollar. A flagged IP stays flagged until replaced.<\/td>\n<\/tr>\n | \n| High-bandwidth dedicated (unmetered, per-Gbps)<\/td>\n | Predictable cost for terabyte-scale transfer, consistent throughput, capacity reserved for you<\/td>\n | You pay for the capacity whether you use it or not. IP reputation still depends on the ranges and on how hard you push each IP.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n The test that matters is your own: run a few hundred videos through each candidate, then compare 403\/bot-check rates and cost per delivered GB.<\/p>\n Troubleshooting<\/h2>\n\n\n\n| Symptom<\/th>\n | Likely cause<\/th>\n | Fix<\/th>\n<\/tr>\n<\/thead>\n | \n\n407 Proxy Authentication Required<\/code><\/td>\n| Wrong credentials, unencoded special characters in the password, or source-IP allow-listing on the provider side<\/td>\n | URL-encode the credentials. Test with curl -x<\/code>. Check the provider's allow-list.<\/td>\n<\/tr>\n\nUnable to connect to proxy<\/code> \/ Connection refused<\/code><\/td>\nWrong host or port, wrong scheme (SOCKS port with http:\/\/<\/code>), or a firewall<\/td>\nMatch the scheme to the port the provider documents. Check with curl -x<\/code>.<\/td>\n<\/tr>\n\nSSL: CERTIFICATE_VERIFY_FAILED<\/code> or WRONG_VERSION_NUMBER<\/code><\/td>\nUsing https:\/\/<\/code> for a plain HTTP proxy (or the reverse), or an intercepting proxy<\/td>\nUsually you want http:\/\/<\/code>. --no-check-certificates<\/code> hides the problem instead of fixing it; only use it for debugging.<\/td>\n<\/tr>\n\nTimeouts, Read timed out<\/code><\/td>\n| Slow or overloaded exit, peer dropped<\/td>\n | Raise --socket-timeout<\/code>, add --retry-sleep<\/code>, reduce concurrency per IP.<\/td>\n<\/tr>\n | | | | | | | | | | | | | | | | | | | |