開発者向けClash設定：TUNでGit・npm・Dockerを快適化

この記事で分かること

開発中にGitHub へ接続できない、npm install が途中で止まる、Docker Hub からのイメージ取得だけ極端に遅い、といった問題は、回線そのものではなくアプリごとにプロキシの扱いが違うことが原因になりがちです。ブラウザはシステムプロキシを利用できても、Git、Node.js、Docker CLI は独自の環境変数やデーモン設定を参照するため、同じ PC 上で「ブラウザは動くのにターミナルは失敗する」という状態が発生します。

本稿では、Clash Verge Rev と Mihomo 系コアを前提に、開発者が日常的に使う Git、npm、pnpm、yarn、Docker を安定させる考え方を整理します。まずシステムプロキシとターミナルの役割を分け、次に TUN モードでプロキシ設定を無視するプロセスも捕捉し、最後にルール・環境変数・ログを使って経路を検証します。特定のドメインを無条件に追加するのではなく、実際のログと所属ネットワークのポリシーを確認しながら、必要最小限の構成にすることが重要です。

なお、会社や学校のネットワークでは、プロキシの利用や TUN によるパケット処理が規約で制限されている場合があります。管理対象の端末では、管理者の許可を得てから設定を変更してください。認証情報や社内リポジトリの通信を、意図しない外部ノードへ送らないことも忘れないようにします。

開発ツールごとに異なるプロキシの仕組み

Clash の設定で最初に理解したいのは、システムプロキシ、環境変数、TUNが同じ機能ではないという点です。システムプロキシは OS の設定を読み取るアプリに有効ですが、すべてのコマンドラインツールが自動的に従うわけではありません。Git は設定ファイルや環境変数、npm は npm 独自の設定、Docker は CLI とバックグラウンドの Docker Engine を別々に参照することがあります。

この違いを無視して、すべての問題を TUN のオン・オフだけで解決しようとすると、社内 VPN やローカル開発環境との競合が起きやすくなります。まずは「そのプログラムはどの設定を読むのか」を確認し、明示的なプロキシ設定で対応できるものと、透明に捕捉したいものを分けて考えます。

Clash Verge Rev で TUN を安全に有効化する

Clash Verge Rev のプロファイルを読み込んだら、最初に正常なノード、プロキシグループ、DNS 設定を確認します。TUN は、その上で OS の通信を仮想インターフェースへ取り込む機能です。アプリがプロキシ環境変数を無視していてもルールへ到達させやすい反面、ルーティングを変更するため、通常のシステムプロキシより影響範囲が広くなります。

1. Clash Verge Rev を起動し、利用するプロファイルを選択します。
2. プロファイルのルールモードが意図した状態で、プロキシグループに利用可能なノードがあることを確認します。
3. TUN の設定画面で、必要な権限やネットワーク拡張の承認を確認します。
4. まず TUN を短時間だけ有効にし、ブラウザ、GitHub、社内サービスの順番で接続を試します。
5. 動作確認後、Clash の接続ログでプロセス名、接続先、使用ルール、最终ポリシーを確認します。

TUN を有効にしても、必ず全通信が同じノードへ流れるわけではありません。ルールモードが Rule なら、ドメインや IP、プロセスの通信はルールの上から順に評価されます。社内 Git、localhost、プライベートネットワークまでプロキシへ送ると、認証や速度に悪影響が出るため、ローカル用途は明確に DIRECT として扱います。

DNS の挙動も重要です。ドメインをローカルで誤解決すると、正しいルールに到達する前に接続が失敗することがあります。Mihomo の DNS 設定を変更する場合は、Fake-IP と Redir-Host の違いを理解し、社内ドメインや開発用のローカル名前解決を除外します。設定を一度に多く変えず、TUN、DNS、ルールを一つずつ確認すると原因を追いやすくなります。

Git・npm・Docker のルールを設計する

開発用のルールは、サービス名を大量に暗記するより、通信目的とログに現れたホスト名を基準に作る方が保守しやすくなります。GitHub ではコード取得、認証、リリースファイル、コンテナレジストリが別ホストになることがあります。npm もパッケージレジストリ、認証、依存パッケージの配布 CDN が分かれるため、最初から一つのドメインだけを許可しても十分とは限りません。

ルールの順序では、社内ネットワーク、localhost、プライベート IPを先に DIRECT とし、その後に必要な外部開発サービスを PROXY へ送る構成が扱いやすいです。最後の MATCH は、環境に合わせて DIRECT またはプロキシグループを選びます。MATCH をいきなり全通信のプロキシにすると、国内サービスや社内システムまで迂回し、どの設定が原因なのか分かりにくくなります。

また、ルールにドメインを追加した後は、既存の接続が古い経路を保持していないか確認します。Git のプロセスや Docker Desktop を再起動し、Node.js の開発サーバーも必要に応じて起動し直してください。ルール変更後に一度だけ成功した場合は、キャッシュや Keep-Alive の影響を除外するため、同じ操作を複数回行うと判断しやすくなります。

ターミナルの環境変数と各ツールの設定

TUN を使わずに済むツールでは、環境変数を明示する方法が分かりやすいです。Clash の混合ポートが例として 7890 なら、シェルで HTTP と HTTPS の両方を設定します。実際のポート番号は Clash Verge Rev の設定画面で確認し、ポートを固定値として思い込まないでください。

export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export ALL_PROXY=http://127.0.0.1:7890
export NO_PROXY=localhost,127.0.0.1,::1,.local

NO_PROXY は非常に重要です。localhost の開発サーバー、Docker のローカル API、社内ドメインなどを外部プロキシへ送ると、名前解決、証明書、認証のいずれかで問題になる可能性があります。一方、会社の内部レジストリを除外するかどうかは組織のネットワーク設計によって異なるため、ドメインを無条件に追加せず、管理者の案内と接続ログを基準に決めます。

Git では、現在の設定を確認してから必要な値だけを変更します。

git config --global --get http.proxy
git config --global --get https.proxy
git config --global http.proxy http://127.0.0.1:7890
git config --global https.proxy http://127.0.0.1:7890

一時的に直接接続を試す場合は、設定を削除する前にコマンド単位で比較する方法が安全です。古い認証付きプロキシ URL が残っている場合、ユーザー名やトークンが設定ファイルに保存されていないかも確認してください。共有端末や公開リポジトリへ設定を載せる場合は、秘密情報を含めないことが基本です。

npm は次のように現在値を確認できます。

npm config get proxy
npm config get https-proxy
npm config set proxy http://127.0.0.1:7890
npm config set https-proxy http://127.0.0.1:7890

npm や pnpm のエラーでは、接続タイムアウト、名前解決、TLS 証明書、レジストリ側の認証エラーが似た表示になることがあります。まず npm config get registry で接続先を確認し、組織指定のレジストリを不用意に公開レジストリへ置き換えないようにします。証明書検証を無効にする設定は、短期的な回避に見えても中間者攻撃を検知できなくなるため、原則として行わないでください。

Docker の通信を検証し、問題を戻す

Docker では、ターミナルから実行する docker コマンドと、実際にイメージを取得する Docker daemon の位置が一致しないことがあります。Docker Desktop を使う場合は、アプリ内のプロキシ設定、daemon の再起動、TUN との競合を順番に確認します。Linux で systemd 管理の Docker Engine を使う場合は、シェルの環境変数だけでは daemon に届かないため、サービス側の設定が必要になることがあります。

検証は大きなイメージをいきなり取得するのではなく、軽量なイメージで行います。Clash のログを開いた状態で docker pull を実行し、認証ホスト、registry、layer 配信ホストがどのルールへマッチしたかを確認します。manifest だけ成功して layer 取得で止まる場合は、Docker Hub の補助ホストや CDN がルールから漏れている可能性があります。

Git と npm も同じように、まず DNS、次に TCP 接続、最後に TLS と認証を分けて調べます。例えば curl -I で HTTPS の応答を確認し、Clash の接続ログに対象ホストが現れるかを見ます。ログに何も出ないなら、対象プロセスが TUN の対象外である、別の VPN を使っている、あるいはローカル DNS で失敗している可能性があります。ログに出ているのにタイムアウトするなら、選択ノード、上流プロキシ、SNI、企業側の TLS 検査を切り分けます。

動作確認が終わったら、不要な TUN や広すぎるルールをそのまま常用しないことも大切です。社内サービスが DIRECT で動くか、ローカルの Kubernetes や Docker ネットワークに到達できるか、Git の push と pull が同じように成功するかを確認します。問題が解決した構成をプロファイルとして保存し、変更点と戻し方をチーム内で共有しておくと、ノード更新や OS 更新の後にも復旧しやすくなります。

再現性のある開発用ワークフロー

安定運用のポイントは、Clash を常に強い設定で動かすことではなく、どの通信をどの理由でどの経路へ送るかを説明できる状態にすることです。まず Rule モードで社内・ローカル通信を DIRECT に整理し、Git や npm などプロキシ設定に対応したツールは環境変数または個別設定で動作確認します。それでも Docker daemon や特定のバイナリが直結する場合にだけ TUN を追加し、ログで実際に捕捉できているかを確認します。

チームで作業する場合は、個人のホームディレクトリにだけ存在する設定へ依存しないようにします。プロジェクトの README には、推奨するレジストリ、プロキシを使う場合のポート確認方法、NO_PROXY に含めるべきローカル名、解除手順だけを記載し、アクセストークンや個人ノード情報は保存しません。新人が参加したときに、ブラウザは使えるのに npm install だけ失敗する理由を説明できる資料があると、同じ調査を何度も繰り返さずに済みます。

Clash を停止した状態でも、社内サービスとローカル開発が復旧できるかを確認しておくと安心です。特定のノードに依存しすぎると、ノード障害が開発全体の停止につながります。複数ノードの遅延や失敗率を比較し、開発用と個人利用でポリシーを分けることも、長時間のビルドや大容量イメージ取得では有効です。

単純な環境変数だけで対応するツールは設定が軽い一方、プロセスごとの漏れが起きやすく、別の VPN クライアントは DNS やルートを独自に変更することがあります。相比而言、Clash はルールログで Git・npm・Docker の経路をまとめて確認でき、必要な通信だけを分流し、TUN が必要な場面にも段階的に対応できます。設定の影響範囲を記録しながら開発環境を整えたい場合は、利用中の OS に合う Clash クライアントを選び、まず安全に試せる構成から始めるとよいでしょう。

Clash を無料でダウンロードして、快適なネット体験を →