凌晨一点十七分，进度条卡在 78%，那个写了三天的表格就是下不完。

关于我

我叫江晚，白天在出版社做资料整理，晚上维护这个小站点。说“维护”其实有点抬举自己——更多时候是在修修补补。去年十一月，我在旧书摊上淘到一本1989年出的《目录学发微》，摊主开价十二块，我给了十块，他嘟囔着“现在没人看这个了”还是卖给了我。那本书里有一段讲文献传抄的断层，我读了三遍，觉得今天下载失败这件事，和当年的传抄中断，骨子里有点像。

这个站就是为此而建的。

我把常见的下载失败情形、报错信息和我自己试过的笨办法一条条记下来，希望下次别人卡在78%的时候，不用像我一样在凌晨一点十七分盯着屏幕发呆。我不算技术专家，写的东西经常有错，有些问题到现在也没答案——比如为什么同一个链接，用敏感网站用什么浏览器里的办法换个环境就能下，我却说不清根本原因。如果你也困惑，欢迎一起讨论。

那天夜里发生了什么

具体时间我记得很清楚：12月28日，凌晨1:17。我坐在书桌前，笔记本风扇转得像冬天的暖风机。那份文件来自一个资料库的镜像页，登记大小是47.2MB，我点了第三次下载，进度条走到78%就停住了。我试着刷新，页面弹出一行灰字：“连接已重置”。我做了个动作——把浏览器缓存清理了一遍，又换了个下载工具，仍然无效。

后来我查了路由日志，才发现问题出在跳转环节。

我把这个排查过程整理成了笔记，顺带翻出了香港宝典免费资料网里提到的一些老式镜像站结构，发现它们和这次遇到的跳转异常有相似之处。这种对照让我既高兴又不安：高兴的是找到了参照，不安的是，很多老站点的说明已经没人维护了。

我的一个不太讨喜的看法

说实话，我认为“下载失败”这件事被严重低估了。大多数教程只告诉你清缓存、换浏览器、关防火墙，但很少有人愿意承认：有些失败是源头侧的资源失效，用户做什么都没用。平台把责任推给网络环境，网络环境又把责任推给用户操作，最后只剩用户自己对着78%的进度条自我怀疑。

这一点，我写这篇文章时仍然没有完全想通。

所以我倾向于在站点里保留那些“不确定”的段落，而不是编一个圆满的答案。前几天邻居家的小孩来问我，为什么他下载一个历史记录恢复工具总是中断，我打开免费历史记录恢复网站的说明页，发现上面的链接指向早已失效的CDN节点。这个发现让我更加确信：很多所谓“解决办法”，首先要把失败的真实原因说清楚。

找我

想聊天？写邮件到 jiangwan@49tuku-notes.example。我个人更习惯邮件，因为可以慢慢写，不必追赶即时回复的节奏。如果你也遇到过下载卡在某个百分比的情况，把错误截图和大致时间发给我，我会尝试一起排查——但我得先说在前面：很多问题我也没有现成答案。

写信时不用太正式，把时间、文件大小、报错原文写清楚就好。

另外说明一下：这个站点不提供任何文件托管，也不代理下载，我只记录过程与方法。如果你在别处看到以本站名义索要账号密码的，那不是我。

三个我记得住的细节

人名与动作：12月29日下午，同事周敏在工位上第三次重新下载同一份参考表格，她敲了一下回车，低声说“又是这个数，78%”。

具体数字：文件登记大小47.2MB，失败时已下载约36.8MB。

时间与动作：凌晨1:17之后，我关掉自动重试，改用分卷下载，分段拿到8个片段里完整的6个，剩下两个至今空缺。

站点在做什么

这里主要记录三类内容：下载失败的现象描述、可以动手验证的排查动作、以及一些仍未解释清楚的现象。我尽量把每一步写具体，包括我试过但失败的方案。因为我觉得，失败的步骤和成功的步骤一样有信息量。

如果你也在整理类似的问题，欢迎来信交换笔记。