検索意図から押さえる：何が「依存のタイムアウト」に見えるか
公式手順では uvx での google-agents-cli 実行や、npx 相当の npm エコシステム経由の起動が前提になりがちです。このとき裏側では PyPI あるいはミラー、npm registry、それに付随する registry.npmjs.org 以外の 静的配信 ドメイン、さらに本体が参照する API や 認可 系ホストへの往復が重なります。画面に出る文言は「Resolved …」「Downloading …」のまま進捗が伸びない、または ECONNRESET／ETIMEDOUT 風の一般化された失敗に折り畳まれるため、利用者側からは単に「依存取得が不安定」と認識されやすいのが実情です。性能ではなく 経路 を疑う第一歩として、失敗の直前に 接続ログ に出る FQDN を一つだけ決め、そこから Clash の設定と各ツールの registry を突き合わせてください。
なぜブラウザは速いのにuvやnpmだけ詰まるのか
多くのブラウザは システムプロキシ を尊重しますが、Node の npm クライアントや uv が内部で呼ぶ HTTP スタックは、環境によっては プロキシ環境変数 を見ない／見方が限定的なことがあります。加えて ターミナル は GUI アプリと別ユーザーコンテキストで動き、シェルの export がログインセッションにだけ存在する、というよくある落とし穴も重なります。結果としてブラウザだけ「きれいなポリシー」に乗り、npm install や uv tool install が 直結 や不安定回線へ落ちる 経路非対称 が再現します。Clash の TUN はここを OS のルーティングでまとめて掬えるため、まず「ターミナルを同じ分流に乗せる」ことを最優先にすると切り分けが早くなります。Windows で WSL2 を挟む場合は別稿の WSL2 と Clash のポート連携 も参照し、ホスト TUN とゲスト側の二重設定に気を付けてください。
第1の一手：TUNでターミナルのHTTPSを捕捉する
HTTP／SOCKS の手動指定だけに頼ると、ツールごとの挙動差で抜け穴が残ります。TUN を有効化すると、ルーティングテーブル上のトラフィックが仮想NICに流れ、Clash Meta（Mihomo）系のルールエンジンへ集約されやすくなります。GUI クライアントでは初回に管理者権限、ネットワーク拡張、ヘルパーの承認が必要になるため、ダイアログを閉じ損ねると「有効化したのに変わらない」状態が続きます。具体的なクリック手順は Clash Verge Rev の TUN モード完全ガイド に譲ります。本稿では方針だけ固定し、google-agents-cli を入れ直す前に TUN ON → 同じ ターミナル で再現コマンド、の順にしてください。
実務のコツ：TUN とシステムプロキシを同時に弄りすぎるとログ判読が難しくなります。まず TUN 単体で再現し、残る抜け穴だけ HTTPS_PROXY やツール固有の設定で埋めると原因が見えやすいです。
分流ルール：ログ起点で npm・PyPI・GitHub を拾う
固定の「必須ドメイン一覧」は更新頻度に追いつきません。現場では 接続ログ に出た名前を DOMAIN-SUFFIX や DOMAIN-KEYWORD で拾い、実際に使う プロキシグループ へマッピングするのが再現性が高いです。典型例として registry.npmjs.org、npmjs.org 周辺、pypi.org、files.pythonhosted.org、github.com や objects.githubusercontent.com、そして Google 側の配布・API サブドメインが混ざります。GEOIP だけに寄せると CDN エッジの所在地で意図しないノードに落ちることがあるため、困っているホストを個別に足すほうが google-agents-cli の取得安定化には向きます。ルール順は MATCH 前方で意図どおり通過しているか、ログのチェーンで必ず確認してください。
# Example sketch: observed hosts -> your policy group (replace YOUR_PROXY_GROUP)
rules:
- DOMAIN-SUFFIX,npmjs.org,YOUR_PROXY_GROUP
- DOMAIN-SUFFIX,pythonhosted.org,YOUR_PROXY_GROUP
- DOMAIN-SUFFIX,github.com,YOUR_PROXY_GROUP
サフィックスの綴り誤りやグループ名の typo は、画面では「謎のタイムアウト」として only 現れがちです。分流の大枠は GEOIP・geosite 分流 も参照しつつ、CLI 取得問題ではログに出たホスト単位の追い込みを優先してください。
DNSとFakeIP：ルール評価と実IPのズレを潰す
「ルールを足したのに効かない」ように見えるとき、OS や別製品の DNS が別経路を向いており、得られた 実IP が想定と食い違っているケースが多いです。fake-ip を使う Clash Meta 系では、返る仮想アドレスと評価順を理解していないと一見ランダムな失敗が出ます。細部は Meta コア DNS リーク防止ガイド に譲りますが、google-agents-cli の導入トラブルでは「名前は解けているつもりが別リゾルバ」「DoH が二重」などを疑ってください。TUN と DNS ハイジャックを併用するとき、企業エージェントのフィルタと競合しないかも合わせて見ます。
npmとuv：レジストリ・指数URL・プロキシの突合
npm では npm config get registry と、プロジェクト／ユーザーごとの .npmrc、CI 由来の NPM_CONFIG_REGISTRY が実際の取得先を変えます。社内ミラーや地域ミラーへ向けている場合、そのミラー自身が外部と同期できていないと、画面上はずっと「取得中」に見えることがあります。uv は UV_DEFAULT_INDEX や設定ファイル、--index-url 相当の指定で PyPI 以外を向くことがあるため、google-agents-cli を uvx で取る文脈では指数URLの行き先を明示的に確認してください。どちらのツールでも HTTPS_PROXY／ALL_PROXY をシェルに入れる前に、listening ポート（mixed-port や SOCKS）が実在し Allow LAN 等の制約に引っかかっていないかを見ます。NO_PROXY に社内サフィックスを入れて直結を残す運用は有効ですが、今回のような外部配布の取得では範囲を狭くし過ぎないよう注意してください。
実務ワークフロー：迷子にならない順序
- Clash を Rule で動かし、購読・ポリシー階層がエラーなく読み込めているか確認する。
- 失敗する導入コマンドを一つに固定し、その直前から 接続ログ を開く。
- TUN を有効化し、同じコマンドを再実行してログの差分を見る。
- 露出した FQDN を 分流 に反映し、MATCH に吸われる前に正しいグループへ流れるか確認する。
- DNS／fake-ip と他リゾルバの競合を切り分ける。
- npm／uv の レジストリ と 端末プロキシ を点検し、必要なら環境変数で補強して再試行する。
注意：利用契約や学校・企業ポリシーによりプロキシや経路変更が禁止されることがあります。許可された範囲でのみ設定を変更してください。
よくある質問
ブラウザでは開けるのに google-agents-cli の取得だけ失敗するのはなぜ？
ターミナル系クライアントはプロキシを通さないデフォルトが残りやすいです。Clash の TUN でまず経路を揃え、ログに出る レジストリ ドメインを 分流 で確実に捕捉してください。
ルールを増やしても npm や uv がタイムアウトする
DNS の返答とルール評価がズレている、ミラーURLが同期遅延、あるいはツールが別の指数URLへリダイレクトされている可能性があります。npm config と uv の指数設定を接続ログと突き合わせてください。
会社支給のPCでも同じですか？
MDM やゼロトラストでブロックされている場合は手順どおりにいきません。情報システムの指示に従ってください。
まとめ
Google Agents CLI（google-agents-cli）は uv と npm の両方から導入フローが用意される一方、取得チェーンは複数ドメインにまたがるため、ブラウザとの 経路差 が残るとタイムアウトに見えやすいです。Clash の TUN で ターミナル をまとめて掬い、ログ優先で 分流 を磨き、DNS と fake-ip をルールと揃え、npm／uv の レジストリ と 端末プロキシ を点検すれば、ドキュメントどおりの再現性が大きく上がります。汎用コマンドだけを手で叩き、設定一行のミスで全体が不安定になるより、プロファイルとログが同じ画面で扱えるクライアントのほうが詰まりどころの発見が早い場面も多いです。まだ試していない方は 無料で Clash をダウンロード し、本文の順番どおりに TUN と DNS、ツール設定を揃えてください。