火狐（Firefox）28 及更高版本（即 2014 年后的每个现代版本）默认将 network.http.response.timeout 设为 300 秒，这似乎会影响大文件下载的续传与稳定。在 about:config 中改为 0 或很大值后，大下载似乎可续传且更稳定；作者不明原因，实验支持。前提是服务器支持断点续传，否则任何设置都无用。Firefox 出错后无法续传本可续传的下载，续传似乎依赖连接超时而非 .part 文件，且会忽略已有 .part。Firefox 续传整体不稳定，这是已知问题。

不知为何，Firefox 28 及更高版本（即大约 2014 年之后的各个现代版本）默认把 network.http.response.timeout 设为 300 秒。这似乎会影响大文件的断点续传，也会让大文件下载本身变得更不稳定。

在 about:config 里把 network.http.response.timeout 改成 0（或一个很大的值），大文件下载就可以续传，而且稳定性也多少好一些。我不知道为什么这样有效，但实验测试支持这一点。

要注意，这假设服务器支持断点续传；如果服务器不支持，Firefox 或任何其他浏览器的设置都帮不上忙。这个设置真正解决的问题是：Firefox 在出错后无法继续一个本可续传的下载。我不完全确定原因，但从实验看，Firefox 的断点续传似乎依赖连接超时，而不是它下载的 .part 文件。如果不改这个选项，Firefox 会毫不在意地无视已有的 .part 文件，我也不知道为什么。

Firefox 的断点续传总体上一直不太稳定，某种形式的这个问题至少从 2005 年 就已存在。我还发现有人用 手动调整 .part 文件来让 Firefox 真正续传的方法，但我才不干这种破事。如果愿意绕开 Firefox，用 wget -c -O "$filename" "$url" 也可以，而且 wget 整体表现得相当稳定。

我还怀疑 Firefox 在判定下载失败之前，会先尽可能做一些隐藏的重试；实验测试显示，这至少在一定程度上和 network.http.response.timeout 有关，超过超时时间会干扰这个过程。

我没有去翻 Firefox 源码来核实这些说法，因为我完全不知道该从哪里看起。

讨论带着明显的惊讶与讽刺：多数人借 Firefox 下载续传 bug 吐槽浏览器二十年后仍搞不定基础功能，并转向外部下载工具；少数人则强调自己续传正常、问题只在一次性链接或特定超时/弱网场景下出现，或给出手动绕过与超时容错层面的技术猜测。

认为这是浏览器/Firefox 长期忽视的基础功能缺陷

• 把下载续传、大文件下载不可靠看作长期顽疾：相关问题至少自 2005 年就已存在，Firefox 多年未修好，社区用讽刺表达不满，认为连这种基础能力都要靠手动折腾或再等二十年。（较多人） > 把 Mozilla 当作小独立公司，再给它二十年也许能搞定这种基础功能。（@maxlin）

主张彻底放弃浏览器内下载，改用外部下载管理器或命令行工具

• 认为 aria2、JDownloader 2、curl、axel、IDM/NDM 等外部工具在协议支持、多线程、断点续传、并行分片和失败回溯上都比浏览器可靠；有人表示自己已多年不在浏览器里下载超过十几 MB 的文件，IDM/NDM 至今仍在更新并被视作黄金标准。（较多人） > 浏览器下载的正确做法就是别在浏览器里下，复制链接后用 curl 即可。（@inetknght）

认为续传失败并非普遍现象，取决于场景与设置

• 有人表示自己不到一个月前还成功续传，且 network.http.response.timeout 保持默认 300，体验完全不同；也有人说只有一次性下载链接被中断时才会出问题，说明缺陷并非所有下载都会触发，在出现更详细的复现分析前外界很难定位。（少数人） > 我不到一个月前还成功续传过，而且一直用默认的 network.http.response.timeout 300。（@userbinator）

认为根因是软件对弱网/高延迟抖动容错太差

• nirui 根据 network.http.response.timeout 猜测 Firefox 可能分不清网络层结束符与请求层结束符；并批评发达地区的工程师很少被真实网络错误困扰，导致对中国跨境连接的高延迟抖动、印度断电/重拨路由器等场景容错不足，而这些本可通过软件改进来缓解。（少数人） > 写代码的工程师大概从没被网络错误真正烦过，因此没把这些问题放在心上。（@nirui）

认为定位这类冷门 bug 要先复现，LLM 和搜索还不够

• shiandow 原本期待 LLM 能帮忙找这种冷门 bug，但发现仅接入搜索引擎的简单模型并不够；面对他人“这类 bug 的解法到底怎么找出来”的提问，他认为下一步最好是先复现问题。（少数人） > 本以为 LLM 能帮上忙，但连着搜索引擎的简单模型还不够，下一步最好先复现这个问题。（@shiandow）

有价值的补充

• edflsafoiewq 给出一次性链接中断后的手动续传绕过步骤：先把旧 .part 文件移到临时文件，重新下载以生成新 .part，暂停后用临时文件覆盖 .part，再继续即可从上次位置恢复；直接续传一次性链接会因 400 响应被 Firefox 删除 .part，因此必须手动替换。
• phendrenad2 提到，在 Firefox 弃用 XUL 之前，许多下载扩展都带有断点续传功能，说明这类能力曾由扩展生态补齐，而非浏览器原生可靠功能。
• majorchord 补充了一个同类“多年失修”的例子：Firefox 的模态搜索高亮功能（曾用于把非结果区域变暗以便定位）也已损坏多年，对应 bug 1872349。