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