📖 チュートリアル ⏱ 約17分で読めます

2026：Clash で DeepSeek を安定利用する分流ルールと DNS（Web・API）

DeepSeekは、ブラウザのチャット画面と、開発者向けの HTTP API（api.deepseek.com など）で触るホスト名が分かれやすいサービスです。端末全体を VPN で一本化する代わりに、Clash の分流ルールで DeepSeek 関連だけを選んだ出口へ寄せ、国内向けトラフィックは従来どおりに保ちたい、という需要が 2026 年も根強くあります。本稿は Google 系の Gemini 向け記事とはドメイン集合を完全に分離し、Web 利用とAPI 呼び出しの両方を想定して、ドメインルール・DNS・ログによる実測までを日本語で整理します。ホスト名はサービス更新で変わり得るため、例は出発点と捉え、自分の環境のログを正としてください。

DeepSeek が「不安定」に見えるときの切り口

症状を分類すると対処が速くなります。(1) ブラウザのチャットだけ読み込みが遅い・途中で切れる、(2) curl や SDK からの APIだけタイムアウトや TLS エラー、(3) ログインや課金画面でループする、といったパターンです。(1)(2) は、該当ホストが意図せず DIRECT になっている／逆に意図しない地域のプロキシに流れている、(3) は認証用サブドメインがルールから漏れている、が典型です。API キーをサーバー側だけで使う構成ではローカルの Clash は関係しませんが、開発用 PC やコンテナホストから直接 API を叩く場合は、同じマシン上の Clash が名前解決と転送経路の両方に影響します。

用語の整理は チュートリアル、ルールの書き方は カスタムルールの解説 と併読するとスムーズです。Google Gemini は googleapis.com など別系統のホストが中心ですが、DeepSeek は deepseek.com 配下に集約されやすい一方、ドキュメント用やステータス表示のサブドメインが増えることがあるため、ログで足りない行を足す姿勢が重要です。

分流の土台：proxy-groups に「DeepSeek 用」を用意する

購読テンプレの PROXY をそのまま指すより、DeepSeekProxy のような用途名のグループを select または url-test で用意し、rules からは常にそのグループ名を参照するのが運用しやすいです。ノードを差し替えてもルール本文を触らずに済み、Web と API を同じ出口に揃えるか、遅延検証でAPI だけ別グループに分けるかも、名前を分けておけば後から変更できます。ネストや型の詳細は proxy-groups のガイド を参照してください。

💡 ヒント テンプレのグループ名と rules 内の綴りが一致しているかを最初に確認してください。ここがずれると「ルールを足したのに効かない」状態になりがちです。

Web と API：DeepSeek 関連でよく現れるホストの考え方

Web チャットでは chat.deepseek.com や www.deepseek.com、公式情報・ログイン周りでは platform.deepseek.com などが使われることがあります。APIの公式ベース URL はドキュメント上 https://api.deepseek.com（OpenAI 互換の /v1 付き URL も併記）が中心です。ドキュメント閲覧では api-docs.deepseek.com、障害確認では status.deepseek.com が参照される例もあります。いずれもサブドメイン追加や CDN の前段で変化し得るため、以下の YAML は出発点の例であり、実際にマシンが接続しているホスト名をログで確認してから狭めたり広げたりしてください。

方針として、(A) チャット UI と API を同じ DeepSeekProxy に寄せるのがシンプル、(B) 課金や開発者コンソールだけ別経路にしたい場合は platform.deepseek.com だけ別グループにする、などに分けられます。(C) DOMAIN-SUFFIX,deepseek.com の一括は手早いですが、意図しないサブドメインまで同じ出口に乗るため、まずはログで必要なサフィックスに絞るのが安全です。ルールの上から先にマッチした行が優先されることは カスタムルール記事 のとおりです。

rules:
  # Examples only — tune group name (DeepSeekProxy) and domains to your logs
  - DOMAIN-SUFFIX,chat.deepseek.com,DeepSeekProxy
  - DOMAIN-SUFFIX,www.deepseek.com,DeepSeekProxy
  - DOMAIN-SUFFIX,platform.deepseek.com,DeepSeekProxy
  - DOMAIN-SUFFIX,api.deepseek.com,DeepSeekProxy
  - DOMAIN-SUFFIX,api-docs.deepseek.com,DeepSeekProxy
  - DOMAIN-SUFFIX,status.deepseek.com,DeepSeekProxy

サードパーティのミラー site や非公式クライアントは別ドメインになることが多く、本稿のリストとは一致しません。その場合は接続ログに出たホストをそのまま DOMAIN や DOMAIN-SUFFIX で追加してください。コミュニティの RULE-SET を併用する場合も、DeepSeek 用の例外を上に積むと意図した出口に寄せやすくなります。

DNS：誤った名前解決が「ルール以前」の問題になるとき

分流ルールが正しくても、DNS が期待と違う応答を返すと、タイムアウトや証明書警告に見えます。Clash／Mihomo 系では dns ブロックの fake-ip、redir-host、DoH の有無が挙動に直結します。テンプレの推奨設定から大きく外すと切り分けが難しくなることもあるため、まずは購読既定で再現する→ 問題が続くときに、(1) DoH エンドポイント、(2) nameserver-policy で特定サフィックスだけ別 DNS、(3) IPv6 の有無、を一度に一項目ずつ変えるのが安全です。

ブラウザ独自の「DNS over HTTPS」と Clash 側の DNS が二重に効いていると挙動が読みにくいので、比較時にはブラウザ側を一時オフにする方法もあります。CLI やコンテナから API を叩く場合、システムプロキシを読まない経路があるとルールが効きません。そのときは TUN モード でトラフィックをコア側に寄せる案や、HTTP(S)_PROXY 環境変数の明示を検討してください。

動作モード：Rule・Global・Direct の使い分け

Rule が日常運用の基本です。Global は「すべてをプロキシへ」として、一時的にルール不足かノード品質かを切り分けるのに便利ですが、国内サイトまで遠回りになるため常時利用はおすすめしません。Direct は Baseline 計測用に、Clash を事実上オフに近い状態で挙動を見るときに使います。DeepSeek だけ不調なときは Rule に戻し、該当ホストが意図したポリシーにマッチしているかをログで確認するのが定石です。トンネル型 VPN との違いは Clash と VPN の比較 も参照してください。

⚠️ 注意 API キーはクライアント側の設定ファイルや環境変数に平文で残りやすいです。リポジトリにコミットしない・共有 PC では権限を絞る、などセキュリティ面はプロキシ設定とは独立して必ず確認してください。

実測手順：ログで「宛先」と「採用ルール」を確認する

  1. 1

    Baseline（Direct または Clash 停止）

    まず Direct でブラウザからチャットを開き、同じ端末から curl 等で API の疎通を試し、症状が再現するかを記録します。これで「ローカル回線やプロバイダ側」の要因も見えます。

  2. 2

    Rule に戻し、Web と API それぞれでログを読む

    チャット操作と API リクエストの両方について、接続一覧／コアログで向いているドメインとマッチしたルール行（またはポリシー名）をメモします。リストにないホストが出たら、それが次に追加すべき行です。

  3. 3

    一行ずつルールを足して再計測

    DOMAIN-SUFFIX を追加し、同じ操作を繰り返します。一度に大量変更すると効いた変更が特定できません。意図と違う行にマッチしているときは、より具体的なルールを上へ移動します。

  4. 4

    DNS ログがあれば併記する

    名前解決結果がおかしい場合はルールより先に DNS を直します。クライアントが DNS ログを出せない場合は、ログレベルを上げる、別ツールで確認するなど環境に合わせてください。

この繰り返しが本稿でいう「実測」です。検索で見つかるドメイン一覧は参考にとどめ、自分のログを正としてメンテすると、UI やエンドポイント変更にも追従しやすくなります。

よくある質問

ブラウザは快適なのに API だけ失敗する

ブラウザはシステムプロキシ経由でルールが効いているが、ターミナルや Docker がプロキシ設定を読んでいないパターンです。環境変数、TUN、または実行ユーザの違いを確認してください。

DOMAIN-SUFFIX,deepseek.com にしたら他の通信まで変わった

サフィックス一括は広くマッチします。影響が大きい場合はログで実際のホストを列挙し、必要なサブドメインだけに狭めてください。

職場・学校のネットワークでは？

組織ポリシーでプロキシ迂回が禁止されている場合があります。技術的に可能でも、規程と管理者の指示を優先してください。

まとめ

DeepSeekのようにWeb フロントとAPI エンドポイントが分かれているサービスでは、分流ルールをシーン別に整理し、DNS と Rule モードでのログ検証をセットにすると、「グローバルプロキシに頼らずに安定させたい」という目的に沿いやすくなります。本稿のドメイン例は出発点であり、ログに基づきルールを育てることが長く使うコツです。Google エコシステム向けの分流は Gemini の記事で別ホスト集合として扱っているため、混同せず参照してください。

安定したクライアントを試す場合は、パッケージの入手先として 本サイトのダウンロードページ を第一にすると、記事との対応も追いやすくなります。ルールの基礎を固めたい場合は カスタムルール完全ガイド も併せてどうぞ。

→ Clash を無料ダウンロードし、DeepSeek 向けの分流と DNS を試す