1 背景とゴールをそろえる
2026 年時点でも、業務や学習での生成 AI と検索の融合は拡大しており、Perplexity は引用つき回答や Pro プラン、モバイルでの音声入力など、プロダクト面の更新が続いています。利用者側のつまずきは、モデル選び以前に分散したドメインへの HTTPS が片方だけ不安定になることに現れがちです。Web フロントは静的アセット、認証、計測、CDN、バックエンド API を複数ホストへ分け、モバイルアプリは OS のネットワークスタック経由で同じエンドポイントへ接続しますが、システムプロキシの有無・TUN の有無・VPN 併用によっては、同じアカウントでも端末ごとに出口が変わり、ブラウザではログインできたのにアプリだけセッション切れに見える、といった切り分けが難しくなります。
本稿のゴールは、帯域をむやみに広げることではなく、Rule モードで Perplexity 向けトラフィックを意図したアウトバウンドへ集約することです。IDE 連携全般はCursor と Clash の記事で扱っています。OpenAI はChatGPT／OpenAI API 向けの記事、Google はGemini 向けの記事、Anthropic はClaude 向けの記事、中国発モデルはDeepSeek 向けの記事が対応します。ここでは Perplexity のホスト設計に寄せ、粗い GEOSITE 一枚だけに頼らず、漏れと過剰マッチの両方を減らすことを意識します。
2 Perplexity の Web と App が触るホストを押さえる
実際のホスト名はプロダクト更新で増減するため、最終的には Clash の接続ログで SNI を確認するのが確実です。それでも設計上、次のような束に分けて考えるとルールが書きやすくなります。
- メイン Web／API の土台：
perplexity.aiおよびwww.perplexity.ai。チャット UI、設定、誘導が*.perplexity.ai配下にまとまることが多く、単一のDOMAINだけでは足りない場面があります。 - 短縮ドメイン：
pplx.aiは共有リンクやリダイレクトで使われることがあり、ブラウザとアプリで経路が分岐しやすいポイントです。DOMAIN-SUFFIX,pplx.aiを同じプロキシグループへ寄せておくと体験が揃いやすいです。 - CDN・計測・認証： フロントのビルドや A／B テストにより、別サブドメインやサードパーティホストが増える場合があります。失敗時はログの SNI を追記してください。
- GEOSITE に頼りすぎない理由： 購読リストの「海外 AI」カテゴリは便利ですが、更新タイミングや分類粒度によっては Perplexity 専用のホストが未収録だったり、逆に不要なドメインまで同じプロキシに乗ったりします。安定性を優先するなら、自前の短いサフィックスリスト＋ログでの追記が扱いやすいです。
まずは失敗時に表示されるエラーが「名前解決」「TCP の拒否」「TLS ハンドシェイク」「HTTP 403／401／レート制限」のどれに近いかを分け、接続ログのドメインと突き合わせてください。ストリーミング応答や長めの検索セッションは HTTP の長い接続になるため、パケット損失の大きいノードでは UI 上「途中で途切れる」ように見えます。
3 ルールモードとプロキシグループの置き方
推奨は mode: rule です。Perplexity 向けに PROXY-PPLX のようなセレクタまたは url-test 付きグループを一枚挟み、遅延の安定したノードと、帯域はあるが不安定なノードを分けておくと、長めのストリーミング応答を比較しやすくなります。グローバルモードは国内向けサービスまで遠回りし、ダイレクト固定ではアプリだけ失敗する、というジレンマが出ます。
購読テンプレートに既に「国外サイト」ブロックがある場合は、その直前に Perplexity 向けの明示ルールを置き、意図せず別タグのノードへ飛ばないようにします。セレクタで国や事業者を切り替える運用では、データ所在地や利用条件の表記とあわせて公式情報を確認してください。チームや家族で端末が分かれる場合は、どの端末がシステムプロキシを見るか、TUN を使うかをメモしておくと、Web とアプリの差の切り分けが速くなります。Web とアプリを別策略グループに分けたい場合は、レイテンシ重視のノードをアプリ用、コスト重視をブラウザ用にする、といった運用も可能ですが、まずは同一グループに集約してログで十分ならシンプルに保つのがおすすめです。
4 YAML に書くルール例と Rule Provider
以下はイメージです。proxy-groups 名やインデントは手元の設定に合わせてください。コメントは英語のみとします。
# Example: route Perplexity properties to a dedicated selector
rules:
- DOMAIN-SUFFIX,perplexity.ai,PROXY-PPLX
- DOMAIN-SUFFIX,pplx.ai,PROXY-PPLX
# Optional: remote rule-provider (path/interval are examples)
# rule-providers:
# perplexity:
# type: http
# behavior: classical
# url: "https://example.com/rules/perplexity.txt"
# path: ./rules/perplexity.yaml
# interval: 86400
# rules:
# - RULE-SET,perplexity,PROXY-PPLX
上記では DOMAIN-SUFFIX,perplexity.ai と pplx.ai で主要ゾーンを覆います。Rule Provider を使う場合も、リモートリストの中身が信頼できるか、更新間隔とローカル追記ルールの優先順位を確認してください。Clash 系は上に書いたルールが先に評価されるため、細かい DOMAIN を上に、広い GEOIP や MATCH を下に置くのが定石です。DOMAIN-KEYWORD,perplexity は無関係サイトを巻き込みやすいので、長期運用ではサフィックスとログ追記を優先します。
ターミナルやサードパーティクライアントから API 風の HTTPS を叩く場合は、プロキシを明示しないと OS のルーティングに任せます。環境変数で HTTPS_PROXY を併用するか、TUN モードで仮想 NIC レベルに揃えると、ブラウザと CLI のばらつきを減らせます。
5 ブラウザとモバイルアプリの経路差
デスクトップのブラウザは、多くの場合 OS のシステムプロキシ設定を参照します。一方、iOS／Android の公式アプリは、実装によっては独自の TLS スタックを持ち、システム VPN やプロキシの外に出ることがあります。Clash 側で安定させる代表的な手段は、(1) システムプロキシとルールを揃えたうえでアプリを試す、(2) うまくいかなければ TUN モードでデバイス全体のトラフィックを同じルールに載せる、の二段構えです。
iPhone／iPad で Clash 互換の設定を扱う場合は、Stash によるサブスクリプション取り込みとルール編集の流れが参考になります。Android では FlClash などクライアントごとに TUN の扱いが異なるため、接続ログで Perplexity 関連の SNI が期待どおりプロキシグループに乗っているかを確認してください。ブラウザ拡張やショートカット経由のリダイレクトでは pplx.ai だけが抜けて失敗する、といったパターンでは、サフィックスの追記とルール順の見直しが効きます。
6 DNS・FakeIP・TLS をセットで見る
ホスト数は検索系サービスとしては比較的コンパクトですが、DNS の答えが期待とズレると「ブラウザでは開けるのにアプリだけ名前解決が変」という現象は同様に起きます。Mihomo では DoH、FakeIP、fallback-filter の組み合わせが定番です。設定の細部はMeta カーネル DNS の実務記事に譲ります。Clash の DNS セクションと OS の DNS を二重管理しないこと、TUN と DNS ハイジャック併用時にローカル開発用ゾーンを DIRECT に残すことが安定の鍵です。
TLS の観点では、SNI が perplexity.ai であっても、途中の企業プロキシによるインスペクションでクライアント証明書検証が失敗するケースがあります。エラー文言が証明書関連なら、まず社内ポリシーと OS の信頼ストアを疑ってください。逆にルールで意図せず DIRECT に落ちていると、RST やタイムアウトとして現れます。アカウント連携やサブスクリプション情報は、公開 Wi-Fi でも平文で送らない、という一般的な注意も変わりません。
7 Web と App の動作確認
ブラウザで Perplexity のメイン UI を開き、ログインと検索が一通りできる状態を基準にします。続けて、同じネットワーク上のスマホから公式アプリで同じアカウントを試し、接続ログに perplexity.ai や pplx.ai が現れるかを見ます。ここでだけ失敗する場合は、ルールよりも端末側のプロキシ認識か、TUN がオフの可能性が高いです。セレクタで別アウトバウンドへ切り替え、再現性を比較してください。
レート制限と課金
ネットワークが正しくても、プランやアカウント状態で 429 や課金エラーが返ることがあります。ダッシュボードの利用状況とあわせて切り分けます。モバイル回線と Wi-Fi を切り替えて挙動が変わる場合は、単純に DNS の差ではなく、キャリアの IPv6 経路やキャプティブポータルの影響も疑ってください。
8 トラブルシューティング
- ブラウザだけ成功してアプリが失敗： システムプロキシと TUN の組み合わせを見直す。iOS／Android では VPN プロファイルや「常時オン」の競合も確認します。
- 共有リンクだけ開けない：
pplx.aiがルールに含まれているか、より広いルールに先にマッチしていないかを確認します。 - ストリームが途中で切れる： ノードのパケット損失や、長時間接続の切断を疑い、セレクタで別サーバへ切り替えて比較します。
- 新しいサブドメインで失敗： 接続ログに出た SNI を
DOMAIN-SUFFIXまたはDOMAINで追記し、Rule Provider のリストにも反映できるか検討します。 - ルールを足したら国内サイトが遅くなった：
GEOIP,JP,DIRECTなど直行ルールとの順序を見直し、誤マッチがないか確認します。
9 まとめ
Perplexity を「ブラウザだけ速くする」のではなく、perplexity.ai 系と pplx.ai を含む共有・短縮ドメインまで、トラフィックをルールと DNS で一貫させると、Web・モバイル・ショートカットをまたいだ再現性が上がります。粗い GEOSITE だけに頼ると漏れと過剰マッチの両方が出やすいので、DOMAIN-SUFFIX とログベースの追記、必要なら Rule Provider で保守性を補います。ChatGPT や Claude、Gemini、DeepSeek を併用する場合も、ベンダーごとに出口を分けておくと切り分けが容易です。
まずは手元の YAML に Perplexity 向けサフィックスを追記し、接続ログで漏れがないか確認してください。DNS の細部はDNS 実務記事に譲ります。ルール分流とログの読み方さえ身につけば、同じ考え方を他のクラウド型検索サービスにも転用できます。
単機能の軽量プロキシより、ルールと DNS を一体で扱える Clash 互換スタックの方が、長めの HTTPS セッションや複数ドメインにまたがるモバイルアプリの通信に強い場面が多いです。AI 検索を日々のフローに組み込むほど、その差は試行回数と体験の安定性に直結します。
