2026-10-16 · 上线实录 ① / ④ · 部署通道
一个骗过我的
127.0.0.1
接手 dola.cn 的第一件事，是把它重新发布出去。我以为这是三分钟的事， 结果先撞上一个会说谎的本地代理。
重做本身不难。我们决定不做通用模板，只做几个页面加一份样式表：没有框架、没有构建步骤， 任何人打开源码都能看懂它怎么工作。
难的是发布。我给自己定了一条规矩：一条命令搞定，而且这条命令必须自己验证结果， 而不是自己宣布成功。这句话说完不到两小时就被打了脸——打的正是这句话。
第一次克隆就失败
仓库在 GitHub Pages 上。按常理，克隆、提交、推送，三分钟的事。第一次 git clone
就失败了。查下去发现：这台机器上 github.com 被解析到了 127.0.0.1——
本地有个代理在接客。
更妙的是，它接得很有礼貌。用 SSH 连上去，它回一句「You've successfully authenticated」： 认证通过。
问题是，我当时手里那把密钥是刚生成的、从没上传到任何地方的。它不可能通过任何真实的验证。
拿一把注定不该成功的钥匙去试。如果它也能开门，这扇门就是假的。 我们用一把随手生成的密钥复现了同样的「认证成功」，于是确认这个入口不可信。
真入口在 443 端口上
GitHub 有一个专供网络受限环境使用的入口：SSH-over-443，也就是 ssh.github.com:443。
它解析到真实 IP，用机器上早就注册过的那把密钥验证——仍然是「成功」。
但这次我没有直接相信：我先用 GitHub API 交叉核对了提交哈希，确认它连的确实是那个真仓库， 才敢继续往下走。同样的「成功」，一个是真的，一个是假的——区别在于我能不能拿别的证据对上它。
0 字节的包
真通道找到了，克隆还是不动。一看本地仓库：objects/pack 里的临时文件停在
0 字节，从头到尾没长过一个字节。可 ls-remote 却能秒回——
说明握手没问题，断在传数据这一步。
换成浅克隆 --depth 1：5 秒，6.2 MB，完事。
仓库里那 3 MB 的音频、几百个历史对象，我们其实一个都不需要。
判断发布成功，别只看命令的退出码，要看结果本身。 我们后来给自己的做法是：抓取线上首页，和本地文件逐字比对。
顺带交代一句：我们的发布脚本一开始也犯了这个错。它那句「已上线」检查的是新旧版本里都存在的文字—— 等于没验证，只是把「没报错」当成了「成功」。改成逐字比对之后，它才真正有资格说话。
《上线实录》连载：① 部署通道 · ② 域名解析 · ③ 邮箱 · ④ 方法论 —— 下一篇讲：为什么邮箱记录一度加不进域名里。 回到笔记