1. 検索意図：「設定したのに効かない」をレイヤーに分解する

典型的には、(A) Firefox がそもそもシステムプロキシを見ていない、(B) 手動で入れた SOCKS のポートや種類が Clash 側と一致していない、(C) DoH により名前解決だけ別経路になっている、(D) 広告ブロックや VPN 系拡張が別のプロキシ／直接接続を強制している、(E) TUN を有効にしていないためブラウザ以外は通っているが Firefox の設定だけズレている、のいずれかです。まず「ブラウザ単体の問題」か「Clash コア全体の問題」かを分けると、その後のabout:configの見どころがはっきりします。

購読やポリシーグループの名前がまだ整理できていない場合は、サブスクリプション取り込みで全体像を押さえてから読み進めてください。

2. Clash 側で先に決める：mixed・HTTP・SOCKS5 のどれを Firefox に渡すか

クライアントによっては mixed-port（HTTP と SOCKS を同一ポートで受ける）、別ポートの HTTP と SOCKS5、といった構成があります。Firefox の「手動プロキシ」で SOCKS ホストを指定する場合、Clash がそのポートで SOCKS5 を実際に公開しているかを確認してください。HTTP 用ポートに SOCKS として繋ごうとして失敗する、逆に HTTP プロキシ欄に SOCKS ポートだけ書いておく、といった取り違えは実務でよくあります。ローカルループバックのアドレスは 127.0.0.1 に固定し、IPv6 の ::1 と混在させない方が切り分けが楽です。

3. 設定 UI：「システムのプロキシ設定を使用する」か「手動」か

設定 → ネットワーク設定では、(1) システム設定を使う、(2) 手動でプロキシを指定、(3) PAC URL、などが選べます。システムプロキシを選んだ場合、OS が Clash のシステムプロキシ注入を受けている必要があります。一方で「Chrome は通るが Firefox だけダメ」かつ Firefox が手動プロキシのまま固定されているときは、OS に追従しないのでUI でモードを合わせるか、後述の about:config で旧設定が残っていないかを確認します。

4. about:config で押さえる項目（バージョンにより名称は変わり得る）

主要なのは、プロキシ種別を決める network.proxy.type（例：手動なら 1、システム設定なら 5 や環境により異なる）、SOCKS のホスト／ポート network.proxy.socks／network.proxy.socks_port、SOCKS v5 の指定 network.proxy.socks_version、および DNS を SOCKS 経由に載せるかどうかを左右する network.proxy.socks_remote_dns です。DNS だけローカルリゾルバに逃げてしまい、見かけ上だけ出口が変わらないように見えることがあるため、socks_remote_dns を期待どおりに合わせます（IPv6 環境では別キーも絡むため、変更は一つずつ検証してください）。

検索バーはabout:configにnetwork.proxyと打ち込んで確認すると見落としが減ります。変更のたびに Firefox を再起動するか、該当プロファイルで新規ウィンドウだけ試すかは環境次第です。

5. DNS over HTTPS（DoH）が経路を別にする場合

Firefox 組み込みの DoH を有効にしていると、ブラウザは指定したリゾルバへ HTTPS で名前解決しに行きます。Clash の DNS 設定や fake-ip と組み合わさったとき、「TCP の出口はプロキシだが、名前は別 DNS で引いている」状態になり、期待した分流ルールに乗らないことがあります。切り分けでは一時的に DoH をオフにして挙動が変わるかを見る、あるいは Clash 側の DNS と矛盾しない解決経路に寄せる、という順が現実的です。詳細なパラメータ名は利用中の Mihomo／Meta のドキュメントと照合してください。

6. 拡張機能・コンテナ・プライベートウィンドウ

プロキシ切り替え拡張や広告ブロック、プライバシー系アドオンが独自のプロキシ設定を持っていると、UI で見た既定より優先される経路があります。複数プロファイルやコンテナを使っている場合も、ウィンドウごとに挙動が違うので、まずは拡張をすべて無効化したプロファイルかセーフモード相当で再現するかを確認します。Firefox Containers と企業ポリシーを併用している環境では、管理者配布のpolicies.jsonがネットワークより優先されることもあります。

7. TUN とブラウザ設定の優先関係

TUN モードでは OS のルーティング層からトラフィックを取り込むため、ブラウザのプロキシ設定が「見かけ上ノイズ」に見えるケースがあります。それでもFirefox が別の明示プロキシに固定されていれば、その経路が優先されることもあるため、「TUN オンでもブラウザだけ別出口」のときは about:config と GUI を再度突き合わせます。有効化手順や権限まわりはTUN モードの記事を参照し、Clash の接続ログにブラウザセッションの宛先が載っているかを確認してください。

8. 実測で使うチェックリスト（順番固定）

  1. Clash が起動し、ミックスまたは SOCKS ポートがリッスンしていることを OS のツールまたはクライアント画面で確認する。
  2. Firefox のネットワーク設定が「システム」か「手動」かを決め、手動ならホスト・ポート・HTTP と SOCKS の取り違えがないか見る。
  3. about:config で network.proxy.* が UI と一致しているか、socks_remote_dns を含めて確認する。
  4. DoH を一時オフにして症状が変わるか試す。変わるなら DNS と分流ルールをセットで見直す。
  5. 拡張をオフにして再現するか確認する。再現しなくなるなら拡張側のプロキシ設定を修正する。
  6. 必要なら TUN をオンにし、接続ログで Firefox のセッションが期待するポリシーに載ったか検証する。

ポート競合やコア未起動など汎用症状はトラブルシュート記事へ。本稿はFirefox 固有のネットワークスタックに焦点を当てています。

9. 既稿との棲み分け：ターミナル・UWP・Docker

Mac ターミナルと環境変数は CLI がプロキシを継がない話が中心です。Windows UWP のループバックはストア系アプリの話で、Firefox は通常デスクトップ版として別筋です。Docker Desktopはコンテナ側の話です。いずれも「ブラウザだけ別出口」という観点では、本稿の Firefox 周りを先に潰すと全体が整理しやすくなります。

10. 追加の落とし穴：IPv6・証明書検査・複数プロファイル

IPv6 が有効な環境では、IPv4 の SOCKS にだけ載せたつもりが別経路に逃げることがあります。企業ゲートウェイのSSL 検査と衝突すると、プロキシは正しくても HTTPS が失敗し、「効いていない」ように見えることがあります。Firefox の別プロファイルを試すと、古い prefs.js に残ったプロキシ値が原因かどうかが切り分けやすくなります。

11. まとめ：Firefox・Clash SOCKS5・システムプロキシ・TUN を一枚に束ねる

Firefox プロキシ設定は Chromium 系より自由度が高く、その分設定 UI・about:config・DoH・拡張のどこかがズレると「Clash を動かしているのにブラウザだけおかしい」状態になります。システムプロキシと手動 SOCKS5のどちらを正とするかを一度決め、Clash SOCKS5 のポートと種類を一致させ、必要ならTUNで下から揃え、DNS は DoH とセットで見る——この順で切り分けると再現性が上がります。

接続ログと設定ファイルを GUI で並べられるクライアントなら、ポート変更やプロファイル試験のたびに見落としが減ります。同種製品のなかでもコアと画面表示の整合が取りやすいものほど、ブラウザ固有の例外にも強い印象です。まずは安定した出口設計から試したい方は、→ Clash を無料ダウンロードして、快適な接続体験を始める