ブラウザは通るのに、ターミナルの git や npm が素通りしてしまう理由
Clash を入れてシステムプロキシや「ブラウザ拡張のスイッチオン」だけ試すと、YouTube を開いたり検索だけは問題なくできても、コンソールからのクローンやパッケージ取得が遅い・失敗することがあります。これはトラブルというより、OS が「どのアプリにどの経路を見せるか」を仕様どおり分けている結果です。
Windows や macOS のシステムプロキシは、ざっくり言えば HTTP(S) プロキシを参照するアプリケーション向けのレールです。Chrome や Edge のようなブラウザはこの設定を読み、通信を 127.0.0.1:7890 のようなローカル混合ポートへ流しやすい一方、git は独自の HTTP 実装と SSH、npm は Node の TLS スタック、curl はオプション次第でプロキシを無視する、といったばらつきがあります。
さらに面倒なのが 環境変数 HTTP_PROXY を読まないプロセスが普通に存在することです。毎回シェルの rc に書く手もありますが、GUI から起動した IDE 付属ターミナルでは継承されない、サブシェルで消える、CI 用コンテナとローカルで設定が食い違う、といった運用コストが積み上がります。
ここで役に立つのが TUN モードです。仮想ネットワークカード（TUN デバイス）を立て、OS が発行する TCP/UDP フローをアプリの種類にかかわらず Clash 側へ引き込むイメージです。HTTP かどうか、プロキシ環境変数があるかどうかに先立ち、パケットがルールエンジンに乗るため、開発者が毎回エイリアスを貼り足す負担が小さくなります。
TUN モードがやっていること（ざっくり OS レベル）
具体名はクライアントやコア（Mihomo など）の実装差がありますが、ユーザー視点では次の三点を押さえれば十分です。
- 仮想インターフェース：OS に「もう一枚 NIC がある」ように見えるデバイスが追加され、既定ルートやスプリットに応じてトラフィックがそこを通る設計になります。
- ルールエンジンへの集約：通過したフローは
DOMAIN-SUFFIXやGEOIP、Rule Provider など、いつもの Clash ルールでDIRECTかプロキシグループかが決まります。 - UDP も含む：HTTP プロキシだけでは扱いづらい QUIC や DNS（アプリが独自に飛ばす UDP）も、設計とルール次第で同じテーブルに載せやすくなります。
つまり TUN は「ブラウザ用の HTTP レールを増設する」のではなく、OS の出口手前で一度トラフィックを束ね直す発想です。そのため pip、go get、ゲームランチャー、社内ツールの独自プロトコルなど、システムプロキシの外に落ちやすいものまでまとめて観測・制御しやすくなります。
用語メモ：GUI によっては “TUN Mode”“仮想アダプター”“Enhanced Tun” など表記が分かれますが、目的は同じで「カーネルに近いところでフローを横取りする」ことです。細部のトグル名は利用中のクライアントのドキュメントに合わせてください。
システムプロキシとの違い（ぱっと見の比較）
| 観点 | システムプロキシ | TUN モード |
|---|---|---|
| 主な対象 | HTTP/HTTPS を意識的にプロキシへ向けるアプリ | TCP/UDP 全般（ルールで DIRECT に落とせる） |
| CLI との相性 | 環境変数や git の http.proxy 設定が必要になりがち |
多くの CLI が追加設定なしでルールに乗る |
| 権限・影響範囲 | 比較的軽く、オフにしやすい | 管理者承認や他 VPN との競合に注意 |
| おすすめの使い分け | 普段のブラウジングや軽い作業 | 開発・レジストリ取得・プロキシ非対応アプリの検証 |
ドキュメントでは「普段はシステムプロキシ、詰まったら TUN」という二段構えが現実的だと書かれることが多いのは、まさに影響範囲とトラブル時の切り分けのしやすさのためです。
有効化の流れ（Clash Verge Rev を例に）
画面名はビルドで多少変わりますが、多くのデスクトップ GUI で共通する順番は次のとおりです。
- 正しいプロフィールを適用済みか確認する：購読 URL から取り込んだ YAML が選択され、プロキシグループにノードが見えている状態にします。空のまま TUN だけオンにしても意味がありません。
- 管理者権限や拡張機能の許可を済ませる：Windows では初回に UAC が出ます。macOS では「ネットワーク拡張」や「システム設定で許可」などの誘導が出るので、案内どおりに進めます。ここで止まると仮想 NIC が立ちません。
- TUN のトグルをオンにする：設定の “TUN” セクション、またはホームのクイックトグルから有効化します。併用型のクライアントではシステムプロキシと独立したスイッチになっていることが多いです。
- 競合する VPN / フィルタを止める：別ベンダーの常駐 VPN や古い仮想 NIC ドライバが残っていると、ルートが期待とズレます。検証中は片方に絞るのが早道です。
- 接続ログを開いたまま試す：ターミナルで何か一つ（後述の
curlなど）を叩き、同じホストがどのルールに当たったかをログで見ます。
仕事用端末では必ずポリシーを確認してください：全トラフィックを横取りする方式は便利な反面、社内イントラやセキュリティ要件と衝突することがあります。許可された環境でのみ利用し、必要なら IT 部門のガイドラインに従ってください。
curl / git / npm でのざっくり検証
動いているかの体感を掴むには、ログとコマンドをセットで見るのが確実です。公開されているテスト用 URL は環境によりブロックされることもあるため、実際に困っているホストへ向けるのが近道です。
curl
TLS のハンドシェイクまで見えるよう、適当な HTTPS を叩いてみます。プロキシを明示しない形（デフォルト）でタイムアウトしないかがポイントです。
curl -I https://www.google.com-v を付けてもよいですが、ログが長くなるのでまずはヘッダだけで十分です。Clash の接続一覧やログに、対象ホストへ意図したポリシー名が並んでいれば、TUN 経由できています。
git
HTTPS クローンでも SSH クローンでも、途中の名前解決と実際の接続経路が分かれることがあります。HTTPS の場合は http.proxy を無効のまま試し、それでも進むかを見ます。進むなら TUN がレイヤーを補っている可能性が高いです。
git ls-remote https://github.com/octocat/Hello-World.gitSSH（[email protected]:...）はポート 22 番の別経路になります。HTTPS よりルールとの相性差が出るので、そのときはログでポートとヒットしたルールを確認してください。
npm / pnpm / yarn
レジストリが registry.npmjs.org であれば単純ですが、企業製のミラーへ向いている場合はドメインが変わります。ひとつのパッケージメタだけ取得してログを確認するのが手早いです。
npm view lodash version結果がすぐ返り、ログでも該当ドメインがプロキシ側に割り振られれば良しです。npx やツールチェーン経由ではサブプロセスが増えるので、失敗時は最初にこのような単発コマンドへ戻してください。
環境変数と二重運用しない：HTTP_PROXY を手で張りつつ TUN もオンにすると、どちらが効いたかログだけでは読みにくくなります。切り分けのときはどちらか一方に絞りましょう。
DNS / fake-ip とルールが噛み合わないとき
TUN が効いていても、名前解決の段で意図と外れた応答が返ると、結果的に迂回ルールへ入らなかったように見えることがあります。Mihomo 系では DNS の enhanced-mode が fake-ip のとき、アプリ側の挙動とルール評価の順序が絡むため、細かくはプロフィール側の説明書を読む価値があります。
- 国内ドメインは直結にしたい：
RULE-SETやDOMAIN-SUFFIXで明示し、GEOIPより手前へ置く、といった定石は TUN と併せて強く効きます。 - DoH と OS の両方から解決しないか：アプリごとに独自 DNS を持っているとログの見え方が二重になります。
- IPv6 だけ別ルートになっていないか：IPv6 が有効で期待と異なる経路になるケースがあります。問題が再現するときだけ一時オフして比較するのも一案です。
うまくいかないときのチェックリスト
- TUN のトグルはオンだがログが増えない：他社 VPN が同じレイヤーを握っている可能性があります。
- 管理者権限の途中でキャンセルした：NIC が作られていない状態に戻るので、許可ダイアログからやり直します。
- すべて DIRECT になる：プロフィールの
rules:冒頭〜MATCHまで、意図せず広い直通ルールが上に無いかを確認します。 - git だけ遅い：
http.versionや証明書ストア、アンチウィルスの HTTPS 検査が絡んでいないか別軸でも見ます。
よくある質問
TUN とシステムプロキシを同時に使って問題ない？
クライアントによってはサポートされていますが、初回セットアップでは両方オンにしない方がログの解釈は簡単です。ブラウザ向けだけシステムプロキシ、開発は TUN と割り切るのも現場ではよくある運用です。
「全部プロキシ」にすると会社の NPM まで遅くならない？
なり得ます。そのため前述のルールで社内ホストや固定 IP は DIRECT に逃がす構成がセットと言えます。クライアントによっては、アプリ単位やインターフェース単位で TUN の対象を絞れる場合もありますので、公式ドキュメントと GUI の説明をあわせて読んでください。
SSH ポートも強制的に中継されるの？
ルールで許可されていれば経由します。DIRECT を先に置くほど、その逆も真です。開発者個人が触るときは「海外のサービスだけをプロキシ、ローカルは直結」を明文化しておくと混乱が減ります。
http_proxy だけの運用と比べたときに Clash 系が強い場面
各ツールに HTTP_PROXY を足す方式は、単一のリポジトリなら手早いです。ただし次のような摩擦が出やすいです。
- GUI アプリから起動したシェルに変数が無い：再現性が低く、チーム内で「私の端末だけ」になりがちです。
- UDP や独自プロトコルが抜ける：HTTP プロキシ前提の設定では穴が残ります。
- 国内外の振り分けが手作業：ルールエンジンが無いと、国内ミラーを毎回手で切り替える羽目になります。
一方、Mihomo コアを載せた Clash クライアントは、購読から入ったプロフィールをそのままルールテーブルとして使い、TUN でアプリ横断に適用できるのが大きな利点です。ブラウザ用とターミナル用で二重の設定ファイルを持たずに済み、接続ログで「どのルールに当たったか」まで一画面で追える製品も多く、詰まった場所の特定が速くなります。
もし「環境変数の貼り替えに飽きた」「npm の取得ログを見ながらルールを直したい」という段階なら、TUN を含めた一式を扱える最新クライアントを揃えておくと運用が軽くなります。配布物がバラつきがちなので、OS 別に整理された入手ページから取ると安全です。