症状の読み分け：TCP がプロキシか、DNS が別穴か

まず整理したいのは、ブラウザが「プロキシを使っていない」のか、それともプロキシは通っているが名前解決だけ別ルートなのか、という二階建てです。前者では IP 確認サイトで自宅回線やキャリアの IPv4がそのまま出ます。後者ではページ本文は開ける一方、特定 CDN の名前だけ ISP の DNS に飛び、Clash 側のログには想定外のドメイン問い合わせが少ない、といったパターンが出ます。Clash の DNS 設定とセットで読むと、「どこで名前が決まったか」をログと突き合わせやすくなります。クライアントによってはシステムプロキシ注入と TUN が別トグルなので、GUI の状態も 選んだクライアントの説明に沿って一度棚卸ししてください。

前提：OS のプロキシ欄と Clash の待受ポート

Firefox を触る前に、OS の「手動プロキシ」または「自動構成スクリプト」が、Clash が案内している 127.0.0.1:mixed-port（例：7890）と一致しているか確認します。ここが空欄や別ポートのままだと、Chrome と Firefox の差ではなく単にシステム側が未設定です。逆に OS は正しくても Firefox が手動プロキシ固定の残骸を抱えているケースがあるため、次節以降が効いてきます。TUN モードへ切り替えると、アプリがシステムプロキシを読まなくてもカーネル近傍で拾えるため、「Firefox だけ」との差が縮まることがあります。ただし企業 VPN や別の仮想 NIC と干渉するので、併用時は同じ記事の注意点も読んでください。

Firefox の DNS：DoH／「既定の保護」をオフにする

Firefox は既定でDNS over HTTPS を有効化する流れが強く、これがオンだとOS の DNS／Clash が返した名前解決と別経路になります。設定 → プライバシーとセキュリティ → DNS over HTTPS を開き、まずはオフか「システムの既定を使用する」相当へ寄せて差分を見ます（ラベルはバージョンで若干異なります）。「保護された DNS」「既定の保護」などの文言でも、要はブラウザ独自リゾルバを止めて OS に戻すことが目的です。DoH を業務で必須にされている環境では勝手に無効化できないことがあるため、その場合はネットワーク管理者の方針に従ってください。

ℹ DoH を切ってもページが開くが所在地だけおかしいという説明になることがありますが、それは別軸で WebRTC や漏れ検査サイトの表示仕様が絡む場合があります。HTTP の経路確認と混ぜないようにします。

設定画面：プロキシを「システムに従う」へ

設定 → 一般 → ネットワーク設定の「設定…」を開き、「システムのプロキシ設定を使用する」（英語 UI では Use system proxy settings）を選びます。ここが「手動でプロキシを構成する」になっていると、OS が Clash を指していても Firefox は自分の欄を優先します。企業ポリシーで項目が灰色になる場合は例外です。変更後は一度ウィンドウを閉じて開き直すか、ブラウザを再起動してから再検証してください。

about:config の network.proxy.* を確認する

UI で直したつもりでも、過去の実験や古いプロファイル由来で about:config に食い違いが残ることがあります。アドレスバーに about:config と入力し、承認後に次を順に見ます。network.proxy.type は「システムプロキシを使う」に相当する値（環境により 5 など）へ揃うのが一般的ですが、まずは設定 UI と値が矛盾していないかを確認してください。network.proxy.http／network.proxy.http_port、network.proxy.ssl／network.proxy.ssl_port に古い社内プロキシや別ポートが残っていたらリセットするか、システム追従へ戻したうえで Firefox を再起動します。network.proxy.no_proxies_on に広すぎる例外（ワイルドカードに近い書き方）がないかも見ます。詳細キーはビルドで追加・改名されることがあるため、値をいじるときは一項目ずつ変更して様子を見るのが安全です。

⚠ 注意：about:config は説明のない項目も多く、誤設定でブラウザ全体の通信が止まります。必ずプロファイルのバックアップや、問題が起きたら直せる状態で試してください。

キャプティブポータル検出と接続チェックの DNS

Firefox は Wi‑Fi のログイン確認などに使う接続チェックを行うことがあり、関連する DNS／HTTP がプロキシ設定から外れる挙動が報告されます。切り分け時には network.captive-portal-service.enabled を一時的に false にして挙動が変わるかを見る方法があります（Wi‑Fi のポータル検出が弱くなる副作用があるため、公共のホットスポットでは元に戻す）。あわせて network.connectivity-service.enabled を疑うケースもあります。ここは「HTTPS はプロキシだが、名前解決だけ別々」という部分的症状のときに効くことが多い論点です。

SOCKS 利用時：network.proxy.socks_remote_dns

システムや Firefox が SOCKS5 を直接指定している構成では、名前解決をプロキシ側（リモート）で行わせる network.proxy.socks_remote_dns を true にすることが重要です（設定 UI では「 SOCKS v5 を使用するときにプロキシ DNS を使用」などと表示されます）。HTTP プロキシだけを使う典型的な Clash mixed-port 運用では優先度は下がりますが、手動で SOCKS に切り替えたプロファイルでは必ず確認してください。自分がどのタイプのプロキシを OS に書いているか（HTTP／SOCKS／両方）を先に固定すると迷いが減ります。

それでもズレるとき：TUN・WebRTC・IPv6 とログ

ブラウザ設定を戻しても IP 表示や遅延がおかしいときは、プロキシ以前に別プロトコルが外を見ている可能性があります。WebRTC は代表例です。また IPv4 と IPv6 の二重スタックでは、片系だけが期待経路から外れることがあり、IPv6 と DNS の整理記事とあわせて OS 側のスタックやルールを確認します。Clash 側では接続ビューや ログの読み方で、Firefox からのターゲットがどのポリシーに載っているかを見ると、「ブラウザ設定の問題」か「ルール／ノード側の問題」かを切り分けられます。ルール順そのものを疑う場合は 分流のベストプラクティスも参照してください。

まとめ

Firefox が Clash のシステムプロキシと噛み合わないときは、(1) DoH／保護 DNS を止めて OS リゾルバへ戻す、(2) プロキシ設定をシステム追従にし、(3) about:config の network.proxy.* 残骸を整理する、(4) 必要ならキャプティブポータル検出まわりを一時オフして検証する——の順が実務的です。拡張が別経路を張っている場合は本稿の対象外となるため、先に SwitchyOmega の整理記事へ寄せてください。ブラウザより下の層まで含めて安定させたい場合は TUN も選択肢です。安定したクライアントとバイナリをサイト経由でそろえたい場合は、→ Clash を無料でダウンロードしてから、本記事のチェックリストでもう一度 Firefox だけを切り分けてみてください。