Perplexity が開けない？Clash / mihomo で「検索型 AI」のドメインを分流し、DNS・Fake-IP まで含めて整える（2026）

1. 他の AI 向け記事と何が違うか（検索型・集約型の位置づけ）

当サイトでは、ChatGPT 向けの固定ノードと fallback、Claude / Anthropic の地域表示と DNS（fake-ip）、Gemini / Google AI の広いドメイン散らばり、DeepSeek の compact な名前空間と API、Grok・xAI・X（Twitter）の別ベンダー束ねを別稿で扱っています。いずれも「表に見えているホストより裏で別名義の通信が増える」点では共通ですが、Perplexity は「検索結果の取得」と「チャット応答」を同一プロダクト内で回すため、Web フロントと api.perplexity.ai 系のバックエンドがセットで安定しないと、ユーザー体感では検索だけ止まる／応答だけ途切れるように見えます。

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

購読の取り込みや初期設定は サブスクリプション導入ガイドを参照しつつ、以下では Perplexity 向けにホスト名の束ね方とDNS の取り回しに焦点を当てます。OpenAI アカウント停止のような別種の「ポリシー・契約」問題は、本稿のスコープ外です。

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

第一層はルーティング（ドメイン分流）です。www.perplexity.ai だけをプロキシに載せても、SDK や拡張機能が api.perplexity.ai に直接伸びていると、画面の一部だけ真っ白・API だけ 403 やタイムアウトが起きます。出発点としては DOMAIN-SUFFIX,perplexity.ai で同一策略グループに揃えるのが素直で、ログを見ながら不足サフィックスを足す運用に移ります。

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

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

3. 押さえたいホスト名：Web・ドキュメント・API

インフラ側の構成は変わり得るため、必ず公式の開発者ドキュメントやブラウザの開発者ツールで実際の通信先を突き合わせてください。2026 年時点の公開ドキュメントでは、Sonar（チャット completions 互換）や Search API、Agent API などが https://api.perplexity.ai 配下のパスとして説明されています。キー発行やコンソール類は Web 側の perplexity.ai ドメインに寄せられることが多く、DOMAIN-SUFFIX,perplexity.ai を一括で同じ策略に載せるのが運用上ラクな出発点になります。

ドキュメント本体は Mintlify 系のホストに載るケースがあり、docs.perplexity.ai のような名前で別ホストが出ることもあります。ネットワークタブで赤表示になっているホストをメモし、perplexity.ai 以外に常習的に出る名前があれば DOMAIN 行で拾うのが安全です。共有リンクや短縮ドメインとして pplx.ai 系が混ざる場面も報告されるため、実測で頻出するなら同じ策略グループに足すか、少なくとも意図した出口に流れているかログで確認してください。

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

4. mihomo ルール例：PERPLEXITY 策略グループへ束ねる

実務では Perplexity 専用の策略グループを一つ切り、そこに安定したノードを割り当てると切り分けがしやすいです。出口の国や事業者ポリシーで挙動が変わる場合は、同一グループ内でノードを切り替えて比較するだけで仮説検証が進みます。以下は構造の例です。プロキシ名は環境に合わせて置き換えてください。

# proxy-groups: dedicated group for Perplexity (web + API + docs)
proxy-groups:
  - name: PERPLEXITY
    type: select
    proxies:
      - NODE-A
      - NODE-B
      - DIRECT

# rules: place before broad MATCH / GEOIP
rules:
  - DOMAIN-SUFFIX,perplexity.ai,PERPLEXITY
  - DOMAIN-SUFFIX,pplx.ai,PERPLEXITY
  - MATCH,PROXY

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

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

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

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

切り分けの手順としては、（1）コアの DNS ログで perplexity 関連クエリがコアに届いているか、（2）接続ログで PERPLEXITY グループ（または意図した策略）にマッチしているかを同じ操作シナリオで見比べます。「ping で通る／通らない」だけに頼らず、TLS の失敗と HTTP ステータスを併記すると原因の当たりが早くなります。検索型 AI は長めのストリーミング応答や複数ホストへの連続フェッチが絡みやすく、一瞬だけ成功して途中で切れる症状は中間プロキシのタイムアウトやノードの帯域も疑う余地があります。

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

6. 心流など「同型」の対話検索への当てはめ

中国語圏で話題になる心流（シンリュウ）検索のようなサービスは、プロダクトごとにドメイン構成が異なり、本稿で固定の DOMAIN リストを列挙することはできません。ただしトラブルの型は Perplexity と同じで、（1）Web の読み込み用ホスト、（2）API やストリーミング用ホスト、（3）分析・認証・CDN の別名に通信が分散し、片方だけ購読ルールの末尾 MATCH に飲まれると症状が分かれて現れます。

実務的な手順は、ブラウザの開発者ツールで失敗しているリクエストのホスト名を列挙し、共通するレジストラサフィックスがあれば DOMAIN-SUFFIX で束ね、バラバラなら DOMAIN 行を積み上げることです。Perplexity で学んだ「API と Web を同一策略に揃える」発想をそのまま持ち込めるため、多言語の検索 UI を横断して使う読者にとっても再利用価値があります。

規制表示やアカウント地域の話題はフォーラムで盛り上がりやすいですが、本稿はネットワーク経路とルール設計に限定します。利用可否は各サービスの規約とご自身の環境に従って判断してください。

7. QUIC について（本稿では深掘りしない理由）

HTTP/3（QUIC）は、ノードやローカルファイアウォールとの相性でTCP の HTTPS より断続的に失敗しやすい場面があります。Gemini / Google AI 向けの記事では QUIC 無効化や UDP まわりの切り分けに厚めに触れています。本稿では Gemini 稿と役割を分けるため、ドメイン一覧と分流／DNS の組み合わせを主役にし、QUIC 固有の手順は Gemini 向けの QUIC 記事に譲ります。ブラウザだけ不安定で curl は通るようなら、そちらを併読してください。

API 経路が HTTP/3 に載っていないケースも多いため、症状が api.perplexity.ai に限定されるなら、優先度はドメイン漏れと DNS の方が高いことが多いです。

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

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

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

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

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

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

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

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

10. まとめ

Perplexityは、perplexity.ai 傘の Web と api.perplexity.ai 系 APIに通信が分岐する検索型・集約型の対話 AIです。まず mihomo の DOMAIN-SUFFIX で関連ホストを同じ策略グループに揃え、ブラウザと API で挙動が分かれるときは DNS（fake-ip）とクライアントのプロキシ設定を疑うと切り分けが速くなります。短縮ドメインやドキュメントホストが混ざる場合はログで足し込むのが確実です。QUIC が気になる場合は Gemini 稿で補完し、心流のような同型サービスには同じドメイン拾いの手順を当てはめてください。

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