📖 チュートリアル ⏱ 約17分で読めます

2026：Perplexity を Clash で安定利用するドメイン分流と DNS（実測）

Perplexityは、2026 年もAI 検索として注目度の高いサービスです。ブラウザの検索 UI と、開発者向けの api.perplexity.ai をはじめとする公式 APIは、参照するホスト名が分かれやすく、さらにドキュメントや課金画面で docs.perplexity.ai やアカウント系サブドメインが混ざることがあります。その結果、「トップは開くのに回答ストリームだけ止まる」「ブラウザは快適なのに curl や SDK からの API だけタイムアウト」といった症状は、単一の PROXY 行に頼るより、分流ルールとDNS（fake-ip・DoH を含む）を揃えた方が切り分けが速くなります。本稿は ChatGPT／OpenAI 向け記事、Gemini 向け記事、Grok／X 向け記事とホスト集合を明確に分離し、Clash（多くの場合 Clash Meta／Mihomo コア）で perplexity.ai 系を想定したルール例、名前解決の注意点、Rule モードでのログ実測までを日本語で整理します。サービス側のエッジやエンドポイントは更新で変わり得るため、以下の YAML は出発点の例とし、自分の環境の接続ログを正としてください。

Perplexity が「開かない／不安定」に見えるときの切り口

症状を分類すると切り分けが速くなります。(1) ブラウザの検索画面だけ読み込みが遅い、ログインや課金フローがループする、(2) ターミナルやアプリからの API 呼び出しだけ失敗する、(3) 公式ドキュメントや開発者コンソールだけ別の挙動になる、というパターンです。(1) は perplexity.ai や静的アセット用ホストが意図せず DIRECT になっている、あるいは意図しない地域のプロキシに乗っていることが多く、(2) は API クライアントがシステムプロキシを読まない経路で出ており Clash のルールが効いていない、(3) は docs.perplexity.ai など別サブドメインがルールから漏れている、が典型です。サーバー側だけで API キーを使う構成では端末の Clash は無関係ですが、開発用 PC から直接 API を叩く場合は、同じマシン上の Clash が名前解決と転送経路の両方に影響します。

用語の整理は チュートリアル、ルールの書き方は カスタムルールの解説 と併読するとスムーズです。OpenAI や Anthropic の記事では openai.com や anthropic.com が主役ですが、Perplexity は perplexity.ai と api.perplexity.ai が軸になりやすく、検索結果の引用元として第三者ドメインへの並行接続も増える点が、他稿のリストをそのまま流用できない理由です。

分流の土台：proxy-groups に「Perplexity 用」を用意する

購読テンプレの PROXY をそのまま指すより、PerplexityProxy のような用途名のグループを select または url-test で用意し、rules からは常にそのグループ名を参照するのが運用しやすいです。ノードを差し替えてもルール本文を触らずに済み、Web と API を同じ出口に揃えるか、レイテンシの都合でAPI だけ別グループに分けるかも、名前を分けておけば後から変更できます。ネストや型の詳細は proxy-groups のガイド を参照してください。

💡 ヒント テンプレのグループ名と rules 内の綴りが一致しているかを最初に確認してください。ここがずれると「ルールを足したのに効かない」状態になりがちです。

Web と API：Perplexity でよく現れるホストの考え方

ブラウザの Perplexity UIでは perplexity.ai や www.perplexity.ai が中心になり、静的リソースや計測用に追加のサブドメインやサードパーティ CDN が混ざることがあります。開発者向け APIの代表例は https://api.perplexity.ai（多くのクライアントで /chat/completions などのパス付き）がドキュメントに載ります。エンドポイントのパス構成はアップデートで変わり得るため、クライアントの preset が古いと 404 に見えることがありますが、プロキシ観点ではまずホスト名をログで押さえるのが先です。公式ドキュメント閲覧では docs.perplexity.ai が現れやすく、課金や API キー管理の UI では別サブドメインが挟まる場合があります。いずれもサブドメイン追加や CDN の前段変更で変化し得るため、以下は出発点の例です。実際にマシンが接続しているホスト名をログで確認してから、DOMAIN-SUFFIX を狭めたり広げたりしてください。

方針として、(A) Web・API・ドキュメントを同じ PerplexityProxy に寄せるのがシンプル、(B) 課金画面だけ別経路にしたい場合は該当ホストだけ別グループにする、などに分けられます。(C) DOMAIN-SUFFIX,ai のような広すぎる一括は避け、perplexity.ai に絞るのが無難です。ルールの上から先にマッチした行が優先されることは カスタムルール記事 のとおりです。コミュニティの RULE-SET と併用する場合も、Perplexity 向けの例外を上に積むと意図した出口に寄せやすくなります。

rules:
  # Examples only — tune group name (PerplexityProxy) and domains to your logs
  - DOMAIN-SUFFIX,perplexity.ai,PerplexityProxy
  - DOMAIN-SUFFIX,api.perplexity.ai,PerplexityProxy
  - DOMAIN-SUFFIX,docs.perplexity.ai,PerplexityProxy

ブラウザ拡張や非公式クライアントは別ドメインになることが多く、本稿のリストとは一致しません。その場合は接続ログに出たホストをそのまま DOMAIN や DOMAIN-SUFFIX で追加してください。HTTPS の SNI と実ホストの取り違えで挙動がおかしいときは、Clash Meta の sniffing と DNS の切り分けも併せて確認すると原因が絞りやすいです。

DNS と DoH：ルールより前に潰れる「名前解決」の落とし穴

分流ルールが正しくても、DNS が期待と違う応答を返すと、タイムアウトや証明書エラーに見えます。Clash／Mihomo 系では dns ブロックの fake-ip、redir-host、DoH の有無が挙動に直結します。テンプレの推奨設定から大きく外すと切り分けが難しくなることもあるため、まずは購読既定で再現する→ 問題が続くときに、(1) DoH エンドポイントの信頼性とレイテンシ、(2) nameserver-policy で perplexity.ai や api.perplexity.ai だけ別 DNS に寄せる、(3) IPv6 の有無と OS の解決順、を一度に一項目ずつ変えるのが安全です。

ブラウザ独自の Secure DNS（DoH）と Clash 側の DNS が二重に効いていると挙動が読みにくいので、比較時にはブラウザ側を一時オフにする方法もあります。CLI やコンテナから API を叩く場合、システムプロキシを読まない経路があるとルールが効きません。そのときは TUN モード でトラフィックをコア側に寄せる案や、HTTPS_PROXY 環境変数の明示を検討してください。ルールの優先順位は、より具体的な DOMAIN を汎用の MATCH や広い RULE-SET より上に置く、という原則が API の取りこぼし防止に効きます。

動作モード：Rule・Global・Direct の使い分け

Rule が日常運用の基本です。Global は「すべてをプロキシへ」として、一時的にルール不足かノード品質かを切り分けるのに便利ですが、国内サイトまで遠回りになるため常時利用はおすすめしません。Direct はベースライン計測用に、Clash を事実上オフに近い状態で挙動を見るときに使います。Perplexity だけ不調なときは Rule に戻し、該当ホストが意図したポリシーにマッチしているかをログで確認するのが定石です。トンネル型 VPN との違いは Clash と VPN の比較 も参照してください。

⚠️ 注意 API キーはクライアント側の設定ファイルや環境変数に平文で残りやすいです。リポジトリにコミットしない・共有 PC では権限を絞る、などセキュリティ面はプロキシ設定とは独立して必ず確認してください。

実測手順：ログで「宛先」と「採用ルール」を確認する

  1. 1

    Baseline（Direct または Clash 停止）

    まず Direct でブラウザから Perplexity を開き、同じ端末から curl 等で api.perplexity.ai への疎通を試し、症状が再現するかを記録します。これで「ローカル回線やプロバイダ側」の要因も見えます。

  2. 2

    Rule に戻し、Web と API それぞれでログを読む

    検索操作と API リクエストの両方について、接続一覧／コアログで向いているドメインとマッチしたルール行（またはポリシー名）をメモします。リストにないホストが出たら、それが次に追加すべき行です。

  3. 3

    一行ずつルールを足して再計測

    DOMAIN-SUFFIX を追加し、同じ操作を繰り返します。一度に大量変更すると効いた変更が特定できません。意図と違う行にマッチしているときは、より具体的なルールを上へ移動します。

  4. 4

    DNS ログがあれば併記する

    名前解決結果がおかしい場合はルールより先に DNS を直します。クライアントが DNS ログを出せない場合は、ログレベルを上げる、別ツールで確認するなど環境に合わせてください。

この繰り返しが本稿でいう「実測」です。検索で見つかるドメイン一覧は参考にとどめ、自分のログを正としてメンテすると、UI やエンドポイント変更にも追従しやすくなります。中国本土や企業ネットのように、特定ネットワークで公式ドメインへの到達性が制約される場合でも、出口の品質・DNS・ルールの三つを同時に疑うと早く収束しやすいです。

よくある質問

ブラウザは快適なのに API だけ失敗する

ブラウザはシステムプロキシ経由でルールが効いているが、ターミナルや Docker がプロキシ設定を読んでいないパターンです。環境変数、TUN、または実行ユーザの違いを確認してください。

DOMAIN-SUFFIX,perplexity.ai にしたら他の .ai サービスまで変わった

perplexity.ai はサフィックスとして他社の *.ai にはマッチしませんが、誤ってより短いサフィックスを書いていないか、広い RULE-SET が先に当たっていないかを確認してください。影響範囲が読みにくいときは DOMAIN 行でピンポイントに足す方法もあります。

職場・学校のネットワークでは？

組織ポリシーでプロキシ迂回が禁止されている場合があります。技術的に可能でも、規程と管理者の指示を優先してください。

まとめ

PerplexityのようにAI 検索の Web 体験と公式 APIが分かれているサービスでは、分流ルールをシーン別に整理し、DNS（DoH を含む） と Rule モードでのログ検証をセットにすると、「グローバルプロキシに頼らずに安定アクセスしたい」という目的に沿いやすくなります。本稿のドメイン例は出発点であり、ログに基づきルールを育てることが長く使うコツです。OpenAI 公式は ChatGPT の記事、Google 系は Gemini の記事、xAI とソーシャル一体の流れは Grok／X の記事で別ホスト集合として扱っているため、混同せず参照してください。

クライアントの入手は 本サイトのダウンロードページ を第一にすると、記事との対応も追いやすくなります。ルールの基礎を固めたい場合は カスタムルール完全ガイド も併せてどうぞ。ルールの見える化と切り替えのしやすさは、他の汎用 VPN ツールに比べて Clash の運用体験が一段整理されやすい点にあります。

→ Clash を無料ダウンロードし、Perplexity 向けの分流と DNS を試す