为什么「系统代理通了」≠「Firefox 一定跟」
Mozilla Firefox（Gecko）与 Chromium 系最大的工程差异之一是：网络栈可调项更多暴露给 about:config，且自带的 DoH／TRR（Trusted Recursive Resolver）可以完全不使用操作系统解析器就能把查询发到公共 DoH——在你已经用 Clash 接管UDP/TCP 53 或劫持查询到内核的条件下，Firefox 仍可「另起炉灶」，于是你会看到：TCP CONNECT 已在代理日志里出现，但握手阶段拿到的 IP 或与站点所在地区不一致，以及「只有本站 HTML 进来了，CDN 子域名全红」的假性故障。
与此同时，Firefox 仍可读系统代理（由 Clash/V2Ray 等在 Windows/macOS/Linux 下发的 HTTP(S) 上游），但一旦曾经保存过手动代理端口、或使用过第三方「代理切换」脚本，network.proxy.http、network.proxy.ssl、network.proxy.share_proxy_settings 这一类键值会抢先于「系统默认值」起作用，体感就是Firefox 单机不服管——这不是 Clash 「没挂上系统」，而是Firefox 自己又画了一条线。
第一层：关掉 DoH，让 DNS 回到系统链路
请优先走完这一层再给规则集或节点「背锅」。做法二选一即可完成其中一种，不必两道全上（除非你愿意做对照实验）。
图形界面（推荐先试）
打开「设置 → 隐私与安全 →基于 HTTPS 的 DNS」，将 DNS over HTTPS 选为关闭（措辞随版本小异，核心是不要使用 Mozilla ／ Cloudflare／下一跳公共解析自带的 TRR）。
about:config 逐项确认
地址栏输入 about:config，接受风险后检索下列键：
network.trr.mode：设为整数 5，表示不使用 TRR／DoH，让DNS 查询退回系统默认解析链路（从而有机会被 Clash 内核或你的本地转发规则接住）。你若曾开启「增强追踪保护」里兜底的 DoH，也建议在此处显式收口。network.trr.uri：若不再需要，可清空或重置为默认值，避免残留 URI 在某个 profile 重启后再次被策略拉起。
dns 段、Fake-IP 或 fallback 链式时，需要两边读同一套叙事。总览请参考
nameserver、fallback 与 fake-ip-filter；
IPv6／双栈下若仍观察到「绕过代理的解析」，可交叉阅读
IPv6 双栈与直连规则专文。
第二层：对齐 network.proxy 与「使用系统代理」
在完成 DoH 收敛后仍只有 Firefox 异常时，多半是代理模式偏好没有落在「操作系统」这一路。
打开「设置 → 常规 →网络设置」，勾选「使用系统代理设置」（新版本文案可能写作「沿用操作系统的代理」这类说法）。这是最接近「跟其他应用一样去问 Clash 写进去的 HTTP 上游」的配置。
若你在 about:config 里维护过高级项，可按下面自检（每次只改一侧：要么完全信任图形界面重置，要么在 about:config 里成组清理）：
network.proxy.type：0 表示不使用代理；1 表示手动填写主机与端口。若你在「网络设置」里已选「使用系统代理设置」，却仍看到长期停留在手写模式，多半是旧配置或未生效的重启——可先完全退出 Firefox 后再读该值，或新建 profile 只做系统代理勾选做对照。network.proxy.share_proxy_settings：在手动模式下将「全部协议共用同一主机」打开，可避免 HTTP 与 HTTPS 指向不一致。- 若你曾为 SOCKS 或与回环／本地相关的实验项改过其他
network.proxy.*，请先核对你当前走的是 HTTP 上游还是 SOCKS5；仅开启 ClashHTTP 系统代理写入时，Firefox 若在 SOCKS 链路上「半配置」容易出现握手异常。 - 若你曾经「导入过 pac」：
network.proxy.autoconfig_url可能仍然活着；删掉或重置它，再回到系统路径。
如果你在多台机器或 profile 间同步了 prefs.js，也容易出现「台式机正常、笔记本 Firefox 跑偏」的假差异——此时不如新建一个干净 Firefox profile只做系统代理勾选做 A/B。
第三层：门户探测与子资源异常
不少公共 Wi‑Fi、校园网或虚拟机桥接网络会触发捕获门户检测。Firefox 的 NC（Network Connectivity） 相关逻辑若判断「需要先登录门户」，会暂时改变对部分请求的放行策略——有时表现为只对明文 HTTP 探测放行，或对 HTTPS/SNI 混合错误，从而让你误以为「HTTPS 没过代理」，其实是链路被门户页劫持。
about:config 中与诊断相关的键包括：network.connectivity-service.enabled、network.captive-portal-service.enabled。在你确认自己已经用合法合规方式连接到受信任网络的前提下，可临时关掉门户检测插件做对照重启，再结合系统侧「是否被要求二次认证门户」一起看。
若症状是局域网地址、路由器面板、打印机在代理开启后打不开，这既可能是 Firefox不使用系统代理对白名单的实现细节，也可能与内核 Fake‑IP／绕过规则有关——后者见 Fake‑IP 与局域网绕过专文。 若 Clash退出后整网不可达，则更可能是操作系统代理残留：
→ 对照 退出 Clash 后的系统代理与 TUN 清理。
在 Clash 里验证 Gecko 的流量
建议按同一时间窗做两条对比：
- 仅开 Firefox新开隐私窗口访问目标站（可先禁用扩展，避免任何扩展再次改写代理）。
- 在 Clash 连接界面观察源进程或源标签（若内核／客户端暴露该字段）或远端 SNI／Host是否与浏览器地址栏一致。
- 若日志里没有出现对应 Host，却仍能在页面里加载部分内容，十有八九仍是DNS／DoH／旁路 QUIC或未进代理的
websocket—— QUIC 相关问题在「纯 Gecko」里相对少见但并非零，可把现象与 TLS、超时报错一起读：timeout 与 TLS 专文。
「页面测速站的出口 IP ≠ 你认为的节点出口」有时是浏览器侧 WebRTC、mDNS STUN等与代理无关的渠道；若你已关闭 DoH／对齐系统代理却仍看到泄漏感，请同步阅读WebRTC 与浏览器查验，避免把第二层 IP 视图误判成内核规则失效。
当你在 macOS 上同时开过 TUN 与系统 HTTP 写入，若Firefox仍偶发走错接口，可把「Firefox 是否与系统共用同一网络服务顺序」也纳入备忘录，并按 macOS TUN 与代理冲突排查 做一次性排除。
about:config 前先备份 profile，或使用「Firefox Profile Manager」建新配置做对照，避免不可逆的手滑。
结语
Firefox 与 Clash（系统代理模式）并不是天然冲突；真正卡住人的往往是三件小事：DoH/TRR 把 DNS 从系统链路偷走；手写 network.proxy 没回到「系统」这一路；门户检测与子资源异常让你误判成「内核规则错了」。逐项关掉变量、再在连接日志里求一个可被命名的 Host／规则名，比一上来改 YAML 更高效。
相比依赖扩展做二次分流的原生写法，Firefox 给了你更多「能看见的 prefs」——善用它，再配合 Clash 的透明可视性，就能把「半截直连」的问题缩小到一两天内可复述的实测步骤表。
→ 立即免费下载 Clash，开启流畅上网新体验：用单一系统代理链路跑通 Gecko，再在本文基础上扩展你自己的书签式排清单。