Claude Code × Clash Verge Rev：Anthropic API を安定させるルーティング実践ガイド（2026）

1. この記事が前提とする検索意図

検索バーにClaude Code、Anthropic API、CLI、そしてClashや分流が同時に並ぶとき、多くの読者はすでに「GUI ブラウザではなんとなく動くが、ターミナル経由は不安定」という地点に立っています。典型は、(1) curl では繋がるのに公式 CLI が繋がらない、(2) 逆にブラウザは直結できて CLI だけプロキシが必要、(3) ルールは書いたはずなのに特定ホストだけ期待した出口に行かない、といった経路の不一致です。ここではClash Verge Revをフロントとして、Mihomo 系コアが読むルールと DNS の相互作用まで含めて説明します。

Anthropic APIはホスト名として最低限 api.anthropic.com を叩く構成が一般的ですが、クライアントのバージョンや認証フローによって追加ドメインが増える余地があります。運用では一度だけ開発者ツールやプロキシログで実際に TLS を張っている SNIを確認し、そのリストをルールにテキストとして固定しておくと再現性が高まります。本記事のサンプルは出発点であり、恒久的な単一情報源は各公式ドキュメントです。

2. ブラウザが動いても CLI が詰まる理由の骨格

ブラウザはしばしばシステムプロキシ設定や拡張機能経由で自動的に経路を決めますが、CLIは標準ライブラリごとに挙動が分岐します。Go 製バイナリは環境変数を読むケースと読まないケースが混在し、Node 系は別モジュールがプロキシを無視することがあります。その結果、「OS のプロキシトグルをオンにしたつもり」でも実プロセスは DIRECTのまま、という状態が普通に起きます。Claude Codeのような開発ツールは内部で複数の HTTP クライアントを混ぜることもあるため、観測ベースで切り分けるのが早いです。

もう一つの大きな軸はDNSです。ルールが DOMAIN-SUFFIX ベースでも、名前解決が別キャッシュや社内 DNS の転送先に固定されていると、実際に張られるコネクションは期待とズレます。fake-ip を有効にしている構成では、アプリケーションが見ている名前とコアが評価している名前が一致しているかをログで確認しないと、机上のルールだけでは真相が見えません。

3. Clash Verge Rev でまず押さえる画面と保存場所

Clash Verge Revはプロファイルの編集、モード切り替え、ログ閲覧を GUI に集約しますが、根っこはテキストの YAMLです。チーム開発では「誰がどのプロファイルを有効化しているか」がズレやすいので、検証用と日常用で名前規約を分け、購読インポート後にローカル追記ルールだけをリポジトリ管理する、という運用が現実的です。サーバー用途では TUN を安易にオンにせず、まずMixed Port の番号とDIRECT／PROXY の境界を決めてから広げてください。

設定画面のラベルは版により微妙に異なりますが、重要なのは次の三点です。(1) 現在有効なプロファイルがどれか、(2) システムプロキシ／TUNが実際にオンか、(3) ログレベルが切り分けに足るか、です。調査フェーズだけログを上げ、平常時は下げることで、詳細ログに HTTP ボディが混ざって残るリスクも抑えられます。

4. Anthropic 向けルールの書き方（出発点）

以下は概念的な断片です。実運用では既存の rules: の優先順位に合わせて挿入位置を調整し、社内向けドメインはより手前で DIRECT に固定してください。プロキシグループ名は読者側の購読テンプレに合わせて読み替えます。

# Example snippet — adjust proxy group names to your profile
rules:
  - DOMAIN-SUFFIX,anthropic.com,PROXY
  - DOMAIN-SUFFIX,claude.ai,PROXY
  - GEOIP,JP,DIRECT
  - MATCH,PROXY

DOMAIN-KEYWORD は誤マッチしやすいので、まずはサフィックスや完全一致を優先します。CDN や計測ドメインが増えた場合は、ホワイトリスト運用ではなくログで実名を拾ってから追加する方が安全です。分流の本質は「思い込みで広げること」ではなく観測に基づく追加です。

5. CLI にプロキシを効かせる：環境変数から手を付ける

まず試すべきはシンプルです。Mixed Portが例えば 7890 なら、シェルで HTTPS_PROXY=http://127.0.0.1:7890 を設定し、同じシェルから curl -I https://api.anthropic.com のような軽いヘッダ確認を行います。ここで TLS が張れるなら、少なくともプロキシチェーンの下半分は生きています。失敗する場合は、(1) ポート番号の勘違い、(2) ループバック以外で待ち受けている、(3) 別セッションで環境変数が引き継がれていない、を疑ってください。

Windows のターミナル複数タブや IDE 統合ターミナルでは、起動シェルが異なると環境変数が共有されないことがあります。Claude Codeを IDE から呼ぶ場合も同様で、親プロセスの環境が子に渡るかは実行経路次第です。確実性を上げるには、ラッパースクリプトで明示エクスポートするか、ツール側がサポートしていれば設定ファイルにプロキシを書く方法があります。

6. システムプロキシと TUN：どちらを選ぶべきか

システムプロキシは「プロキシ設定を尊重するアプリ」に効きやすく、導入摩擦が低い反面、無視する実装も残ります。TUNは仮想インタフェース経由でキャプチャできるため強力ですが、既存の VPN クライアントや社内エンドポイント製品とルート競合しやすいです。開発マシンでは、まず環境変数＋Mixed Portで十分なケースが大半であり、どうしても取りこぼすプロセスだけ TUN で拾う、という段階的拡張がトラブルを減らします。

サーバーや CI では TUN を前提にしない構成が無難です。コンテナや Runner は別議論でも、原則明示的なプロキシ環境変数かアウトバウンド許可リストで設計するほうが監査にも説明しやすいです。ローカル開発だけ Clash を挟む、という二層に切ると責任分界も明快になります。

7. タイムアウトと TLS：ログでの切り分け順序

症状がタイムアウトだけだと原因が広く見えますが、ログではだいたい次のどちらかに寄ります。(A) CONNECT が確立しない → 経路・DNS・ファイアウォール寄り。(B) CONNECT は成功だが HTTP が 401／403 → 認証情報・リージョン・アカウント制約寄り。Anthropic 側のレスポンス本文は機密になりがちなので、共有ログに全文を貼らない運用を前提に、ステータスコードと x-request-id など相関に必要な最小情報だけを残します。

ミドルボックスによる TLS インスペクション環境では、社内 CA を信頼ストアに入れていないクライアントだけが失敗する、というパターンもあります。ブラウザは社内ポリシーで CA が注入済みでも、CLI は別ストアを見ていることがあります。この場合、プロキシ経由に統一して一つの信頼チェーンに寄せるほうが安定することがありますが、セキュリティレビューが前提です。

8. パフォーマンスと安定性：keep-alive と再接続

API クライアントは長時間セッションでコネクション再利用を試みますが、途中のプロキシや NAT がアイドル切断すると途中で詰まったように見えることがあります。実務ではクライアント側のタイムアウト値とリトライ方針が効きますが、ネットワーク観測としてはプロキシログで同一ストリームに対するRSTの頻度を見るとヒントが得られる場合があります。根本は出口側の品質ですが、ローカル側で過剰な verbose を避け、計測だけを短期オンにするのがバランスが良いです。

9. セキュリティ：鍵・ログ・共有端末

Anthropic APIキーはファイルや環境変数に置きがちですが、共有マシンでは権限とシェル履歴に注意してください。export した変数は子プロセスに伝播し、クラッシュダンプやサポートzipに紛れ込むこともあります。チーム運用では短命トークンや秘密管理サービスに寄せ、ローカルファイルは .gitignore と権限で二重に閉じます。プロキシがHTTPS を復号しない前提でも、ミス設定で中間キャッシュが残らないかだけは確認してください。

10. 運用チェックリスト（そのまま転記可）

短時間で一周するための並びです。(1) 有効プロファイルが意図どおりか。(2) api.anthropic.com の名前解決結果が期待と一致するか。(3) Mixed Port で curl が通るか。(4) Claude Code を起動するシェルにプロキシ環境変数が載っているか。(5) それでもダメなら TUN を一時オンにして症状が変わるか。(6) 変わらないなら認証・エンドポイント側へ移る、の順が無駄が少ないです。

よくある質問

システムプロキシをオンにしても Claude Code が迂回しないのはなぜですか？

CLI 実装ごとにプロキシ認識がバラつきます。環境変数で明示する、ツール設定でホストとポートを直書きする、あるいは TUN で拾う、の三段階で切り分けてください。

ルールは書いたのに api.anthropic.com が DIRECT のままになります。

DNS の経路と fake-ip の組み合わせを疑ってください。キャッシュを消し、プロキシ側のドメインログと実際の SNI を突き合わせます。

TUN は有効ですが途中で接続が落ちます。

競合 VPN が典型です。一旦 TUN をオフにして Mixed Port のみで安定するかを確認し、ルートテーブルの変化を観察してください。

API キーをプロキシログに残さないには？

verbose を常時オンにしないことと、HTTP ボディをログに出さない設定を確認してください。共有端末では権限と履歴リスクを別レビューします。

単機能の「常時オン VPN」型アプリは手軽ですが、開発トラフィックと業務ブラウザまで一枚岩にすると、障害時にどこで落ちたかが見えにくくなります。一方、Clash／Mihomo 系はルールをテキストとして説明可能なので、Anthropic だけ別出口、社内レジストリは直通、といった段階的分流が現実的です。閉じた商用クライアントにありがちな「画面上はオンだが内部がブラックボックス」に比べ、CLI とブラウザのズレをログで突き合わせやすいのが強みです。ルール駆動のプロキシという前提に共感できるなら、下の導線から各 OS のクライアントを揃え、チームの開発マシンと CI の境界まで含めて設計を締め直してみてください。