2026：Claude 公式 Web と Anthropic API の Clash 分流ルールと DNS（実測）
Claude（Anthropic）は、一般向けの claude.ai、開発者向けの Claude Console、そして api.anthropic.com をはじめとする公式 APIとで、TLS で向き先が分岐しやすいサービスです。2026 年時点ではブランド統合に伴い console.anthropic.com から platform.claude.com へのリダイレクトが進み、ドキュメントやヘルプも *.claude.com 側に寄っています。検索で見つかる「AI サービス用の巨大ルールセット」をそのまま貼るだけでは、OpenAI や Google 向けに書いた行とマッチ順が衝突したり、fake-ip まわりで名前解決だけがズレたりしがちです。本稿は ChatGPT／OpenAI 向け記事や Gemini 向け記事とホスト集合を分離し、Clash（多くの GUI が載せる Clash Meta／Mihomo コア想定）でコンソール／Web／APIをどうルールに割り当てるか、既存ルールとの優先順位、DNS と Rule モードでのログ検証までを日本語で整理します。以下の YAML は出発点の例であり、実際に端末が接続している FQDN をログで確認してから調整してください。
Claude／Anthropic が「不安定」に見えるときの切り口
症状を分類すると切り分けが速くなります。(1) ブラウザの claude.ai だけ読み込みが遅い、ストリーミングが途切れる、(2) API 呼び出しだけタイムアウトや証明書エラーになる、(3) API キーや使用量の Console だけログインループや空白画面になる、というパターンです。(1) はフロント用ホストと静的アセット用ホストのどちらかが DIRECT に落ちている、あるいは意図しない地域の出口に乗っていることが多く、(2) は CLI やコンテナがシステムプロキシを読まず Clash のルールが効いていない、(3) は platform.claude.com や認証まわりの別ホストがルールから漏れている、が典型です。サーバー側だけで SDK を動かす構成では端末の Clash は無関係ですが、開発用 PC から直接 Anthropic API を叩く場合は、同じマシン上のコアが名前解決と転送経路の両方に影響します。
用語の整理は チュートリアル、ルールの書き方は カスタムルールの解説 と併読してください。OpenAI は chatgpt.com と api.openai.com、Gemini は googleapis.com や gstatic.com が主役になりがちですが、Anthropic は anthropic.com 系と claude.com 系、そして api.anthropic.com が別レーンに並ぶため、「汎用 AI 用 DOMAIN-KEYWORD」を一括で足すと他社ルールと順序が読めなくなる点に注意が必要です。
分流の土台：proxy-groups に「Anthropic 用」を用意する
購読テンプレの PROXY を直接指すより、AnthropicProxy のような用途名のグループを select または url-test で用意し、rules からは常にそのグループ名を参照するのが運用しやすいです。Web・Console・API を同じ出口に揃えると Cookie や課金画面の地域ブレが減ります。レイテンシや帯域の都合で API だけ別グループに分けたい場合も、名前を分けておけば後から差し替えが容易です。ネストや型の詳細は proxy-groups のガイド を参照してください。
rules 内の綴りが一致しているかを最初に確認してください。ここがずれると「ルールを足したのに効かない」状態になりがちです。
コンソール・Web・API：Anthropic 公式でよく現れるホストの考え方
一般向け Web チャットでは claude.ai が中心になり、フロントの読み込みに伴い *.claude.ai や CDN・解析系の別ホストが混ざることがあります。開発者向け Consoleは 2026 年時点で platform.claude.com が新しいハブとなり、従来の console.anthropic.com はリダイレクトでつながる運用が説明されています。ドキュメント類は docs.claude.com、サポートは support.claude.com など *.claude.com が増えやすい一方、企業サイトや採用・ポリシー類では anthropic.com 本体や www.anthropic.com が使われます。
公式 Claude APIのエンドポイントは、ドキュメント上 https://api.anthropic.com（多くのクライアントで /v1/messages など）が代表例です。AWS Bedrock や Vertex 経由の Claude は別ホストになるため、本稿のリストとは一致しません。いずれもサブドメイン追加やエッジ変更で変化し得るため、以下は出発点の例です。実際にマシンが接続しているホスト名をログで確認してから、DOMAIN-SUFFIX を狭めたり広げたりしてください。
方針として、(A) claude.ai・claude.com・anthropic.com・api.anthropic.com を同じ AnthropicProxy に寄せるのがシンプル、(B) 企業サイトだけ DIRECT にしたい場合は www.anthropic.com などをより上の行で例外化する、(C) コミュニティの RULE-SET と併用する場合は、Anthropic 向けの具体的な DOMAIN を広い MATCH や巨大セットより上に積む、が実用的です。ルールの上から先にマッチした行が優先されることは カスタムルール記事 のとおりです。
rules:
# Examples only — tune group name (AnthropicProxy) and domains to your logs
- DOMAIN-SUFFIX,claude.ai,AnthropicProxy
- DOMAIN-SUFFIX,claude.com,AnthropicProxy
- DOMAIN-SUFFIX,anthropic.com,AnthropicProxy
- DOMAIN-SUFFIX,api.anthropic.com,AnthropicProxyDOMAIN-SUFFIX,anthropic.com は Console リダイレクトや企業ページまで広く巻き込みます。国内向けの別用途と衝突する場合は、ログで列挙したサブドメインだけに狭めるか、DOMAIN,platform.claude.com のように一段細かくしてください。サードパーティのラッパーや非公式クライアントは別 FQDN になることが多く、検索で見つかった「AI 一括ルール」とは一致しない前提でログを正にしてください。
OpenAI／Google ルールと併用するときの優先順位
すでに OpenAI 向けや Gemini 向けの行がある構成では、どの行が先にマッチするかがそのまま挙動になります。たとえば広い DOMAIN-KEYWORD,google や巨大な RULE-SET が上にあると、意図しないホストまで一括で流れ、逆に MATCH,DIRECT が先に来ていると API だけ取りこぼす、といった現象が起きます。Anthropic 専用の行は、自分の環境で実際に使う FQDN について OpenAI／Google の行より上に置くのが安全な出発点です。ただし「すべてを最上流に積む」とファイルが読みにくくなるため、ログで再現したホストだけを上に持ち上げる運用が現実的です。
複数の生成 AI を日々切り替える場合でも、プロダクトごとに proxy-group 名を分け、ルール側はグループ名だけを指すようにしておくと、ノード差し替えや遅延試験のたびに YAML の本文をいじる回数が減ります。Claude だけ遅いときは、まず同じ AnthropicProxy を指しているか、次にノード品質を疑う順が定石です。
DNS・fake-ip：ルールより前に潰れる名前解決の落とし穴
分流ルールが正しくても、DNS が期待と違う応答を返すとタイムアウトや証明書エラーに見えます。Clash／Mihomo 系では dns ブロックの fake-ip モード、redir-host、DoH、nameserver-policy の有無が挙動に直結します。fake-ip はルールマッチ前の名前解決と相性がよい一方、アプリが独自 DNS を使う・ブラウザの Secure DNS が二重に効くと、ログ上のホストと実際の経路が食い違って見えることがあります。テンプレの推奨から大きく外すと切り分けが難しくなることもあるため、まずは購読既定で再現する→ 問題が続くときに、(1) DoH エンドポイント、(2) nameserver-policy で anthropic.com や claude.com だけ別 DNS、(3) IPv6 の有無、を一度に一項目ずつ変えるのが安全です。
CLI や IDE から API を叩く場合、システムプロキシを読まない経路があるとルールが効きません。そのときは TUN モード でトラフィックをコア側に寄せる案や、HTTPS_PROXY の明示を検討してください。ブラウザ側の DoH を一時オフにして挙動を比較する方法も有効です。トンネル型 VPN との違いや「全体を一本化しない」メリットは Clash と VPN の比較 も参照してください。
動作モード：Rule・Global・Direct の使い分け
Rule が日常運用の基本です。Global は「すべてをプロキシへ」として一時的にルール不足かノード品質かを切り分けるのに便利ですが、国内サイトまで遠回りになるため常時利用はおすすめしません。Direct はベースライン計測用に、Clash を事実上オフに近い状態で挙動を見るときに使います。Claude だけ不調なときは Rule に戻し、該当ホストが意図したポリシーにマッチしているかをログで確認するのが定石です。
実測手順：ログで「宛先」と「採用ルール」を確認する
-
1
Baseline（Direct または Clash 停止）
まず Direct でブラウザから
claude.aiを開き、同じ端末からcurl等でapi.anthropic.comへの TLS 疎通を試し、症状が再現するかを記録します。ローカル回線やプロバイダ側の要因も見えます。 -
2
Rule に戻し、Web・Console・API それぞれでログを読む
チャット操作、Console の画面遷移、API リクエストの各タイミングで、接続一覧／コアログに向いている FQDNとマッチしたルール行（またはポリシー名）をメモします。リストにないホストが出たら、それが次に追加すべき行です。
-
3
一行ずつルールを足して再計測
DOMAIN-SUFFIXや必要ならDOMAINを追加し、同じ操作を繰り返します。一度に大量変更すると効いた変更が特定できません。意図と違う行にマッチしているときは、より具体的なルールを上へ移動し、OpenAI／Google 行との順序を調整します。 -
4
DNS クエリログがあれば併記する
fake-ip 有効時は、表示される IP と実サーバの対応が直感とずれることがあります。名前解決結果がおかしい場合はルールより先に DNS を直します。クライアントが DNS ログを出せない場合はログレベルを上げる、別ツールで確認するなど環境に合わせてください。
この繰り返しが本稿でいう「実測」です。検索で見つかるドメイン一覧や「汎用 AI ルール」は参考にとどめ、自分のログを正としてメンテすると、Console の URL 変更や新サブドメイン追加にも追従しやすくなります。
よくある質問
ブラウザは快適なのに API だけ失敗する
ブラウザはシステムプロキシ経由でルールが効いているが、ターミナルやコンテナがプロキシ設定を読んでいないパターンです。環境変数、TUN、実行ユーザの違いを確認してください。
DOMAIN-SUFFIX,claude.com にしたら意図しない通信までプロキシに乗った
サフィックス一括は広くマッチします。影響が大きい場合はログで実際のホストを列挙し、必要なサブドメインだけに狭めてください。
職場・学校のネットワークでは？
組織ポリシーでプロキシ迂回が禁止されている場合があります。技術的に可能でも、規程と管理者の指示を優先してください。
まとめ
Claudeのように一般向け Web、開発者 Console、公式 APIが別ホストに分かれやすいサービスでは、分流ルールを用途別に整理し、DNS（fake-ip・DoH を含む）とRule モードでのログ検証をセットにすると、OpenAI や Google 向けルールと共存させつつ安定させやすくなります。本稿のドメイン例は出発点であり、2026 年以降のドメイン統合や新 UI に合わせてログに基づきルールを育てることが長く使うコツです。OpenAI 公式のホスト集合は ChatGPT の記事、Google 系は Gemini の記事で扱っているため、混同せず参照してください。
クライアントの入手は 本サイトのダウンロードページ を第一にすると、記事との対応も追いやすくなります。ルールの基礎を固めたい場合は カスタムルール完全ガイド も併せてどうぞ。用途ごとに出口を切り替えられる点では、端末全体を常時トンネルする汎用 VPN に比べ、Clash の運用が一段整理されやすい場面が多いです。