Perplexity が「ずっと読み込み」に見える層

対話型の AI 検索では、チャット画面の HTML だけでなくストリーミング応答・埋め込みウィジェット・計測・認証が別ホストに分かれます。Perplexity に限らず、引用を重視する製品ではDOI 解決・出版社ドメイン・プレプリント・学術データベースへのリクエストが続きます。ここで本体だけプロキシ、引用先は意図せず DIRECTのような状態になると、ブラウザは一部のリソースだけ長時間待ち、結果としてタイムアウトや無限スピナーに見えます。原因が「サーバが遅い」単体ではなく、経路の半端さであることが多いです。

Clash は接続ごとに ポリシーグループ（どの出口へ送るか）を決めます。同じタブ内の数十リクエストで出口が混在すると、TLS 完了タイミングがバラバラになり、体感では「Perplexity だけ不安定」に見えます。DNS の答えと実際に選ばれた経路が食い違う（fake-ip とルールの不一致など）場合も同様です。本稿は迂回の一般論ではなく、ドメイン単位のルールとルールセットで名前空間を揃える話に限定します。利用が禁止されている環境では読むのをここで止めてください。

ℹ 切り分けのコツ：開発者ツールのネットワークで失敗または pending のホスト名をメモし、Clash のログでそのホストがどのポリシーに命中したか照合します。「Perplexity が遅い」より「どのサフィックスが DIRECT のまま残ったか」が実務的です。

ChatGPT 記事との違い：学術ドメインが増える

すでに公開している ChatGPT／OpenAI 向け分流では、openai.com や chatgpt.com などベンダー集中型の名前空間が中心でした。一方、Perplexity のような製品ではユーザーが触れる引用リンクの先が arXiv、出版社、Crossref、PubMed、Semantic Scholar など横に広い学術ドメインになります。OpenAI 用ルールだけ整備しても、引用プレビュー用のホストがルールに乗らなければ、画面は再び「壊れたように」見えます。

対策の考え方は二つあります。一つは学術・研究向けをまとめたポリシーグループ（例：RESEARCH_PROXY）を置き、AI 検索本体と同じ出口に載せること。もう一つは geosite 系のルールセットで「学術」「CDN」「論文」を広くカバーしつつ、誤爆しやすい DOMAIN-KEYWORD に頼りすぎないことです。どちらも「コピーしたら終わり」ではなく、実際のネットワーク一覧でホスト名を確認しながら足し算していく作業になります。

ポリシーグループ：AI 検索と学術をどう分けるか

運用しやすい分け方は、日常トラフィックは DIRECT、AI 検索と学術引用を同一の論理出口にまとめることです。ノードの品質が許せば本体と学術を別グループに分けてもよいですが、分けすぎるとルール順の調整コストが上がります。まずは「AI_SEARCH と学術を同じグループ」で様子を見、遅延や帯域の理由で分割する、という順が現実的です。

ポリシーグループ名は購読やクライアントの UI にそのまま出るので、意味が分かる短い名前にします。PROXY 一つにすべて載せるより、後からルールを読む自分のためのラベルとして AI_RESEARCH のような名前を付けておくと、数ヶ月後の自分が助かります。分流の書き方の型は ルール分流のベストプラクティス に沿ってください。

DOMAIN-SUFFIX とルールセットの例

DOMAIN-SUFFIX は接尾辞一致でホスト名をポリシーへ送ります。Perplexity 周辺では、サービスが使う公式ドメイン（例：perplexity.ai、環境によっては pplx.ai など）を観測ベースで列挙し、まずそこを AI_RESEARCH のようなグループへ載せます。学術側は、よく出る arxiv.org、doi.org、crossref.org、利用領域に応じて semanticscholar.org、出版社ドメインなどを段階的に追加します。実際に表示された引用元に合わせて増やすのが確実です。

ルールプロバイダ（リモートのルールセット）を併用する場合、リストが巨大だと順序と誤分類に注意が必要です。国内向けの直結ルールを先に置き、AI／学術向けの具体行が広い捕捉ルールに飲まれないようにします。下の YAML はあくまでイメージであり、実在のサービス構成に合わせて接尾辞を差し替えてください。

Illustrative YAML fragment

rules:
  - DOMAIN-SUFFIX,perplexity.ai,AI_RESEARCH
  - DOMAIN-SUFFIX,pplx.ai,AI_RESEARCH
  - DOMAIN-SUFFIX,arxiv.org,AI_RESEARCH
  - DOMAIN-SUFFIX,doi.org,AI_RESEARCH
  - DOMAIN-SUFFIX,crossref.org,AI_RESEARCH
  - DOMAIN-SUFFIX,semanticscholar.org,AI_RESEARCH
  - GEOIP,JP,DIRECT
  - MATCH,DIRECT

GEOIP の国コードや MATCH の既定は環境に合わせてください。学術サイトのうち国内ミラーが速いものは DIRECT のままにしたい、という場合は、より具体的な DOMAIN-SUFFIX を上に積むか、例外行を足します。ルールは上からマッチするため、広すぎる行を先頭に置くと細かい調整が効きません。

DNS・fake-ip とルールの食い違い

fake-ip モードでは、ローカルが合成アドレスを返し、実際の名前解決はプロキシ側で行われます。このときドメインルールが追従していないと、見かけ上は解決できても出口と期待がズレ、「一瞬で終わったのに繋がらない」症状になります。ブラウザの Secure DNS、OS のリゾルバ、Clash の DNS を同時に弄ると優先順位が複雑になるので、検証中はレイヤを減らすのが近道です。詳しい整理は FAQ の接続まわり を参照してください。

学術ドメインは CDN やリダイレクトが多く、一度のクリックで複数ホストに触れます。DNS だけ正常でも、途中のホストが DIRECT のまま狭い経路に残ればタイムアウトします。ここでも失敗したホスト名とポリシー命中の突き合わせが有効です。

検証：開発者ツールと Clash ログ

手順はシンプルです。Perplexity を開き、開発者ツールでネットワークを表示したままクエリを送り、失敗・長時間 pending のホストを控えます。次に Clash 側でそのホストがどのルールに当たったかを確認し、足りない DOMAIN-SUFFIX を追加します。TLS エラーと TCP タイムアウトは別物なので、ログの読み分けは timeout と TLS の記事 が役立ちます。

ブラウザがシステムプロキシを無視する構成では、Clash の TUN を検討します。干渉や権限の話は TUN の詳解 を読んでからにしてください。クライアント選びは クライアントの選び方 も参考になります。

購読・ルール更新のループ回避

リモートのルールセットと購読 URL の取得が、意図せずプロキシ経由だけに偏ると更新が止まり、新しいエンドポイントに追従できません。更新用 URL には DIRECT か信頼できる低リスク経路を割り当て、更新成功をログで確認する習慣があると安定します。運用の型は 購読とノード保守 にまとまっています。

⚠ コンプライアンス：利用するネットワーク・地域の法令と、雇用主や学校のポリシー、各サービスの利用規約を遵守してください。本稿は許可された環境での経路設計の話であり、禁止された回避やセキュリティ対策の無効化を助長するものではありません。

コンプライアンスと自己チェック

次の順で確認すると、設定トグルを増やす前に原因を絞れます。

  1. この環境で対象サービスとプロキシ利用が許可されているか。
  2. 開発者ツールで失敗・pending のホスト名を列挙したか。
  3. Perplexity 本体と引用先の DOMAIN-SUFFIX がポリシーに載っているか。
  4. ルール順で具体行が広い捕捉に負けていないか。
  5. DNS モード・fake-ip とルールが整合しているか。
  6. 購読とルールセットの更新がループせず成功しているか。
  7. それでも失敗する場合、ノード品質とベンダー障害を切り分けたか。

まとめ

Perplexity のような対話型 AI 検索は、チャット UI だけでなく学術引用のための多数のドメインを伴います。Clash の分流では、これらをバラバラの経路にしないことが、タイムアウトや半端表示を減らす近道です。ポリシーグループと DOMAIN-SUFFIX、必要ならルールセットを組み合わせ、DNS とルールの食い違いを潰す——この三つを揃えると、設定は増えても挙動は予測しやすくなります。

ホットな話題に乗せても、中身は「コピペ可能なルール」と「検証手順」に落ちるかどうかが価値を決めます。本稿の YAML はイメージなので、実際に観測したホスト名へ書き換えてください。

→ 無料で Clash をダウンロードし、引用元のドメインを当てずっぽうで足すのではなく、ログとルールで再現可能な経路にそろえてください。