症状の型：Chrome と Firefox で何が違うか
切り分けの出発点は、次のどれに近いかを一文で決めることです。第一に、Firefox だけ特定サイトが開かない が、同じマシンの Chromium 系では開ける。第二に、Firefox の設定画面では 「システムの設定を使用する」 と表示されているのに、開発者ツールやルーター側の見え方では ISP 直の経路のままである。第三に、過去に試した 手動 SOCKS5 のホストやポートが残っており、Clash 側のポート変更と食い違っている。第四に、Clash の TUN をオンにすると急に全体が不安定になるため、Firefox だけ別設定に逃げようとして二重化している。
Chromium 系は OS のプロキシ設定に追従しやすい一方、Firefox は歴史的に 独自のプロキシ UI と about:config を持ち、プロファイルやポリシー、拡張機能（例：プライバシー系）が 上書き することがあります。だから「OS のシステムプロキシは Clash が正しく書き換えている」ことを確認できても、Firefox がその層を読んでいない ケースが普通に起きます。ここを飛ばして YAML のルールだけを疑うと、時間が溶けやすいので、本稿ではブラウザと OS と Clash の 責務の境界 を先に固定します。
ステップ1：設定画面で「プロキシなし」を一度明示し、システム設定へ戻す
まず Firefox の 設定 → ネットワーク設定（設定の一番下） を開きます。ここで 「プロキシなし」 を選んで一度 OK を押し、タブを閉じてから同じ画面を再度開き、「システムのプロキシ設定を使用する」（表記はバージョンにより微妙に異なります）へ戻します。古い手動値が UI に見えていなくても、内部状態が中途半端に残っていることがあるため、明示的なリセットの往復 が効く場面があります。
続けて、Firefox を 完全終了 させてから起動し直します。Windows ではバックグラウンドの更新タスクが残りがちなので、タスクマネージャでプロセスが消えたかを一瞥すると安心です。macOS では Dock の終了に加え、必要ならアクティビティモニタで確認します。この段階で Chromium 側が問題なく通るなら、OS の システムプロキシ 自体は生きている可能性が高く、以降は Firefox 側の上書き要因を潰すフェーズです。
ステップ2：about:config で network.proxy 系を実値確認する
アドレスバーに about:config と入力し、警告を承認したうえで、次のキーを順に検索します。第一に network.proxy.type。一般的に 0 はプロキシなし、1 は手動、2 は PAC、5 はシステムプロキシを使用（環境により表が異なる場合があるため、UI の説明文と突き合わせてください）。ここが 1 のまま固定されていると、設定画面の文言と実態が食い違います。
第二に network.proxy.http、network.proxy.ssl、network.proxy.socks などの 手動ホスト が空でないか。過去の実験で 127.0.0.1 が残り、今の Clash のポートと一致していないパターンは多発です。第三に network.proxy.socks_version が期待どおりか。第四に企業環境向けの network.proxy.autoconfig_url が残っていないか。これらはいずれも ブラウザプロキシ の実体なので、ここを掃除してから Clash の システムプロキシ へ寄せ直すと効果が出やすいです。
値を変える前に、スクリーンショットやメモで元値を残しておくと安全です。複数プロファイルを使っている場合、仕事用プロファイルだけ別値になっていることもあるため、症状が出ているプロファイル で作業しているかも確認してください。
ステップ3：システムではなく「手動 SOCKS5 のみ」で揃える場合の順序
会社ポリシーや一時検証で、Firefox だけ Clash のローカル SOCKS に載せたい場合は、システムプロキシよりも 手動指定の方が意図が明確 になります。手順は次のとおりです。第一に Clash クライアントの画面か設定 YAML で、SOCKS ポート（mixed ポートではなく SOCKS 側の数値）を確認します。第二に Firefox のネットワーク設定で 手動でプロキシを設定 を選び、HTTP／HTTPS 欄は空にするか、意図的に同じ 127.0.0.1 とポートへ揃えるかを方針決めします。第三に SOCKS ホスト に 127.0.0.1、ポートに確認した値、種別に SOCKS v5 を指定します。
第四に about:config で network.proxy.socks_remote_dns を true にします。名前解決がローカルに残ると「ブラウザはプロキシを通しているのに見た目だけ直結」に近い挙動が出るため、SOCKS 運用ではこの値が重要です。第五に、この構成は Firefox 以外のアプリには効きません。同時に Clash の システムプロキシ も有効だと、二重に経路が掛かると誤解しやすいので、検証中はどちらか一方に寄せるか、意図をメモに残してください。
ルールの書き方や購読ルールとの順序は Clash YAML ルール分流ガイド を参照しつつ、Firefox から出ているホストがログに載っているかを確認すると安心です。購読リンク（サブスク URL）で取り込んだプロファイルを更新した直後だけ症状が変わる場合は、カスタム追記が購読側の RULE-SET に負けていないか もあわせて見ます。
ステップ4：DNS over HTTPS と Clash DNS の取り合いを切る
Firefox は DNS over HTTPS をブラウザ内で完結させる選択肢があり、Clash の fake-ip やローカルの DNS ハイジャック と組み合わさったときに、Chrome とは違う症状だけが出ることがあります。設定のプライバシーとセキュリティから DNS の項目を開き、検証中は一旦 オフ もしくは 既定のみ に寄せ、症状が変わるかを見ます。
Clash 側では dns: ブロックの enhanced-mode や nameserver の構成が解決順に影響します。ブラウザの DoH をオンにしたまま TUN と併用すると、「HTTPS のサイト本体は通るが特定 API だけ失敗」などに見えることがあるため、Firefox の DNS 設定を一段シンプルにしてから もう一度アクセスを試すのがこのステップの狙いです。詳細な理屈は Fake-IP と Redir-Host の記事 に譲り、本稿では Firefox だけ例外 という切り口に絞ります。
ステップ5：Clash TUN をオンにして「ブラウザ設定より OS を信じる」状態へ
ここまでで Firefox を システムプロキシ か 手動 SOCKS5 のどちらかに揃えても改善が限定的なら、TUN モード を検討します。TUN は仮想 NIC を通じて OS のルーティングに乗るため、Firefox がシステムプロキシを読み損ねていても、多くの TCP／UDP が Clash のポリシーに載りやすくなります。手順のイメージは次のとおりです。第一に Clash クライアントで TUN／仮想アダプタ を有効化し、管理者権限やセキュリティソフトの許可が必要なら従います。第二に、既存の別 VPN やフィルタドライバと競合していないかを確認します。
第三に TUN 有効化直後に 全アプリがオフライン に見えたら、まず TUN をオフにして復帰できるかを確認し、DNS やスタック競合を疑います。第四に安定したら Firefox を システム設定使用 に戻し、ログで主要サイトのホストが期待のポリシーに乗るかを見ます。Windows 11 で UWP やループバックが絡む場合は UWP と localhost ループバックの記事 も参照すると、似た層の混乱を避けられます。
ステップ6：ログ検証と拡張機能・コンテナの最終確認
最後に、Clash の接続ログで Firefox からのホスト が流れているか、ポリシー名が想定どおりかを確認します。ここで何も増えない場合は、Firefox が別プロファイルで動いている、プライベートブラウジング専用の拡張が経路を変えている、企業ポリシーでプロキシが固定されている、などの 外れ値 を疑います。
拡張機能は一旦すべて無効化して再現するか、新規プロファイルを作って 素の Firefox で同じ URL にアクセスし、差分を見ます。Multi-Account Containers を使っている場合、コンテナごとにプロキシ挙動が分岐するケースもあるため、同一条件で比較してください。ここまで通れば、原因が ブラウザプロキシ／DNS／TUN のどの段にあったか を説明できる状態になっています。
開発者向けに npm や IDE を併用している場合は Cursor と npm の分流 も参照すると、環境変数とブラウザ設定が混線しないよう整理しやすいです。
よくある質問（補足）
Firefoxで「システムの設定を使用する」にしているのに直結に見えるのはなぜ？
プロファイル別の上書き、拡張機能、about:config の残骸、DoH だけが別経路、などが典型です。設定画面と about:config の実値を突き合わせてください。
SOCKS5だけ手動指定する場合、Clashのどのポートを入れる？
クライアントに表示されている SOCKS ポートを入れ、SOCKS5 を選びます。名前解決を寄せるなら network.proxy.socks_remote_dns を true にします。
TUNを有効にすればFirefoxの設定は無視されてよい？
多くの通信は取り込まれやすくなりますが、DNS や競合で例外もあります。TUN で改善するかを切り分けたうえで、Firefox 側もシステム設定に揃えると安定しやすいです。
まとめ
Clash が動いていても Firefox だけが 直結 や失敗に見えるとき、最初に疑うべきは YAML より前の ブラウザプロキシスタック です。本稿の 六ステップ は、設定 UI のリセット、about:config の network.proxy 実値確認、手動 SOCKS5 に寄せる場合の順序、DNS over HTTPS の切り分け、Clash TUN で OS 層に寄せる判断、ログと拡張機能による最終確認、という実務順に並んでいます。システムプロキシ と TUN を同時にいじるときは、意図を一文で書き留めてから操作すると迷いが減ります。
コア世代や GUI の表記差でトグル名が異なる場合は、Clash Meta（mihomo）のアップグレード を前提に画面と YAML を照合してください。クライアントの入手先は ダウンロードページ からまとめて確認できます。購読リンク（サブスク URL）でプロファイルを更新したあと、Firefox を再起動してログを見る——この往復を習慣にすると、同種の不具合に再遭遇したときの復旧が速くなります。