Perplexity が開かない・読み込みが終わらない？Clash 分流とノード固定

1. 利用シーンとよくある症状

ブラウザで Perplexity の会話や検索を開く、社内端末の標準ブラウザから同サービスを使う、バックエンドから API でクエリを投げる——いずれも「複数ホストへ HTTPS を張り直しながら、ストリーミングに近い応答やリダイレクトを処理する」動きです。経路が一定でないと、画面上は真っ白のまま、スピナーが終わらない、一部のスクリプトやフォントだけ取得できない、API だけタイムアウトする、といった形に見えがちです。

企業ネットワークや共有プロファイルでは、「社内ポリシーで直結は許可されていないが、Clash のルール分流で必要なホストだけを整理したい」というニーズも出ます。本稿が扱うのは、利用規約と法律の範囲内で、クライアント側のプロキシ設定と名前解決を整える話に限ります。回避策や規約に抵触し得る操作は取り上げません。クライアントの入手は当サイトのダウンロードページを、挙動の理解はドキュメントと併せて参照してください。

2. ネットワーク側で起きやすいこと

まず「端末・Clash・上流ネットワーク」に原因がないかを切り分けると手戻りが減ります。Perplexity まわりで典型的なのは次のとおりです。

名前解決：DNS やブラウザの DoH がプロキシ外で解決され、ルール評価と実パケットの出口がズレる
ルール漏れ：perplexity.ai は PROXY なのに、共有リンクや計測・静的ファイルの別サフィックスが DIRECT のまま残り、TLS や fetch が途中で失敗する
ノード品質：遅延・パケット損失・ブロックで長めの接続やストリーミング的な応答が切れる
二重プロキシ：ブラウザ拡張や別 VPN と Clash が競合し、Cookie やストレージまわりが不整合になる

これらはアカウント状態や課金とは独立に、「画面が進まない」印象を強めます。経路と DNS を揃えると、不要な再読み込みやセッション断が減る環境もあります（効果は個別環境に依存します）。

ヒント：失敗直後に Clash のログへ出た Server Name（または接続先ホスト）をメモし、ルールに足す優先度を決めます。公開リストより自分の端末の実ログを正にするのが安全で再現性も高いです。

3. Perplexity のドメインとエンドポイント

Perplexity の公式 Web は perplexity.ai およびそのサブドメインが前面に出ることが多く、フロントのビルド資産や計測、共有リンク用に pplx.ai 系が混ざる場合があります。API 利用では api.perplexity.ai など、ホスト名がドキュメントに明示されるエンドポイントへ直接 HTTPS する構成が一般的です。ホスト名はプロダクト更新で変わり得るため、以下は観点の例であり、最終判断は常にログの実名に委ねてください。

Web／アプリ：perplexity.ai および *.perplexity.ai
共有・短縮・周辺：pplx.ai および *.pplx.ai（環境により出現頻度が異なります）
API：api.perplexity.ai（SDK／自前 HTTP クライアント）
静的資産・サードパーティ：CDN や認証連携のホスト（環境ごとにログで確認）

他クラウド経由の API との混同を避ける

同一モデル系列を別のマーケットプレイスやクラウド経由で呼ぶ構成では、接続先が amazonaws.com や googleapis.com 側になることがあります。本稿の perplexity.ai／pplx.ai ベースのルール分流だけではカバーできないため、契約形態とエンドポイントを混同しないことが重要です。Google 向けの整理は Gemini／Google API の記事が補助になります。

ブラウザと API のポリシーを揃える

開発者は API だけ別ノードへ寄せたくなりがちですが、同一アカウントや同じ端末からブラウザと API を行き来する場合、出口が極端に変わるとレート制限やリスク判定まわりで相性が悪いことがあります。まずは perplexity.ai と pplx.ai、api.perplexity.ai を同じポリシーグループに載せ、改善が見えないときだけ慎重に分割するのが無難です。

4. Clash でのルール分流テンプレート

Clash（Mihomo 系）では rules: に DOMAIN-SUFFIX や購読 RULE-SET を並べ、最後に MATCH でフォールバックします。Perplexity をまとめて PROXY へ寄せる最小イメージは次のとおりです（実ホストは必ずログで検証してください）。

# Example only — verify hostnames in your client logs
rules:
  - DOMAIN-SUFFIX,perplexity.ai,PROXY
  - DOMAIN-SUFFIX,pplx.ai,PROXY
  # Add CDN, auth, or telemetry hosts from your logs if they use other suffixes
  - MATCH,DIRECT

公開ルールセットだけに頼ると、新サブドメインの追加タイミングで取りこぼしが出ることがあります。個人用の短い追記ルールで切り分け、安定したら購読側の更新を待つ、という二段構えが運用しやすいです。DOMAIN-KEYWORD は他サービスへ誤爆しやすいので、可能な限り DOMAIN-SUFFIX とログベースの DOMAIN を優先してください。

注意：ルールは上から順に評価されます。広い GEOIP や早すぎる MATCH によって、perplexity.ai 向け接続が意図せず DIRECT に落ちていないかを必ず確認してください。

5. ノード選択と安定性

ノード選択は ping だけで決めない方がよいです。Perplexity の Web は長めの TLS 接続やストリーミング的な応答を伴うことがあり、輻輳した出口や頻繁なフェイルオーバーは「途中で止まる」「再読み込みが増える」体感につながりやすいです。実務的には、同一プロファイル内で手動で別ノードを固定し、ブラウザと API の両方で改善するかを見てから、自動切替を検討するのが安全です。

自動選択グループを使う場合、閾値が甘いと短時間で出口が変わり、逆に厳しすぎると復旧が遅れます。社内回線では「特定地域の出口だけが不安定」というパターンもあるため、時間帯を変えて再現性を見るのも有効です。

症状	ありがちな原因	先に試すこと
UI の枠は出るが中身がずっと読み込み	静的ホストや別サフィックスが `DIRECT`	ログのホスト名を PROXY 側ルールに追加
ログイン直後だけ失敗する	認証・リダイレクト用ホストの経路不一致	失敗時の SNI をルールに反映、DNS を確認
API だけタイムアウト	`api.perplexity.ai` が別ルールに飲まれている	`perplexity.ai` サフィックスの優先順位を確認
数分ごとに途切れる	ノード不安定、IPv6 の別経路、中間装置のタイムアウト	出口固定、IPv4 優先、別ノードでの A/B

6. DNS・DoH・Fake-IP・IPv6

DNS がプロキシ外で解決されると、画面上のルールは PROXY でも実際のパケットは別経路へ出ることがあります。ブラウザが DoH（DNS over HTTPS）を有効にしている場合、解決が Clash の dns セクションと別レーンを走り、Fake-IP 構成では特に「ログでは正しそうなのにブラウザだけおかしい」状態が起きがちです。Perplexity のような複数ホストへ細かく伸びる UI では、そのズレが白画面や無限スピナーとして現れやすい点に注意してください。

切り分けの観点としては、(1) OS／ブラウザの DoH を一時オフにして挙動が変わるか、(2) Clash の DNS モード（redir-host／fake-ip など）とクライアントの説明どおりに整合しているか、(3) 企業ポータルやフィルタが特定ドメインの解決だけ書き換えていないか、を順に見ます。大方のケースでは、漏れのない DNS とルールと矛盾しない名前解決が揃えば改善します。

IPv6 が意図せず別経路に抜けている場合は、一時的に IPv4 を優先する・IPv6 をオフにする、といった切り分けも有効です。Windows で TUN を有効にしている場合は、仮想アダプタとルート、ファイアウォールが前面に出ます。TUN とファイアウォールの切り分けと併読すると、ブラウザ以外のプロセスまでトンネルに載せたときの挙動も整理しやすくなります。

7. API 利用者向けの注意

サーバーや CI、ローカルの CLI から Perplexity API を呼ぶ場合、ブラウザのシステムプロキシ設定が自動では乗らないことがあります。実行環境に HTTPS_PROXY などを明示する、Clash のローカルポートへ向ける、コンテナならネームスペースごとにプロキシを揃える、といった実行コンテキスト単位の確認が必要です。ターミナル全般の整理は npm／Git と環境変数の記事とも補完的です。

また、API キーや組織ポリシーはクラウド側の制限とセットで効きます。ネットワークを整えても 401／403／429 が続くときは、キーのスコープ・IP 許可・利用枠の方を疑う段階です。ここでもルール分流は「到達性」を整える役割に留まり、契約や権限の問題を解決するものではありません。

出口の急変を避ける：短時間に ノードを何度も切り替えない（再試行ロジックと相性が悪い場合がある）
二重プロキシを解消する：企業スキャン用プロキシと Clash が二重になっていないか
時刻の正確さ：OS 時刻のずれは TLS や署名検証に影響する
ログの保存：インシデント調査用にホスト名とポリシー名を短時間だけ残す（運用ポリシーに従う）

これらは規約やセキュリティ制御を迂回するための手順ではなく、正当な利用の範囲で接続を安定させるための一般的な整理です。

8. 他の生成 AI 記事との違い

当サイトでは、ChatGPT／OpenAI（別記事）、Google Gemini（別記事）、Claude／Anthropic（別記事）、Grok／xAI（別記事）向けの分流も公開しています。いずれもドメイン集合が異なり、ルールをコピーして置き換えるだけでは取りこぼしや誤爆が増えます。本稿は Perplexity（perplexity.ai／pplx.ai）の経路整理が主題です。

開発者向けには Cursor／GitHub のタイムアウト対策（別記事）もありますが、IDE と AI 検索公式ドメインは別物です。ログに出た実名でルールを育てる習慣が、複数ベンダーを横断して使う 2026 年の運用では特に効きます。

9. セルフチェック

短いチェックリストです。上から順に試すと無駄が少ないです。

クライアントの更新：ダウンロードページから入手できる最新系へ。
システムプロキシと TUN：ブラウザと API 実行環境のどちらにトラフィックが載るかを統一。
ルールのヒット：ログで perplexity.ai／pplx.ai／api.perplexity.ai が期待のポリシーに乗っているか。
ノード：別ノードへ切り替えて再現性を確認。
DNS／DoH：Fake-IP／redir-host とブラウザ設定の整合。
競合ソフト：他 VPN／フィルタが TLS を壊していないか。

これでも改善しない場合は、プロバイダ側の障害、地域的な制限、サービス側のメンテナンス、あるいはアカウント側の制限の可能性が高まります。公開ステータスやコミュニティの報告と突き合わせ、時間を置いて再試行するのも現実的です。

10. まとめ

Perplexity（perplexity.ai）は単一ホストへの接続では済まない構成になりがちです。ルール分流で perplexity.ai と pplx.ai を軸にサブドメインを拾い、api.perplexity.ai を含めてログで見つかった静的・計測・認証補助ホストを足し、ノード選択と DNS／DoH をセットで見直すと、読み込みの停滞や API のタイムアウトは減らせることが多いです。別クラウド経由の API とはホストが異なるため、記事やルールセットを混同しないことが重要です。

同種のクライアントと比べて、Clash 系は接続ログとルールの対応が追いやすく、試行錯誤のコストを下げやすい面があります。分流を少し整えるだけで、AI 検索の会話や API 呼び出しが途切れにくくなることも珍しくありません。

→ Clash を無料ダウンロードして、Perplexity 向けの接続を試す