2026：Manus など AI エージェントを Clash で安定利用するドメイン分流と DNS（実測）
2025–2026 年は、単一のチャット画面に留まらない自律型 AI エージェントやタスク実行型プロダクトへの関心が高まっています。Manusのようにブラウザ上のセッション、ドキュメント・開発者向けのAPI、さらに計測や静的配信のための追加ホストが同時に動く構成では、openai.com 一本に寄せた分流ルールだけでは取りこぼしが出やすく、DNS（fake-ip・DoH）とルールの優先順位のずれが「画面は開くのにタスクだけ止まる」「長時間ジョブだけ切断」といった症状に見えがちです。本稿は具象的な検索入口として Manus（公式 Web やドキュメントが manus.im 系として現れやすい例）を軸に、Clash（多くの場合 Clash Meta／Mihomo コア）側でドメイン分流と名前解決を揃える考え方、Rule モードでのログ実測までを日本語で整理します。ChatGPT／OpenAI 向け記事、Perplexity 向け記事、Grok／X 向け記事とホスト集合を分離し、エージェント系に特有の多ドメイン混線に焦点を当てます。サービス側のエッジやサブドメインは更新で変わり得るため、以下の YAML は出発点の例とし、自分の環境の接続ログを正としてください。
なぜ「単一モデル向けルール」をそのまま流用しにくいか
従来の「ブラウザで一つの大規模言語モデルに質問する」用途と比べ、AI エージェント系では、(1) タスク実行に伴うバックエンド呼び出し、(2) ドキュメント・課金・開発者コンソールの別ホスト、(3) ブラウザ内の長めのセッションやWebSocketに近い維持接続、が同時に絡みやすいです。Clash の観点では「どのホストが DIRECT に落ちているか」「広い RULE-SET に先に飲まれていないか」「CLI や SDK がシステムプロキシを読まずに別経路で出ていないか」が分岐点になります。チュートリアルでモードの前提を押さえたうえで、カスタムルールの書き方と併読すると、エージェント向けの例外を上に積む判断がしやすくなります。
Manusを例に取ると、ユーザー向けの Web やドキュメントが manus.im 配下にまとまりやすい一方、公開ドキュメントや API の案内では open.manus.ai のような別ルートのホスト名が登場する場合があります（時期により変化し得ます）。いずれにせよ「代表ドメイン一行の PROXY」より、実際に TLS で繋いでいるホスト名の一覧をログから拾い、DOMAIN-SUFFIX や DOMAIN で足していく方が、安定アクセスの再現性が高まります。
分流の土台：proxy-groups に「エージェント用」を置く
購読テンプレの汎用 PROXY を直接指すより、AgentProxy のような用途名のグループを select または url-test で用意し、rules からは常にその名前を参照するのが運用しやすいです。Web の閲覧と API 呼び出しを同じ出口に揃えるか、レイテンシや規約の都合でAPI だけ別グループにするかも、グループ名を分けておけば後から差し替えが容易です。ネストや型の詳細は proxy-groups のガイド を参照してください。
rules 内の綴りが一致しているかを最初に確認してください。ここがずれると「ルールを足したのに効かない」状態になりがちです。
Web・ドキュメント・API：ホストの考え方（Manus クラス）
ブラウザのメイン UIでは manus.im や www.manus.im が中心になりやすく、静的アセットや計測用に追加のサブドメインやサードパーティ CDN が混ざることがあります。ドキュメント閲覧では manus.im/docs のようなパス配下に加え、別ドメインでホストされる説明ページが現れる場合があります。開発者向け APIや公開仕様の案内では、open.manus.ai など別ゾーンの FQDNがドキュメントに載る例があり、プロキシ設定では「Web と同じサフィックス一行」では足りないことがあります。いずれもインフラ変更で増減し得るため、以下は出発点の例です。実際に端末が接続しているホスト名をログで確認してから、ルールを狭めたり広げたりしてください。
方針として、(A) ユーザー向け Web・ドキュメント・公開 API 案内を同じ AgentProxy に寄せるのがシンプル、(B) 長時間ジョブだけ別ノードにしたい場合は、ログで頻出するホストだけ別グループに分ける、が現実的です。(C) DOMAIN-SUFFIX,ai のような広すぎる一括は他サービスへ波及しやすいので避け、manus.im やログで確認したサフィックスに絞るのが無難です。ルールの上から先にマッチした行が優先されることは カスタムルール記事 のとおりです。コミュニティの RULE-SET と併用する場合も、エージェント向けの例外を上に積むと意図した出口に寄せやすくなります。
rules:
# Examples only — tune group name (AgentProxy) and domains to your logs
- DOMAIN-SUFFIX,manus.im,AgentProxy
- DOMAIN-SUFFIX,open.manus.ai,AgentProxyブラウザ拡張、デスクトップクライアント、curl や SDK からの呼び出しは、参照するホスト名が UI と一致しないことが多く、本稿のリストとは必ずしも一致しません。その場合は接続ログに出た FQDN をそのまま DOMAIN や DOMAIN-SUFFIX で追加してください。HTTPS の SNI と実ホストの取り違えで挙動がおかしいときは、Clash Meta の sniffing と DNS の切り分けも併せて確認すると原因が絞りやすいです。
DNS と DoH：ルールより前に潰れる「名前解決」の落とし穴
分流ルールが正しくても、DNS が期待と違う応答を返すと、タイムアウトや証明書エラーに見えます。Clash／Mihomo 系では dns ブロックの fake-ip、redir-host、DoH の有無が挙動に直結します。テンプレの推奨設定から大きく外すと切り分けが難しくなることもあるため、まずは購読既定で再現する→ 問題が続くときに、(1) DoH エンドポイントの信頼性とレイテンシ、(2) nameserver-policy で manus.im や open.manus.ai だけ別 DNS に寄せる、(3) IPv6 の有無と OS の解決順、を一度に一項目ずつ変えるのが安全です。
ブラウザ独自の Secure DNS（DoH）と Clash 側の DNS が二重に効いていると挙動が読みにくいので、比較時にはブラウザ側を一時オフにする方法もあります。CLI やコンテナから API を叩く場合、システムプロキシを読まない経路があるとルールが効きません。そのときは TUN モード でトラフィックをコア側に寄せる案や、HTTPS_PROXY 環境変数の明示を検討してください。ルールの優先順位は、より具体的な DOMAIN を汎用の MATCH や広い RULE-SET より上に置く、という原則が API や長時間接続の取りこぼし防止に効きます。
動作モード：Rule・Global・Direct の使い分け
Rule が日常運用の基本です。Global は「すべてをプロキシへ」として、一時的にルール不足かノード品質かを切り分けるのに便利ですが、国内サイトまで遠回りになるため常時利用はおすすめしません。Direct はベースライン計測用に、Clash を事実上オフに近い状態で挙動を見るときに使います。エージェントのタスクだけ不調なときは Rule に戻し、該当ホストが意図したポリシーにマッチしているかをログで確認するのが定石です。トンネル型 VPN との違いは Clash と VPN の比較 も参照してください。
実測手順：ログで「宛先」と「採用ルール」を確認する
-
1
Baseline（Direct または Clash 停止）
まず Direct でブラウザからサービスを開き、同じ端末から
curl等で公開ドキュメントに記載の API ベース URL への疎通を試し、症状が再現するかを記録します。これで「ローカル回線やプロバイダ側」の要因も見えます。 -
2
Rule に戻し、UI と API それぞれでログを読む
エージェントにタスクを走らせる操作と、ターミナルからの API 呼び出しの両方について、接続一覧／コアログで向いているドメインとマッチしたルール行（またはポリシー名）をメモします。リストにないホストが出たら、それが次に追加すべき行です。
-
3
一行ずつルールを足して再計測
DOMAIN-SUFFIXを追加し、同じ操作を繰り返します。一度に大量変更すると効いた変更が特定できません。意図と違う行にマッチしているときは、より具体的なルールを上へ移動します。 -
4
DNS ログがあれば併記する
名前解決結果がおかしい場合はルールより先に DNS を直します。クライアントが DNS ログを出せない場合は、ログレベルを上げる、別ツールで確認するなど環境に合わせてください。
この繰り返しが本稿でいう「実測」です。検索で見つかるドメイン一覧は参考にとどめ、自分のログを正としてメンテすると、UI やエンドポイント変更にも追従しやすくなります。企業ネットや地域によっては特定ドメインへの到達性が制約される場合でも、出口の品質・DNS・ルールの三つを同時に疑うと早く収束しやすいです。他の自律型ツールを使う場合も、手順は同じでホスト集合だけが異なると考えると運用が楽です。
よくある質問
ブラウザは快適なのに API だけ失敗する
ブラウザはシステムプロキシ経由でルールが効いているが、ターミナルや Docker がプロキシ設定を読んでいないパターンです。環境変数、TUN、または実行ユーザの違いを確認してください。
長時間タスクだけ途中で切れる
別ホストへの再接続や WebSocket 様の維持接続が、意図せず DIRECT や遅いノードに落ちている可能性があります。ログに出たホストを追加し、該当行を上に移動して再確認してください。ノード側のアイドルタイムアウトも疑ってください。
職場・学校のネットワークでは？
組織ポリシーでプロキシ迂回が禁止されている場合があります。技術的に可能でも、規程と管理者の指示を優先してください。
まとめ
ManusのようなAI エージェント系では、単一チャット向けのホストリストより多ドメインに分流ルールを当て、DNS（DoH を含む） と Rule モードでのログ検証をセットにすると、「自律タスクを安定アクセスで回したい」という目的に沿いやすくなります。本稿のドメイン例は出発点であり、ログに基づきルールを育てることが長く使うコツです。単一ベンダーのチャット中心の整理は ChatGPT の記事、AI 検索まわりは Perplexity の記事、ソーシャル連携は Grok／X の記事で別ホスト集合として扱っているため、混同せず参照してください。
クライアントの入手は 本サイトのダウンロードページ を第一にすると、記事との対応も追いやすくなります。オープンソースの参照や Issue の確認は GitHub 等でも可能ですが、インストーラの主導線は本サイトのダウンロードページに寄せるのが、他の AI 向け記事とも揃った使い方です。ルールの基礎を固めたい場合は カスタムルール完全ガイド も併せてどうぞ。用途ごとに出口を切り替えられる点では、端末全体を常時トンネルする汎用 VPN に比べ、Clash の運用体験が一段整理されやすい場面が多いです。