结论：github.com 不通，不代表 GitHub 不通——同一个站的几个域名，实测两死一活，而活的那个比所有第三方镜像都快。

本次实测：五个通道，真正能用的只有一个半

任务是把 DeepSeek Harness（命令行名 dsh）的源码和可执行版本装到本机。第一步 git clone 就卡住：两分钟内目录体积停在 4MB 不动。于是把通道本身逐个测了一遍：

目标 实测结果 判定
github.com HTTP 000，25 秒无响应 ❌
raw.githubusercontent.com 解析到 IPv6，0.15 秒即失败 ❌
codeload.github.com HTTP 200，45 秒下到 4.34MB（约 96KB/s） ✅ 最快
registry.npmmirror.com HTTP 200，0.59 秒，包版本 0.2.0-rc.2 ✅ 稳
ghproxy.net（第三方镜像） 能动，但中途停滞 → early EOF ⚠️ 不可靠
gitclone.com（第三方镜像） ls-remote 通过 ✅ 备用

顺手排除了一个常见误判：DNS 是干净的——github.com 解析出的是真实公网 IP，不是代理那类私有段。卡点不在域名解析，而是 TCP 层到 github.com 就断了。

最终方案是两条腿：运行用 npm 装的 CLI（走 --registry=https://registry.npmmirror.com，快且稳），源码用 codeload 的 tar 包（32MB 压缩包，解包后 157MB，含 apps/ packages/ docs/ benchmarks/）。

一个坑：别把"GitHub 不通"当结论

现象：git clone 挂住不动，第一反应是"被墙了，去找镜像"，然后挨个试第三方加速站——实测其中两个会中途断，一个根本不通，时间全耗在这里。

复现步骤：三个域名分开测，10 秒就能看清：

sh curl -4 -s -o /dev/null -w "github: %{http_code}\n" --max-time 20 https://github.com curl -4 -s -o /dev/null -w "raw: %{http_code}\n" --max-time 20 \ https://raw.githubusercontent.com/deepseek-ai/deepseek-harness/master/README.zh.md curl -4 -s -o /dev/null -w "codeload: %{http_code} %{size_download}\n" --max-time 45 \ https://codeload.github.com/deepseek-ai/deepseek-harness/tar.gz/refs/heads/master

解法：绕过 git 协议，直接取 tar 包：

sh curl -4 -L --retry 3 -o dsh.tar.gz \ https://codeload.github.com/deepseek-ai/deepseek-harness/tar.gz/refs/heads/master tar xzf dsh.tar.gz

顺带记一个版本差异（后面几期细说）：npm 通道给的是 0.2.0-rc.2，源码 master 是 0.2.1-alpha.1——官网主推的"开箱即用"通道，比仓库落后一档。看文档对不上号时，先查这一条。

总评

4.5 / 5，只针对"能不能装到"这一件事。 卡点不在工具本身，全在从墙内到达它的路上；而答案不在第三方镜像里，就在官方自己的下载域名里。这十分钟的诊断，省掉了后面一小时的瞎试。

测试环境：Windows + WSL2（Ubuntu）、Node 22.23.2。命令、耗时、报错均为本机实测。

文 / 程实