再現できるテスト条件を整える

まず自動でのノード切り替えを止め、ノード、テストするURL、通信の取り込み方式をそれぞれ1つに固定します。クライアントの「接続済み」は、通常、コアが起動しているか、システムプロキシや仮想ネットワークアダプターが有効になっていることを示すだけです。ブラウザーの通信がコアに届いていることや、接続先ノードが対象サイトとのTLSハンドシェイクを完了できることまでは保証しません。

  1. 現在の設定名、プロキシモード、プロキシグループの選択状態、システムプロキシとTUNのオン・オフを記録します。サブスクリプションURL全体は公開しないでください。
  2. 現在の設定を保存します。その後は一度に1項目だけ変更し、テストしてから変更を維持するか元に戻すか判断します。
  3. ほかのプロキシクライアントやVPNを終了します。会社の端末でセキュリティソフトやネットワークポリシーが関係する場合は管理者に確認し、保護機能を安易に無効化しないでください。
  4. クライアントの接続一覧とログを開き、まずはinfoレベルで確認します。一時的にdebugへ上げる場合、ログにアクセス先のドメインやローカルネットワーク情報が含まれることがあるため注意してください。
  5. ブラウザーを完全に終了してから再起動し、古い接続の再利用を防ぎます。比較テストではすべて同じURLにアクセスしてください。

1. システムプロキシの接続先ポートを確認

まず「システムプロキシをオン、TUNをオフ」にして、ブラウザーのテスト環境を整えます。システムプロキシの影響を受けるのは、OSのプロキシ設定に従うアプリが中心で、すべてのプロセスが対象になるわけではありません。ゲーム、コマンドラインツール、ブラウザー拡張機能、独自のプロキシ設定を持つソフトは別の経路を使うことがあります。

システム設定とブラウザー拡張機能を確認する

  • Windows 11：「設定」→「ネットワークとインターネット」→「プロキシ」→「手動プロキシ セットアップ」を開き、アドレスとポートを確認します。自動構成スクリプトと手動プロキシが同時に設定されている場合もあるため、実際に適用されている設定を確認してください。
  • macOS：「システム設定」→「ネットワーク」→現在のネットワーク接続→「詳細」→「プロキシ」を開き、WebプロキシとセキュアWebプロキシがクライアントの実際の待ち受けアドレスを指しているか確認します。
  • ブラウザー：プロキシを制御する拡張機能を一時的に無効にし、独自のプロキシ設定や除外リストがないか確認します。シークレットウィンドウでも、すべての拡張機能が無効になるとは限りません。

ローカルでよく使われるアドレスは127.0.0.1です。ポートは現在有効な設定に従ってください。7890がすべてのクライアントで共通とは限りません。以下は各項目の用途を示すYAMLの抜粋で、完全な設定ファイルではありません。既存のサブスクリプション設定をそのまま置き換える必要もありません。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

mixed-portはHTTPとSOCKSの両方のプロキシ接続を受け付けます。socks-portのみのポートをHTTPプロキシとして設定することはできません。external-controllerでよく使われる9090は管理用APIのポートで、Web通信の入口ではありません。ローカルのブラウザーを調べるだけなら、「LAN内接続を許可」を有効にする必要もありません。

システム設定を介さず、ローカルプロキシを直接テストする

次のWindowsコマンドはHTTPプロキシを明示して実行するため、「システム設定の問題」と「プロキシ経路の問題」を切り分けられます。実際のポートが7890でない場合は、コマンド内のポートを変更してください。macOSとLinuxではcurlを使い、NULを/dev/nullに置き換えます。

curl.exe --noproxy "" --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -o NUL -sS -w "HTTP=%{http_code}\n" https://example.com/
  • プロキシを明示すれば成功し、ブラウザーでは失敗する：ノードの設定を続けるのではなく、システムプロキシ、ブラウザー拡張機能、プロキシの除外設定を確認します。
  • ローカルポートに接続できないとすぐに表示される：まずコアが起動しているか、ポート番号が正しいか、待ち受けプロセスが現在のクライアントのものか確認します。
  • 接続確立後にタイムアウトする：ログでノードへの接続、DNS、対象サイトへのアクセスのどの段階で止まるか確認します。タイムアウトだけを根拠にポートの問題と決めつけないでください。

HTTPステータスコードが返るなら、少なくともHTTP応答は受信できています。ただし403や451は、サイト側のポリシーによる制限の可能性があります。想定したプロキシ経由か確認するには、接続記録の出口経路も確認してください。

2. ポートの競合とコアの起動状態を確認

システムプロキシが設定されていても、設定エラーでコアが起動していなければ、ブラウザーのリクエストは待ち受けていないポートに送られます。ポートを変更する前に、ログで起動エラーを確認してください。たとえば、待ち受けの失敗、設定の解析エラー、参照先のないプロキシグループなどが考えられます。

Windowsで待ち受けプロセスを確認する

PowerShellで次のコマンドを実行します。1つ目で待ち受け状態とプロセスIDを確認し、2つ目で結果に表示されたOwningProcessを使ってプロセスを調べます。例の1234は実際の値に置き換えてください。

Get-NetTCPConnection -LocalPort 7890 -State Listen
Get-Process -Id 1234

macOSではlsof -nP -iTCP:7890 -sTCP:LISTENを使えます。別のクライアントが待ち受けている場合は、そのクライアントを通常の手順で終了してから、使いたいクライアントを起動してください。ポート競合だけを理由に、正体のわからないシステムプロセスを終了しないでください。

  • 待ち受けが見つからない：コアの稼働状態、有効な設定、ポートの種類を確認し、クライアント画面のスイッチが実際に反映されているか確かめます。
  • ポートが以前のプロセスに使われている：重複して起動したインスタンスを終了します。必要に応じてタスクマネージャーで古いプロセスが残っていないか確認してください。
  • 別のポートに変更した場合：システムプロキシとアプリ内のプロキシ設定も更新します。クライアントが7891で待ち受けているのに、ブラウザーが7890へ接続する状態を避けてください。

サブスクリプションのファイルと実際に動作している設定は異なる場合があります。クライアントの上書き設定、設定のマージ、GUIでの設定によって待ち受けポートが変わることがあるため、実行時の設定と待ち受け結果を基準にしてください。各項目の意味はポート設定の説明を参照してください。

3. TUNの権限とルーティングを切り分ける

システムプロキシではアクセスできるのにTUNを有効にすると失敗する場合は、仮想ネットワークアダプター、ルーティング、DNSの取り込みを重点的に確認します。TUNはIP通信をコアに渡し、システムプロキシに従わない一部のソフトにも適用できますが、対応するコアと、ネットワークアダプターの作成やルート変更などの権限が必要です。

  1. システムプロキシをオフにし、TUNだけを有効にして、テストするアプリを再起動します。これにより、2つの通信経路が重なって原因を判断しにくくなるのを防げます。
  2. 使用中のクライアントの要件に従ってサービスモードをインストールまたは起動し、OSの権限要求を許可します。Windowsではバックグラウンドサービスが特権操作を行うことが多く、macOSではヘルパープログラムの許可が必要な場合があります。Linuxでは適切なネットワーク管理権限が必要です。
  3. ログに仮想ネットワークアダプターの作成失敗、権限不足、ルート追加失敗がないか確認します。スイッチがオンでも初期化エラーが出ている場合、通信の取り込みに成功したとはいえません。
  4. ほかのVPNを切断して再テストします。複数の仮想ネットワークアダプターがデフォルトルートを奪い合うと、ノードへの通信が誤ってトンネルに戻され、ループすることがあります。
  5. スリープからの復帰後やWi-Fiの切り替え後に問題が発生する場合は、クライアントのコアを再起動してTUNを再確立し、ルートが復旧しているか確認します。

TUNのプロトコルスタック変更、IPv6の有効化、MTUの変更、DNSの切り替えを一度に試さないでください。大容量ファイルの転送や一部のHTTPSサイトだけで止まる場合は、基本的な接続が確認できてからMTUを調べます。MTUの確認を「Webサイトが開けない」問題全般の最初の対処にするべきではありません。

4. システムDNSとコアのDNSを切り分ける

no such host、lookup failed、ドメイン名の名前解決タイムアウトが表示されたら、まずどの層で名前解決しているかを確認します。ブラウザーがセキュアDNSを使っている場合もあれば、OSとClashのコアがそれぞれ独自にDNSを使い、対象ドメインやプロキシノードのドメインを解決している場合もあります。システムDNSを変更しても、コアのDNS動作が変わるとは限りません。

まず名前解決の結果を確認し、その後キャッシュを消去する

Windowsで次のコマンドを実行すると、OSの経路での名前解決結果を確認できます。ただし、ブラウザーやコアも同じDNSを使っていることの証明にはなりません。

nslookup example.com
ipconfig /flushdns

2つ目のコマンドが消去するのは、Windows DNSクライアントのキャッシュだけです。ブラウザー、コア、上流のDNSリゾルバーにも別のキャッシュがある場合があります。設定変更後は、クライアントでサポートされている方法でコアを再起動し、ブラウザーの接続を確立し直してください。

  • ノードサーバーがドメイン名を使用している：ノード自体の名前解決も必要です。上流DNSへの問い合わせに、まだ確立されていないプロキシが必要な場合、起動時の依存関係がループすることがあります。ノードのドメイン名がどの経路で解決されるか確認してください。
  • DoHを使用している：https://形式のDNSアドレスでも、ネットワーク接続と証明書の検証が必要です。システム時刻と、リゾルバーのドメイン名を初回にどう解決するかを確認してください。
  • ブラウザーがセキュアDNSを使用している：比較のため、一時的にOSのDNSを使う設定に切り替えます。切り替え後に問題が解消したら、不明な設定をそのまま使い続けず、ブラウザーのDNS通信に適用されるルールを確認してください。
  • IPv6の接続先だけ失敗する：ローカルのIPv6接続とプロキシ経路の対応状況を確認します。比較のため、関連するIPv6設定を一時的にオフにする方法もありますが、変更範囲を記録し、テスト後に設定を再確認してください。

Fake-IPアドレスが表示されても、DNSエラーとは限らない

Fake-IPモードでは、名前解決の結果が設定された合成アドレスプールに割り当てられることがあります。よくある設定例は198.18.0.1/16です。コアはドメイン名と合成アドレスの対応を保持し、その後の接続を処理します。198.18.x.xが表示されても、ドメインが誤って解決された証拠にはなりません。また、単純なpingの結果だけでWebプロキシが正常かどうかを判断することもできません。

確認すべきなのは、合成アドレスを取得した通信が同じコアを通り続けているか、対応付けが有効なままかどうかです。アプリがFake-IPを取得した後、TUNを迂回して直接接続すると、アクセスに失敗することがあります。LAN内の機器検出、プリンター、実アドレスを必要とするアプリでは、必要に応じてfake-ip-filterを設定してください。すべてのドメインをフィルターに追加する必要はありません。基本的な概念はアドレスとGeoIPの説明および用語集を参照してください。

5. 接続記録でルールと出口を確認する

リクエストがコアに届いている場合は、接続一覧で対象ドメイン、適用されたルール、プロキシグループ、最終的に選ばれたノードを確認します。Ruleモードではルールが上から順に評価され、通常は最初に一致したルールで出口が決まります。プロキシグループの名前が「自動選択」でも、現在利用可能なノードが選ばれているとは限りません。

RuleとGlobalを一時的に比較する

  1. 現在のノードを変えずにRuleモードで対象サイトを開き、適用されたルールと出口を記録します。
  2. 一時的にGlobalへ切り替え、GLOBALプロキシグループで同じノードを明示的に選んでから、接続し直します。
  3. GlobalではアクセスできるのにRuleでは失敗する場合、対象の通信がDIRECT、REJECT、または利用できない別のプロキシグループに振り分けられていないか確認します。
  4. テスト後はRuleに戻します。Globalは原因の切り分けに使うもので、すべての通信に対する恒久的な解決策ではありません。

ルールを変更するときは優先順位に注意してください。新しいドメインルールをフォールバックのMATCHより後ろに追加しても、先行するルールがリクエストを処理するため、通常は適用されません。設定を維持する場合は、クライアントが対応する上書き設定やルールのマージ箇所に追加します。リモートサブスクリプションから生成されたファイルを直接編集すると、次回の更新で上書きされることがあります。具体的なマッチ方法はルールによる振り分けガイドを参照してください。

6. ノードと対象サイトの状態を確認する

遅延テストに成功しても、指定したタイムアウト内に1回のテストが完了したことしかわかりません。対象サイトが利用できることを示すものではありません。たとえば一覧に180 msと表示されても、実際のページが20 秒後にタイムアウトする場合があります。テスト先、接続プロトコル、出口の制限、対象サービスが異なれば、結果は矛盾しません。ここに示した数値は結果の見方を説明する例で、実測値ではありません。

  • すべてのノードで失敗する：サブスクリプションの有効期限、アカウントの通信量残高、現在の設定の有効化状態、サーバー側のメンテナンス告知を確認します。
  • 特定のノードだけ失敗する：同じサブスクリプション内の別ノードに切り替え、同じサイトにアクセスします。ノードとDNSを同時に変更すると、どちらで解決したのか判断できません。
  • 特定のサイトだけ失敗する：対象サイトの稼働状況と地域制限を確認します。ほかのHTTPSサイトにアクセスできるノードの問題を、すぐにローカルポートのせいにしないでください。
  • 認証またはハンドシェイクエラーが表示される：サブスクリプションが最新か、ノードの認証情報が有効か、コアがそのプロトコルとパラメーターに対応しているか確認します。
  • 証明書エラーが表示される：まずシステムの日付、タイムゾーン、証明書環境を確認します。問題を隠すために証明書検証を無効にしないでください。

Wi-Fiとスマートフォンのテザリングを切り替える比較テストも有効です。同じクライアント、同じノード、同じURLで現在のネットワークだけ失敗する場合は、そのネットワークのアクセス制限、UDP対応、DNS経路をさらに確認します。テザリングではモバイルデータを消費するため、テスト前に通信量に注意してください。

症状に応じて次の操作を選ぶ

確認できた症状 優先して確認する項目 次の操作
プロキシを明示すれば成功するが、ブラウザーでは失敗する システムプロキシまたはブラウザー独自の設定 アドレス、ポート、拡張機能を確認し、ブラウザーを再接続する
ローカルプロキシポートへの接続が拒否される コアの起動状態と待ち受け状況 起動ログと待ち受けプロセスを確認し、ポート設定をそろえる
システムプロキシでは成功し、TUNでは失敗する ネットワークアダプターの権限、ルーティング、DNSの取り込み TUNだけを有効にし、初期化ログを確認する
Globalでは成功し、Ruleでは失敗する 適用ルールとプロキシグループの出口 同じノードで比較し、誤って適用されるルールを修正する
ログにドメイン名の名前解決失敗が繰り返し記録される システム、ブラウザー、コアのDNS経路 エラーが発生した層を特定し、上流との接続と起動時の依存関係を確認する
特定のノードまたはサイトだけ失敗する ノードの状態と対象サイトのアクセス制限 ほかの条件を変えずにノードまたはネットワークを切り替えて比較する

解決しない場合は、必要最小限の診断情報を共有する

メンテナーに報告する際は、OS、クライアントのバージョン、コアのバージョン、発生時刻、プロキシモード、通信の取り込み方式、再現手順を記載してください。発生前後およそ30 秒分の必要なログを添え、「プロキシを明示した場合は成功するか」「TUNをオフにすると復旧するか」「Globalではアクセスできるか」も説明します。これらの情報は「接続済み」と表示された画面の画像より、原因の特定に役立ちます。

送信前にサブスクリプションのトークン、ノードのパスワード、管理APIのキー、不要な個人のアクセス履歴を削除してください。調査後は一時的な変更を元に戻し、デバッグログをオフにして、システムプロキシが現在起動中のクライアントを指していることを確認します。よくあるエラーはトラブルシューティング、サブスクリプションの追加と設定の有効化はサブスクリプションの読み込みガイドを参照してください。