火狐浏览器彻底阻止崩溃报告自动发送的配置方法

许多用户认为在设置中关闭“自动发送崩溃报告”就能高枕无忧，实际上这个选项只控制点击弹窗时的响应——后台的 crashreporter 进程依然在运行，浏览器重启后积压的崩溃日志仍会悄悄上传。要想彻底切断所有上传通道，必须组合四层配置，缺一不可，否则就可能留下漏网之鱼。

火狐浏览器的崩溃报告之所以难以完全禁用，根本原因在于图形界面开关仅控制前端触发，无法阻止后台服务进程。必须将隐私设置、about:config 高级配置、安装目录策略文件、本地缓存和目录权限这四条路径全部封堵，才能有效防止积压报告重新发送、健康报告附带上传、Breakpad 服务静默启动等问题。

仅关闭隐私设置中的“自动发送崩溃报告”远远不够

此选项只决定用户点击“发送报告”弹窗时的回应，对已经启动的 crashreporter 进程毫无影响，也不会阻止浏览器重启后自动提交之前积压的报告。即便勾选了“从不发送”，只要 toolkit.crashreporter.enabled 仍为 true，崩溃日志照样会写入本地的 Crash Reports 目录，等待上传。

• 必须同步取消“向Mozilla发送技术和交互数据”“向Mozilla发送每日使用情况报告”“安装和运行研究”这三项，否则遥测服务会将崩溃元数据一并打包发送出去。
• “改进Firefox建议体验”如果处于开启状态，会启用 browser.ping-centre.telemetry，间接激活崩溃上报链路。
• 关闭后无需重启浏览器，但仅执行这一步，已经存在的积压报告仍然可能被上传。

about:config 中必须将以下四个键设为 false

这才是真正切断崩溃采集逻辑的关键操作。只修改其中一两个，其他模块仍可能启动 crashreporter，或复用其 HTTP 客户端。

• toolkit.crashreporter.enabled — 设为 false 才能阻止 Breakpad 初始化；如果保持 true，哪怕 UI 已关闭，崩溃依然会生成 minidump。
• datareporting.crashreports.uploadEnabled — 控制是否允许上传，必须关闭；否则重启后积压报告会自动发送。
• breakpad.reportURL — 需要双击清空其值，不能直接设为 false（它是字符串类型），否则默认 URL 仍可能被 fallback 使用。
• toolkit.telemetry.enabled — 遥测服务如果运行，会将崩溃事件作为 ping 的一部分打包发出，必须禁用。

distribution/policies.json 是最高优先级的拦截手段

这个文件在 Firefox 启动的最早阶段加载，能够覆盖 about:config 和用户设置，防止策略更新或 profile 重置导致意外恢复。

• 路径必须是 Firefox 安装根目录下的 distribution/policies.json，而不是 profile 目录。
• 内容必须是严格 JSON 格式，无 BOM，且必须包含 "DisableCrashReporter": true（仅写 DisableTelemetry 是不够的）。
• 示例内容：

  {"policies": {"DisableTelemetry": true, "DisableCrashReporter": true}}

• Windows 下典型路径：C:Program FilesMozilla Firefoxdistributionpolicies.json

删除缓存并锁定 Crash Reports 目录才算最终收尾

本地缓存文件不清理，浏览器重启后会试图补传；目录不锁定，某些插件或脚本仍然可能写入新报告。

• 删除 profile 下的 healthreport、crashes、datareporting 三个文件夹（路径类似 %APPDATA%MozillaFirefoxProfilesxxx.default-release）。
• 将 crashes 文件夹权限设为“只读”或“拒绝写入”。Windows 下可以右键 → 属性 → 安全 → 编辑 → 拒绝“写入”。
• 如果使用了 arkenfox 的 user.js，确认它已经启用 privacy.spoof_english 和 network.http.referer.XOriginPolicy，避免因 UA 或 referer 泄露触发额外遥测。

最容易被忽略的是两处：breakpad.reportURL 的清空操作和 crashes 目录的写入权限控制。前者必须清空才能防止 fallback，后者不锁住就永远存在静默写入的风险——这才是真正的收尾动作。