Firefox 自托管扩展为何手动可更新、自动更新失败？

2026-11-04数据小陈

结论

仅凭“打开 Browser Console 后更新开始”，还无法确定根因，也没有依据判断这是 Firefox 的普遍故障。Browser Console 开启和更新开始在时间上重合，但这不能证明前者触发了后者。手动检查成功，说明 Firefox 当时能找到并安装某个更新；这本身不能证明自动检查的触发时机、请求路径和响应都正常。

Firefox 自托管更新要求已安装版本中的 browser_specific_settings.gecko.update_url 指向更新清单。Firefox 会继续使用已安装版本保存的这个 URL 检查更新。更新清单中的 add-on ID、较高的版本号和可用的 XPI 也必须匹配。Firefox Extension Workshop：更新扩展

先核对扩展包中的配置

检查旧版本 0.9.12 实际打包的 manifest.json，确认其中包含正确的自托管更新地址，例如：

{
  "browser_specific_settings": {
    "gecko": {
      "id": "<my add-on ID>",
      "update_url": "https://example.com/updates.json"
    }
  }
}

update_url 应指向更新清单的 HTTPS 地址，而不是 XPI 下载地址。只修改服务器上的新版本 manifest.json，不会改变已安装旧版本中保存的更新地址。Mozilla 文档也说明，自托管扩展需要在 manifest.json 中配置 browser_specific_settings.gecko.update_url。提交扩展

核对更新清单和 XPI

确认清单是完整、有效的 JSON，并且 addons 下的 ID 与已安装扩展的 ID 完全一致。清单中的 version 应高于已安装版本，update_link 也应能由 Firefox 访问，并返回预期的签名 XPI。你提供的清单列出了 1.1.4 和 1.1.4.1；具体情况应以 Firefox 请求到的清单内容和已安装版本为准。

Mozilla 文档介绍了 Firefox 的更新清单格式和 update_link 的用法。更新扩展

找出自动检查停在哪里

查看服务器访问日志，确认 Firefox 是否请求了 update_url，并记录请求时间、HTTP 状态码和最终响应地址。
如果收到了清单请求，检查响应正文是否为预期的 JSON；如果之后又请求了 XPI，再核对 XPI 的状态码、下载内容和签名情况。
保持设置不变，记录自动检查未发生的时间点，再执行手动检查作对照。比较两种情况下的服务器日志和 Browser Console 信息。
重新安装旧版本时，确认安装的确实是 0.9.12，并检查该 XPI 内的 manifest.json，不要只看服务器上的当前文件。

extensions.update.interval 设为 120 秒，并不能证明某次请求一定会在两分钟整时发出。是否发起过自动检查，应以请求记录和控制台日志为准。如果打开 Browser Console 后现象再次出现，可以把它作为复现线索，记录具体时间和日志。现有信息还无法解释它为何恰好与更新开始同时发生。