この記事で分かること
Perplexity Cometを使っていると、ブラウザ自体は起動するのに検索結果の表示が遅い、ページの一部だけ読み込めない、ログインやストリーミング中に接続が切れる、といった問題に遭遇することがあります。こうした症状は Comet の設定だけでなく、DNS、システムプロキシ、利用中のネットワーク、そして接続先ごとの経路が関係している場合があります。
本稿では、Clash Verge Rev と Mihomo 系の設定を例に、Perplexity Comet を試すときの基本的な考え方を整理します。購読プロファイルの読み込み、プロキシモードの選択、Comet 関連通信を意識したルール分流、接続確認、遅延や切断が起きたときの切り分けまでを順番に説明します。特定のサービスを無条件にプロキシへ送るのではなく、必要な通信だけを確認しながら設定することがこの記事の中心です。
なお、Perplexity Comet の提供地域、アカウント条件、利用規約、ネットワーク管理者のポリシーは変わる可能性があります。Clash は通信経路を整理するためのツールであり、サービス側の利用条件を回避するためのものではありません。勤務先や学校のネットワークでは、管理者のルールを優先してください。
Cometで確認したい通信の基本
Comet は一般的なウェブブラウザと同じように、検索ページ、認証、画像、スクリプト、ストリーミング、外部 API など複数の通信を組み合わせて画面を構成します。そのため、トップページだけが開いたからといって、すべての機能が正常とは限りません。検索は成功しても回答生成だけが止まる場合や、テキストは表示されるのに画像や埋め込みページが読み込めない場合があります。
最初に見るべきなのは、問題がすべてのサイトで起きるのか、Perplexity Comet 周辺だけで起きるのかという範囲です。Clash を停止した状態でも一般サイトが開けないなら、Wi-Fi、DNS、OS、ルーター側の問題を先に調べます。一方、通常のウェブサイトは安定しているのに Comet の検索やログインだけが失敗するなら、接続先の経路、プロキシの認証、ルールのマッチ先を確認する価値があります。
ブラウザの設定と Clash の設定が一致しているとも限りません。Comet が OS のシステムプロキシを参照する構成なら、Clash Verge Rev でシステムプロキシを有効にする必要があります。反対に、ブラウザやアプリが独自のプロキシ設定を持っている場合は、OS 側だけを変更しても通信経路は変わりません。
設定前に確認する項目
Clash を使った確認を始める前に、プロファイルと端末の状態を整理します。購読 URL はノードやルールを取得するための重要な情報なので、SNS、公開掲示板、サポートチャットのスクリーンショットなどにそのまま貼り付けないでください。URL に認証情報が含まれている場合、第三者に見られると契約中の通信を利用されるおそれがあります。
| 確認項目 | 見るポイント |
|---|---|
| Clash クライアント | Clash Verge Rev など、現在使っているアプリとバージョンを確認する |
| コア | Mihomo が起動しているか、エラー表示がないかを見る |
| 購読プロファイル | 期限切れ、更新失敗、空のプロキシグループがないか確認する |
| ローカルポート | HTTP、混合、SOCKS のポート番号を記録する |
| 競合アプリ | 別の VPN、プロキシ、TUN アプリを一時的に停止する |
プロファイルを更新した直後に通信が不安定になった場合は、ノードの数だけでなく、ルールや DNS の変更内容も確認してください。新しいプロファイルが読み込まれていても、選択中のグループが自動選択のまま、あるいは応答の遅いノードを保持していることがあります。更新前のプロファイルを残しておけば、ノード側の問題と設定側の問題を比較できます。
Clashの基本設定を行う
まず Clash Verge Rev を起動し、購読プロファイルが一覧に表示されていることを確認します。未登録の場合は、契約しているプロバイダや管理者から発行された Clash 対応 URL を購読管理画面へ追加し、プロファイルを更新します。読み込みが終わったら、プロファイルを有効にして、プロキシグループに利用可能なノードが表示されるかを確認してください。
次に、現在の動作モードを確認します。一般的な切り分けでは、まずRule モードを使います。Rule モードでは、ルールに合う通信をプロキシへ送り、それ以外を DIRECT にする設計ができます。Global モードは通信全体を同じグループへ送りやすく、原因調査には便利ですが、国内サービスや社内システムまで迂回して速度やログイン状態に影響する場合があります。
デスクトップブラウザで試す場合は、Clash のシステムプロキシを有効にし、Comet を完全に終了してから再起動します。ブラウザが起動中に古い接続を保持していると、設定変更後も以前の経路が残っているように見えることがあります。タブを閉じるだけでなく、バックグラウンドプロセスが残っていないかも確認してください。
それでもアプリの一部通信が Clash に現れない場合は、すぐに TUN を有効にするのではなく、まず Comet がどのプロキシ方式に対応しているかを確認します。TUN はプロセスがシステムプロキシを読まない場合にも通信を捕捉しやすい一方、VPN、企業セキュリティソフト、仮想ネットワークアダプターと競合することがあります。必要性が明確なときだけ、権限と DNS の動作を確認しながら使うのが安全です。
Comet向け分流ルールの考え方
Perplexity Comet の通信を調べるときは、サービス名だけを頼りに広いドメインを一括指定するのではなく、Clash の接続ログに実際に表示されたホスト名を基準にします。サービスは更新によって認証、静的ファイル、画像、ストリーミングなどの接続先を変更することがあるため、古い一覧をそのまま信頼すると、必要な通信が漏れたり、関係のない通信までプロキシへ送ったりします。
Clash Verge Rev のログ画面を開いた状態で Comet を再起動し、ログイン、検索、回答の生成、ページ内リンクの表示をそれぞれ試します。各操作の直後に表示される接続先と、選択された策略グループを確認してください。接続先が DIRECT になっていて失敗しているなら、対象ホストを必要に応じてルールへ追加します。反対に、正常な国内サービスまで PROXY になっている場合は、より具体的な DIRECT ルールを上位へ置くことを検討します。
| 確認する通信 | 観察する内容 | 設定の考え方 |
|---|---|---|
| 認証 | ログイン画面、認証リダイレクト、セッション更新 | 認証関連ホストが同じ経路で完了するか確認する |
| 検索と回答 | 検索開始、回答生成、ストリーミング表示 | 途中で接続先やルールが変わっていないか見る |
| 画像と静的ファイル | 画像、CSS、JavaScript、埋め込みコンテンツ | 必要な CDN が DIRECT 漏れしていないか確認する |
| 更新通信 | ブラウザやサービスの更新確認 | 頻繁な更新通信を無条件にプロキシへ送らない |
ルールの順番は重要です。Mihomo のルールは上から評価されるため、広い MATCH や大まかな GEOIP ルールが先にあると、意図したドメインルールへ到達しません。変更後は Comet のキャッシュを利用した結果だけで判断せず、新しい検索や再ログインを行い、ログに表示されたルール名を確認してください。
実際に接続をテストする手順
ここからは、設定を変更したあとに何を確認するかを説明します。目的は「ページが開いた」という印象ではなく、同じ条件で再現できる経路を作ることです。
- Clash を起動する：コアが正常に動作し、プロファイルとプロキシグループが有効になっていることを確認します。
- モードを固定する：最初は Rule モードを選び、自動選択に任せる場合も選択されたノード名を記録します。
- システムプロキシを有効にする：OS のプロキシ設定が Clash のローカルポートを参照しているか確認します。
- Comet を終了する：ウィンドウを閉じるだけでなく、バックグラウンドに残ったプロセスも終了させます。
- ログを開いて再起動する：認証、検索、回答生成を別々に実行し、各通信のルールとグループを記録します。
- 経路を比較する：Clash を停止した状態、Rule モード、必要に応じて TUN の順に比較し、どの段階で改善したかを確認します。
テスト中は、ノードを何度も切り替えないようにします。ノード変更とルール変更を同時に行うと、改善した理由が分からなくなります。まず一つのノードを選び、同じ検索を数回行って、回答生成の開始、ストリーミングの継続、画像表示の三つを観察します。特定のノードだけが不安定なら、設定よりもノードの混雑、上流回線、地域経路の問題である可能性があります。
ブラウザのキャッシュや Cookie も切り分けに影響します。ログインだけ失敗する場合は、いきなり全データを削除せず、まずプライベートウィンドウや別のブラウザプロファイルで同じ操作を試します。これで再現しないなら、拡張機能、古い Cookie、保存された認証状態を順番に確認します。
接続できないときの切り分け
ページが完全に開かない場合は、Clash のコア、ローカルポート、システムプロキシの三点を確認します。コアが停止しているのに OS がプロキシを参照していると、ブラウザ全体が接続できなくなります。Clash を終了したらシステムプロキシも自動で解除されるとは限らないため、停止後に一般サイトが開けるかを確認してください。
検索はできるが回答が途中で止まる場合は、長時間接続、ストリーミング、アイドルタイムアウトを疑います。ログに接続の開始だけがあり、一定時間後に切断されているなら、ノードの安定性やプロキシ側の接続制限を比較します。複数のタブで同時に回答を生成すると症状が強くなる場合は、帯域や同時接続数も確認してください。
ログインを繰り返し求められる場合は、認証用通信が複数の経路に分かれている可能性があります。ログインページはプロキシ経由でも、リダイレクト先やセッション更新だけが DIRECT になると、認証状態が完了しないことがあります。ただし、認証関連のドメインを推測で大量に追加するのではなく、ログに出たホストを一つずつ確認してください。
Comet だけでなく他のサイトも遅くなった場合は、分流が広すぎるか、DNS や TUN が全体へ影響している可能性があります。Rule モードへ戻し、Global モードや TUN を一度停止して比較します。さらに、IPv6 が DIRECT のまま IPv4 だけプロキシされている構成では、アプリごとに挙動が変わることがあります。DNS モードを変更する場合も、変更前の値を記録してから一つずつ試してください。
よくある質問
CometのためにGlobalモードを使うべきですか？
常に Global モードへする必要はありません。Global モードは短時間の比較には便利ですが、すべての通信が同じプロキシグループへ送られるため、国内サイト、社内ツール、決済、動画サービスなどにも影響します。まず Rule モードでログを確認し、必要な通信だけを分流する方が、速度と安全性を管理しやすくなります。
システムプロキシで動かない場合はTUNを有効にしますか？
Comet がシステムプロキシを参照しないことが確認できた場合、TUN は候補になります。ただし、TUN は VPN や企業のセキュリティソフトと競合する場合があります。権限を確認し、DNS とルーティングの状態を記録したうえで短時間だけ試してください。TUN で改善しても、常用する前に不要な通信まで捕捉していないか確認しましょう。
購読プロファイルを更新すれば接続は安定しますか？
更新によって古いノードやルールが修正されることはありますが、必ず安定するとは限りません。更新後は、プロファイルの読み込み、選択中のグループ、ノードの遅延、ルールのマッチ先を確認してください。更新前より悪化した場合に備え、以前のプロファイルや設定をすぐ戻せる状態にしておくと安心です。
職場や学校のネットワークでClashを使ってもよいですか？
ネットワーク管理者の規約と現地の法令を確認してください。組織の端末では、プロキシや TUN の利用が禁止されている場合があります。許可されていないネットワークで設定を変更したり、アクセス制限を回避したりするのではなく、必要なら管理者へ正式な接続方法を問い合わせるべきです。
安定運用のためのチェックポイント
Comet を継続して試す場合は、毎回設定を変えるのではなく、基準となる構成を一つ決めておくと管理しやすくなります。たとえば Rule モード、特定のプロキシグループ、確認済みの DNS モード、システムプロキシの状態をメモし、問題が起きたときだけ一項目ずつ比較します。ノード名やプロファイルの更新日時も記録しておくと、同じ症状が再発したときに判断が早くなります。
また、必要以上に広いルールを追加しないことも大切です。Comet の表示に関係しているように見えても、すべての Google、CDN、広告、分析ドメインを一括でプロキシへ送ると、接続数と遅延が増えることがあります。ログで確認できた接続先、実際に失敗した操作、選択された策略グループを根拠にして、最小限のルールから始めてください。
同類のブラウザ拡張や単純な全体プロキシは、設定が少ない反面、Comet の認証・検索・ストリーミングだけを分けて確認しにくく、全通信を迂回して速度やログイン状態に影響することがあります。比較すると Clash は Rule モード、ログ、複数プロファイル、TUN の段階的な選択を使って、どの通信をどの経路へ送るかを可視化しながら調整できます。Perplexity Comet の接続を自分の環境に合わせて丁寧に検証したい場合は、まず対応する Clash クライアントを入手して、無理のない範囲で基本設定から始めてください。