DeepSeekのWeb・APIが不安定？Clash分流とDNS・Fake-IP整理（2026）

1. 他の AI 向け記事と何が違うか（DeepSeek のドメイン集合）

当サイトでは、ChatGPT 向けの固定ノードと fallback、Claude / Anthropic の地域表示と DNS（fake-ip）、Gemini / Google AI の広いドメイン散らばりと QUIC、Grok・xAI・X（Twitter）の別ベンダー束ねを別稿で扱っています。いずれも「表に見えているホストより裏で別名義の通信が増える」点では共通ですが、DeepSeek は deepseek.com を中心とした比較コンパクトな名前空間でありつつ、チャット UI・開発者コンソール・API エンドポイントが別サブドメインに分かれるため、片方だけ購読ルールの末尾 MATCH に飲まれると症状が分かれて現れます。

本稿は製品レビューではなく、接続が途切れる・名前解決が妙・API だけ失敗するといったユーザー側のトラブルシュートに寄せています。各サービスの利用規約・表示される地域制限・法令順守は技術とは別レイヤーです。ここで述べる手順は一般情報であり、特定サービスの利用を推奨・保証するものではありません。

購読の取り込みや初期設定はサブスクリプション導入ガイドを参照しつつ、以下では DeepSeek 向けにホスト名の束ね方とDNS の取り回しに焦点を当てます。

2. 症状を「ルール」「DNS」「API クライアント」の三層で切り分ける

第一層はルーティング（ドメイン分流）です。chat.deepseek.com だけをプロキシに載せても、鍵発行や課金画面が platform.deepseek.com、実リクエストが api.deepseek.com に分岐していると、画面の一部だけ真っ白・API だけ 403 やタイムアウトが起きます。基本は DOMAIN-SUFFIX,deepseek.com で同一策略グループに揃えるか、ログを見ながら不足サフィックスを足すことです。

第二層がDNSです。mihomo 系で fake-ip を使う構成では、ブラウザとターミナルで名前解決の通り道が異なると、見かけ上は同じ URL でも実接続先の策略が食い違うことがあります。ルールを増やしても体感が変わらないときは、ここを疑う価値が高いです。詳しい考え方は Claude 向け DNS 稿と重なるため、本稿では DeepSeek 特有のAPI クライアント層との組み合わせに筆を厚くします。

第三層がAPI クライアント（curl、Python、Node、IDE 拡張）です。多くのツールは システムプロキシを自動では読まないか、HTTPS_PROXY と NO_PROXY の例外で意図せず直結します。ブラウザで快適でも CLI だけ失敗するときは、クライアント側のプロキシ設定と、コアログ上の接続先ホストをセットで確認してください。

3. 押さえたいホスト名：Web・プラットフォーム・API

インフラ側の構成は変わり得るため、必ず公式の開発者ドキュメントやブラウザの開発者ツールで実際の通信先を突き合わせてください。2026 年時点の公開情報では、API のベース URL は https://api.deepseek.com（互換のため /v1 を付ける構成も文書化されています）として説明され、キー管理やコンソール類は platform.deepseek.com 側に寄せられることが多いです。ドキュメント本体に api-docs.deepseek.com のようなホストが出る場合もあるため、DOMAIN-SUFFIX,deepseek.com を一括で同じ策略に載せるのが運用上ラクな出発点になります。

Web チャットやマーケティングページは www.deepseek.com や chat.deepseek.com など、同一サフィックス配下に収まるケースが多いですが、サードパーティの埋め込みや分析タグで別ドメインが混ざることもあります。ネットワークタブで赤表示になっているホストをメモし、deepseek.com 以外に常習的に出る名前があれば別ルールで拾うのが安全です。

ルールの評価順はルールルーティング解説のとおり、具体的な DOMAIN 行を、広い GEOIP や MATCH より上に置きます。購読ルールセットの末尾に追記するだけでは効かないことがある点に注意してください。

4. mihomo ルール例：専用策略グループへまとめる

実務では DeepSeek 専用の策略グループを一つ切り、そこに安定したノードを割り当てると切り分けがしやすいです。ChatGPT 稿のように fallback で IP を固定したい要件がある場合は、同じグループ内で fallback 型に切り替えるだけで済ませられます。以下は構造の例です。プロキシ名は環境に合わせて置き換えてください。

# proxy-groups: dedicated group for DeepSeek (web + platform + API)
proxy-groups:
  - name: DEEPSEEK
    type: select
    proxies:
      - NODE-A
      - NODE-B
      - DIRECT

# rules: place before broad MATCH / GEOIP
rules:
  - DOMAIN-SUFFIX,deepseek.com,DEEPSEEK
  - MATCH,PROXY

DOMAIN-SUFFIX,deepseek.com は api.deepseek.com・platform.deepseek.com・api-docs.deepseek.com など同一レジストラ配下のサブドメインをまとめて拾う意図です。ログに deepseek を含まない別ホストが頻出するようなら、そのサフィックスを個別の DOMAIN 行で追加してください。逆に、業務用の無関係ドメインまで誤って同じノードへ流さないよう、過度に広いパターンは避けるのが安全です。

TUN モードとシステムプロキシでは挙動が変わります。モードごとの違いは TUN モードの解説も参照し、名前解決と実接続のログが矛盾していないかを確認してください。

5. DNS・fake-ip でズレる典型パターン

fake-ip を有効にしていると、アプリケーションが受け取る IP はローカルプールのダミーであり、実際の出口決定はコア内のルールと実接続フェーズで行われます。このギャップが、「解決は成功したのに期待した国のノードに出ていない」といった違和感として表れることがあります。DeepSeek のように HTTPS の SNI でホスト名が明示されるタイプの通信ではルールマッチ自体は追いやすい一方、ブラウザ拡張 DNS・別 VPN・OS の DNS 上書きが同時に有効だと、問い合わせだけコアをすり抜けるケースがあります。

切り分けの手順としては、（1）コアの DNS ログで deepseek 関連クエリがコアに届いているか、（2）接続ログで DEEPSEEK グループ（または意図した策略）にマッチしているかを同じ操作シナリオで見比べます。「ping で通る／通らない」だけに頼らず、TLS の失敗と HTTP ステータスを併記すると原因の当たりが早くなります。

企業ネットワークでは分割 DNS や SSL インスペクションが入り、自宅で動いた設定が再現しないことがあります。その場合は社内ポリシーを優先し、本稿は個人環境向けの参考として扱ってください。

6. API アクセス：環境変数・SDK・ログの見方

公式ドキュメントは curl https://api.deepseek.com/chat/completions のような例を掲げ、OpenAI SDK 互換の base_url 指定でも接続できる旨を説明しています。ここで詰まりやすいのは、ターミナルから実行したプロセスがシステムプロキシを見ていないことです。Clash の mixed-port や HTTP ポートに向けるなら、シェルで export HTTPS_PROXY=http://127.0.0.1:7890 のように明示し、NO_PROXY に誤って api.deepseek.com が入っていないかも確認してください。

Python や Node の SDK を使う場合、ランタイムを起動した IDE が別のプロキシプロファイルを持っていると、ターミナルと結果が分かれます。症状が「IDE 内だけ失敗」のときは、その IDE の HTTP プロキシ設定と、実際に使われている環境変数を開いて比較してください。ストリーミング応答では長めの TCP セッションや中間プロキシのタイムアウト値も効いてきます。

429 や認証エラーはプロキシ以前の要因であることが多いです。レート制限・キー失効・請求まわりのメッセージをログに残し、同じリクエストをプロキシ無し（許される環境のみ）で一度試すと切り分けが進みます。本稿はネットワーク経路に焦点を当て、課金やアカウント状態の詳細には踏み込みません。

7. QUIC / HTTP3 が絡むとき（他稿との補完）

UDP 上の QUIC は、ノード側やローカルファイアウォールとの相性でTCP の HTTPS より断続的に失敗しやすい場面があります。ブラウザだけ不安定で、curl は通るようなら HTTP/3 を疑う価値があります。具体的な無効化手順は Gemini / QUIC の記事に譲り、本稿ではDeepSeek の Web を触る際も同じ切り分けを併用できる点だけ押さえます。

Chromium 系では chrome://flags から QUIC をオフにして比較するのが手軽です。API 経路が HTTP/3 に載っていないケースも多いため、症状が API に限定されるなら優先度はドメイン漏れと DNS の方が高いことが多いです。

QUIC を切っても改善しない場合は、ルール順序・直結・ノードの UDP 制限など別要因に戻ってください。

8. 実測の進め方：コアログでホスト名を拾う

おすすめの順序は次のとおりです。（1）問題の操作をしながらコアログで deepseek 関連ホストがどの策略にマッチしたかを確認する。（2）意図したグループに揃っているのに失敗するなら、DNS ログと fake-ip 設定を確認する。（3）ブラウザ症状なら QUIC を無効化して再試行する。（4）API のみなら HTTPS_PROXY と NO_PROXY、IDE 設定を確認する。（5）それでも断続するなら別ノード・別プロトコル（UDP 許可）を比較する。

開発者ツールのネットワークタブで失敗しているホスト名をスクリーンショットやメモで残すと、後からルールに反映しやすくなります。再現手順が長いほど、ログのタイムスタンプと操作の対応を取る習慣が効いてきます。

Cursor 向けの開発者ドメイン分流稿では IDE 周りのホストを扱っています。エディタ内から DeepSeek 互換エンドポイントを叩く構成では、両稿の視点を組み合わせると抜け漏れが減ります。

9. つまずきやすいポイント

第一に、ルールの順序ミスです。広い MATCH や GEOIP が先に勝つと、DeepSeek 用の行が評価されません。ルールの並びを購読ファイル全体で見直してください。

第二に、API クライアントの直結です。ブラウザは通っても CLI が直結のままだと、出口が変わらずタイムアウトが続きます。環境変数とアプリ個別設定を疑ってください。

第三に、サービス側のレート制限やメンテナンスです。プロキシを正しくしても 5xx や 429 が返る場合は、ステータスコードとレスポンス本文を記録し、公式ステータスやフォーラム情報と突き合わせてください。

10. まとめ

DeepSeekは話題の集中とは別に、deepseek.com 傘のホストへ通信が分散するタイプのサービスです。まず mihomo の DOMAIN-SUFFIX で関連ホストを同じ策略グループに揃え、ブラウザと API で挙動が分かれるときは DNS（fake-ip）とクライアントのプロキシ設定を疑うと切り分けが速くなります。断続的なブラウザ不調には QUIC 無効化を、長文のストリーミングでは 中間プロキシのタイムアウトも視野に入れてください。

同じ Clash 系スタックでも、GUI の表記とコア世代は移り変わります。購読とルールを整理し、ログでホスト名を追う姿勢を保つのがいちばん確実です。クライアントの入手から始めるなら、 → 無料で Clash をダウンロードし、快適な接続体験を試すところから環境を揃えるのがおすすめです。