はじめに
ブラウザでは問題なくウェブサイトを開けるのに、ターミナルで npm install や pip install を実行すると、ダウンロードが止まる、接続がタイムアウトする、あるいは一部のパッケージだけ取得できない。こうした症状は、ブラウザと開発ツールで通信経路が異なることが原因の一つです。
多くのブラウザはシステムプロキシ設定に従いますが、ターミナル上のプログラムは環境変数や独自のプロキシ設定を参照する場合があります。さらに、DNSの名前解決、IPv6、証明書、プロキシノード側の制限なども通信に影響します。ブラウザが使えるからといって、npm や pip も同じ経路で接続できているとは限りません。
この記事では、Clash Verge Rev などの Mihomo 対応クライアントを例に、TUN モードの役割と有効化、DNS・権限の確認、ターミナルからの段階的なテスト方法を解説します。設定を一度に何か所も変更するのではなく、確認項目を分けて原因を特定することが安定化への近道です。
この記事で確認すること
TUN とシステムプロキシの違いを理解し、名前解決・接続・パッケージ取得を順番にテストして、必要な設定だけを調整します。
1ブラウザは使えるのにターミナルが失敗する理由
Clash の「システムプロキシ」は、OS のプロキシ設定に対応したアプリケーションの通信を振り分けます。一方、npm、pip、Git、Docker などの開発ツールは、システム設定を自動で使わないことがあります。ツールがプロキシを参照していなければ、ブラウザだけがプロキシ経由で接続し、ターミナルは通常回線から接続しようとします。
TUN モードは仮想ネットワークインターフェースを作り、アプリケーションが明示的にプロキシ設定を持たない場合も含めて、端末の IP 通信を Clash に取り込む仕組みです。そのため、環境変数を設定していない開発ツールの通信を捕捉したい場合に役立ちます。ただし、TUN をオンにすればすべてのエラーが解決するわけではありません。ルールが DIRECT を選んでいる、DNS が正しく解決できない、接続先が一時的に停止しているといった問題は別途確認が必要です。
| 症状 | まず確認する項目 |
|---|---|
| 接続がタイムアウトする | TUN の稼働状態、Clash の接続ログ、ルールと選択中のプロキシグループ |
| ホスト名を解決できない | DNS 設定、DNS の到達性、VPN や他の DNS ソフトとの競合 |
| npm だけ失敗する | npm 独自のプロキシ設定、レジストリ URL、環境変数 |
| pip だけ失敗する | pip の設定ファイル、インデックス URL、Python の証明書設定 |
切り分けのポイント
最初に同じ端末で一般的な HTTPS 接続をテストし、その後に npm や pip を試します。ツール固有の設定を調べる前に、端末全体の通信が Clash を通っているかを確認できます。
2Clash で TUN モードを有効にする
以下は Clash Verge Rev と Mihomo を想定した手順です。クライアントのバージョンや OS によって表示名は異なりますが、基本の考え方は共通です。まずプロファイルを読み込み、プロキシグループで利用可能なノードを選択して、通常のウェブ接続ができる状態にしてから TUN を有効にしてください。
- クライアントの設定画面で、使用中のコアが Mihomo など TUN をサポートするものか確認します。
- 「TUN Mode」または「TUN モード」をオンにします。初回は仮想ネットワークインターフェースやルーティングの作成許可を求められることがあります。
- 権限を求められた場合は、クライアントが案内する正規の方法で許可します。Windows では管理者権限やサービスの起動状態、macOS では VPN 構成の追加許可などが関係する場合があります。
- 接続表示とログを確認し、TUN が稼働してからターミナルを開き直します。アプリによっては、起動時に環境変数やネットワーク状態を読み込むためです。
- 端末全体の通信テストを行い、成功してから npm または pip のインストールを試します。
権限と競合に注意
TUN はシステムのネットワーク経路に関わります。別の VPN、仮想マシン、コンテナ用ネットワーク、セキュリティソフトが同時に経路を変更すると競合することがあります。問題が起きた場合は、他のネットワークツールを一時的に停止して切り分け、確認後に必要なものを一つずつ戻してください。
TUN の有効化後も、開発ツール向けの通信が意図した経路を通るとは限りません。Clash の接続画面やログで、テスト中に対象のドメインが表示されるか、どのルールとプロキシグループが選択されたかを見ます。接続が DIRECT になっている場合、TUN の問題ではなくルールやグループ選択が原因の可能性があります。設定を変更する際は、まず一つの項目だけを変えて結果を比較しましょう。
3DNS とルーティングを確認する
npm や pip は、レジストリのドメイン名を解決してから HTTPS 接続を開始します。ドメイン名を解決できなければ、プロキシノードが正常でもインストールは始まりません。Clash の DNS 機能が有効か、指定された DNS サーバーへ到達できるか、クライアントのログに名前解決エラーがないかを確認してください。
Mihomo の設定を自分で管理している場合、DNS の項目名や対応機能はコアのバージョンによって違うことがあります。インターネット上の設定例をそのまま貼り付けるのではなく、現在のコアで有効な構文か確認し、変更前のプロファイルを保存しておきましょう。DNS を複数のアプリやサービスで同時に上書きすると、問い合わせ先が想定と異なり、原因特定が難しくなることがあります。
ルーティングでは、テスト対象の通信が選択したプロキシグループに入るかを確認します。ルールセットやカスタムルールを利用している場合、先に一致したルールが後続のルールより優先されることがあります。対象ドメインの通信がどのルールに一致したかをログで調べ、必要なら設定の管理元でルールを修正します。プロファイルを更新すると手動変更が上書きされる構成もあるため、編集場所にも注意してください。
- 使用しているクライアント名とコアのバージョン
- TUN のオン・オフと、クライアントに表示される稼働状態
- DNS のエラー表示と、対象通信に一致したルール
- 他の VPN、プロキシ環境変数、端末側の DNS 設定
4ターミナルから順番に接続テストする
テストは「名前解決」「HTTPS 接続」「パッケージマネージャー」の順で進めます。下記のコマンドは一般的な例です。利用している OS やシェルによってコマンドが異なる場合があるため、エラーが出たときは各ツールの公式ドキュメントも参照してください。
1. DNS の名前解決
まず、npm レジストリや Python Package Index のホスト名を解決できるか確認します。
nslookup が失敗する場合は DNS やネットワーク経路を、名前解決は成功して curl がタイムアウトする場合はルール、ノード、HTTPS 接続を優先して確認します。HTTP の応答コードが返ってくることと、インストールが成功することは同じではありませんが、切り分けの手掛かりになります。
2. npm と pip の動作確認
HTTPS のテストが成功したら、実際のパッケージマネージャーを試します。大きなプロジェクトを使う前に、小さな確認コマンドを実行するとログを追いやすくなります。
npm config get registry の結果が想定外の URL なら、レジストリ設定を確認します。pip では pip config list で設定を調べられます。接続エラーにプロキシ、証明書、名前解決のどの情報が含まれているかを確認し、エラーメッセージを省略せずに記録してください。
3. プロキシ環境変数を確認する
シェルに古いプロキシ設定が残っていると、TUN モードと二重に異なる経路を指定してしまうことがあります。まず現在の値を確認し、心当たりのない設定を無条件に削除するのではなく、設定元がシェルの起動ファイルか、開発環境かを調べます。
環境変数を使う方式を選ぶ場合は、Clash クライアントが表示する HTTP プロキシのアドレスとポートを確認してから設定します。ポート番号を推測して入力したり、用途の異なる SOCKS ポートを HTTP 用として指定したりすると失敗します。TUN と明示的なプロキシ設定を併用する必要がなければ、まず片方だけでテストすると原因を特定しやすくなります。
5よくある失敗と改善方法
- TUN をオンにしても変化がない： クライアント上で TUN が実際に稼働しているか、権限エラーが出ていないかを確認します。オンの表示だけで判断せず、接続ログとテスト結果を見てください。
- 特定のパッケージだけダウンロードできない： レジストリ以外に、パッケージの配布先や依存関係のホストへ接続している場合があります。失敗した URL やログに表示されたドメインを確認し、その通信に適用されたルールを調べます。
- プロキシ設定後にかえって失敗する： 古い環境変数、npm の独自設定、pip の設定ファイルが残っていないか確認します。値を変更する前に現在の設定を保存し、一度に複数のプロキシ指定を混在させないようにします。
- 証明書エラーが出る： エラーの内容、システム時刻、Python や Node.js のバージョンを確認します。検証を無効化する設定は安全性を損なうため、恒久的な回避策として使用しないでください。
- 設定変更後にネットワーク全体が不安定： 直前に変更した DNS、TUN、ルールを一つずつ元に戻して再テストします。他の VPN やネットワーク管理ソフトとの競合も確認しましょう。
原因がプロキシ経路にある場合も、すべての通信を同じノードに固定する必要はありません。開発に必要なドメインだけを適切なグループに振り分ける方法もあります。プロバイダーや組織のネットワークポリシーに従い、利用できるノード・レジストリ・接続方法を選択してください。職場や学校の管理ネットワークでは、管理者のルールを確認してから変更することが重要です。
よくある質問
TUN モードは必ず有効にする必要がありますか？
必須ではありません。npm や pip に有効なプロキシ設定を行い、接続できるならシステムプロキシや環境変数だけで足りる場合があります。TUN は、アプリごとの設定が難しい場合や、システムの通信をまとめて Clash に取り込みたい場合に検討してください。
TUN と HTTP プロキシの環境変数を併用できますか？
構成によっては可能ですが、二重に経路を指定すると、どちらの設定が通信に使われているか分かりにくくなります。まず TUN のみ、または環境変数のみでテストし、必要性が確認できた場合にだけ併用してください。
npm は成功するのに pip が失敗するのはなぜですか？
npm と pip は独立した設定、インデックス、証明書環境を持つため、片方だけが異なる接続先やプロキシを使っている可能性があります。両方の設定表示とエラー内容を比較し、失敗時にアクセスしているホスト名を確認してください。
TLS 検証を無効にしてもよいですか？
おすすめできません。TLS 検証を無効にすると、接続先の正当性を確認できなくなるおそれがあります。証明書エラーが出る場合は、システム時刻、証明書ストア、Node.js や Python の設定、ネットワーク管理者の案内を確認し、検証を有効に保ったまま原因を解決してください。
TUN、DNS、ルール、開発ツールの設定を順番に確認すれば、ブラウザとターミナルの通信経路の違いを切り分けやすくなります。まずは簡単な接続テストから始め、変更内容と結果を記録しながら、自分の環境に合う設定を見つけましょう。