検索意図からみるつまずき：npm で「依存は取れるはずなのに止まる」
ユーザーが入力しがちなのは「Gemini CLI インストール 遅い」「npx Gemini 証明書」「npm registry タイムアウト」「google gemini CLI 設定」など、症状ベースとツールベースが混ざったクエリです。内部的にはほぼ常に複数フェーズがあります。第一段階は @google スコープ配下など公式が案内するパッケージ名を registry.npmjs.org（またはユーザー指定の別 registry）から解決し、第二段階で tarball の実体を CDN 側のホストから落とします。ログに名前が並ばないときは NPM_CONFIG_REGISTRY やプロジェクト直下の .npmrc が実際には社内／地域ミラーを指しており、そのミラー自身が上流と同期できていない、という単純なパターンも残ります。第三段階は CLI が動いたあとでの OAuth／API キー と、Google 側のエンドポイントへの呼び出しです。検索クエリ側がどの段階に刺さっているかを意識しておくと、本稿後半のワークフローで「ログに出ているのはホストなのか、証明書なのか、認可なのか」を切り分けやすくなります。
とくに読者が強いフラストレーションを感じやすいのは、画面上に出る進捗表示が抽象的なときです。Installing … のまま数分、その後に一般化されたエラーへ折りたたまれると、体感はすべて「タイムアウト」になります。その裏側では TCP の再送だけが続いていたり、中間証明書の検証が失敗してすぐ RST で切られていたりすることがあります。ここでの第一歵はログにFQDN が出ているかです。Clash 系クライアントでは接続一覧からドメイン名を拾い、その名前を分流のキーとして足します。名前が出ず IP だけのときはDNS か sniffer を疑う順になります。Gemini CLI のREADMEが読み込まれるときに裏側でgistやraw.githubusercontent.comへ飛ぶような周辺導線が増えれば、リストはさらに長くなるため、ログ起点の増分修正が運用上もっとも壊れにくいです。
ブラウザは問題ないのにターミナルの npm が遅い理由
ブラウザは多くの場合 システムプロキシ を尊重します。一方 Node.js の npm はバージョンと設定により、環境変数のみを見ないケース／逆にプロキシは見るが証明書ストアとの整合が異なるケースが混ざります。さらに macOS であれば別ユーザーランチサービスとの兼ね合い、Windows であればコンソールの継承と企業証明書配布とのズレという、プラットフォーム固有のひっかかりも増えます。GUI アプリだけが許可リストに載っていて、ターミナルが除外されている企業構成もまれに見られます。こうしたときに単に HTTPS_PROXY を並べても、アプリ側の独自実装によっては読まれないので、環境だけを増やして疲弊する状態になりがちです。TUN は経路という下位レイヤーをまとめて Clash に引き込むので、「ターミナルがどんな設定を読もうとも、既定で外へ突き抜ける前に規則を噛ます」という意味で第一の武器になります。もちろん例外もありません。すべてのプラットフォームでヘルパーと権限の承認を完了していないときの「見かけオン」は致命的に紛らわしいので、その確認はグラフィカル設定画面と OS の状態表示の両側で済ませるのが安全です。
もうひとつの典型は経路より前の名前解決レイヤでの事故です。Clash Meta（Mihomo）の fake-ip をオンにしているのに評価順が噛み合っていない、あるいは同時に複数製品が DoH を奪い合っている状態だと、アプリ側のエラーログは抽象的なままになります。その場合でも接続一覧に「名前は付いているが意図と違う出口」だけは残るので、一覧を眺めるのは依然として有用です。また WSL2 の Linux コンテナ側から Windows 側 TUN を経由させるときはポートと境界の問題が増えるため、コンテナ開発を重ねるユーザーはホスト側のルールとゲスト側のプロキシの二枚看板になりやすい点に注意してください。Windows 側の典型は WSL2 の Git と npm を Windows Clash とつなぐ手順 に寄せられますが、読者のワークスペースがそこにあるなら同時に頭に載せます。
第1アクションとして TUN を優先してオンにする
手順の具体的なクリック順は環境によりけりなので、ここでは方針だけ固定します。RULE（ルール） モードで動かしている前提で、まずTUN を有効化し、ヘルパーインストールと管理者／セキュリティダイアログを完了させてください。そのうえで同じシェルから再試行すると、一覧に registry 周辺のホストだけでなく、アーティファクト配信ドメインのサブセットが増えやすくなります。Gemini CLI のバージョンと公式READMEの変更で追加される URL は当然あるため、「一度足したリストで一生」より「今回ログに見えた名前を足していく」のほうが持続します。競合となるフルVPN と同時オンはログが二重になり原因が読めなくなるので検証だけでも切り離すのが得策です。GUI とシステムトレイ両方にある「システムプロキシ」を触るときは文言が似ているので、ポート番号だけをコピペで正として扱ってください。Mixed port と SOCKS の読み間違いはタイムラインの途中でだけ失敗するときに効いてきます。
運用ヒント：TUN と手動HTTPS_PROXYの両方をいきなり最大にしないでください。二重経路になり失敗ログが増えやすくなります。まず TUN だけで一覧を読み、ダメ押しだけ環境変数を付ける順が読みやすいです。
分流ルールはログ優先：npm と Google と周辺
「必須ドメイン」の固定リストだけに頼ると、CDN の切り替わりや運用側の細かな差分ですぐ陳腐化します。その代わりに、Clash の接続ログまたはダッシュボードで実際に出たドメイン名をソース・オブ・トゥルースにします。registry 周辺でよく名前に出やすいのは registry.npmjs.org と npmjs.org であり、続いて tarball の配信側として Amazon 系や Fastly などのCDN名が並ぶことがあります。Gemini 実行時にはGoogle関連の名前が増え、そのなかでも API 側は *.googleapis.com や *.googleusercontent.com、認可まわりはブラウザ起動OAuthに寄った場合に広告ブロッカと衝突しがちなドメインが混じることがあります。名前が長くてグルーピングに困るときはログに出ていた最短の共通サフィックスだけをDOMAIN-SUFFIXにして、評価位置をMATCHより手前へ持ってくる形が堅実です。RULE-FINAL（MATCH）が意図せず強い直行に寄っているときは一覧の色とラベルを疑ってください。Gemini CLI のドキュメントに GitHub Releases への直リンクしか無いワークフローを選んだ読者には github.com と objects.githubusercontent.com が独立して増えます。
# Sketch: paste observed domains into YOUR_PROXY_GROUP
rules:
- DOMAIN-SUFFIX,npmjs.org,YOUR_PROXY_GROUP
- DOMAIN-SUFFIX,googleapis.com,YOUR_PROXY_GROUP
# Add only what logs show during failing runs
GEOIPだけで「アメリカっぽいから PROXY」のようにざっくり振る運用でも動くことは動きますが、CDN と実ユーザーの体感が食い違う典型も出やすく、CLI問題では名前ベースとの併記が強いです。もし自分の構成が GEOIP メインでも、問題が出ているときだけ名前ルールが先に評価される並び順になっていることをダッシュボード側で確認します。リストの増え方自体がレートリミットの兆しであるケースでは、ルール以前にノード側の並びや DNS の再試行過多という別軸にも目を向ける必要があります。分流の共通テンプレについてはGEOIP・geosite 分流の総覧も参照すると全体像がブレません。
DNS と Fake-IP：TUN とセットで頭の中で同期させる
「名前はdigで返るのにClash一覧がおかしい」というとき、OS のリゾルバ順序と Mihomo の dns セクション、Enable tun stack の組み合わせを一枚の図にしておくと早いです。DoH とローカルの別製品キャッシュDNSが競合しているとログは静かでも経路だけがフラップします。細部は Meta DNS リーク対策ガイド に譲りますが、ひとつの実務チェックだけ挙げるなら名前解決の当事者が誰かです。自分が Clash に寄せているつもりでターミナルだけ/etc/resolv.confの別名前を読んでいれば、リストの名前と評価の対象FQDN が食い違います。また企業環境での透明プロキシは証明書の置き換えとセットで名前の途中改ざんに見える挙動を起こすこともあり、そこだけ切り離して家で再現させるほうが収束も早くなりがちです。Windows の一部構成ではウィルス対策製品がローカルのフックにより独自の名前解決を挟みます。その場合 Mihomo側の名前が正しくても下流で遮断されていればアプリ側のエラーだけが残ります。
npm：registry と strict-ssl、スコープ、ミラーとの突合
CLI導線でまず確認するべきコマンド列は環境にもよりますが、最低限npm config get registryとnpm config list -lだけは通します。ユーザー領域、プロジェクト、CI由来の環境変数の三層を片付けずに増やすほど結果が読めなくなるので、「いま自分が叩いているシェル」の実値だけをソースにします。@google スコープが別registryへ向けられていたり、証明書を差し込む運用ではstrict-ssl falseが紛れていると、結果がセキュアではない経路だけ通るような歪みにもなり得ます。その是非は環境規程次第なので断定はできませんが、少なくとも意図と一致しているかは見ておいたほうがいいです。また tarball の転送だけ極端に遅くても中間に「小さく速いCDN→大きく遅いミラー」の二段階になっているときは一覧の並び順にホスト単位での差が読みやすく残ります。CIでprefer-onlineや--fetch-timeoutを増やしている例も見ますが、その前に経路側を正すほうが再現ログがきれいです。
# Minimal checks before blaming API keys
npm config get registry
npm ping
npm doctor
pnpm やyarn で同じワークスペースを触っているときはロックファイル側のインデックスURLが異なるだけで問題が増殖します。その場合でも「どのインデックスホストへどのTLSが張られているか」という観点は同じで、名前と証明書の二種類だけに注目すると判断が楽です。npx を使うワークフローでは一時ディレクトリに展開されますが一覧に出るドメイン列はnpm install相当と同質ですので比較のしようがあります。
CLI 実行後の Google API 側：証明書・認可・出口の三本柱
依存取得が成功しても、その直後や初回ログイン後にだけ止まる読者もいます。ログに出る名前がoauth2.googleapis.com系なのか、もっと細かく製品側の開発者コンソール名なのかを見れば、ルール側に足すべき共通サフィックスが変わります。環境によっては広告ブロックや会社のブラウザ分離機能が開発者コンソールの一部 URL だけ異常応答になり、OAuth が途中で終わって CLI が待ち続ける、という構成もまれに見られます。もう一本は証明書検証であり、経路側は正しいのに企業証明書の足りない中間チェーンや期限切れで止まっている場合はタイムラインだけでは判別できません。そのときはブラウザの開発者コンソールのTLSエラーとnpmのログの文言を並べられないかだけは試します。三本目は単純にGemini側の許可状態と課金境界ですが、経路側の問題と混ざって観察されるので、まずはネットワークのログとHTTPステータスの双方を離して見ることが重要です。Gemini ウェブのみを安定させたいときはブラウザ特化が早いので、並行読みで 前述の Gemini ウェブ記事 を活用してください。
そのまま使えるワークフロー：迷子になりにくい順番
- ClashをRULEで読み込み、ダッシュボードにエラーが無い状態にする。
- 失敗を再現するコマンド（
npx/npm i -g/gemini …のいずれか）を一つだけ決める。 - TUNをオン→同じシェルで再実行して一覧とログを比較する。
DOMAIN-SUFFIXで不足ホストのみを増やす。MATCH手前での評価順を確認する。- DNSと
dig／OS側の並び／DoH競合を点検する。 - npm側の
registryと.npmrcおよびNPM_CONFIG_*を実値だけ見る。 - 必要最小限のみ
HTTPS_PROXY類を試し、過剰な二重経路になっていないか戻して確認する。
注意：契約／学校・会社の運用規程によりプロキシ改変やTUNが禁止される場合があります。その場合は情報システムの案内だけに従ってください。
よくある質問
ウェブではnpmのページも開けるのに CLI の取得だけタイムアウトするのはなぜ？
ブラウザとNodeのHTTP実装／プロキシ解釈／証明書ストア／IPv4・IPv6の優先順位が異なるだけで、その差が出ます。TUNはまずターミナル発の経路だけを統一します。
ルール追加後も tarball で止まる
名前は正しいがリダイレクト先が一覧に載っていない、あるいは社内証明書で TLS が落ちている可能性があります。分流とnpm configを同じセッションで見直してください。
API キーは正しいが応答しない
キー設定以前に経路側でドロップされていないか、OAuth途中のブラウザ遷移だけ遮断されていないかを疑います。Geminiコンソールの権限状態も別視点で確認します。
まとめ
Gemini CLI（google-gemini/gemini-cli）は2026現在もアクティブに更新されている公式ターミナルツールで、開発者検索クエリにも現れ続けるテーマです。導線はnpm/npxに集約されがちな一方、実際はregistryと tarball とGoogleのAPI名前空間への縦長のHTTPSチェーンになり、ブラウザとの経路非対称だけでタイムアウトに見えてしまう場面があります。ClashのTUNと分流ルール、それにDNSとターミナルプロキシ、npmの設定を順に揃えれば、モデル側以前のレイヤでの詰まりはかなりの割合で解消されます。とはいえ、プロファイルを手だけで書き換え続けるよりログと一覧が並んだクライアントのほうが詰まりの発見は速い経験も多く、まだ試していない方は 無料で Clash をダウンロードして本文のワークフローと同順で設定し、自分の一覧に載る実名だけを増やしていく運用へ移してください。