简介面向希望加固Firefox隐私与安全、优化浏览性能的用户整理了一份about:config参数修改清单及配套材料。内容围绕安全浏览、隐私保护与性能调优等常见项展开既给出参数取值与作用说明也提供可直接参考的配置脚本方便在重装系统或新设备上快速恢复习惯设置。压缩包共7个文件以4张PNG操作示意截图、1个JavaScript配置脚本、1份Markdown说明文档及许可证文件为主整体约369KB体积轻量却覆盖了配置思路、可视化对照与使用说明。已有328人学习下载适合想按图索骥完成Firefox隐私加固的普通用户也能为需要批量整理参数、排查配置项作用的中高级用户提供参考。对重装后逐项恢复设置、理解安全浏览开关影响、对照截图确认生效结果均有帮助也可作为团队统一浏览器安全基线的参考减少逐项查找与试错成本。1. about:config 不是收藏册三类参数的代价各不相同在地址栏输入about:config会先弹出一个警告页点击继续之后看到的是一张按字母序排好的键值表。Firefox 的安全、性能、隐私开关大多集中在这张表里改动一个布尔值就能改变浏览器行为——关掉遥测上报、调整内容进程数、把 TLS 下限抬到 1.2都在这里一步到位。它没有校验也没有场景提示值改错了多半不报错只在你某个具体操作里悄悄出问题比如附件传不上去、会议软件黑屏。这份资源就是围绕这张表整理的一份参数清单适合需要在多台机器上统一隐私策略的从业者也适合想把每个开关背后的代价弄明白的人新手照着改能出效果熟手能看清取值的边界在哪里。2. 隐私参数收敛从遥测上报到 DNS 预取的四层开关隐私这一块最容易出事因为它不是“越关越安全”的线性关系。关掉上报纯赚关掉 Cookie 可能让单点登录全线失效关掉 WebRTC 会让视频会议直接黑屏。所以我会按四条独立的链路分开处理遥测、Cookie、网络层指纹、浏览器指纹。四条链路互相不依赖改坏一条不影响其他三条回滚也只用回滚一条。2.1 遥测与实验开关先把上报链路掐掉这部分是纯收益项几乎不会影响任何站点功能。在about:config顶部的过滤框里输入telemetry会列出十几条相关参数其中真正需要动的只有五六条。参数默认值建议值作用toolkit.telemetry.enabledtruefalse关闭遥测采集总开关datareporting.healthreport.uploadEnabledtruefalse停止健康报告上传datareporting.policy.dataSubmissionEnabledtruefalse停止数据提交通道app.shield.optoutstudies.enabledtruefalse退出 Shield 试验性功能app.normandy.enabledtruefalse关闭远程配置推送通道toolkit.telemetry.archive.enabledtruefalse不再本地归档遥测数据注意datareporting.healthreport.uploadEnabled这一条要优先处理把它置为 false 之后上层的datareporting.policy.dataSubmissionEnabled会失去意义。我在实际操作时习惯先过滤datareporting把这组链条上的参数一次性处理完再处理toolkit.telemetry这一组最后处理app.前缀的试验开关。顺序反了也不会错只是过滤框每次都要重新输入效率很低。双击每一行的值布尔类型的值就会在原值与新值之间翻转改完不需要重启但有些参数要等下一次启动才真正生效比如遥测上报模块本身。如果想确认是否生效可以打开about:telemetry如果这个页面已经拿不到任何数据说明采集端已经停止工作。这里有一个常见误解有人以为关掉toolkit.telemetry.enabled就够了结果app.normandy.enabled还开着浏览器依然会从远端拉取功能开关。这两条走的是不同通道必须分别处理。2.2 追踪保护与 Cookie 隔离network.cookie.cookieBehavior 的取值陷阱network.cookie.cookieBehavior是这一个环节里最容易被旧教程带偏的参数。整数取值在不同大版本里语义调整过直接照抄“1 等于拦截全部第三方 Cookie”的旧结论在新版本上会得到完全不同的行为。现在比较稳妥的理解是这样0全部接受等于放弃这块的防护。1拦截跨站跟踪类 Cookie日常浏览够用兼容性最好。4按跟踪保护列表拦截规则更积极个别站点登录回调会受影响。5对跨站 Cookie 做分区隔离隐私最强嵌套登录流程容易出问题。我一般把它设在1或4只有在明确知道自己的使用场景不涉及跨站登录时才会去碰5。改完之后还需要确认另外两条配套参数privacy.trackingprotection.enabled设为 true 打开常规跟踪保护privacy.trackingprotection.socialtracking.enabled设为 true 把社交平台追踪器一并纳入。改这里最典型的翻车场景是单点登录公司内部用统一认证跳转认证服务器在 A 域、业务系统在 B 域Cookie 一分区回调回来的时候会话就丢了表现是“登录成功但页面还是未登录状态”。遇到这种症状先别怀疑密码回到cookieBehavior把值降到1试一遍能立刻验证是不是这一条导致的。2.3 网络层指纹预取、预连接、Referer 与 WebRTC浏览器在你看不见的时候会做很多“提前行动”预解析 DNS、预连接、预取下一页、把鼠标悬停的链接提前建连。这些行为提升体感速度但也把你的浏览意图提前暴露给了第三方。对应的关闭参数如下全部是布尔类型双击即可。// 网络层行为收敛逐条对应一个提前动作 user_pref(network.dns.disablePrefetch, true); // 关闭 DNS 预解析 user_pref(network.prefetch-next, false); // 关闭下一页预取 user_pref(network.predictor.enabled, false); // 关闭连接预测器 user_pref(network.http.speculative-parallel-limit, 0); // 关闭悬停预连接 user_pref(beacon.enabled, false); // 关闭信标上报 user_pref(geo.enabled, false); // 关闭地理位置接口network.http.speculative-parallel-limit设成 0 之后鼠标扫过一屏链接不会再产生后台连接代价是首次点击多几毫秒的建连时间日常基本感知不到。Referer 是另一组network.http.referer.XOriginPolicy控制跨站请求带不带来源页network.http.referer.XOriginTrimmingPolicy控制跨站时裁到哪一级。这两个值动得太狠会出问题——很多后台系统的文件上传接口会把 Referer 当作来源校验一旦跨站 Referer 被完全剥掉服务端直接返回 403前端表现就是“点上传没反应”。我一般只把XOriginTrimmingPolicy设为2跨站只保留源XOriginPolicy保持默认把兼容性留给业务系统。media.peerconnection.enabled设为 false 会禁用 WebRTC能挡住通过候选地址暴露本地网络信息的路径但代价非常直接所有基于浏览器的音视频会议、在线客服、网页版通话全部不能用典型症状是能进会议室、能看到别人自己这边摄像头一直是黑的。办公机器上我建议保持 true只在纯阅读用途的机器上关。2.4 指纹随机化privacy.resistFingerprinting 的真实代价privacy.resistFingerprinting是这套清单里影响面最大的一条。打开之后浏览器会统一 UA、统一时区表述、把窗口尺寸做 letterboxing 处理、给 canvas 和 WebGL 的读取结果加噪声、把高精度时间戳降到毫秒级以上。防的是通过设备特征组合把你认出来的那类追踪。代价也很实在。窗口缩放会出现灰色边框某些依赖 canvas 精确绘制的在线工具图表编辑器、在线 PS 类应用会出现色彩偏差依赖高精度计时的页面部分行情、在线考试计时行为会变最烦的是 UA 被统一之后一些老旧的业务系统会走错兼容分支页面排版直接散架。我的做法是分级只做日常阅读和信息检索的机器打开privacy.resistFingerprinting和privacy.resistFingerprinting.letterboxing要跑内部业务系统的机器关掉指纹随机化只在 Cookie 和跟踪保护两层做收敛。把这两类机器分成两个配置文件比在同一台机器上反复切换要省心得多。3. 性能与内存进程模型、缓存与首屏渲染的边界性能参数是最容易出现玄学结论的地方——有人说调到某个值快了 30%换一台机器就完全没感觉。原因是这些参数大多和硬件、站点特征、使用习惯强耦合。我处理这一块的原则是只动那些有明确观测手段的参数改完必须能用about:processes或about:support验证验证不了的先不动。3.1 dom.ipc.processCount 与 fission.autostart 的关系dom.ipc.processCount控制内容进程的上限dom.ipc.processCount.webIsolated控制隔离站点各自能分到多少进程fission.autostart决定是否启用站点隔离架构。三者是联动关系只改一个往往没效果。// 内存 16GB 档位的取值示例改完重启浏览器再观察 user_pref(fission.autostart, true); // 站点隔离安全收益明确 user_pref(dom.ipc.processCount, 8); // 内容进程上限 user_pref(dom.ipc.processCount.webIsolated, 4); // 隔离站点进程数 user_pref(browser.tabs.unloadOnLowMemory, true); // 内存紧张时卸载后台标签取值怎么定8GB 内存的机器dom.ipc.processCount压到 2 到 4进程越多每个进程的固定开销叠加起来越明显开二十个标签反而更卡16GB 保持默认或 832GB 以上可以往上调但收益递减因为瓶颈通常已经不在进程数上了。验证方式很直接开一批日常用的标签页打开about:processes看总内存占用和进程数。改前改后各截一次图对比比凭感觉判断靠谱。别一次性把进程数拉满那是最典型的翻车姿势——表面上每个标签独立了实际上内存压力上来之后系统开始换页整机都卡。3.2 磁盘缓存与 sessionstore 的 IO 权衡browser.cache.disk.enable关掉磁盘缓存能减少写入但每次回访都要重新下载静态资源网络差的场景下体感非常差。我一般不动这一条而是调browser.cache.disk.capacity控制上限user_pref(browser.cache.disk.capacity, 512000); // 磁盘缓存上限单位 KB user_pref(browser.cache.memory.capacity, 65536); // 内存缓存上限单位 KB user_pref(browser.sessionstore.interval, 60000); // 会话落盘间隔单位毫秒browser.sessionstore.interval默认是 15000 毫秒也就是每 15 秒往磁盘写一次会话状态。在固态盘上这个频率本身不是问题但在老机械盘或者磁盘 IO 本来就紧张的机器上把间隔拉到 60000 到 120000 能明显减少后台写入的抖动。代价是崩溃恢复时丢失的标签页会多一点——最多丢两分钟的浏览记录。这是个明确的取舍不是纯优化。注意browser.cache.disk.capacity的单位是 KB写 512000 是 500MB 左右别按 MB 写否则会得到一个不合理的巨大值。3.3 首屏渲染延迟与无障碍服务这一组参数争议最大。nglayout.initialpaint.delay控制首次绘制前的等待时间单位毫秒早期默认值是 250后来在多个版本里被调到很小的值甚至 0。如果你照着十年前的教程把它改成 0在现在的版本上大概率什么也感觉不到因为这个值本来就已经很低了。user_pref(nglayout.initialpaint.delay, 0); user_pref(nglayout.initialpaint.delay_in_oopif, 0); user_pref(accessibility.force_disabled, 1); // 强制关闭无障碍服务桥接accessibility.force_disabled设为 1 是另一回事某些系统上无障碍接口被第三方软件挂上之后渲染路径会退化页面滚动明显发涩。强制关闭能恢复但副作用是屏幕阅读器、部分自动化测试工具会失效。办公机器上如果有人在用辅助功能这一条不要动。我自己的习惯是首屏延迟类的参数改完必须用开发者工具里的性能面板录一段加载过程做对比看首次绘制的实际时间点有没有变化。只看“感觉快了”没有意义这一块最容易产生心理作用。3.4 硬件加速与 WebRender 怎么试渲染相关的参数在不同显卡、不同驱动上表现差异极大这也是玄学感最强的一块。常用的是user_pref(gfx.webrender.all, true); // 强制启用 WebRender user_pref(gfx.webrender.software, false); // 关闭软件渲染回退 user_pref(layers.acceleration.force-enabled, true); // 强制硬件加速合成改完必须打开about:support找到“图形”一节看“合成”和“WebRender”两行的实际状态。如果显示的是软件回退说明驱动或显卡被判定为不兼容强行开启的结果通常是花屏、闪烁、视频解码异常。我见过最典型的情况是改了layers.acceleration.force-enabled之后网页正常但视频全绿回滚这一条就好了。所以这一块的顺序是先看about:support里的现状确认浏览器自己判定的路径再决定要不要干预。如果现状已经是硬件加速就没有必要改动。这类参数属于“能用就别碰”的类型。4. 安全加固HTTPS-Only、混合内容与 TLS 下限安全参数的风险比隐私参数更直接隐私改错了是丢登录态安全改错了是页面完全打不开。所以这一块我会严格控制在少数几条收益明确、回滚路径清晰的参数上改完立刻用内部站点和外部站点各测一遍。4.1 dom.security.https_only_mode 及其配套开关开启之后所有 http 请求在发出前先尝试升级到 https升级失败则弹拦截页由你决定是否继续。user_pref(dom.security.https_only_mode, true); // 主开关优先 HTTPS user_pref(dom.security.https_only_mode_pbm, true); // 隐私窗口同样启用 user_pref(dom.security.https_only_mode_send_http_background_request, false);第三条是争议点。设为 true 时在升级到 https 的同时会在后台补发一次 http 请求用于提速代价是这次明文请求本身构成一次泄露。设为 false 更干净代价是首次访问的握手时间略长。我倾向设 false毕竟开这个开关的目的就是不要明文。实际落地时最常撞上的是内网老系统。很多内部管理页面还在 http 上跑开了这个开关之后直接被拦。处理办法是在拦截页上点“继续访问”浏览器会把这个域名记到例外列表里对应参数是dom.security.https_only_mode.upgrade_on_redirect之外的那个例外集合。判断标准很简单如果某个域名你每天都要点一次“继续访问”就把它加进例外不要为了一个开关把日常工作卡住。4.2 混合内容的两条拦截项https 页面里加载 http 资源叫混合内容。旧教程常说“全部拦截”但现在更合理的是分级处理参数建议值说明security.mixed_content.block_active_contenttrue拦截脚本、iframe 等活动内容security.mixed_content.upgrade_display_contenttrue图片、音视频先尝试升级到 httpssecurity.mixed_content.block_display_contentfalse不建议全部拦截会造成大量图片裂图活动内容必须拦这是硬底线被动内容全部拦截会导致大量老站点的图片、字体加载失败视觉上一片空白反而不如升级策略温和。upgrade_display_content是折中方案能升级就升级升不上去再放行兼顾了安全和可用性。4.3 TLS 版本下限与证书相关user_pref(security.tls.version.min, 3); // 最低 TLS 1.2 user_pref(security.tls.version.enable-deprecated, false); // 不启用回退旧协议 user_pref(security.OCSP.require, false); // 不强制 OCSP 硬失败security.tls.version.min的值3对应 TLS 1.24对应 TLS 1.3。设成 4 更严格但会挡掉一部分还在用 1.2 的内部系统目前在多数环境里设 3 是比较务实的下限。security.OCSP.require设为 true 会在证书状态查询失败时直接拒绝连接安全性最高但在网络抖动或者 OCSP 响应服务器不稳定的时候表现是“网站莫名其妙打不开”。我一般保持 false把可用性留给日常使用。4.4 file_unique_origin 与本地 HTML 工具privacy.file_unique_origin设为 true 之后每个本地文件被视为独立来源本地 HTML 页面无法再通过脚本读取同目录下的其他文件。收益是防止下载的恶意 HTML 读取你本地的其他文件代价是一批本地文档工具、离线手册、单文件应用会失效表现是页面能打开但数据加载不出来。如果日常要用本地 HTML 工具把这一条设为 false同时确保security.fileuri.strict_origin_policy为 true。两台机器两个用途比在一台机器上反复切换省事。5. 避坑与排查改崩了怎么用后悔药救回来参数改多了总会有一次重启之后发现不对劲。这一章记录的是我实际撞过、并且有明确复现路径的几类问题都按“现象、原因、解决”的顺序写遇到同类症状可以逐条比对。5.1 现象改完的值重启后又回到默认这是最高频的一类。你在about:config里明明改了重启浏览器值又变回去了反复改几次都一样。原因通常是配置文件目录里存在user.js。这个文件的优先级高于prefs.js每次启动时会被重新应用一遍你在界面上的修改在下次启动时会被它覆盖。第二种可能是企业下发的策略文件被策略锁定的参数会显示为锁定状态界面上无法修改。第三种是自己记错了改的是另一个配置文件的参数。解决路径先打开about:support找到“配置文件文件夹”点开目录看有没有user.js和policies.json。有user.js就编辑它把要改的值直接写进去而不是在界面上改。查策略打开about:policies如果看到“已启用”的策略条目说明参数被外部锁定界面上改不动是正常现象得从策略源头改。确认参数是否被锁看它在表格里的显示状态——被锁定的行通常有明显标记双击也不会进入编辑态。5.2 现象所有站点都要重新登录多设备同步也断了改完 Cookie 相关参数之后所有网站都退出了登录重新登录之后切个标签页又掉同步功能也提示认证失败表现很像账号出了问题。原因基本锁定在network.cookie.cookieBehavior。设成5跨站隔离之后第三方登录回调拿不到第一方设置的会话登录流程走完但会话没建立。设成2拦截全部 Cookie更彻底所有需要会话的站点全部失效。同步功能依赖跨域认证也会一起挂掉。解决把cookieBehavior降回1重启浏览器重新登录一次验证。如果确实需要用隔离策略就只在特定场景下启用或者对常用站点通过地址栏的盾牌图标添加例外而不是全局开满。5.3 现象后台系统上传附件失败点按钮没反应内部管理系统里点“上传附件”选完文件之后进度条不动控制台里能看到请求返回 403。同一台机器换个浏览器就正常说明不是服务端挂了。原因通常是network.http.referer.XOriginPolicy被设成了2跨站请求不带 Referer而服务端把 Referer 当成来源校验的一部分直接拒绝。另一种可能是privacy.resistFingerprinting打开了UA 被统一成通用值服务端按 UA 分流到错误分支。解决先把XOriginPolicy恢复默认测试上传是否恢复。没恢复再看XOriginTrimmingPolicy把它从2调回0试一次。都不行就临时关掉指纹随机化重新登录再传一次。定位到具体是哪一条之后只保留必要的那一条别为了一个上传功能把整套隐私配置推翻。5.4 现象视频会议能进房间但本地摄像头一直黑屏会议页面正常加载能看到其他人的画面自己这边一直显示摄像头关闭系统层面确认摄像头在工作浏览器权限也给过了。原因就是media.peerconnection.enabled被设成了 false。这条参数禁用整个 WebRTC 通道页面上的设备枚举和媒体采集全部失效表现和硬件故障很像但它其实是配置层面的。解决改回 true重启浏览器重新进入会议。如果确实需要在大部分场景下禁用 WebRTC就只在专用配置文件里关闭不要在同一台机器上开开关关很容易忘了当前处于哪个状态。5.5 现象部分参数在 about:config 里根本搜不到过滤框里输入关键字结果列表是空的而你确定这个参数在别的机器上存在。原因是这个参数在当前版本上还没被写入默认值或者已经被移除、改名。Firefox 的参数表随版本变化旧教程里的参数在新版本上可能已经不存在或者被拆成了两个新名字。解决不要硬找。先在about:config里搜关键字的前半段而不是完整名字很多时候能搜到改过名的新参数。找不到就说明它已经不在配置层或者只在特定平台存在。这种情况宁可不改也不要凭记忆去“创建”一个同名参数——手动新建一个不存在的布尔值不会有任何效果只会让配置文件多一条无效数据日后排查时误导自己。6. 把参数固化成基线user.js 的写法与三档模板手工在界面上点几十次换台机器就得重来一遍这是最没效率的做法。我会把确认过的参数写进配置文件目录下的user.js让它每次启动自动应用。这个文件不需要扩展不需要脚本纯文本改完重启就生效。// user.js 放在 about:support 里的“配置文件文件夹”下 // 每行一条值类型必须与参数本身一致布尔不加引号字符串加引号 user_pref(toolkit.telemetry.enabled, false); user_pref(datareporting.healthreport.uploadEnabled, false); user_pref(app.normandy.enabled, false); user_pref(privacy.trackingprotection.enabled, true); user_pref(network.cookie.cookieBehavior, 1); user_pref(network.dns.disablePrefetch, true); user_pref(network.prefetch-next, false); user_pref(dom.security.https_only_mode, true); user_pref(security.tls.version.min, 3); user_pref(security.mixed_content.block_active_content, true);写这个文件有两个硬性注意点。第一值类型必须对布尔写true/false不带引号整数直接写数字字符串必须带引号类型写错整行会被忽略而且不会有任何提示。第二它每次启动都会覆盖prefs.js也就是说user.js里写了的参数你在界面上改不动——改了下次启动也会被打回去。所以要么全放user.js要么全在界面改别混着来。三档模板我按用途分档位适用机器核心差异保守档办公主力机、跑内部系统只关遥测和跟踪保护不动 Cookie 和指纹均衡档日常浏览、混合用途加 HTTPS-Only、预取关闭、Cookie 设 1激进档纯阅读、专用查询机全量开启含指纹随机化和 WebRTC 关闭验证方法固定三步打开about:config搜其中两三条确认值和你写的一致打开about:support看配置文件夹路径是否正确随便访问一个内部系统和外部站点各一次确认没有出现拦截页或功能失效。三步都过这套基线才算可用。血泪经验是别一次性把激进档推到所有机器上。我吃过一次亏把一个包含 Cookie 隔离的配置批量推下去第二天一半人的统一认证挂掉只能挨个回滚。从那以后我每次改完一批参数都先用about:profiles新建一个干净配置文件验一遍确认没影响再推给整批机器。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助?