Why Firefox disagrees with “the system already uses Clash”
Unlike Chromium-derived browsers that lean heavily on the operating-system proxy hooks on each platform, Firefox historically maintained its own network configuration surface: manual HTTP, HTTPS, SOCKS (with SOCKS4 versus SOCKS5 toggles), auto-detect PAC, and per-connection DNS behavior that can diverge from what captive portal services or DHCP advertise. Enterprises relied on those knobs long before ubiquitous VPN tunnels, meaning power users routinely set explicit loopback proxies even when laptops report “No proxy.” When you install a Mihomo-compatible client exposing a mixed inbound on 127.0.0.1, you must reconcile two facts: your operating system profile may funnel traffic globally through TUN adapters, yet Firefox might still obey an older pinned manual SOCKS host or PAC URL stored in prefs.
Another nuance hides in mixed ports: modern Clash forks expose simultaneous HTTP CONNECT and SOCKS5 endpoints on adjacent ports—or collapse them depending on YAML. Plugging HTTP proxy semantics into SOCKS fields (or reversing the mapping) silently fails: sessions appear to handshake but selectors never steer you through the outbound you expect.
Step 1 — Match Firefox manual proxy to Mihomo SOCKS5 localhost
Open Clash Verge Rev, Clash.Meta GUI, or your bare Mihomo systemd unit and jot down inbound addresses. Typical patterns include SOCKS5 on port 7891 and mixed HTTP/SOCKS on port 7890, although your profile may remap them. Inside Firefox preference UI (about:preferences#general → Network Settings), enable manual proxy and point SOCKS Host to 127.0.0.1 while mirroring your listener port. Double-check SOCKS version selectors: SOCKS5 aligns with Mihomo SOCKS proxy lines; SOCKS4 seldom applies.
Some users mistakenly fill only “HTTP Proxy” while disabling SOCKS; Firefox treats them independently. Mixed ports accept HTTP CONNECT, so referencing http://127.0.0.1:7890/-style proxies also works—but Clash SOCKS5 remains the tighter match when QUIC or HTTP3 layers misbehave behind CONNECT-only relays. Prefer parity with how you configure terminal tools referencing SOCKS5 localhost; our macOS shell environment guide parallels the rationale when matching export variables to Mihomo listeners.
After edits, reopen a private window (Ctrl+Shift+P / Cmd+Shift+P) before testing caches: normal profiles may cling to speculative connections until restart.
Step 2 — Cross-check prefs with about:config for hidden overrides
Navigate to about:config and filter network.proxy. Confirm network.proxy.type: manual maps to numeric 1; 0 means direct; 2 indicates PAC; 4 aligns with conditional system proxy usage depending on version. Rogue enterprise policies occasionally force network.proxy.share_proxy_settings off-sync with the Preferences UI.
Validate network.proxy.http, network.proxy.ssl, network.proxy.share_proxy_settings, and network.proxy.socks strings line up—typos like stray whitespace break lookup. Inspect network.proxy.allow_hijacking_localhost contexts when chaining multiple VPN layers intercept loopback unusually.
If you experimented with SOCKS remote DNS forwarding, scrutinize network.proxy.socks_remote_dns; toggling it changes whether DNS queries ride the SOCKS tunnel—a critical interplay when diagnosing “wrong country but HTTPS works.” Pair these checks with the broader playbook in our Clash troubleshooting guide so resolver behavior lines up alongside rule evaluation.
Step 3 — System proxy inheritance versus Firefox-only proxies
Windows “Use system proxy settings” leverages WinINet-derived configuration; Firefox consults whichever profile the OS advertises—including WPAD-derived PAC when enabled. Mihomo dashboards often expose a “Set system proxy” button that aligns WinHTTP proxies with local listeners—but toggling that option does not magically rewrite Firefox prefs if Firefox already locked manual SOCKS entries. Harmonize deliberately: switch Firefox to automatic system adoption only after Mihomo asserts the underlying Windows LAN settings point at 127.0.0.1 with your mixed port.
On macOS, System Settings → Network → Wi-Fi/Ethernet detail → Proxies may list HTTP/HTTPS proxies toward Clash listeners. Gatekeeper-signed GUI apps respecting system proxies line up—but Firefox retains independent toggles unless you unify them.
Linux desktop mixes NetworkManager dbus properties, KDE proxy modules, GNOME Proxy mode, plus flatpak portals; Firefox reading “Use system proxy” may still surprise you if SNAP or Flatpak sandboxing restricts reading host settings. Matching explicit SOCKS on 127.0.0.1 avoids fighting desktop integration layers altogether.
Step 4 — DNS-over-HTTPS (Firefox DoH) versus split DNS stacks
Even when TLS flows exit properly through SOCKS, resolver answers may originate upstream of your tunneled vantage if DoH points at resolver clusters outside your Mihomo outbound. Disable DoH briefly under about:preferences#privacy → DNS over HTTPS—or set “Increased Protection” without custom providers—to see whether CDN mapping shifts. Conversely, aligning DoH endpoints with proxies that share your exit avoids mismatch between DNS-informed routing and transport routing.
Watch Firefox DoH interplay with ECS and EDNS caching: geographically distant answers may degrade streaming handoffs even though HTTP requests proxy correctly.
Step 5 — Extensions, PAC files, and auto-configuration scripts
Extensions such as Omega Switchy or privacy suites sometimes inject per-tab proxy swaps. Visit about:addons, disable suspects, then retest minimal profiles. Inspect network.proxy.autoconfig_url; stale corporate PAC blobs still respond with DIRECT for subsets of hosts intentionally.
Container tabs (Firefox Multi-Account Containers) may pin distinct proxy presets per identity—verify isolation if only some containers misroute traffic.
When diagnosing PAC scripts, temporarily download the referenced file and search for literals such as return "DIRECT" against your target host patterns; large enterprises wrap hundreds of lines of legacy logic that might exclude entire top-level domains you believe should proxy. Keep a scratch note with the PAC URL you expect versus the one Firefox actually resolved after caching—stale DNS answers to wpad.yourdomain often explain intermittent bypasses that vanish after ipconfig /flushdns on Windows or sudo dscacheutil -flushcache on macOS.
Step 6 — TUN mode versus explicit SOCKS in Firefox
TUN mode moves transparent forwarding into the kernel path so naive applications ignorant of proxies still traverse Mihomo—even when localhost listeners stay idle—assuming policies include your destinations. Explicit Firefox proxies duplicate intent: both may coexist, but diagnosing becomes confusing when overlapping double-hop or split-DNS regressions emerge. Decide on a deliberate strategy:
- Tunnel-first desktops: Keep Firefox on “Direct / system” after enabling TUN, letting global policies decide; confirm no leftover manual SOCKS persists in prefs.
- Mixed workstations: Keep explicit SOCKS pinned for Firefox-only experiments while Chromium uses system proxies—maintain Mihomo inbound ports stable between them.
Consult our focused Clash TUN mode guide for ICMP caveats and administrator elevation quirks that still affect QUIC fallbacks Firefox negotiates underneath HTTP versions.
Step 7 — Evidence Mihomo receives Firefox flows
Enable verbose logging temporarily in Mihomo dashboards: watch process names versus remote SNIs whenever Firefox opens YouTube test pages streaming googlevideo.com edges. Matching timestamps with browser network panel (Ctrl+Shift+E) distinguishes DNS timing issues from stalled TLS handshakes.
- Close other browsers; open one tab to
https://ifconfig.mebehind SOCKS only—note IP. - Toggle SOCKS remote DNS pref; rerun; compare IP/country deltas.
- Disable TUN, rely solely explicit SOCKS—confirm Mihomo inbound charts tick upward.
- Re-enable system proxy bridging; reconcile Windows LAN settings referencing
127.0.0.1:<mixed>.
When SOCKS traffic never hits Mihomo listeners, antivirus HTTPS inspection or captive-portal interception may wrap connections before localhost—whitelist Clash binaries or temporarily pause SSL scanning for diagnosis.
Windows loopback guardrails and cloned Firefox profiles
On Windows, confirm netsh winhttp show proxy matches what your Mihomo GUI reports after you click “Set system proxy.” Firefox only mirrors those values when you choose “Use system proxy settings”; if manual SOCKS remains active, WinHTTP output is irrelevant for Mozilla but still helps you understand whether other subsystems align. When loopback inspection tools block 127.0.0.1 connections unless signed with a local CA, flip the antivirus setting that exempts browser-to-localhost TLS or pause web shielding briefly while you capture evidence in Mihomo—otherwise you stare at contradictory packet captures forever.
Multi-profile setups deserve separate inventories: bookmarks sync across profiles, yet prefs.js clones may carry divergent SOCKS strings if you migrated from tarball backups copied between machines. Duplicate profiles amplify confusion when one inherits enterprise policy while personal profiles stay manual—open about:support and skim Important Modified Preferences for anything beginning with network.proxy; paste suspect lines beside your Mihomo inbound table when asking maintainers or filing issues upstream.
Containers, Profiles, Nightly regressions
Firefox Developer Edition or nightly channels sometimes flip networking experiments behind about:flags-adjacent prefs; create a pristine profile (firefox -ProfileManager) if corruption persists beyond toggles noted above.
Enterprise-managed deployments injecting policies.json overrides may forbid manual SOCKS; consult IT documentation before escalating.
Common misconfiguration patterns we still see daily
- SOCKS entry references port
7890HTTP mixed port expecting SOCKS handshake semantics—the session stalls until corrected. - IPv6 egress bypasses SOCKS while IPv4 obeys; disable conflicting IPv6 global routes transiently.
- Warp or cloud VPN overlays another default route above Mihomo adapters—traffic never reaches SOCKS listener.
- Corporate root MITM appliances expect HTTP proxies with installed roots; SOCKS setups fail certificate pinning on specific sites though others load.
Summary
Aligning Firefox with Mihomo proxy flows is seldom a single checkbox—it is the intersection of typed listener ports (Clash SOCKS5), about:config truthfulness, deliberate system proxy adoption versus manual overrides, Firefox DoH choices outside your tunnel, extension orchestration, and whether TUN mode replaces or duplicates explicit SOCKS bridging. Iterate with logging turned on rather than blindly flipping subscription groups; once SOCKS rows appear with correct process hints, polishing split rules matters again.
Compared with opaque routers that conceal hop-by-hop telemetry, Mihomo-compatible clients emphasize transparency so you reconcile browser prefs with observable connections. Ready to unify listeners with approachable dashboards and fewer YAML pitfalls? Start from our curated channel rather than scattering download links across issue trackers.