YouTube 下载器架构封面

[!TIP]

受众：对自托管工具感兴趣、经常与各种“限制”博弈的开发者。 核心目标：构建一个完全受控的 YouTube 媒体采集系统，解决 n challenge 签名挑战。 问题-方案映射：

  • 登录墙/Cookie $\rightarrow$ Manifest v3 浏览器插件同步
  • 动态签名 (n-sig) $\rightarrow$ Docker 内置 External JS Solver (node)
  • 实时观测 $\rightarrow$ Socket.io 流式转发 stdout

最近在折腾自己的“数字主权”基础设施，其中一个刚需就是 YouTube 下载。市面上的工具很多，但随着 YouTube 对 n-sig（一种通过混淆 JS 动态生成的签名）的限制加码，很多开源项目开始在大音轨下载上“翻车”。

作为一个写了 20 年代码的老兵，我最受不了的就是“工具不可控”。于是，我把这套老伙计重新打磨了一下，做了一个“主权级”的架构。

1. 架构：为什么非要搞这么复杂？

很多人觉得 yt-dlp 一行命令能解决的事，为什么要搞插件、Docker 和后端？

答案是：骨感现实。

  • Cookie 维护：手动导 cookies.txt 太脏。我写了一个 Manifest v3 插件，点一下直接同步到云端。
  • 环境隔离：我的开发机是 Windows，但下载器必须部署在 Linux Docker 里，且需要精准控制 ffmpeg 和 yt-dlp 的版本。

这就是我们的“三足鼎立”：

  • 插件 (Bridge)：负责打通浏览器会话。
  • 后端 (Engine)：Node.js + Socket.io，负责进程管理和实时日志。
  • 容器 (Infra)：解决一切环境依赖。

2. 泥地打滚：解决 n-sig 的深层逻辑

前阵子，我的下载器突然报错：n challenge solving failed。这是 YouTube 升级了混淆逻辑，yt-dlp 默认的 Python 模拟器解不动了。

这就像是“泥地打滚”，你必须直接接入对方的战场。

我们的对策：

  1. 引入 External JS Solver：既然是 JS 写的混淆，那就用 JS 来解。我们在 Docker 里安装了 yt-dlp-ejs。
  2. 强制 Node 运行时：在配置文件中指定 --js-runtimes node。这让 yt-dlp 在遇到挑战时，直接“弹”出一个 Node 进程去跑解密，稳如老狗。

3. 部署：自动化就是尊严

老兵的习惯是“能不手动就不手动”。我写了一个 Python 脚本 deploy_remote_v3.py，通过 SSH 自动化同步代码并触发 docker-compose 重建。

这种“本地编写、远程生产”的节奏，才是主权化工具应有的样子。

🤖 Technical Metadata (AI-Ready)

  • Primary Tooling: yt-dlp, ffmpeg, Node.js 20-slim, Docker Compose.
  • Key Configuration:
    • yt-dlp version: nightly-2026.x.x
    • n-sig fix: yt-dlp-ejs + --js-runtimes node.
    • Auth strategy: Custom Chrome Extension (Netscape Cookie format sync).
  • Network: SSH/SFTP via paramiko.