典型现象：为什么总是「Chrome 正常、Firefox 不正常」

在 Windows 与 macOS 上，Chromium 系浏览器通常会尊重操作系统通过 PAC 或固定主机端口下发的代理设置；而 Mozilla 的 Firefox 更强调「用户显式选择网络路径」，出厂默认值并不保证「自动跟系统」。于是你会看到一种非常稳定的组合故障：Clash 已开、系统代理已写入、Chrome 或 Edge 立刻能翻，Firefox 却仍然直连到被墙的目标，表现为超时、RST，或 TLS 在 ClientHello 阶段就失败。

另一类常见误判是：你以为开了 Clash TUN 就「整机透明」，于是 Firefox 里还留着一份手动 SOCKS5，结果流量被送进两层代理链，或 SOCKS 端口其实指向了 HTTP 专用入站，握手一碰就断。排查时请记住一句话：先决定「谁来接管默认路由」，再决定「浏览器要不要自己再找代理」，顺序反了就会陷入「看起来什么都配了，但谁也不生效」的泥潭。

下文所有步骤都假设你已经能正常更新订阅、在至少一个非 Firefox 程序里验证出口可用；若连订阅拉取都不稳定，请先回到下载页核对客户端版本与导入方式，再处理浏览器这一层。

三种网络栈：先选对「谁说了算」

在动手改 about:config 之前，用三十秒把目标模式钉死。你可以把下面三种模式理解成互斥优先级，而不是「全开就更稳」。

模式 Firefox 应怎么设 典型适用
仅系统代理 设置 → 网络设置 →「使用系统代理设置」；不要另填手动 SOCKS 未开 TUN、只靠 Clash 写入系统代理；希望与 Chrome 行为一致
仅 SOCKS5（或 HTTP 手动） 选手动代理，SOCKS 主机 127.0.0.1，端口填客户端标明的 SOCKS 入站 不想动系统代理、或系统代理被组策略锁定；Firefox 单独走本地环回
Clash TUN 与系统代理并存 TUN 负责路由层；Firefox 优先「无代理」或「使用系统代理」二选一，避免双栈 SOCKS 需要游戏、终端与浏览器同策略；已读TUN 专文并完成权限与 DNS 自检

如果你当前的真实状态是「TUN 已开 + Firefox 里还填了 SOCKS5 + Clash 同时勾选系统代理」，建议先把 Firefox 手动代理清空，只保留「使用系统代理设置」或「无代理」之一，再进入后面的六步。否则你很难从现象反推究竟是内核规则没命中，还是浏览器自己在环回上绕圈。

合规提醒 使用代理访问受地域或版权限制的服务可能违反服务条款或当地法规。本文仅作网络栈与客户端排错说明，请自行评估合法合规性。

第 1 步：在 Clash 里写下「三个数字」——HTTP、SOCKS、mixed

打开你所用的 Clash 系客户端连接信息页，把本机入站端口抄在便签上：是否存在 mixed（常见如 7890 同时承载 HTTP 与 SOCKS）、是否单独拆出 HTTP 与 SOCKS 两个端口。Firefox 手动填 SOCKS 时，最容易犯的错误就是把「看起来像主端口」的数字填成实际只监听 HTTP 的那一格，结果 SOCKS 握手一上来就被拒绝。

若你打算走「仅 SOCKS5」路径，请同时确认客户端是否勾选允许局域网（Allow LAN）之类选项——在部分发行版里，仅监听 127.0.0.1 与监听所有接口的行为会影响本机其他用户配置，但对单用户桌面 Firefox 通常不是首因，仍建议保持默认「仅本机」即可。

这一步的目标很简单：保证你接下来在 Firefox 里填的每一个端口，都能在客户端日志里看到对应协议真正在监听。数字没对齐，后面改再多 about:config 也是沙上盖楼。

第 2 步：Firefox 设置页——从「不使用代理」切到正确模式

进入 Firefox「设置」→「常规」→ 滚动到「网络设置」→「设置」。若你期望跟 Chrome 一样走操作系统代理，请选择使用系统代理设置。这是多数「Chrome 能翻 Firefox 不能」场景的止血点：默认安装里，用户或某些「隐私向导」一键脚本可能把 Firefox 留在「不使用代理」。

若你选择手动代理配置，请只填与你目标一致的一项：要走 SOCKS5，就确保类型为 SOCKS v5，主机为 127.0.0.1，端口为第 1 步核对的 SOCKS 入站；HTTP 与 HTTPS 代理栏是否一并填写，取决于你是否希望页面子资源走不同协议栈——对 Clash 用户更常见的简洁做法是「只配 SOCKS5，并勾选『使用 SOCKS v5 时代理 DNS』」，让域名解析也经代理侧完成，减少本地 DNS 泄漏与解析环路。

改完后不要只凭「能打开百度」判断成功；请用与你真实需求同域名的 HTTPS 站点复测，并观察是否仍有「部分资源直连」导致的半白屏。半白屏往往提示你还有 DoH 或扩展在改 DNS，而不是主文档代理本身失效。

第 3 步：DNS over HTTPS 与「通过 SOCKS 查询 DNS」不要打架

Firefox 内置的 DNS over HTTPS（DoH）会在应用层绕过系统解析路径。若 DoH 上游不可达、或被公司网络拦截，你会看到「地址栏显示已连接，但页面卡在第一步解析」的假死。此时即便 SOCKS5 配对了，也会表现为「代理开了等于没开」。建议在排障窗口暂时关闭 DoH，回到系统解析或交给 Clash 侧 DNS，确认主路径畅通后再逐步恢复隐私增强。

与 Clash TUN 并存时，还要避免「TUN 劫持 DNS + Firefox 仍强制 DoH 到公网」这类双通道竞态：两者并非不能共存，但需要你对上游可达性心里有数。更稳妥的排障顺序是：先关 DoH → 验证页面 → 再开 TUN → 再决定是否恢复 DoH。这与我们DNS 专文里强调的「先定 DNS 再谈规则」是一致的。

第 4 步：核对 Clash TUN——Firefox 流量有没有进内核

当你启用 Clash TUN 后，理论上 Firefox 与 Chrome 一样走系统路由，不必再单独配置浏览器代理。若此时 Firefox 仍异常，优先怀疑的不是「Firefox 特殊」，而是TUN 未真正接管、规则把目标域名送错组、或 DNS 环路。请打开连接日志，在复现问题时观察是否出现目标域名的连接记录、策略组命中是否符合预期。

若日志里完全没有浏览器访问记录，而 Chrome 有，才回到 Firefox 侧查「是否仍强制无代理」。若两条浏览器都有记录，但 Firefox 单独失败，更像 TLS 或证书类问题：检查是否装了抓包根证书、企业中间人、或扩展注入了冲突的代理脚本。

Windows 上若 UWP 或商店类应用曾让你折腾过回环豁免，可对照《Windows 11 UWP 与 Clash》里关于系统代理与 TUN 的并存顺序；虽然 Firefox 不是 UWP，但「系统里还有另一层代理或过滤驱动」时的症状是相似的。

第 5 步：about:config——把被脚本改坏的代理键位拉回正轨

在地址栏输入 about:config，接受风险提示后，按关键字过滤以下条目（不同版本键名可能略有增减，以你本机显示为准）。核心思路是：让 network.proxy.type 与你在设置页选择的模式一致，并避免残留的旧主机与端口。

  • network.proxy.type：常见为 0（直连）、1（手动）、2（PAC URL）。「使用系统代理」在不同版本与平台上对应的整数值可能不同，请以当前版本文档为准；切换 UI 时观察该键是否随之变化。若 UI 已选系统代理而此处仍为 0，多半有策略、用户脚本或扩展在覆盖。
  • network.proxy.socks 与 network.proxy.socks_port：走 SOCKS 路径时与 UI 一致；改完建议重启 Firefox，避免热切换缓存。
  • network.proxy.http / network.proxy.ssl：若你只打算用 SOCKS，可保持与 UI 同步或留空，避免一半流量走 HTTP 代理栏里的陈旧 IP。
  • privacy.resistFingerprinting：在部分版本与场景下会影响环回与端口行为。若你近期为隐私打分开启过它，可临时回默认后复测代理问题是否消失，再决定是否以其他方式替代。

不建议在不明所以的情况下「恢复全部默认」——更可控的做法是逐项截图备份、单键回滚。企业环境若存在策略锁定，about:policies 页面会显示由管理员注入的网络相关策略，此时本地改 UI 可能被秒级覆盖，需要先与策略提供方对齐。

第 6 步：用连接日志做「验收」——别凭感觉

最后一步是把问题从「我觉得好了」变成「日志证明好了」。在 Clash 连接面板或日志里，过滤你刚访问的站点域名或 IP，确认策略组、链路与出口与你设计的一致。若使用 Fake-IP，还要接受「日志里先出现 fake 地址、再映射到真实域名」的阅读习惯，避免误判为「没走代理」。

建议准备一张小小的对照表：同一台机器上，Chrome 访问同一 URL 与 Firefox 访问同一 URL，在相同节点与相同模式下，日志条目是否只有进程名不同而策略命中一致。若 Chrome 命中代理组、Firefox 命中直连组，则几乎可以断定仍是浏览器代理或 DNS侧把流量送到了不同路径，而不是节点质量问题。

验收通过后，再把第 3 步里临时关闭的 DoH、或第 5 步里为排障改动的隐私项，按「一次只恢复一项」的原则加回去。每恢复一项就重复一次短验收，未来你自己也能快速定位「是哪一次改动让 Firefox 又掉队了」。若你希望把规则写得更细，可继续阅读《YAML 规则分流指南》，把浏览器与其他应用的分流统一进同一套策略哲学里。

常见问题（与 JSON-LD 一致）

Chrome 已经能翻墙，为什么只有 Firefox 还在直连？

Chromium 默认更顺从系统代理；Firefox 需要你在网络设置里显式选择「使用系统代理设置」或正确的手动 SOCKS。另有一些隐私类配置会影响环回与本地解析，表现为只有 Firefox 掉队。

开了 Clash TUN 以后，还需要在 Firefox 里再开「使用系统代理设置」吗？

TUN 解决的是路由层；浏览器层再叠 SOCKS 容易造成双通道。推荐在 TUN 稳定后，让 Firefox 选「无代理」或「使用系统代理」之一，不要与手动 SOCKS 混用，除非你非常清楚自己在做端口映射或链式代理。

Firefox 里填 SOCKS5 时，端口应该写 7890 还是 7891？

写你客户端里标为 SOCKS 或 mixed 的真实监听端口，而不是凭记忆猜。HTTP 与 SOCKS 端口拆分发行版时，填错一格就会握手失败。

about:config 里哪些项最容易把 Firefox 从代理路径上拽下来？

除 network.proxy.type 外，关注 SOCKS 主机端口键位、DoH、以及 privacy.resistFingerprinting。逐项回滚并重启验证，比一次性重置更安全。

小结：先排「栈顺序」，再改「单点参数」

Firefox 与 Chrome 对待系统代理的默认哲学不同，这不是谁的 bug，而是产品取舍。你已经为整台机器付过学习成本去配 Clash TUN 与订阅，就不值得再在浏览器里用「随手填的端口」把结论搅浑。把「仅系统代理 / 仅 SOCKS5 / TUN 并存」先选清，再按六步从端口、设置、DNS、TUN 日志、about:config 到验收走一遍，大多数「一机两浏览器表现不一致」的案子都能落地到具体键位或具体策略组。

相比在论坛里碎片化搜答案，把 Clash 系客户端与规则维护在同一生态里，长期成本往往更低。全平台安装包与免费订阅链接的维护入口在本站下载中心；把客户端版本与订阅源先稳住，再折腾浏览器细枝末节，会省掉大量无效试错。

→ 立即免费下载 Clash，开启流畅上网新体验

更多排查与分流文章见技术专栏。