Perplexity 接続 Clash 分流と固定ノードウェブ 2026

「ブラウザ版は出るのに Pro だけ遅い」は、Clash 分流の抜けと出口のブレが重なると起こりやすい

AI サーチ分野の代表格の一つである Perplexity は、トップの検索欄、引用リンクの取得、要約、画像やモバイル用アセット、課金・管理画面、短縮ドメインのリダイレクトなど、短時間に別のホスト名へ分岐しやすい構造を持っています。体感的には同じ「ひと続きの会話」でも、裏では OAuth、決済、CDN、計測、そして会話用 API に近い層が並列に走り、どれか一つが DIRECT や品質の悪い出口に落ちると、ページ全体が一瞬だけ開きかけて止まる、Pro だけ重い、といった部分的成功に見えがちです。

手元のネットワークが安定していても、Clash 分流の設計が「広い GEOIP や国内直結に先に飲まれる」「url-test でノードが高頻度に入替わる」状態だと、ドメインごとに出口が揃わず、TLS 再試行や再ログイン、ストリーミングの再開が多発します。本稿の狙いは、禁止回避を煽ることではなく、正当なアクセス権を前提に、ルールの命中と固定ノードを揃えて、名前解決（DNS）と証明書検証（SNI）の前提を一つに戻すことです。大枠の国内直通の設計は国内直結と海外プロキシの分流、ログの見方は接続ログの記事と併せてください。

💡

他の AI 記事との棲み分け OpenAI 系はChatGPT 向けの記事、Google 系はGemini 向けの記事、X 上の Grok はGrok 向けの記事で扱い、本稿は Perplexity ドメイン列に限定してキーワードの重なりを抑えます。

三つの面を分けて考える：一般会話、課金 Pro、補助ドメイン

設定を層に分けると、あとからログで追いやすくなります。第一の層は、多くの利用者が触る ブラウザ版の会話体験。第二の層は、追加機能や従量に関する Pro／アカウント周辺。第三の層は、短縮や遷移のために出やすい pplx.ai などの補助ホストです。いずれも HTTPS 前提ですが、許容したい出口リージョンと、遅延よりも「切れない」ことが優先かどうかが、面ごとに違います。

実際のホスト名はプロダクト更新で動くため、接続ログに出た名前を正としてルールに足すのが安全です。初期の当たりとして、多くの環境で perplexity.ai や www.perplexity.ai、pplx.ai、配下の API らしき *.perplexity.ai が挙がりがちですが、googleapis.com ほど他用途と衝突するわけではない一方、サフィックスを雑に広げすぎると国内向けトラフィックまで巻き込む危険があるので、ログに根拠のある行から追加する方針を推奨します。

YAML の例：会話用と Pro 用（概念デモ）

下記は入門向けの概念デモです。ノード名・購読名は環境に合わせて置き換えてください。行末コメントは英語のみにします。

proxy-groups:
  - name: PPLX-WEB
    type: select
    proxies:
      - US-PPLX-WEB
      - JP-PPLX-WEB
      - DIRECT
  - name: PPLX-PRO
    type: select
    proxies:
      - US-PPLX-PRO
      - JP-PPLX-PRO
      - DIRECT
  - name: PPLX-AUX
    type: select
    proxies:
      - US-PPLX-AUX
      - DIRECT

rules:
  # Place before wide GEOIP / MATCH
  - DOMAIN-SUFFIX,perplexity.ai,PPLX-WEB
  - DOMAIN-SUFFIX,pplx.ai,PPLX-AUX
  # If logs show a dedicated billing host, add it explicitly
  # - DOMAIN-SUFFIX,example-billing.perplexity.ai,PPLX-PRO
  # ... GEOIP / MATCH

上では「会話面」と「有料面」をポリシーとして分けられるように示しました。実際の課金フローがメイン会話と同一ドメイン上にある場合、一行で束ねてから固定ノード一つに落とし、抜けがないかを接続ログで確認するほうが早い場面が多いです。購読の再配布で上書きされる場合、prepend-rules を使ったオーバーライドで先頭に差し込むのが扱いやすいです。

固定ノード：ヘルスチェックだけの `url-test` に頼りすぎない

Perplexity のように長い応答や引用リンク周りの遅延が出やすいサービスでは、間隔の狭い url-test だけを上に載せると、測定のたびに別出口へ乗り換え、TLS ハンドシェイク途中の切断や、ブラウザ側の再試行のスパイクが出やすくなります。体感的に「ブラウザ版が一瞬出て止まる」症状は、サーバ品質の前に出口のブレを疑う価値があります。

現実的なのは、検証に通った 1 ノードを select 型のポリシーで手動に近い形で留める、あるいは fallback の計測間隔を長くして乗り換え頻度を下げることです。まずは単一リージョンに固定し、同じ手順を繰り返したときの再現性が下がるかを見ると、切り分けが速いです。接続行に選ばれているラベル名がセッション中に行ったり来たりしていないか、ログで併せて確認します。

ルールの優先順位：細い DOMAIN を、広い `GEOIP,CN` より前に

典型の落とし穴は、リストの上から順に当たる仕組みのなかで、DOMAIN-SUFFIX,perplexity.ai,... より前に、広い GEOIP,CN,DIRECT や「残り全部プロキシ」系が置かれていることです。DNS の戻りや fake-ip 設定の組み合わせ次第で、一部のサブドメインが意図せず DIRECT のまま残り、Top は表示されるのに、課金・API 層だけが遅延する、という部分的成功に見えます。対策は、確定してほしい DOMAIN 行を上に、広い行を下に、です。

大枠の中国本土向けを直結にする方針は、まず国別の設計を国内直結の記事のとおり整え、その上に本稿の Perplexity 用の行を重ねるイメージが噛み合いやすいです。YAML の長さに自信がなければ、最終的にはログ上の host と選ばれた policyの対応を見るほうが早いことが多いです。

DNS・fake-ip と SNI：名前と ClientHello の齟齬を潰す

fake-ip では、画面に見えているホスト名と、実際にルーティングが追う解の関係が直感とズレやすく、ルールは当たっているのに出口だけ別、という挙動が出ます。OS の暗号化 DNS やブラウザの DoH、Clash 側の DNS 設定を、検証中は一つに寄せて挙動差を見るのも有効です。手早くモード比較するならfake-ip と redir-hostの記事を併用してください。

HTTPS では、ClientHello に載る SNI が証明書の名前と揃っていなければ失敗に見えます。企業内のスキャン、透明プロキシ、広告止め拡張が同居していると、Clash 以前の層で不整合が生じ、AI 系サイトが「一瞬だけ不調」に見えることがあります。切り分けのコツは、Clash のみ・拡張オフのミニマルなブラウザで同じ手順を試し、悪化が消えるなら、プロキシ以外の層を疑います。TLS 周りの深堀はClaude 向け SNI 稿と相互補完になります（サービス名は違いますが、SNI 思考は共通です）。

TUN とシステムプロキシ：「ブラウザだけルール外」にしない

ブラウザは OS プロキシと TUN モードのどちらに従うかで挙動が変わります。デスクトップ拡散や PWA 形式に寄せると、一部の子プロセスやバックグラウンド更新が、見えづらい経路に外れることがあるので、全アプリ等重にルールを当てたい場合は TUN か、mixed-port に明示で揃えます。CLI スクリプトで API 風のエンドポイントに直接叩いているなら、HTTPS_PROXY／ALL_PROXY と、ループバック上の待受ポートの一致も忘れないでください。

Pro／アカウント層：地理的に離れた出口の連続利用に注意

有料層のセッションは、同じ端末内でも、短時間に大きく離れた出口から同じサービスへ到達し続けると、再認証や追加の確認に見える挙動が出やすいことがあります。切り分けのためとはいえ、利用規約と接続元として許容された範囲を常に超えないでください。まず手元の改善としては、会話用と管理用を同一ポリシーに戻し、固定ノード一つに揃えて再現性が落ちるかを見るのが早道です。

照合チェックリスト

会話のストリーミングだけ途切れる

メイン会話用ドメインが意図した select に乗り、MATCH 前に抜けがないかを接続ログで確認。ノードを一時的に一つに固定し、url-test 由来の乗り換えが多すぎないか併せて見る。

課金・Pro 導線だけ遅い

決済アセットや *.stripe.com 等の第三ドメインが、別の広いルールに先食いされている可能性。ログ上の host ごとに、該当行を上へ寄せ、必要なら専用ポリシーに分ける（過剰な一括 DOMAIN-KEYWORD は慎重に）。

短縮リンク遷移でだけ失敗

pplx.ai 系が AUX 用ポリシーに入っているか、DIRECT に落ちたまま再ダイレクトを繰り返していないかを確認。DNS 汚染が疑われるなら一時的に 信頼できる名前解決に寄せて差分を観測（恒久設計はネットワーク方針に従う）。

まとめ：2026 年、Perplexity を Clash 分流で安定させる三原則

本稿は、AI サーチの人気に伴い話題性の高い Perplexity を題材に、Clash 分流で DOMAIN を束ね、固定ノードで出口のブレを抑え、ルールの優先順位で細い行を抜かさない、DNS と SNI の前提を一つに戻す、という流れに整理しました。他の大規模言語系サービス向けの手順は上記の既刊に譲り、Grok や ChatGPT タイトルとの重複を避けています。購読の基礎がまだなら購読 URL チュートリアル、クライアント導入は当サイトのダウンロードから揃えてからルール足しが近道です。オープンソースの追跡は各 GitHub でも構いませんが、配布物の取り違えを減らす目的では、初回導入は当サイトのパッケージ付き導線が扱いやすいでしょう。

実際のネットワークでは、一つの行を入れた瞬間に全体のバランスが少し動くことがあります。大きな変更の前にバックアップを取り、一行ずつ戻しながら最終形を作るのが安全です。ここまでの方針で、ブラウザ版の体感が揃い始めたら、余裕を見て Pro 導線だけ別ポリシーに戻し、挙動を比較してみると運用知見が積めます。他の大規模 AI 系記事に比べ、Perplexity では短縮ドメイン行を別ポリシーに切り出す価値が高い場面が多いです。クライアント導入とバイナリの揃い方に迷ったら、まずダウンロードページの手順に従うのが分かりやすいでしょう。→ Clash を無料ダウンロードし、Perplexity の出口とルール命中を同じ手元で確かめる