この記事で分かること

2026 年前後、エディタ統合の Copilot 類とは別軸で、ターミナル中心に動く Claude Code（およびそれに近い開発者向け CLI／エージェント）をローカル PC で回す人が増えています。検索クエリには「Claude Code」「タイムアウト」「Anthropic API」「CLI」「プロキシ」が並びがちですが、現場でつまずくのはしばしばブラウザでは問題ないのに、ターミナルだけが間欠的に切れるというパターンです。

本稿では GUI クライアントとして Clash Verge Rev（Mihomo コアを束ねるデスクトップ向けフロントエンドの一つ）を前提に、(1) ルール分流（Rule）で Anthropic 関連ホストを意図したノードへ送る、(2) それでも取りこぼすときに TUN やシステムプロキシをどう足すか、(3) HTTPS_PROXY・HTTP_PROXY・ALL_PROXY・NO_PROXY をどのファイル／どのシェルセッションに書くか、までを一続きで整理します。万能ドメイン一覧は製品アップデートで変わりうるため、ログと curl で実際に叩かれているホストを確かめる前提にします。GUI の基本操作は Clash Verge Rev のチュートリアルも参照してください。

検索に現れる症状と、背後で起きていること

ユーザーが検索ボックスに打ち込みやすい言い回しと、画面／ログで見える事象の対応関係はおおむね次のとおりです。

  • リクエストが数十秒〜数分かかったあとタイムアウト：経路が迂回できず輻輳している、SNI が途中で詰まっている、あるいはプロキシを経由すべきホストが DIRECT のまま DNS だけ迷走しているときに起きやすいです。
  • 成功と失敗が交互に出る（フラッピング）：複数プロセスが別々のプロキシ設定を読んでいる、Keep-Alive の接続だけ古い経路に残っている、ノードの_health が不安定、など状態が二系統に分裂しているサインです。
  • HTTP 429 やレート制限に見えるがタイミングが奇妙：実際には TLS ハンドシェイクの再試行やリトライバックオフが表に出ていることがあります。まず Clash のログで接続確立の段階で止まっているかを切り分けます。

いずれも「ネットワーク自体が完全に死んでいる」のではなく、開発者ツール特有の HTTPS クライアントが期待どおりのプロキシチェーンに載っていないケースが多いです。Cursor のような Electron アプリ向けに書いた別記事の分流ガイドとはクライアントの種類が異なるため、ターミナルでは環境変数の比重が高くなります。

ルール分流とグローバル TUN：実務での選び方

Rule（ルール分流）は「どのドメイン／どの地理的属性を、どのポリシーに送るか」を YAML で説明可能にするモードです。日本の決済や国内 CDN は DIRECT、Anthropic・GitHub・モデルプロバイダは PROXYのように切りたいときの第一選択になります。ログ一行で「そのホストがどのルールにマッチしたか」が追えるため、開発者代理（開発機だけ細かく経路を変える）という運用と相性がよいです。

一方 TUN はカーネル近傍でトラフィックをキャプチャし、プロセスがプロキシ設定を無視していても一度 Mihomo に引きずり込める強力な手段です。反面、社内 VPN、ゼロトラストクライアント、別製品の仮想 NIC とスタック競合しやすく、トラブル時の切り分けコストも上がります。実務的には、(1) Rule とシステムプロキシでターミナルまで届くか確認、(2) それでも特定バイナリだけ直結するなら、そのプロセス限定で TUN を試す、(3) 全体を常時 TUN にするのは最後の手段、という順が安全です。

Clash Verge Rev 側では「システムプロキシをセット」「TUN を開始」といったトグルが並ぶため、ブラウザだけ整ってターミナルが裸のままというずれが起きやすい点に注意してください。ターミナルアプリを再起動したうえで、env | grep -i proxy を見る癖が効いてきます。

HTTPS_PROXY など：ターミナルが読む環境変数をどこに書くか

Node.js／Rust／Go 製の CLI は、ライブラリごとに参照する変数名が微妙に異なりますが、実務では次のセットを揃えておくとターミナル代理の取りこぼしが減ります。

  • HTTPS_PROXY：HTTPS クライアントがこちらを優先することが多いです。
  • HTTP_PROXY：http:// スキームの先行リクエストやリダイレクトで参照されます。
  • ALL_PROXY：SOCKS を明示したいときや、単一変数しか読まないツール向けの「よく効く保険」になります（ツールにより無視されます）。
  • NO_PROXY：localhost、127.0.0.1、社内イントラのドメインをカンマ区切りで除外し、ループや証明書ピンニングを壊さないようにします。

書き場所の典型例は次のとおりです。

  • 常時有効にしたい：~/.zshrc（Zsh）／~/.bashrc（Bash）。ログインシェルだけなら ~/.zprofile や ~/.bash_profile。
  • プロジェクト単位：direnv の .envrc に export HTTPS_PROXY=... を書き、リポジトリに入ったときだけ有効化する。
  • 一発検証：HTTPS_PROXY=http://127.0.0.1:7890 claude ... のようにコマンド前置きでセッションを汚さない（ポートは自分の mixed-port に読み替え）。

プロキシ URL は多くの場合 http://127.0.0.1:<mixed-port> で足ります（HTTP CONNECT で TLS をトンネルするため）。SOCKS5 を明示したい場合は socks5://127.0.0.1:<port> 形式になりますが、社内ポリシーやクライアント実装によっては HTTP の方が安定することがあります。

ルールに載せたいホストの「型」（ログで確かめる前提）

公開エンドポイントは変更されうるため、ここに固定リストは置きませんが、検索・ログで繰り返し見かけるホストの型として次を押さえておくとよいです。

  • Anthropic の API 本体：api.anthropic.com ほか、証明書と一致する名前だけをルールに載せる（中間証明書検査製品がある環境では別問題になります）。
  • 認証・コンソール・補助サービス：claude.ai や関連 CDN がログに混ざることがあります。
  • ソースコードや依存関係取得：Git リモートやパッケージレジストリが別経路だと、モデル API だけ成功してビルドだけ失敗する、という分裂した失敗が起きます。NO_PROXY の過不足を疑ってください。

実測のすすめ：Verge Rev のログレベルを上げ、Claude Code を一度動かして実際に SYN が張られたホスト名をメモします。その文字列をそのまま DOMAIN-SUFFIX または DOMAIN ルールへ載せると、憶測で広げすぎたルールより安全です。

TIP：一度だけGlobal に近い状態（すべてプロキシ側へ寄せるプリセット）で CLI を叩き、タイムアウトが消えるか確認してください。消えるならルール順・MATCH の先行・DIRECT 漏れが本命の原因です。

ルール記述の例（ポリシー名は自分のプロファイルに合わせる）

以下は Mihomo／Clash Meta 互換の想像上のスニペットです。PROXY はお使いのポリシーグループ名に読み替え、既存の MATCH より上へ置いてください。

# Example rules snippet — replace PROXY with your policy group name
rules:
  - DOMAIN-SUFFIX,anthropic.com,PROXY
  - DOMAIN-SUFFIX,claude.ai,PROXY
  - DOMAIN-KEYWORD,anthropic,PROXY

GEOSITE やサードパーティ製ルールセットを使っている場合でも、ログで DIRECT に落ちているホストを個別に足すほうが早いことがあります。中国語圏の記事で見かける「AI サービス一式をまとめてプロキシ」の書き方は参考になりますが、日本語圏でも大学キャンパス網やキャリア NAT で特定パスだけ劣化することはあるため、コピペだけに頼らないほうが安全です。

ステップ・バイ・ステップ：安定稼働までの現実的な順序

  1. Verge Rev でコアが動き、mixed-port が把握できていることを確認する。プロファイルのリロード忘れに注意。
  2. ブラウザで同一ノードを使い海外サイトが開けるかを確認し、問題がターミナル限定かを切り分ける。
  3. Rule でログに出たホストを PROXY へ固定し、fake-ip とドメインルールの組み合わせでマッチがズレていないか見る。
  4. システムプロキシ連動をオンにしても改善しない場合、シェルに HTTPS_PROXY を載せて Claude Code を新しいターミナルから再起動する。
  5. curl -vI https://api.anthropic.com などで TLS が張れるか、Clash ログでチェーンが期待どおりか確認する。
  6. それでも特定バイナリだけ直結するなら TUN を試すが、その前にウイルス対策・VPN の競合を疑う。

検証のコツ（開発者代理ならではの観点）

「環境変数は設定したつもり」でも、GUI ターミナルがログインシェルを読まず非対話セッションとして起動していると反映されません。IDE の統合ターミナル設定に明示的に環境変数を書く必要があるケースもあります。

  • 同一ホストへ curl と Claude Code を並べる：どちらもタイムアウトならノード品質や DPI が疑わしく、片方だけならプロセス側のプロキシ解釈が疑わしいです。
  • IPv6 だけ別経路になっていないか：-4 を付けて IPv4 限定で試すと差が出ることがあります。
  • 会社 LAN の Split DNS：社内ドメインは DIRECT のまま、外部 API だけ PROXY へ送る二段構成が安定しやすいです。
注意：ソースコードやログをクラウドモデルへ送る操作は、利用規約とデータの取り扱いポリシーの両方に触れます。ネットワーク経路を安定させることと、機密情報を外部へ送ってよいかは別問題です。
ダウンロードページへ

それでも直らないとき

症状：curl は通るが Claude Code だけ失敗

想定原因：実行バイナリが標準のプロキシ環境変数を読んでいない、別の設定ファイルでエンドポイントが固定されている。

対処：公式ドキュメントでプロキシ関連の環境変数名を再確認し、ラッパースクリプトで明示 export する。PATH 上に同名の古いバイナリがないかも見る。

症状：PROXY に載っているのに応答が極端に遅い

想定原因：選択ノードの輻輳、UDP／HTTP3 まわりのフォールバック、DNS の迂回失敗。

対処：別リージョンのノードへ切り替え、DNS 設定をプロファイル内で明示、TLS インタセプト製品を一時停止して比較する。

症状：TUN をオンにすると社内ツールだけ死ぬ

想定原因：社内 IP レンジが意図せずプロキシ側へ流れた、Split routing が崩れた。

対処：TUN をオフに戻し、NO_PROXY と Rule の PRIVATE／GEOIP 例外を厚くする。IT 部門のガイドラインに従う。

よくある質問

ブラウザは問題ないのに Claude Code だけタイムアウトします。なぜですか？

参照しているプロキシ設定のレイヤが違うためです。ブラウザは OS 設定や拡張を見る一方、ターミナルはシェルの環境変数や libc の実装に依存します。HTTPS_PROXY を揃えても効かないときは TUN で内核側から整えるか、該当プロセスのドキュメントを確認してください。

ルール分流とグローバル TUN はどちらを選べばよいですか？

細かく国内／海外を分けたいなら Rule が基本です。プロセスがプロキシ非対応なら TUN が早いですが、競合リスクが高いので限定的に試すのがおすすめです。

HTTPS_PROXY はどこに書けばいいですか？

常時ならシェル設定ファイル、direnv、IDE のターミナル環境変数。一時検証ならコマンド前置きの export だけに閉じてください。

単一ベンダ VPN との比較視点で見た Clash の強み

ワンタップの商用 VPN は初期導入が楽ですが、ドメイン単位の例外やログからの逆引きには向きにくく、開発機では「Git だけ直結できない」「社内証明書と衝突する」といった摩擦が出やすいです。対して Clash 系は本文で触れたようにルール分流とログで経路を説明できるため、Anthropic API だけ別チェーンのようなチューニングが現実的になります。学習コストはありますが、タイムアウトのたびにブラックボックスな再接続を繰り返すより、長期的には再現可能な設定ファイルとして資産化しやすいのが開発者代理としての利点です。

GUI は OS に合わせて選べますが、Verge Rev はプロファイル編集とログ閲覧が一体になっており、ターミナル用途と並べて運用しやすいです。チームで設定を共有する場合も、ルール差分をテキストで渡せる点が単一アプリ VPN に対する実務的な優位になります。

無料で Clash を入手し、ターミナル向けの分流と検証を試す →