1 背景とゴールをそろえる
2026 年時点で、海外系の大規模言語モデルは引き続き注目を集めており、Anthropic は Claude ファミリーを軸にコンソール、API、エンタープライズ向け機能を拡張しています。利用者側から見ると、課題は「モデルそのもの」よりも、分散したドメインへの TLS 接続が片方だけ詰まることに現れがちです。例えば claude.ai の SPA は静的アセットと API 呼び出しを別ホストに分け、開発者向けは api.anthropic.com へ直接 HTTPS を張ります。システムプロキシ、環境変数、TUN の有無がバラバラだと、同じマシンでもアプリごとに出口が変わり、ログインは成功したのにストリーミングだけ途切れる、といった切り分けが難しくなります。
本稿のゴールは、帯域をむやみに広げることではなく、Rule モードで Anthropic 向けトラフィックを意図したアウトバウンドへ集約することです。IDE 連携全般はCursor と Clash の記事で扱っています。Google クラウド側の整理はGemini／Google AI Studio 向けの記事が対応します。ここでは Anthropic のホスト設計に寄せ、粗い GEOSITE 一枚だけに頼らず、漏れと過剰マッチの両方を減らすことを意識します。
2 Claude の Web と API が触るホストを押さえる
実際のホスト名はプロダクト更新で増減するため、最終的には Clash の接続ログで SNI を確認するのが確実です。それでも設計上、次のような束に分けて考えるとルールが書きやすくなります。
- コンシューマ向け Web（claude.ai）：
claude.ai本体に加え、フロントのビルドや計測で*.claude.ai配下のサブドメイン、サードパーティ CDN や認証連携が混ざることがあります。単一のDOMAINだけでは足りない場面があります。 - コーポレート／ドキュメント（anthropic.com）：
anthropic.com、www.anthropic.com、サポートやステータス、開発者向けドキュメントのホストがこの系統にまとまることが多いです。コンソール UI はconsole.anthropic.comなど別名で切り出される場合があります。 - Messages API： REST クライアントは通常
api.anthropic.comを向きます。SDK はHTTPS_PROXYを参照する場合と、独自の HTTP クライアントで OS プロキシを無視する場合があります。 - GEOSITE に頼りすぎない理由： 購読リストの「海外 AI」カテゴリは便利ですが、更新タイミングや分類粒度によっては Anthropic 専用のホストが未収録だったり、逆に不要なドメインまで同じプロキシに乗ったりします。本題の安定性を優先するなら、自前の短いサフィックスリスト＋ログでの追記が扱いやすいです。
まずは失敗時に表示されるエラーが「名前解決」「TCP の拒否」「TLS ハンドシェイク」「HTTP 403／401」のどれに近いかを分け、接続ログのドメインと突き合わせてください。
3 ルールモードとプロキシグループの置き方
推奨は mode: rule です。Anthropic 向けに PROXY-ANTHROPIC のようなセレクタまたは url-test 付きグループを一枚挟み、遅延の安定したノードと、帯域はあるが不安定なノードを分けておくと、長めのストリーミング応答を A/B しやすくなります。グローバルモードは国内向けサービスまで遠回りし、ダイレクト固定では API だけ失敗する、というジレンマが出ます。
購読テンプレートに既に「国外サイト」ブロックがある場合は、その直前に Anthropic 向けの明示ルールを置き、意図せず別タグのノードへ飛ばないようにします。セレクタで国や事業者を切り替える運用では、Anthropic のデータ所在地や利用条件の表記とあわせて公式情報を確認してください。
4 YAML に書くルール例と Rule Provider
以下はイメージです。proxy-groups 名やインデントは手元の設定に合わせてください。コメントは英語のみとします。
# Example: route Anthropic properties to a dedicated selector
rules:
- DOMAIN-SUFFIX,claude.ai,PROXY-ANTHROPIC
- DOMAIN-SUFFIX,anthropic.com,PROXY-ANTHROPIC
- DOMAIN,api.anthropic.com,PROXY-ANTHROPIC
- DOMAIN,console.anthropic.com,PROXY-ANTHROPIC
# Optional: remote rule-provider snippet (path/interval are examples)
# rule-providers:
# anthropic:
# type: http
# behavior: classical
# url: "https://example.com/rules/anthropic.txt"
# path: ./rules/anthropic.yaml
# interval: 86400
# rules:
# - RULE-SET,anthropic,PROXY-ANTHROPIC
Rule Provider を使う場合も、リモートリストの中身が信頼できるか、更新間隔とローカル追記ルールの優先順位を確認してください。Clash 系は上に書いたルールが先に評価されるため、細かい DOMAIN を上に、広い GEOIP や MATCH を下に置くのが定石です。
CLI やコンテナから API を叩くときは、プロキシを明示しないと OS のルーティングに任せます。Python 等では HTTPS_PROXY=http://127.0.0.1:7890 を併用するか、TUN モードで仮想 NIC レベルに揃えると、環境変数のばらつきを減らせます。
5 DNS・FakeIP・TLS をセットで見る
ホスト数は Google ほど膨大ではありませんが、DNS の答えが期待とズレると「ブラウザでは開けるのに CLI だけ名前解決が変」という現象は同様に起きます。Mihomo では DoH、FakeIP、fallback-filter の組み合わせが定番です。設定の細部はMeta カーネル DNS の実務記事に譲ります。Clash の DNS セクションと OS の DNS を二重管理しないこと、TUN と DNS ハイジャック併用時にローカル開発用ゾーンを DIRECT に残すことが安定の鍵です。
TLS の観点では、SNI が api.anthropic.com であっても、途中の企業プロキシによるインスペクションでクライアント証明書検証が失敗するケースがあります。エラー文言が証明書関連なら、まず社内ポリシーと OS の信頼ストアを疑ってください。逆にルールで意図せず DIRECT に落ちていると、RST やタイムアウトとして現れます。
6 Web と API の動作確認
ブラウザで claude.ai を開き、ログインとチャットの送受信が一通りできる状態を基準にします。続けて、同じマシンからターミナルで curl 等により api.anthropic.com への TLS ハンドシェイクが完了するかを見ます。ここでだけ失敗する場合は、ルールよりも環境変数か、CLI がプロキシを参照していない可能性が高いです。ストリーミング応答は HTTP の長めのセッションになるため、パケット損失の大きいノードでは UI 上「途中で途切れる」ように見えます。セレクタで別アウトバウンドへ切り替え、再現性を比較してください。
API キーとエンドポイント
キーはリポジトリにコミットせず、環境変数やシークレットマネージャに載せるのは共通の鉄則です。ベース URL やパス形式は公式ドキュメントの最新版を正とし、ネットワーク記事の古い例をそのまま流用しないでください。レート制限や課金の境界もダッシュボードの数字で確認します。
7 トラブルシューティング
- ブラウザだけ成功して CLI が失敗： システムプロキシと環境変数のどちらかが未設定、または TUN がオフ。シェルに
http_proxy／https_proxyを足すか、TUN を有効化して経路を一本化します。 - 403／401／レート制限のメッセージ： ルールではなく API キー、アカウント、リージョン側の制約の可能性があります。公式ステータスとドキュメントを照合します。
- ストリームが途中で切れる： ノードのパケット損失や、長時間接続の切断を疑い、セレクタで別サーバへ切り替えて比較します。
- 新しいサブドメインで失敗： 接続ログに出た SNI を
DOMAIN-SUFFIXまたはDOMAINで追記し、Rule Provider のリストにも反映できるか検討します。 - ルールを足したら国内サイトが遅くなった：
GEOIP,CN,DIRECTなど直行ルールとの順序を見直し、誤マッチがないか確認します。
8 まとめ
Claude を「ブラウザだけ速くする」のではなく、claude.ai と api.anthropic.com を含む Anthropic 向けトラフィックをルールと DNS で一貫させると、Web・API・サードパーティツールをまたいだ再現性が上がります。粗い GEOSITE だけに頼ると漏れと過剰マッチの両方が出やすいので、DOMAIN-SUFFIX とログベースの追記、必要なら Rule Provider で保守性を補います。Google の Gemini を併用する場合も、ベンダーごとに出口を分けておくと切り分けが容易です（Gemini 向け記事と対で読むと整理しやすいです）。
まずは手元の YAML に Anthropic 向けサフィックスと API 用 DOMAIN を追記し、接続ログで漏れがないか確認してください。DNS の細部はDNS 実務記事に譲ります。ルール分流とログの読み方さえ身につけば、同じ考え方を他のクラウド API にも転用できます。
単機能の軽量プロキシより、ルールと DNS を一体で扱える Clash 互換スタックの方が、長めの HTTPS ストリームや複数ドメインにまたがるセッションに強い場面が多いです。海外 AI サービスを業務や開発に組み込むほど、その差は試行回数と体験の安定性に直結します。
