一、为什么「系统其它程序已走代理」不等于 Firefox 一定走代理

Firefox 并非简单封装系统网络 API：在勾选使用系统代理设置时，它会读取当前操作系统记录的 HTTP/HTTPS 代理与例外列表；在选择手动代理配置时，则由浏览器进程内的 network.proxy.* 系列偏好驱动，这两套路径不会自动互相纠错。与此同时，Clash 客户端常见混合端口（mixed）同时承载 HTTP 与 SOCKS，若你在 Firefox 里只填了 HTTP 代理栏却实际期望走 SOCKS5，或端口填成了 7890 与内核真实监听不一致，表象就是「别的软件正常、Firefox 单独失灵」。

此外，TUN 模式在路由层接管流量，理论上不要求每个应用单独填写代理；但若 Firefox 启用了强制 HTTPS、DoH 或某些隐私扩展对请求做了改写，仍可能出现策略分裂：DNS 解析走了加密通道，TCP 连接却因规则命中不当表现为直连或反复失败。排查时应避免先看「是不是节点慢了」，而应先确认浏览器意图的出口类型与内核侧观测是否一致。

二、Clash 侧先对齐：监听地址、mixed 与 SOCKS5 端口

在改 Firefox 之前，请在客户端或配置中确认：socks-port、mixed-port（或端口转发 UI 中的等价项）、以及bind-address是否为 0.0.0.0 或仅 127.0.0.1。若 SOCKS 仅监听环回地址且 Firefox 被装在沙箱或远程会话中，需要同步核对是否能访问该 IP。

常见配对方式是：Firefox「手动代理」里 SOCKS 主机填 127.0.0.1，端口填与 Mihomo 订阅面板一致的 SOCKS 或 mixed 端口；SOCKS 版本选 SOCKS v5。若同一端口在文档里标注为 mixed，通常仍可接受 SOCKS5 握手，但请以你所用内核与客户端组合的实际表现为准——若握手失败，优先改用明确的 socks-port 或在客户端开启允许局域网连接类选项后再仅绑定本机。

需要路由层统一接管时，可读《Clash TUN 模式开启方法》：启用 TUN 后，Firefox 即使不显式填代理，也应能在连接面板中看到访问目标域名随策略走代理或直连；若仍大量 DIRECT，说明问题在规则/DNS而不是浏览器表单。

三、设置界面：手动代理与「使用系统代理设置」二选一认知

打开 Firefox「设置 → 网络设置」，你会看到几种模式：

  • 不使用代理：明确直连；若此时仍能翻墙，多半来自 TUN、系统级 VPN 或其它注入，而不是 Firefox 自身表单。
  • 使用系统代理设置：依赖操作系统「Internet 代理」或 macOS/桌面环境的系统代理项；Clash 若仅注入用户空间代理而未写入系统代理，Firefox 这一栏可能读不到任何代理，表现为直连。
  • 手动代理配置：HTTP/HTTPS/SOCKS 分流填写；对 Mihomo 用户而言，统一走 SOCKS5往往比拆 HTTP/HTTPS 更少踩坑，前提是端口与版本配对正确。

若你刚从 Chrome 换过来，请记住：Chrome 在多数桌面环境上高度依赖系统通道或自身策略，而 Firefox 代理设置在 UI 层与 about:config 层可能并存覆盖关系；修改一处后应用重启或清空会话有时才能稳定生效。

四、about:config：建议逐项核对的核心键（名称以当前版本为准）

在地址栏输入 about:config，接受风险提示后，可按下列方向检索（不同大版本偏好键可能更名，若检索不到请以官方文档为准）：

  • 代理类型：network.proxy.type —— 取值含义通常包括：无代理、手动、PAC、系统代理与若干自动探测模式；若此处被策略文件或企业策略锁定，你在 UI 里改的选项可能被覆盖回滚。
  • SOCKS：network.proxy.socks、network.proxy.socks_port、network.proxy.socks_version —— 与 Clash SOCKS5 监听对齐；端口错误是最常见人为失误。
  • 共享与例外：network.proxy.share_proxy_settings、各类 no_proxies_on 或绕过列表 —— 局部主机名被放进绕过代理时，会出现「同一浏览器内有的站点走代理、有的直连」。

若存在自动化配置（PAC）或遗留的「自动检测」，可能与手动 SOCKS 并存冲突；此时建议暂时改为纯手动以便对照实验，再回到 PAC 方案。

五、DNS over HTTPS（DoH）与代理：两条并行路径

Firefox 可在设置 → 隐私与安全 → HTTPS DNS 中启用 DoH。启用后，域名解析可能不经由你在 Clash 里为直连配置的 DNS 逻辑，而是走向浏览器选定的 DoH 提供商；这与内核 fake-ip、订阅分流里的域名规则叠加时，易出现解析结果与应用连接不一致的体感：网页空白、证书报错或间歇性超时。

实测排查顺序建议：在对照试验中暂时关闭 DoH 或改为「默认」，观察连接日志里对应主机名是否恢复稳定命中；确认路径清晰后，再按需把 DoH 与Mihomo DNS策略对齐，而不是同时开启多套互相不透明的解析通道。

六、扩展与「仅限浏览器」的代理插件

SwitchyOmega 类扩展、广告拦截、隐私套件有时自带代理配置文件或强制直连规则，优先级可能高于你在 Firefox 全局设置里填写的内容。表现为：无痕窗口正常、普通配置档异常，或个别域名永远直连。

务实做法是：禁用所有扩展做一次最小复现；或使用全新配置文件（配置文件管理器新建空白 profile）仅安装 Clash、不设扩展，再比对差异。企业环境中还需留意策略管控是否禁止用户改写代理。

七、TUN 与系统代理：两条验收路径怎么选

系统代理路径下，Firefox 勾选「使用系统代理设置」应与操作系统面板中由 Clash 写入的 HTTP/HTTPS 代理一致；适合不想改浏览器、希望多应用共享同一 PAC/系统项的用户场景。

TUN路径下，期望应用无感走策略路由；此时 Firefox 即便关闭手动代理，也应由虚拟网卡把流量送进 Mihomo。若 TUN 已开却仍像直连，优先回到内核日志核对目标进程与域名是否进入隧道，而不是反复切换 Firefox 表单。

与终端环境变量类代理（参见站内《macOS 终端与 Clash 代理环境变量》）相比，浏览器栈更复杂：**终端通了不代表 Firefox 同一参数**，反之亦然；请分通道验收。

八、可复制自检清单（建议自上而下执行）

  1. 内核侧：确认 Clash 进程运行、端口监听与当前生效配置（非僵尸编辑器缓冲）。
  2. 浏览器表单：核对 SOCKS 主机、端口、版本；或与系统代理选项联动一致。
  3. about:config：确认 network.proxy.type 与 UI 预期一致，无 PAC/策略残留打架。
  4. DoH：做一轮开关对照，观察解析与连接日志是否同步改善。
  5. 扩展与配置文件：最小化启用或换新 profile 排除扩展劫持。
  6. TUN 对照：开启 TUN 与关闭 TUN 各测一轮，记录内核日志差异与浏览器出口 IP。

九、如何验收「真的走了 Clash」

避免只看某一测试页结论：建议同时观察出口 IP、DNS 泄漏面板（若使用）以及 Mihomo 连接面板中对应域名的策略命中。若网页显示已代理而内核无会话，可能是缓存页面或扩展伪造结果；若内核大量直连而浏览器显示代理，优先怀疑分流规则把站点打在 DIRECT。

更系统的共性报错也可对照《Clash 常见报错与排查指南》，把端口占用、订阅失效与内核启动失败先排除，再回到 Firefox 专属叠加因素。

使用代理访问网络可能受当地法律法规与服务条款约束。本文仅讨论浏览器网络栈、端口配对、DNS 与分流观测等工程技术问题，不构成任何违法用途指引；请在合法合规前提下阅读与实践。

十一、小结

Firefox 上的「代理未生效」多数是表单里的 SOCKS5 端口与地址与 Clash SOCKS5 真实监听不一致、系统代理未被写入、about:config 残留 PAC/类型冲突，或 DoH 与扩展改写路径叠加所致。先把TUN与内核日志当作地面真相，再把Firefox 代理设置调到与之相容，通常比盲目更换节点更快收敛。相比零散试错，成熟图形客户端在 Mihomo 内核上的连接记录与规则编辑一体化，长时间排查场景里往往更省心。→ 立即免费下载 Clash，开启流畅上网新体验