1. 「くるくる」が示すもの：単一路径では説明しにくい症状
ブラウザのタブで Perplexity を開いたとき、画面が真っ白のまま、あるいは骨格だけ表示されて本文が永遠に流れ込まない。こうした症状は、ユーザーから見ると単なる「重い」に見えますが、裏側では複数ホストへの並列リクエストのどれかがタイムアウトや TLS 失敗で詰まっていることが多いです。Clash の接続一覧やログに出るホスト名と実際に選ばれたポリシーを並べると、想像以上に早く切り分けが進みます。
設定の全体像をまだ把握していない場合は、先にサブスクリプション取り込みの記事で YAML の骨格とルールモードを押さえておくと、以降の手順が読みやすくなります。
2. Perplexity 周辺の通信を「層」に分ける
実際のホスト名はプロダクト更新で変わり得るため、開発者ツールのネットワーク欄と Clash のログに出た名前を正とします。設計メモとして、次のような役割分けを頭に置いておくとルールが書きやすくなります。
| 層 | イメージ | 切り分けのポイント |
|---|---|---|
| メイン UI | perplexity.ai ドメイン群 | ページの骨格は出るが中身が止まるなら API／CDN を疑う。 |
| API／ストリーム | 別サブドメインや pplx 系 | 検索ボタン後だけ固まるパターンと相性がよい。 |
| CDN・静的ファイル | クラウド CDN のサブドメイン | 広すぎるサフィックスルールは他サイトへ副作用。ログで絞る。 |
| 認証・決済周辺 | サードパーティの ID／課金 | ログインだけ失敗するなら本体とは別ルールが必要なことも。 |
ここで重要なのは、「トップが開けば全部通っている」ではないという点です。フロントエンドは初期 HTML のあと、別ホストからスクリプトやデータを引きに行くため、一枚岩のドメイン想定でルールを書くとすぐ破綻します。
3. ドメイン収集：ブラウザと Clash の両方で拾う
収集の基本は次の二系統です。どちらか片方だけでは取りこぼしが出やすいので、併用してください。
- ブラウザの開発者ツール（ネットワーク）を開き、Perplexity をハードリロード。フィルタを外し、ドメイン列を眺めて
perplexity、pplx、明らかに CDN らしいホストをメモする。 - Clash（Mihomo 対応 GUI なら接続ビュー）で、同じ操作のあとに現れた接続行を時系列で並べ、
DIRECTや想定外のポリシーに落ちている名前をマークする。 - ストリーミング応答中だけ増えるホストがあるため、実際に検索を一度走らせたあとにもう一度ログを眺める。
- 重複やワイルドカード化できそうなサフィックスを整理し、購読ルールより手前に置くべき具体ルールとして YAML に落とす。
ポートやプロセス周りの一般的な詰まりはトラブルシュート記事へ。本稿は AI 検索サービス特有のマルチドメイン構成に焦点を当てます。
4. 推奨する切り分け順序
- Clash が起動していること、システムプロキシかTUNのどちらでブラウザトラフィックを握っているかを確認する。
- 接続ログで Perplexity 関連ホストが、意図したポリシーグループに入っているか、誤った
DIRECTがないかを見る。 fake-ipを含む DNS 設定を確認し、必要なら特定サフィックスへnameserver-policy等を当てて名前解決のブレを減らす。- メイン UI・API・CDN をホスト／サフィックス単位でルール化し、購読ルール内の広い
DIRECTより上側に矛盾なく配置する。 - ルールが意図どおりになったあとで、遅延の揺れが少ないノードを選び、過剰な自動切替を避ける。
5. システムプロキシと TUN：ブラウザでも取りこぼしがある
OS のシステムプロキシに Clash の mixed ポートを指定する方法は手軽ですが、プロキシ設定を読まないコンポーネントや、拡張機能・別プロファイルのブラウザが混ざると、見かけ上「同じ Chrome なのに別経路」が起きます。TUN はルーティング層でトラフィックを取り込むため一貫性は上がりますが、他 VPN との競合や権限まわりのトレードオフがあります。有効化するならTUN モードの解説を参照し、有効化後に再接続ログで Perplexity 関連ホストがすべて期待どおりの経路になったか検証してください。
6. DNS／fake-ip：名前解決とルール判定のズレ
fake-ip は体感速度を上げる一方、設定次第では「ルールに渡る前の名前」と「実接続の宛先」の整合が崩れやすくなります。Perplexity のようにサブドメインと CDN が多いサービスでは、軽いズレでもフロントがリトライを繰り返し、ユーザーにはただのローディングに見えます。対策の基本は、上流 DNS を信頼できるものにそろえ、収集した主要サフィックスへ専用の名前解決ポリシーを当てることです。フィールド名はコアのバージョンで差があるため、利用中の Mihomo／Clash Meta のドキュメントと照合してください。
7. 分流ルールの考え方（記述例は置き換え前提）
購読ルールに「広い DIRECT」が先に入っていると、意図せず国内直結へ落ちるホストが紛れ込みます。より具体的な DOMAIN／DOMAIN-SUFFIX を、矛盾なく上側に置くのが実務的です。以下は例示であり、実際のホスト名は必ずログで確認して置き換えてください。CDN については cloudfront.net など極めて広いサフィックスを安易に丸ごとプロキシに載せると、他サービスへ副作用が出ます。ログに出た特定サブドメインに絞るか、別手段（ルールセットの細分化など）を検討してください。
# Example only — verify hostnames in your Clash logs before use
rules:
- DOMAIN-SUFFIX,perplexity.ai,PROXY
- DOMAIN-SUFFIX,pplx.ai,PROXY推論用 API だけ別グループ（例：PROXY_AI）に分け、静的取得用（PROXY_CDN）と切り離すと、障害時の切り分けが容易になります。グループ名は proxy-groups に定義済みである必要があります。
8. 他の AI 向け記事との違い
ブラウザ上の ChatGPT や OpenAI API を安定化する話は、OpenAI 向け分流記事が軸になります。DeepSeek、GitHub Copilot、Cursor、Claude（Anthropic）も、それぞれ別記事でホスト構成を整理済みです。本稿はそこからスコープを移し、Perplexity の Web 検索型 UI とその背後のマルチドメインに絞ります。複数の生成 AI を併用する環境では、プロダクトごとにポリシーグループを分けておくと、片方の障害が他方のルール調整を汚染しにくくなります。
9. ノード選定：瞬間最速より「揺れの少なさ」
スピードテストで一位でも、短時間で往復遅延が跳ねるノードは、ストリーミング応答型の検索 UI には不向きです。TLS の再ハンドシェイクが増え、ブラウザ側はリトライやタイムアウトとして現れます。手動選択で様子を見たり、AI 検索専用グループを作って安定路線に固定するのが実用的です。プロトコル特性の比較はプロトコル比較記事も参考になります。
10. 追加の落とし穴：拡張機能・企業プロキシ・複数 VPN
ブラウザ拡張が独自プロキシを指定していると、OS 設定と二重化し結果が読みにくくなります。検証時は一旦無効化してください。また企業ネットワークの PAC／SSL 検査と Clash が衝突すると、特定ドメインだけ証明書エラーになることもあります。別製品の VPN と TUN を同時に有効にしている場合も、ルートの奪い合いで「ときどきだけ直結」が紛れ込みます。単一路径に戻してからログで確認するのが早道です。
11. まとめ：証拠ベースでドメインを束ねる
Perplexity の検索画面が読み込みのまま進まない症状は、単一設定ミスよりもモード・DNS・ルール順・ノードの揺れの積み重ねで起きがちです。本稿の順序どおりにログで確認していけば、「とりあえず別ノード」より再現性の高い改善が期待できます。2026 年も AI 検索の利用は広がる一方で、ホスト構成の変化は速いので、購読ルールに頼り切らず、自分の環境で一度ホスト表を更新する習慣を持つと安心です。
接続ログと購読更新を GUI でまとめられるクライアントを使うと、YAML を毎回手で触る負担も下がります。同種ツールのなかでも、ルールとコアの整合が取りやすい製品ほど長く運用しやすい印象です。安定した AI 検索環境を整えたい方は、→ Clash を無料ダウンロードして、快適な接続体験を始める