検索意図：移行直後に「ブラウザは動く・CLI だけ詰まる」が増える理由
ユーザーが入力しがちなのは「Kiro CLI インストール 遅い」「Amazon Q Developer CLI から更新」「npm ETIMEDOUT」「AWS SSO login できない」「terminal proxy mac」「Clash TUN DNS」といった組み合わせです。製品側のバージョンやパッケージ名は時期で変わり得ますが、ネットワーク観点ではだいたい次のレイヤが重なります。第一段階は npm が registry.npmjs.org（または社内／地域ミラー）からメタ情報を取り、続いて tarball の実体を別ドメインへリダイレクトされながら落とす長い HTTPS チェーンになります。第二段階は Kiro 系 CLI が公式またはサードパーティのバイナリ・プラグインマニフェストを取得するときの追加ホストです。第三段階はモデル推論やクラウド側 API のエンドポイントです。第四段階が AWS SSO で、ブラウザを開いてデバイスコードや OIDC のリダイレクトを経由しつつ、CLI がローカルのコールバックを待つ構成になりやすい点が「ブラウザと経路がズレる」典型です。検索意図としてはいずれか一つが表に出ていても、裏では複数段が同時進行しているので、ログに出たFQDN単位で整理するのがもっとも壊れにくいです。
さらに分流ルールを静的リストだけで固定すると、CDN の切替やリージョンごとの別名ですぐ陳腐化します。そのため本稿では「必須ドメイン一覧」よりClash の接続ログをソース・オブ・トゥルースにする方針を取ります。ログに名前が出ず IP だけのときはDNS と sniffer／fake-ip の評価順を疑う順番になります。Amazon Q Developer 時代からの移行でキャッシュされた古い証明書検証エラーや、残留した HTTPS_PROXY が二重経路を作っている場合もあり、単にルールを増やしても改善しないパターンがあります。
ブラウザは速いのにターミナルだけ失敗する構造
ブラウザは多くの OS でシステムプロキシを尊重しやすく、証明書ストアも GUI と同步していることが多いです。一方 Node.js の npm は環境変数・.npmrc・ユーザー／プロジェクトごとの設定が積み重なり、企業端末ではターミナルだけ別ポリシーになる構成も珍しくありません。Kiro CLI のような Go／Rust／Electron 系バイナリを混ぜたスタックでは、HTTP クライアント実装ごとにプロキシ解釈が異なり、単一の export HTTPS_PROXY=... が効かないケースもあります。ここでTUNは「アプリがどのライブラリで HTTP を張ろうとも、OS のルーティングより手前で一度 Clash に載せる」という意味で強力です。例外として、ヘルパーや権限が未完のまま GUI 上だけオンに見える状態はログが静かでも実際は迂回できておらず、まずグラフィカル設定と OS のセキュリティダイアログの両方で確認してください。
AWS SSO はブラウザ側の signin.aws.amazon.com や地域起点のログイン URL、OIDC のトークンエンドポイント、場合によっては企業 IdP のホストへ分散します。CLI が待つローカルコールバックはプロキシの対象外ですが、認可フローの前半の HTTPS が迂回できていないとブラウザさえ開いても途中で止まります。経路非対称（ブラウザはプロキシ経由、CLI の外向きだけ直結など）は split horizon DNS と組み合わさると特に紛らわしいので、検証では同一端末・同一 Wi‑Fi でRULEモードとログ表示を固定してください。
第1手：TUN を有効にしてターミナル発トラフィックを掬う
具体的なクリック順はクライアントによりけりですが、方針は共通です。Clash をRULE（分流）で動かしたうえで TUN をオンにし、競合する別製フルVPNは切り離します。二つの VPN が同時だとログが二重になり原因特定が難しくなります。続いて失敗するコマンド（例：npm install、CLI のバージョン確認、aws sso login）を同じシェルから再実行し、一覧に新しく並ぶホスト名をメモします。Mixed port と SOCKS の取り違えは途中経路だけおかしくなる典型なので、設定画面のポート番号を一字一句確認してください。TUN と手動 HTTPS_PROXY をいきなり併用しない運用も推奨します。二重経路はタイムアウトだけが増えやすく、ログも読みにくくなります。
運用ヒント：WSL2 利用時は Linux ゲストと Windows ホストで境界が増えるため、ホスト側 TUN とゲスト側環境変数の二枚看板になりやすいです。ゲストで詰まる場合は WSL2 と npm の記事 も合わせて確認してください。
分流ルール：AWS・npm・OIDC をログ起点で足す
よく名前に出やすい起点としては *.amazonaws.com、amazonaws.com.cn（中国リージョン利用時）、signin.aws.amazon.com、oidc.* 配下、企業 IAM Identity Center のスタート URL、npm では registry.npmjs.org・npmjs.org・ tarball の CDN（ログに出た名前へDOMAIN-SUFFIX）などがあります。RULE-FINAL（MATCH） が意図せず強い直行や DIRECT に寄っていると、ほかの細かいルールを足しても効きません。評価順を MATCH より手前へ持ってきたうえで、ログの色とラベルが期待どおりかを確認してください。GEOIP だけに頼る運用でも動くことはありますが、CLI 問題では名前ベースとの併記が安定しやすいです。分流全体の整理は GEOIP・geosite 分流の総覧 が参考になります。
# Sketch: add only hosts your logs show during failures
rules:
- DOMAIN-SUFFIX,amazonaws.com,YOUR_PROXY_GROUP
- DOMAIN-SUFFIX,aws.amazon.com,YOUR_PROXY_GROUP
- DOMAIN-SUFFIX,npmjs.org,YOUR_PROXY_GROUP
# SSO / IdP hostnames from connection log
実際の運用では製品アップデートで追加ホストが増えるため、「一度きりの完全リスト」よりログを見て増分で足すほうが長期もちます。レートリミットやノード側の輻輳が疑わしいときはルール以前に出口や DNS の再試行過多も見ます。
DNS・fake-ip・nameserver-policy をルールと同期させる
「dig では返るのに Clash 一覧の名前がおかしい」「fake-ip のせいで評価対象がずれる」といった症状は Mihomo 利用者で繰り返し出ます。nameserver-policy を使えば +.amazonaws.com や +.npmjs.org などドメイン別に DoH を割り当て、社内リゾルバと競合しにくくできます。細部のリーク対策は Meta DNS リーク対策 に譲りつつ、実務の要点は名前解決の当事者が誰かを一枚のメモにすることです。別製品のローカル DNS が透明プロキシのように振る舞うと、一覧だけ正常でもアプリ側が別経路を読むことがあります。fake-ip を使う場合は fake-ip-filter や評価順をルールと矛盾させないよう、問題発生時は一度ログのホスト別に「名前→出口」を表にして確認してください。
nameserver-policy の具体例は nameserver-policy のドメイン別 DoH 記事 で段階的に追えます。AWS と npm を同じポリシーに押し込みすぎると一方だけ速くなる副作用もあるため、ログで詰まっている側だけを切り出すのが安全です。
npm：registry・strict-ssl・ミラーとの突合
CLI のセットアップやアップグレードでまず通すべき最低限は npm config get registry と npm config list -l、可能なら npm ping です。ユーザー領域・プロジェクト直下の .npmrc・CI 由来の環境変数の三層を混ぜず、「いまのシェルで実際に効いている値」だけをソースにします。社内ミラーが上流と同期できていないと、一覧上はタイムアウトだけが残ります。strict-ssl false が紛れているケースはセキュリティ上の是非は別として、少なくとも意図と一致しているかは確認してください。 tarball の転送だけ極端に遅いときは CDN とミラーの二段構えになっていることがあり、接続ログのホスト順を読むと判別しやすくなります。
# Minimal checks
npm config get registry
npm ping
npm doctor
pnpm や yarn を併用しているモノレポではロックファイルのインデックス URL が食い違い、症状だけが増殖することがあります。その場合でも「どのホストへ TLS が張られているか」という視点は共通です。
AWS SSO と CLI：ブラウザ連携の経路を揃える
aws configure sso から始まるフローでは、スタート URL の入力、ブラウザでの許可、CLI 側のトークン保存までが一連です。途中の HTTPS が迂回できていないホストが一つでもあると、画面上は「待機」のままになります。ブラウザの広告ブロックや企業の URL フィルタが IdP の一部パスだけ異常応答にすることもあります。CLI が参照する AWS エンドポイントと、ブラウザが開くログイン URL が同じ出口・同じ DNS 視点にあるかを確認してください。ca-bundle をカスタムしている環境ではブラウザと CLI で信頼鎖が異なるだけで失敗することもあるため、エラーメッセージに x509 が出ていないか並べて読みます。
なお本稿はネットワーク経路の整え方が主題であり、IAM の権限設計や SCIM 連携そのものの説明はしません。経路が整ったあとも API 側で拒否される場合は、コンソールの権限と別線で CLI のプロファイルを確認してください。
そのまま進めるワークフロー
- RULE でプロファイルを読み込み、ダッシュボードに設定エラーが無いことを確認する。
- 失敗する操作を一つに決め（npm／CLI 更新／SSO など）、再現直前から接続ログを開く。
- TUN をオンにして同じシェルから再実行し、増えた FQDN をメモする。
DOMAIN-SUFFIXなどで不足ホストのみルールに追加し、MATCH 手前で評価されることを確認する。- DNS・fake-ip・nameserver-policy を見直し、別リゾルバとの競合を解く。
- npm の registry／証明書設定を実値で確認する。
- 必要最小限だけ
HTTPS_PROXYを試し、二重経路になっていないかを戻して確認する。
注意：契約・学校／会社の規程により TUN やプロキシ改変が禁止されている場合があります。その場合は情報システムの案内にだけ従ってください。
よくある質問
Q CLI からの更新コマンドと Kiro CLI のパッケージ名が記事と違う
公式ドキュメントが更新されるとコマンド例やパッケージ名も変わり得ます。本稿のネットワーク手順は製品名が変わっても適用できます。迷ったら公式のインストール手順を優先しつつ、ログの FQDN はその時点の実測をソースにしてください。
ルールを追加しても npm の tarball で止まる
リダイレクト先ドメインがログに載っていない、fake-ip と実接続が不一致、企業証明書で TLS が落ちているなどが典型です。分流と npm config を同じセッションで突き合わせてください。
SSO のブラウザは開くが CLI が認証完了しない
ローカルコールバック以外の外向き HTTPS がまだ迂回できていない、またはブラウザ拡張がリダイレクトを改変している可能性があります。TUN をオンにした状態でログのホストをもう一度確認してください。
まとめ
Kiro CLI は Amazon Q Developer CLI 利用者の移行先として注目度が高く、検索にも「アップデート」「SSO」「npm」の語が集中しやすいテーマです。一方で症状は npm registry・プラグイン配布・モデル API・AWS SSO が縦に連なるHTTPS の複合問題になりがちで、ブラウザだけ見ていると取りこぼします。Clash のTUNでターミナルプロキシを揃え、ログ起点で分流ルールを増やし、DNS の nameserver-policy と fake-ip を同期させれば、再現性のある切り分けがしやすくなります。手だけで YAML を書き換えるより、一覧とログが揃った公式クライアントのほうが詰まりの発見が速い経験も多いので、まだ試していない方は 無料で Clash をダウンロードし、本文のワークフローどおりに一度セットアップしてから、自分の環境のログに載ったホスト名だけを増やしていく運用へ移るとよいでしょう。