Gemini CLI でパッケージ取得がタイムアウト？Google AI と npm registry を Clash・mihomo で分流して切り分ける実測手順（2026）

1. なぜ CLI では「片方だけ」タイムアウトしやすいか

第一の理由は、Node／npm が参照する HTTP スタックと、CLI 本体の HTTP クライアントが別実装になりやすいことです。どちらも HTTPS でも、プロキシ環境変数を読むか、OS のシステムプロキシを信じるか、TUN 配下で自動的に奪われるかはランタイムごとに違います。その結果、同じマシンでも googleapis 系は迂回ノードへ、npm の tarball だけ直結のような非対称な出口ができ、タイムアウトや TLS handshake の失敗がコマンドの種類だけで再現性が変わるように見えます。

第二に、Google AI 周辺は単一ホストに集約されにくい点です。generativelanguage.googleapis.com のような具体的な API ホストに加え、googleapis.com 配下の他サービス、場合によっては ai.google.dev やドキュメント／OAuth まわりのホストが絡みます。購読テンプレの「PROXY」一括送りのままでは、意図しないノードや DIRECT にばらけるため、失敗している fqdn をログで拾い、サフィックス単位で束ね直す運用が安全です。

第三に、症状がプロキシ以前のレイヤにあるケースです。例えば API キー期限切れ、プロジェクト設定、課金やクォートなどは、HTTP ステータスや JSON のエラーメッセージに現れます。本稿は経路・名前解決・registry の技術的な詰まりに絞り、アカウント側の順守や設定ミスは別途公式ドキュメントと合わせて確認してください。

2. ブラウザ版 Gemini・QUIC 記事・他 AI CLI 稿との違い

当サイトのブラウザ向け Gemini・Google AI の記事は、画面読み込みと HTTP/3（QUIC）の切り分けが主役です。検索意図も「ページが開かない」「一部リソースだけ落ちる」に寄りがちで、Chrome や Edge の安全な DNS・QUIC 無効化とセットで読む想定になっています。

一方、本稿はGemini CLI・ターミナル・npm／npxにフォーカスします。検索キーワードも「CLI」「registry」「TLS」「タイムアウト」に寄るため、ブラウザ稿と記事同士が検索結果で食い合わない補完関係になります。QUIC が絡む場合はブラウザ稿の知見を、純粋に HTTPS（TCP）と名前解決の話は本稿を優先してください。

Claude Code と Anthropic＋npmの稿は、別ベンダーの API と npm を束ねる点で構造が似ています。ドメインセットが Anthropic から Google に置き換わるイメージで読み替えてください。Cursor 向けの開発者ドメイン稿は IDE 公式ホスト中心であり、Gemini CLI と npm の二本立ては本稿の方が直截です。

MCP と npm／GitHubの記事は Model Context Protocol と tarball／GitHub APIが前面です。Gemini CLI が GitHub 上のパッケージに依存しそうなら、その稿のドメインもログで必要分だけ併用してください。

3. ログから拾う Google AI と npm のホスト束

ドメインはサービス側の変更で入れ替わり得るため、以下は切り分けの出発点です。実際にコアログや CLI のエラーに出た fqdnを最優先し、足りなければ追記してください。

Google AI／Gemini API では generativelanguage.googleapis.com や *.googleapis.com、ドキュメントや認証周辺では google.com 配下の別名が出ることがあります。広すぎる DOMAIN-SUFFIX,google.com は国内向けトラフィックまで巻き込み得るため、まずはgoogleapis.com などAPI に直結しそうなサフィックスから始め、ログで不足分だけ上乗せするのが運用上つきにくいです。

npm では registry.npmjs.org が標準のメインレジストリです。npmjs.org／npmjs.com 系や tarball のホスト名もログに出たら同じ開発者向け策略へ寄せるか、レート制御のために別策略に分けるかを選べます。社内 Verdaccio やミラー URLを使う場合は、その fqdn を必ず明示ルールに含める必要があります。

ルールの評価順は ルールルーティングの解説どおり、具体的な DOMAIN／DOMAIN-SUFFIX を MATCH や広い GEOIP より上に置きます。購読ルールの末尾にだけ追記すると効かない典型なので、追記位置もログとセットで確認してください。

4. mihomo ルール例：DOMAIN-SUFFIX と並べ順

実務では 「Gemini CLI＋npm 開発」用の策略グループを一つ用意し、関連サフィックスをそこへ送る形が扱いやすいです。以下は構造の例です。プロキシ名・末尾の MATCH は環境に合わせて置き換えてください。

# proxy-groups: single egress bucket for Gemini CLI + npm
proxy-groups:
  - name: GEMINI_DEV
    type: select
    proxies:
      - LOW_LATENCY
      - NODE_FRIENDLY
      - DIRECT

# rules: developer hosts before broad MATCH / GEOIP
rules:
  - DOMAIN-SUFFIX,googleapis.com,GEMINI_DEV
  - DOMAIN-SUFFIX,registry.npmjs.org,GEMINI_DEV
  - DOMAIN-SUFFIX,npmjs.org,GEMINI_DEV
  - DOMAIN-SUFFIX,ai.google.dev,GEMINI_DEV
  - MATCH,PROXY

generativelanguage.googleapis.com は googleapis.com に包含されますが、ログで別名ばかり見る場合は明示行を足すとレビューしやすくなります。PROCESS-NAME で Node や Gemini CLI の実行ファイルだけを分ける手もありますが、OS やパッケージ管理によるパス違いが出やすいので、まずドメインで束ねるのが無難です。

TUN と併用する場合は TUN モードの解説も参照し、名前解決クリーンアップと実接続の策略が矛盾していないかを確認してください。

5. 策略グループ：開発者向け出口を固定する意味

API 呼び出しと tarball 取得で別ノードにばらけると、片方だけ輻輳やフィルタに引っかかったように見えることがあります。select でレイテンシの良いノードに固定し、チーム内で「Gemini／npm 用の推奨ノード名」を共有すると、個人間の切り分けコストが下がります。

自動切替を使うなら url-test／fallbackの間隔が、対話的 CLI の体感に合うかを見てください。長めのストリームやアップロード途中でノードが切り替わると、クライアント側がタイムアウト扱いにする場合があります。

UDP を使う HTTP/3 を CLI ランタイムが選ぶ環境では、TCP の HTTPS より不安定に見えることがあります。ブラウザ主体の切り分けはGemini QUIC 稿へ譲り、本稿ではまず TCP と名前解決を優先します。

6. DNS・fake-ip をルールと噛み合わせる

dns.enhanced-mode を fake-ip にしていると、ブラウザと CLI で名前解決の経路が分岐し、DOMAIN ルールが思ったとおりに評価されないように見えることがあります。対照と修正の順序は Clash Meta の DNS モード比較記事にまとめています。

fake-ip-filter にレジストリ fqdn を入れるか、nameserver-policy で googleapis／npmjs 向けの問い合わせ先を分けるかは、自環境の再帰問い合わせの挙動と購読テンプレに依存します。つまずいたら 「そのホストの解決がどこで終わっているか」をログに残し、ルールのサフィックスと一致しているかを確認してください。

ブラウザの「安全な DNS」が有効だと、OS や Clash の意図とずれます。Windows の Chrome／Edgeでは システム代理と DoH の校正も合わせて確認すると、Web 周辺と CLI を同じ前提で語りやすくなります。

7. ターミナル・npm のプロキシとレジストリ URL

TUN やシステムプロキシが有効でも、npm が環境変数なしで直結することは珍しくありません。HTTPS_PROXY／HTTP_PROXY と NO_PROXY を、社内ミラーや localhost 向けに分割して書く手順は、Windows 向け npm／pnpm と環境変数の記事が一層詳しいです。macOS や Linux でもシェルにエクスポートする値と mixed-port の不一致は同型で起きます。

npm config get registry が社内 URL に変わっている場合、その fqdn 用のルールが無いと意図せず DIRECTになります。サブスクリプション導入でポートを揃えたあと、実際に listen している mixed-portと環境変数の宛先が一致しているか確認してください。

コンテナや CI で同じワークフローを回す場合、ホストとコンテナのネットワーク名前空間が別物です。Docker とホストの Clashを参照し、ゲートウェイ・NO_PROXY・buildkitまで含めて再チェックしてください。レジストリ風のタイムアウトは Docker Hub とミラー の稿とも症状が似るため、pull 主体ならそちらも併読価値があります。

8. 実測の切り分け手順とログの見方

推奨の順序は次のとおりです。（1）コアログで問題のホストがどの策略にマッチしたかを確認する。（2）意図した策略なのにタイムアウトするなら、そのグループ内のノードを入れ替えるか、同一ホストで別経路のレイテンシを比較する。（3）TLS アラートや確定的な HTTP エラーなら、経路以外（キー・レート・課金）を疑う。

Gemini の呼び出し直後だけ npm が固まるように見える場合、同時接続数や帯域がノード側の閾値に触れていないかもログで確認してください。体感の「なんとなく直った」ではなく、ホスト名・策略名・時刻をメモに残すと、再現性とルールの肥大化防止の両方に効きます。

Windows 本体で Clash の購読更新自体が不安定なら、購読の TLS／DNS ログ稿で上流のつまりを先に潰す方が早いです。CLI の話に入る前にコアが健全に更新できる状態かを確認してください。

9. よくある質問

10. まとめ

Gemini CLIは Google AI の API と npm registryを短い間隔で連続して叩くワークフローになりやすく、出口や名前解決が少しでもずれるとタイムアウトや TLS 失敗に見えます。mihomo で googleapis／npmjs 系を開発者用策略に束ね、DNS fake-ip と矛盾がないか確認し、必要ならターミナルのプロキシ環境変数まで揃える——この流れは、ブラウザ版 Gemini 稿や他ベンダー CLI 稿と検索意図を分担する補完記事として整理できます。

汎用 VPN クライアントや古いプロキシ手順のままだと、GUI では「つながったつもり」でもCLI だけ別経路のままになり、ルールの追記位置や DNS を変えても改善が頭打ちになりがちです。購読と YAML をモダンなコアで保守でき、ドメインと fake-ip をログから揃えていけるクライアントの方が、開発者向けの切り分けコストは下がります。環境を一度リセットして試すなら、 → 無料で Clash をダウンロードし、快適な接続体験を試す から入手し、本稿のルールと組み合わせるのがおすすめです。