「たまに落ちる」Claude はネットワークの長接続が弱点になりやすい

Claude（claude.ai のウェブ UI や Anthropic API／公式 CLI 経由の利用）は、単発のページ取得より長時間の HTTPS セッションとストリーミング応答に依存します。ブラウザではチャットのトークン送出、埋め込みウィジェット、計測や CDN へのサブリクエストが並行し、API 側では api.anthropic.com への継続的なコネクションや再試行が続きます。ここで出口ノードが頻繁に切り替わる、一部ホストだけ別ポリシーに落ちる、TLS の途中で中間機器が割り込むといったことが重なると、体感は「完全に繋がらない」より生成の途中で止まる再接続ループに入るといったAPI 安定性の問題として現れやすいです。

本稿の狙いは、Anthropic 側の仕様変更の予測ではなく、Claude プロキシとして Clash を使うときに自分の経路で再現・改善できる層にフォーカスすることです。具体的には、Clash 分流の評価順、手動固定に近い固定ノードの選び方、接続ログでのルール命中確認、そしてTLS ハンドシェイクに載る接続先名（SNI）が期待どおりか、の四点です。これらを順に潰すと、「ノードを総入れ替えしたのに直らなかったが、実は DOMAIN-SUFFIX が一つ足りなかった」といった徒労を減らせます。

💡
Cursor／Copilot 稿との棲み分け IDE・GitHub まわりの開発者向け記事では、エディタ拡張や複数レジストリとの兼ね合いを中心に扱いました。本稿はブラウザで claude.ai を開く場面とAPI／CLI が参照するエンドポイントに寄せ、ドメイン集合と「長いストリームを落とさない」ための出口の持ち方を優先します。両方とも AI ツールですが、最適なルール順は同一とは限りません。

トラフィックの形：単一ホストでは終わらない

実運用では、画面に見えているホスト名より背後で並行する FQDNの方がトラブルの源になります。ウェブの claude.ai ではメインの HTML／API 呼び出しに加え、静的アセット、認証まわり、サードパーティのスクリプトやフォント読み込みなどが絡みます。API 利用ではクライアントが直接 api.anthropic.com へ向かう一方で、社内プロキシやクラウド出口の手前で別の検査プロキシが立っているケースもあります。

したがって「claude.ai だけ通せばよい」というより、ログに出た失敗先を足していく方が安全です。Clash Meta（Mihomo）系であれば、接続ログに表示されるホストとポリシー名をメモし、広い GEOIP や MATCH より前に明示的な DOMAIN-SUFFIX または RULE-SET を置く、という骨格に戻すのが近道です。分流の地盤づくり自体は国内直通と海外プロキシの整理で扱っている考え方と共通し、本稿ではその上に「AI 向けホストの束ね方」を載せるイメージです。

再現用の最小例：Anthropic 向けポリシーとルール

以下は概念デモです。実際の購読名・ノード名に合わせて置き換えてください。YAML 内のコメントは英語のみとしています。

proxy-groups:
  # Sticky egress for Anthropic (manual or slow health-check)
  - name: AI-ANTHROPIC
    type: select
    proxies:
      - US-STABLE
      - JP-STABLE
      - DIRECT

rules:
  # Pin Anthropic surfaces before broad GEOIP DIRECT
  - DOMAIN-SUFFIX,claude.ai,AI-ANTHROPIC
  - DOMAIN-SUFFIX,anthropic.com,AI-ANTHROPIC
  # api.anthropic.com is covered by anthropic.com; add more from logs if needed
  # Add hosts seen in live connection logs (CDN / auth may differ)
  # ... your GEOIP / MATCH rules follow

リモートの RULE-SET だけに頼ると、更新タイミングでホストが抜けることがあります。ローカルに追記ファイルを用意し、prepend-rules やマージで常に先頭に効かせる方法は、オーバーライドガイドの考え方と相性がよいです。キーワードマッチは誤爆しやすいので、まずはログ根拠のあるサフィックスから足してください。

固定ノードとポリシー：速さより「切り替わりすぎない」こと

チャットの長文生成や API のストリームでは、同一 TCP／TLS セッションの寿命とサーバ側のレート制御が絡みます。ここに間隔の狭い url-testだけを載せると、ヘルスチェックのたびに別アップストリームへ寄り、結果としてハンドシェイク途中の切断や再試行のスパイクが出やすくなります。API 安定性を優先するなら、検証済みの 1 ノードをSelectorで手動固定するか、計測間隔を長めにした fallback と組み合わせ、「動けばすぐ乗り換えない」挙動に寄せるのが現実的です。

マルチリージョンのロードバランサ的な運用が必要な場合でも、まずは単一リージョンに固定したうえで症状が消えるかを見ると切り分けが早いです。Claude プロキシ用途では「理論上最速」よりブレの少ない出口の方が体感の切断は減りやすい傾向があります。

ルール順と命中：Clash 分流で取りこぼさない

典型的な失敗は、冒頭に広い GEOIP,CN,DIRECT や「国内は直結」の塊があり、その後ろに Anthropic 向けの行が追いやられているパターンです。エッジの選定や DNS の結果次第で、サブドメインの一部が意図せず DIRECTのまま残り、画面は開くが API だけ失敗、という部分的成功が起きます。対策はシンプルで、確定しているドメイン行を先に置き、広いルールは後ろへ、です。

設定を読むよりログで実測するのが確実です。接続ログの見方で説明しているとおり、失敗リクエストがどのポリシーに入ったかを確認し、YAML の評価順と突き合わせてください。「ノードが弱い」に進む前に、そもそもプロキシに乗っていないケースを潰すと時間の節約になります。

SNI と TLS：接続先名が経路と一致しているか

HTTPS では、クライアントが最初に送る ClientHello に接続したいドメイン名（SNI）が含まれます。通常のフォワードプロキシ経由では、この名前がそのままアップストリームへ伝わり、サーバ証明書の検証と整合します。ここが崩れる典型例は次のとおりです。企業の HTTPS インスペクションでローカルが発行した証明書に置き換わっている。透明プロキシが別ホスト名で終端している。誤ったルールにより、実際の宛先と別経路のノードに流れている。

Clash 側でできることは、まずMITM を有効にしていないか、TUN／システムプロキシの二重適用で奇妙なループになっていないかを確認することです。次に、ログで失敗した接続のホスト名と実際に選ばれたプロキシを突き合わせます。ブラウザ拡張や別製品の「HTTPS フィルタ」が同居している場合、SNI まわりで衝突することがあるため、一度ミニマルなプロファイル（Clash のみ、拡張オフ）で再現するのも有効です。

DNS・fake-ip・TUN：名前と経路のズレを潰す

fake-ip を使うと、見えている IP と実際の転送先の関係が直感とズレやすくなります。症状としてはトップページだけ開く、API だけタイムアウト、などホスト単位で成功と失敗が分かれるパターンが出ます。まずはログで「そのホストがどのポリシーに入ったか」を確定させ、必要なら redir-host との比較や、TUN モードとシステムプロキシのどちらで捕捉するかを揃えてください。OS の DNS が Clash の外へ逃げていないかも、セットアップ時に一度だけ確認しておくと後戻りが減ります。

API／CLI 利用時の追加チェック

環境変数 HTTPS_PROXY／ALL_PROXY を CLI に渡す運用では、プロキシのスキーム（HTTP CONNECT か SOCKS5 か）とループバック除外のリストが Clash のリスンアドレスと一致しているかを確認します。コンテナや WSL からホスト側の Clash に向ける場合、名前解決がコンテナ内 DNS で止まることもあるため、ホスト名ではなく IP を明示する・extra_hosts を足す、といった層も同時に見ます。

ここでも基本は同じで、API 安定性を落としているのが「プロキシの遅延」なのか「そもそも別ホストが DIRECT」なのかを、ルール命中で分岐させます。長文のストリームが途中で切れるときは、まず出口の固定ノードを疑うより、ホスト単位のルール抜けを疑うと早いことが多いです。

⚠️
法令と利用規約 接続先のネットワークポリシー、居住地域の法規、Anthropic の利用規約を順守してください。本文は、正当なアクセス権限のある環境で Clash を用いて技術的な経路を意図どおり揃えるための参考情報です。

切り分けチェックリスト

応答ストリームが途中で止まる

ポリシーの自動切替を一時停止し、単一ノードに固定して再現性を見ます。改善するなら出口のブレが主因の可能性が高いです。

ページは開くが送信だけ失敗する

別サブドメインが DIRECT のままになっていないか、ログでフィルタします。Clash 分流の順序修正が先で、ノード入れ替えは後です。

証明書エラーや TLS ハンドシェイク失敗

HTTPS インスペクションや拡張のフィルタを疑い、ミニマル構成で試します。SNI と証明書の不一致がログやブラウザのエラー文言に出ていないかも確認します。

まとめ：Claude 向けは「ドメイン・DNS・固定出口・TLS」の四角形

話題のサービス名は変わっても、切り分けの型は似ています。まず接続ログで失敗ホストとルール命中を確定し、次に評価順と DNS、続いて固定ノードによるブレ低減、最後に TLS／SNI まわりの異常——この順で進めると、設定ファイルを全面置換せずに済むことが多いです。claude.ai と API の両方を快適に使いたい場合も、同じ四角形に立ち返るのが実務的です。

クライアントの導入や購読の取り込みがまだなら、当サイトのダウンロードページから入手し、購読 URL チュートリアルで土台を整えてから本稿のルールを足すとスムーズです。オープンソースのソースコードや議論は各プロジェクトの GitHub で追えますが、初回インストールのパッケージはサイト経由で揃えると取り違えが減ります。→ Clash を無料ダウンロードし、Claude 向けの経路を手元で試す