YouTube 下载器架构封面

[!TIP]

受众：对自托管工具感兴趣、需要排查下载失败原因的开发者。 目标：记录一次 YouTube 下载器的整理过程，重点是 n challenge 签名问题、Cookie 同步和日志观测。 问题-方案映射：

  • 登录墙/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 进程处理 JS。

3. 部署：减少手动步骤

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

这种“本地写配置、远程跑任务”的方式，目前更适合我维护和排错。