1. 検索意図と前提：CLI が詰まる理由は「モデル」だけではない

本稿が想定する読者は、検索どおり「Claude Code CLI で開発したいのに、npm タイムアウトや GitHub 由来の取得停止、Anthropic API の実行だけ不安定」といった症状を、単に別ノードへ差し替えるのではなく再現性のある手順で直したい方です。CLI はブラウザよりプロキシ設定の取り込み方が不均一で、OS のシステムプロキシを読まず環境変数だけ見る、逆に古い HTTP_PROXY が残って二重に効く、などのズレが起きやすいです。まず「すべてが遅い」のか、「取得フェーズだけ」「推論フェーズだけ」といったレイヤーごとの失敗なのかを分けると、その後の YAML 編集が速くなります。

購読ルールの基本がまだ不安な場合は、サブスクリプション取り込みの記事で全体像を押さえてから読み進めてください。

2. よくある症状の型：装備フェーズと実行フェーズを分ける

装備フェーズでは npm install、グローバル CLI の更新、バイナリのダウンロード、証明書チェーンの取得などが中心です。実行フェーズでは Anthropic API への長めの HTTP セッション、ストリーミング応答、補助的なテレメトリや認証エンドポイントが増えます。前者だけがタイムアウトするなら registry／CDN／GitHub 側の経路分裂を疑い、後者だけが不安定なら API サブドメインと DNS の整合を疑うのが筋です。両方ダメなら、全量代理の遅延やノードの輻輳、あるいはターミナルがプロキシを無視して直結している可能性が高まります。

3. 通信を「面」に分けて眺める（CLI 版）

以下は設計メモです。ホスト名は実ログでの置き換え前提であり、完成ルールのコピペ集ではありません。

面典型ホストのイメージ症状との対応
npm registry と tarballregistry.npmjs.org、リージョナルミラー、パッケージ tarball の配信 CDN依存解決は進むが取得だけ止まる、ETIMEDOUT が続く。
GitHub／Gitgithub.com、api.github.com、raw／releases の配信ホストgit clone や GitHub CLI のログイン以外は通るのに特定操作だけ失敗。
Anthropic API と周辺api.anthropic.com ほかログで確認できる名前ローカル編集は軽いがモデル実行だけ切断やタイムアウト。
付帯サービスログ送信、設定同期、サードパーティ SDK のエンドポイント本体は動くが警告だらけ、稀にレート制御が連鎖。

2026 年時点でも各社がエッジ構成を更新し続けるため、過去に動いた静的ルールだけへ依存するのは危険です。自分のログでホスト表を更新するのが最も安全です。

4. ブラウザ Claude 既稿との読み分け

Claude／Anthropic の Web・API 分流記事では、ブラウザで触れる claude.ai と一般 API の安定化を扱いました。本稿は同一プロバイダでも経路集合が異なるという前提で、CLI のパッケージ取得と実行時 APIに絞ります。症状が似ていても FQDN が違えば、記事を読み分けたうえでルールを束ねてください。OpenAI 系の並列接続はCodex／コンソール分流の記事と題材分担になります。

5. ログ収集：シナリオを三つに分ける

CLI のログは一度に流れ込むため、次の三つのシナリオへ分けると読みやすくなります。

  1. Clash を起動し、システムプロキシかTUNのどちらかに統一する。併用 VPN は一旦オフにする。
  2. ターミナルだけ別の http_proxy を持っていないか確認し、必要なら一時的にクリアして再現する。
  3. npm のクリーンインストールだけを単独で走らせ、registry／tarball のホストと命中したポリシー名をメモする。
  4. 続けて GitHub へのアクセス（git fetch、GitHub CLI、リリース DL）を実行し、api とオブジェクトストレージ系が npm と同じ出口かを見る。
  5. 最後に Claude Code CLI の実タスクを実行し、Anthropic API 周辺ホストのタイミングとステータスを拾う。

ターミナル全体のプロキシの扱いは、macOS ターミナルとプロキシの記事や、WSL を跨ぐ場合はWSL2 の記事と合わせると取りこぼしが減ります。コア自体が立ち上がらない場合は汎用トラブルシュートへ回してください。

6. npm が詰まるとき：registry・認証・ロックファイル

npm は企業レジストリミラー、プロジェクト直下の .npmrc、ユーザー全体の設定、環境変数の順で挙動が変わります。Clash のログ上では「registry はプロキシ」「 tarball の CDN だけ DIRECT」のような部分的成功がよく起きます。対策の核心は、ログに出た CDN サフィックスを購読ルールの広い DIRECT より上へ具体ルールとして置くことです。ミラーへ強制している場合も、実際の取得ホストが別名になるのでログ優先が鉄則です。

ヒント：npm config get registry と実際の fetch ログを突き合わせ、名前解決が OS の DNS と Clash の fake-ip で食い違っていないかも見ます。

7. GitHub と GitHub CLI：API とオブジェクト取得の二段構え

GitHub CLI を含む開発フローでは、ブラウザ OAuth、api.github.com、git 操作、大容量のリリース資産取得が別ホストへ分散します。GitHub 側だけ別ノードに落ちると、認証は成功しても後続の REST がタイムアウトする、という見え方になります。Clash の接続ビューで同一秒付近のホスト列を並べ、策略が三点跳びしていないかを確認してください。IDE 連携で SSE が絡む場合はCursor MCP と GitHub／SSE の記事も足し算になります。

8. Anthropic API：実行フェーズのホストと長回線

Anthropic API は TLS と HTTP の往復が細かく連なるため、軽いジッターでも CLI 側では「応答が途中で途切れた」ように見えます。ログでホスト名を押さえたら、誤った地理位置のノードへ流していないか、企業 FW のSSL 検査と衝突していないかも併せて確認します。ストリーミングが絡むときは、単発の curl では再現しにくいので、実際の CLI セッション中のログを主証拠にしてください。

9. 検証コマンド：curl と openssl を短時間で使う

GUI ログだけでは足りないときは、同一マシンで curl -v や openssl s_client を使い、名前解決と TLS のどちらで止まっているかを分けます。頻度とデータ量は最小にし、利用規約と社内ポリシーを守ることが前提です。プロキシ環境変数が二重に効いていないかも、この段階で潰せます。

10. DNS：fake-ip とサブドメイン爆増の相性

Anthropic API や npm CDN のようにサブドメインが増えるサービスでは、fake-ip と実アドレス解決の組み合わせ次第で「ルールに載った名前」と「実接続の宛先」の整合が崩れ、クライアントが静かにリトライを続けることがあります。上流 DNS を信頼できるサーバへ揃え、頻出サフィックスへ nameserver-policy 相当の設定を当てる、といったDNS の切り分けをルール編集と同列に置いてください。フィールド名は利用中の Mihomo／Clash Meta のバージョンで差があるため、公式ドキュメントとの照合が必要です。

11. 推奨する切り分け順序（チェックリスト）

  1. Clash が起動していること、システムプロキシかTUNで捕まえているかを決める。
  2. 接続ログで npm・GitHub・Anthropic API が意図したポリシーグループに入っているか、誤った DIRECT がないかを見る。
  3. DNS モードと fake-ip の組み合わせを確認し、必要なら特定ゾーンだけ実アドレス解決へ寄せる。
  4. registry／tarball／GitHub API／リリース資産／API をホスト／サフィックス単位でルール化し、購読内の広い DIRECT より上側へ矛盾なく配置する。
  5. 全体的に遅いだけなら、不要な大容量を出口から外すか、低揺らぎのノードへ寄せる。
  6. ターミナルだけ別経路なら、環境変数と mixed／HTTP ポートの一致を再確認する。

12. 分流ルールの考え方（記述例は置き換え前提）

購読ルールに「広い DIRECT」が先に入っていると、国内直結へ落ちるホストが紛れ込みます。より具体的な DOMAIN-SUFFIX を上側に置くのが実務的です。以下は例示であり、実際のホスト名はログで確認して置き換えてください。

# Example only — verify hostnames in your Clash logs before use
rules:
  - DOMAIN-SUFFIX,npmjs.org,PROXY
  - DOMAIN-SUFFIX,anthropic.com,PROXY
  - DOMAIN-SUFFIX,github.com,PROXY
  - DOMAIN-SUFFIX,githubusercontent.com,PROXY

API だけ別グループ（例：PROXY_API）へ切り出すと、「取得は速いが実行だけ不安定」といった切り分けがしやすくなります。グループ名は proxy-groups に定義済みである必要があります。

13. システムプロキシと TUN：CLI の取りこぼしを減らす

システムプロキシは導入が容易ですが、プロキシ設定を読まないプロセスがあると経路が分裂します。TUN はルーティング層で取り込むため一貫性は上がりますが、権限や競合のトレードオフがあります。手順はTUN モードの解説を参照し、有効化後に再接続ログで関連ホストが期待どおりか検証してください。

14. 追加の落とし穴：IPv6、証明書ピン留め、LAN 配布

IPv6 が有効な回線では、IPv4 だけプロキシに乗るなどデュアルスタックの偏りで API だけ別経路へ落ちることがあります。一部 CLI は証明書ピン留めを持ち、OS のプロキシ設定と食い違うことがあります。別端末へプロキシを配る場合はLAN プロキシの記事で allow-lan とファイアウォールの要点を確認してください。

15. よくある質問（短文）

Q. npm はシステムプロキシだけで足りますか？
場合によります。.npmrc や環境変数が優先されることがあるので、Clash ログと npm 設定を両方見てください。

Q. GitHub と npm を同じ策略でよいですか？
小規模では同一でも構いません。片方だけ不安定ならログで実測し、分割を検討してください。

Q. Anthropic のホストは固定ですか？
固定と決めつけず、ログで都度確認してください。

Q. TUN は必須ですか？
必須ではありません。取りこぼしが続くときの選択肢です。

16. まとめ：CLI のタイムアウトは「ホスト表の更新」が最短ルート

2026 年のコマンドライン AI ブームほど、検索に現れる「npm タイムアウト」「Anthropic API が繋がらない」は、単一パラメータより経路分裂と DNS の積み重ねで起きがちです。ログでホスト表を更新し、ルール順とターミナル環境を揃えれば、「とりあえず別ノード」より再現性の高い改善が期待できます。

この手の開発者向けプロキシ運用では、GUI で接続ログとルール編集を一体運用できるクライアントが長く使われます。一方で、購読ファイルだけ貼り替えるタイプのツールは、マルチホストの並列接続が増えるほどどこが直結になっているか視認しづらく、試行錯誤の時間が伸びやすい印象です。策略の見える化とコア設定の整合が取りやすい製品ほど、CLI と IDE を跨ぐ日常作業に耐えます。最初からログ優先の出口設計で組み立てたい方は、→ Clash を無料ダウンロードして、快適な接続体験を始める