Perplexityに接続できない？Clashのタイムアウト対策と設定方法

Perplexity が Clash でタイムアウトする理由

Perplexity がブラウザで開けない、検索結果の表示途中で止まる、回答生成だけが長時間待機する、といった症状は、単純な「ノードが遅い」問題とは限りません。Clash を使っている場合、通信は大きく分けて名前解決、TLS 接続、ルールによる出口選択、ストリーミング応答の順に進みます。どこか一つが別の経路へ落ちると、トップページは表示できても検索 API や回答生成だけがタイムアウトすることがあります。

まず確認したいのは、Perplexity の画面そのものではなく、Clash の接続ログです。Perplexity のウェブ画面を開くと、メインドメイン以外に API 用ホスト、認証関連ホスト、静的ファイル用 CDN、分析や決済に関係するホストが現れる場合があります。すべてが同じドメイン名になるとは限らないため、perplexity.ai だけをルールへ追加して終わりにすると、回答リクエストだけが MATCH や DIRECT に流れることがあります。

また、ブラウザがシステムプロキシを使用していても、Clash のコアが停止していたり、別の VPN が仮想アダプターを優先していたりすると、実際の出口は想定と異なります。Clash Verge、Clash Verge Rev、Mihomo Party、Clash for Android などは画面の名称こそ違いますが、確認すべき要素は共通しています。すなわち、現在有効なプロファイル、稼働中のコア、プロキシモード、DNS モード、そして対象ホストに適用されたポリシーです。

最初に確認する基本設定とノードの状態

最初から TUN モードや複雑なルールセットを変更する必要はありません。まず Clash のホーム画面でコアがRunningまたは同等の稼働状態になっているかを確認し、プロキシグループに利用可能なノードが表示されていることを見ます。ノード名に緑色の表示があっても、それは単純な速度測定が成功しただけで、Perplexity のログインや長いストリーミング通信まで安定することを保証しません。

次に、プロキシグループの現在の選択を確認します。select グループなら手動選択したノードが本当に反映されているか、url-test なら測定先が実際の用途に近いかを見ます。測定 URL への応答が速くても、Perplexity への TLS 接続や長時間の HTTPS 応答が不安定なノードは存在します。そのため、速度の数字だけでなく、数回の検索と回答生成を行ったときの再現性を重視してください。

OS のプロキシ設定も重要です。Clash の mixed-port がたとえば 7890 なら、システムプロキシの HTTP と HTTPS に同じポートを設定し、SOCKS 専用ポートを誤って入力していないか確認します。GUI に「システムプロキシを設定」という項目がある場合は、いったんオフにしてからオンへ戻し、ブラウザを完全に再起動します。ブラウザが古い接続や PAC の結果を保持していると、設定を直しても直結経路が残っているように見えるためです。

ただし、ブラウザのプロキシ設定と Clash の設定を同時に複数箇所で変更するのは避けます。手動プロキシ、拡張機能、企業 PAC、別 VPN を重ねると、どの層が接続を変更したのか分からなくなります。検証時は別のブラウザプロファイル、またはプライベートウィンドウを使い、拡張機能を一時的に無効化すると比較しやすくなります。

実際に行う切り分け：ルール、DNS、接続ログ

ここでは設定を一度に大量変更せず、差分を小さく取ります。まずアクティブなプロファイルをバックアップし、Clash のルール画面または YAML エディターで、Perplexity 関連のルールがどこにあるかを確認します。すでに購読側で専用ルールが配られている場合は、その上に同じ内容を重複追加しないでください。重複ルールは見た目には安心でも、実際には上側の広いルールが先に一致していることがあります。

1. ノードを固定する：自動選択を一時的に外し、比較的安定している一つのノードを選択します。これで成功するなら、ルールよりも自動選択やノード品質の問題である可能性が高くなります。
2. 対象ホストを観測する：Perplexity のページを再読み込みし、接続ログで関連ホスト、使用ポリシー、接続時間、エラー表示を確認します。画面に出たホストだけを根拠にし、想像で大量のドメインを追加しないことが重要です。
3. 専用ルールを上位へ置く：購読の広告ブロック、GEOIP、地域別ルール、一般的な CDN ルールより前に、観測した Perplexity のドメインルールを配置します。
4. 一項目ずつ反映する：設定を保存してコアを再読み込みし、同じ検索文で再現テストを行います。複数のルールと DNS モードを同時に変えると、改善した理由が分からなくなります。

Illustrative rules fragment — replace the policy name and hosts with your observed configuration

rules:
  - DOMAIN-SUFFIX,perplexity.ai,AI_STABLE
  - DOMAIN-SUFFIX,perplexity.com,AI_STABLE
  - MATCH,YOUR_FALLBACK_POLICY

上の断片は考え方を示す例であり、すべての環境へそのまま貼り付けるものではありません。実際の接続ログに別の API ホストや認証ホストが出る場合は、必要な範囲だけ DOMAIN または DOMAIN-SUFFIX で追加します。広すぎる DOMAIN-SUFFIX を使うと、Perplexity と無関係なサービスまで同じ出口へ送られ、原因を増やすことがあります。

DNS も確認します。DNS が直結、HTTPS、Fake-IP、リモート DNS の混在状態になっていると、ブラウザが取得したアドレスと Clash が期待するルール評価の対象がずれることがあります。特に Fake-IP を使用している場合は、対象ドメインを fake-ip-filter へ追加する必要がある環境もあります。逆に、普段のプロファイルが Redir-Host 前提なのに Fake-IP を部分的に有効化すると、名前解決だけ成功して HTTPS 接続が不安定になることがあります。

DNS の変更後は、ブラウザの DNS キャッシュと既存の接続を整理してから再試行します。ブラウザを閉じるだけでなく、Clash の接続を切断して再接続し、必要ならコアを再起動します。Windows では OS の DNS キャッシュ、macOS ではネットワークサービスの状態、Android ではプライベート DNS や別 VPN の設定も影響します。ここで重要なのは、DNS を速くすることではなく、同じホストが一貫した経路へ解決されることです。

TUN モードを使う場合の確認と再発防止

システムプロキシだけで一部の通信が漏れる場合は、TUN モードが有効な選択肢になります。TUN はアプリケーションがプロキシ環境変数を継承していなくても、より下位のネットワーク層で通信を捕捉できるため、ブラウザ以外のアプリや WebView、バックグラウンド通信にも対応しやすい方式です。ただし、TUN をオンにすれば必ず安定するわけではありません。仮想アダプターの権限、システムルート、DNS hijack、別 VPN との競合が新たな原因になります。

TUN を有効にする前に、Clash の管理者権限やシステム拡張の許可が完了しているかを確認します。Windows では Wintun などの仮想アダプター、macOS ではネットワーク拡張、Android では VPN 接続の許可が関係します。初回テストでは「自動ルート」「DNS hijack」「スタック方式」などを一度にすべて変えず、既定値から一項目ずつ確認してください。TUN を有効にした直後にインターネット全体が切れた場合は、Perplexity のルール以前に仮想インターフェースや DNS の設定を戻すべきです。

TUN とシステムプロキシを同時に使う構成では、二重処理にも注意します。ブラウザはシステムプロキシへ接続し、別アプリは TUN へ流すという設計なら意図的な併用ですが、両方が同じ通信を再度捕捉すると遅延やループが発生することがあります。まず TUN のみ、次にシステムプロキシのみという二つのテストを行い、どちらの構成で Perplexity の回答生成が安定するかを比較してください。

再発防止には、設定を変更した日時、使用したノード、DNS モード、該当ルール、接続ログのエラーを簡単に残す方法が有効です。「接続できない」と感じたときも、ページ自体が開かないのか、ログインだけ失敗するのか、検索はできるが回答生成が止まるのかで確認箇所は変わります。ノード変更で直った場合も、元のノードが悪いと断定せず、同じホストが別ポリシーへ落ちていなかったかを比較します。

Perplexity だけを対象に考えると、古い GUI クライアントは TUN、DNS、ルールの状態が別画面に分散していて確認に時間がかかり、単純なプロキシアプリは長いストリーミング応答やアプリ単位の経路制御が弱いことがあります。Clash V.CORE なら、安定ノードの固定、ドメイン単位の分流、DNS と TUN の切り替え、接続ログによる検証を一つの運用フローへまとめやすく、Perplexity のタイムアウト原因を再現条件とともに追跡できます。今回の手順を自分の環境へ適用するために、まずは ダウンロードページへ進むのがよいでしょう。