まずログの取得元とリクエスト時刻を確認
Clashのログには、カーネルが接続を処理する過程が記録されます。ブラウザーのページ全体を診断するものではありません。ページが開かない原因は、アプリがプロキシを使っていない、ルールの選択、名前解決、ノードへの接続、接続先の応答など、さまざまな段階で発生します。まず失敗した箇所を特定してから該当する設定を変更しましょう。赤いエラーを見てすぐクライアントを再インストールするより、原因に沿って確認するほうが効果的です。
Clashはカーネルや関連クライアントの一般的な呼称です。Clash Metaはその後、mihomoとして開発が続けられています。カーネルやデスクトップクライアント、画面のバージョンによって、ログの項目名やメニュー名は異なる場合があります。この記事のログ行は構造を示す例であり、特定のネットワーク環境で実測した結果ではありません。例にあるポート番号をそのまま自分の設定に使わないでください。
- クライアントのサイドバーから「ログ」または「Logs」を開きます。ログ画面がない場合は、「設定」にあるログディレクトリやカーネルログの項目を探してください。
- 現在の時刻、使用中の設定名、動作モード、プロキシグループで実際に選択されているノード、システムプロキシとTUNの有効・無効を記録します。
- 画面上の古いログを消去してから、問題のあるページを1つだけ開きます。約10秒待ち、スクロールを止めるか、この間のログをエクスポートします。
- 接続先のドメイン、ポート、時刻で絞り込みます。自動更新や接続テスト、Webページのリクエストが同じ画面に混在するため、最後のエラーだけを見て判断しないでください。
ログレベルの設定：まずinfo、必要なときだけ短時間debug
よく使われるログレベルはsilent、error、warning、info、debugです。通常のトラブル対処では、接続やルールの一致を確認できるinfoを使います。名前解決や接続処理、カーネルの詳細を確認する必要がある場合に限り、debugを短時間有効にしてください。
| レベル | 確認できる内容 | 使い方 |
|---|---|---|
| error | カーネルがエラーとして扱うイベント | 情報量が少なく、最初の調査でこれだけを頼りにするのは不向き |
| warning | 警告以上のイベント | 一部の失敗は確認できるが、接続の詳しい状況は分からない |
| info | 通常の接続、ルール選択、警告・エラー | 問題を初めて再現するときに使用 |
| debug | 内部処理の詳細な記録 | 再現した時間帯だけ有効にし、調査後はinfoに戻す |
| silent | 通常のログ出力を無効化 | 調査中は使用しない |
設定の変更場所と上書き
画面に「設定」→「ログレベル」がある場合は、まず画面から変更してください。カーネルの設定を直接管理している場合は、現在有効なYAMLの最上位に次の項目を設定できます。dnsやtunの子項目ではありません。
log-level: info保存後、クライアントが対応する方法で設定を再読み込みし、ログをもう一度確認します。クライアントによっては、設定の上書き・マージや実行時パラメーターでログレベルを制御します。サブスクリプションの更新で、直接編集したファイルが上書きされる場合もあります。ディスク上のファイルだけで反映を判断せず、画面の設定と実際のログ出力の両方を確認してください。調査後はinfoに戻し、リクエストの記録が長期間たまり続けないようにします。
接続ログの読み方：接続先・ルール・出口・エラーの流れ
ログは、時刻、リクエスト先、ルールと実際の出口、エラーの順に読むと状況を把握しやすくなります。以下は簡略化した構造例です。実際のログでは項目の順序や改行形式が異なる場合があります。
[warning] [TCP] 127.0.0.1:53124 --> www.example.com:443
match DomainSuffix(example.com) using Proxy[ノードA]
error: dial tcp 192.0.2.10:443: i/o timeout127.0.0.1:53124は、カーネルが認識した接続元です。53124は一時的な送信元ポートであり、システムプロキシに設定する待ち受けポートではありません。www.example.com:443はリクエスト先です。443はHTTPSでよく使われますが、ポート番号だけではWebサイトの証明書が正常かどうかは判断できません。matchの後は、一致したルールを確認する箇所です。ルールモードでは通常、上から順に照合され、先に一致したルールが後続の通信先を決めます。using Proxy[ノードA]は、今回使用したプロキシとノードを示します。プロキシグループ名はノードサーバーのアドレスではありません。実際に選択されたメンバーも確認してください。dial tcpの後にあるアドレスは、今回接続しようとした相手です。直接接続ならWebサイトのアドレス、プロキシ経由ならノードのアドレスの場合があります。エラー全体の流れと合わせて判断してください。
例にある192.0.2.10は説明用のアドレスであり、設定に入力しないでください。本来ノード経由でアクセスする想定なのにDIRECTと表示される場合は、まずルールとモードを確認します。REJECTの場合は、ノードの切断ではなく遮断ルールを確認してください。
dial timeoutとi/o timeout：どの接続段階でタイムアウトしたか
dial timeoutやconnect: connection timed outは、通常、期限内に接続を確立できなかったことを示します。i/o timeoutはより広い範囲を指し、接続確立後の読み書き中に発生することもあります。いずれも待ち時間の超過を示すもので、「ノードが無効」や「DNSが汚染されている」と直ちに判断できるわけではありません。
失敗の範囲から原因を絞り込む
- 特定のWebサイトだけ開けない：同じノードで、アクセスできることが分かっている別のWebサイトを開きます。問題のドメインに別のルールが適用されていないか、直接接続になっていないか確認してください。
- 同じノードで複数のWebサイトが開けない：同じプロキシグループで別のノードに切り替え、同じリクエストを試します。元のノードだけ失敗する場合は、そのノードのアドレス、ポート、サービスの状態を重点的に確認してください。
- すべてのノードで失敗する：まずローカルネットワークが使えることを確認し、ノードのドメイン解決、ファイアウォール、上位ネットワークの制限、サブスクリプションの有効期限を調べます。
- TUNモードだけ失敗する：設定とノードは変えずに、システムプロキシで比較します。プロキシを明示的に指定すれば正常でTUNだけ異常な場合は、ルーティング、DNSの取り込み、ほかのVPNとの競合を確認してください。
WindowsではPowerShellでTest-NetConnection -ComputerName ノードのドメイン名 -Port ノードのポートを実行できます。ただし、2つの値は現在の設定にある実際の値に置き換えてください。このTCPテストが使えるのはTCP接続が必要なエンドポイントだけです。UDPベースのプロトコルの正常性は判断できません。また、ポートに接続できても、認証やTLS、アプリケーションのリクエストが成功するとは限りません。
最初にタイムアウト時間を延ばすのは避けてください。待ち時間を長くしても、誤ったアドレス、停止したサービス、通信できない経路は直りません。まずログでタイムアウトした接続先を特定し、必要な場合に限ってタイムアウト関連の設定を変更します。
connection refused：ローカルと接続先のポートを見分ける
connection refusedは、接続を試みた結果、拒否されたことを示します。該当するアドレスとポートでサービスが待ち受けていない、またはネットワーク機器が接続を拒否している場合によく発生します。応答がないまま時間切れになるタイムアウトとは異なります。まず拒否されたアドレスが127.0.0.1か、ノードサーバーのアドレスかを確認してください。
ローカルの127.0.0.1:7890で接続が拒否される
7890はよく使われる例のプロキシポートで、すべてのクライアントで共通の固定値ではありません。アプリからローカルの7890への接続が拒否される場合は、クライアントの「設定」でポートまたは混合ポートを確認し、カーネルが起動しているか、実際の待ち受けポートが変更されていないかを調べます。カーネルログにポートのバインド失敗が先に記録されていないかも確認してください。
# Windows：ローカルの7890が待ち受け状態か確認
netstat -ano | findstr ":7890"
# macOS / Linux：TCP 7890を待ち受けているプロセスを確認
lsof -nP -iTCP:7890 -sTCP:LISTENWindowsの出力では、ローカルアドレス列とLISTENINGの状態を合わせて確認します。「7890」と表示されただけでプロキシが起動していると判断しないでください。ポートを使用中のプロセスが見つかった場合は、まずプログラムを特定します。正体の分からないシステムプロセスをいきなり終了しないでください。
接続先ノードのポートで拒否される
ノードのアドレスから拒否された場合は、サブスクリプションに記載されたサーバーアドレスとポートが有効か確認し、サブスクリプションを更新して再試行します。HTTPプロキシの認証情報が誤っている場合は、407 Proxy Authentication Requiredなどの応答が返ることがあります。すべての拒否をパスワードの誤りと決めつけないでください。ノードのポートに接続できても、プロトコルと認証は別途確認が必要です。
DNS解決に失敗した場合：Webサイトのドメインとノードのドメインを区別
no such host、lookup ... failed、DNS resolve failedはいずれも名前解決に関するエラーですが、解決できなかったドメインはアクセス先のWebサイトとは限らず、ノードサーバーの場合もあります。ノードのドメインを解決できなければ、WebサイトのDNS設定が正しくても、ノードに接続できません。
- Webサイトのドメインを解決できない：現在の実行設定にある
dnsセクション、DNSリゾルバーへの接続、直接接続とプロキシ経由で使われる名前解決のルールを確認します。 - ノードのドメインを解決できない：mihomoで
proxy-server-nameserverが設定されているか、ノードに接続する前から該当するDNSリゾルバーを利用できるかを確認します。 - DoHリゾルバー自体に接続できない：DoHのアドレス、ホスト名を最初に解決する方法、外向きの通信経路を確認します。「ノード接続にDNSが必要で、DNSにも未接続のノードが必要」という循環を避けてください。
- TUNでのみ失敗する：TUNのDNS取り込み設定、現在のシステムDNS、ほかのVPNが同時にネットワーク設定を変更していないかを確認します。
システムの名前解決が正常でも、カーネルの名前解決が正常とは限らない
nslookup www.example.comを実行すると、システムが使うリゾルバーの応答を確認できます。ただし、mihomo内蔵のDNSを経由するとは限りません。ブラウザーでセキュアDNSが有効になっていると、別の経路で名前解決されることもあります。そのため、「nslookupで結果が返る」ことは比較材料にはなりますが、カーネルが実際に使うリゾルバーの正常性を証明するものではありません。
fake-ipモードでは、設定されたFake IPアドレス範囲内の合成アドレスが表示されても正常な場合があります。たとえば、よく使われる範囲に198.18.0.0/16があります。このアドレスを見ただけで、通信が乗っ取られたと判断しないでください。接続が正しくカーネルのルーティングに戻っているか、実際の上流DNSやノードへの接続に失敗していないかを確認します。詳しい確認箇所はマニュアルのDNSトラブル対処を参照してください。
証明書・ポートのバインド・TUNの権限に関するエラー
| ログのキーワード | 意味と優先して確認する箇所 |
|---|---|
x509: certificate has expired or is not yet valid | OSの日付・時刻・タイムゾーンを確認し、エラーが発生したWebサイト、ノード、サブスクリプションの接続先を特定する |
certificate signed by unknown authority | 証明書の信頼チェーン、社内ネットワークによる通信の検査、ノードの証明書設定を確認する。検証を安易に無効化しない |
bind: address already in use | 待ち受けポートまたはアドレスの競合。混合ポート、DNSの待ち受けポート、コントロールポートを確認する |
permission denied / operation not permitted | 前後のログから、設定ファイル、ネットワーク機器の作成、ルーティング操作のどの権限が不足しているかを判断する |
connection reset by peer / EOF | 接続がリセットされた、または読み取りが終了した状態。プロトコルのどの段階で起きたか、どの範囲で再現するかを確認する。パスワードの誤りと即断しない |
TLSエラーでは、まず接続先を特定します。カーネルが報告する証明書エラーは、ノードとのハンドシェイク、サブスクリプションのダウンロード、DNS over HTTPSのリクエストで発生することもあり、ブラウザーでアクセスしたWebサイトが原因とは限りません。通常のプロキシでHTTPS通信を中継する場合、Webサイトの証明書は通常、最終的にブラウザーが検証します。
TUNの作成やルート設定に必要な権限がない場合は、クライアントの「設定」にあるサービスモード、権限、TUN関連の画面を開き、クライアントの案内に従ってサービスをインストールするか、権限を付与します。Windowsのデスクトップクライアントでは、インストール済みのバックグラウンドサービスが必要な場合があります。LinuxではTUNデバイスやネットワーク管理の権限が関係することがあります。手順はクライアントによって異なるため、あらゆるエラーへの対処として常に管理者権限で実行することはおすすめしません。
待ち受けポートを変更した場合は、システムプロキシ、ターミナルのプロキシ環境変数、ブラウザー拡張機能の手動設定も合わせて変更してください。カーネルが正常に起動していても、アプリが古いポートを参照していれば、ローカル接続の失敗が続きます。
再テストの手順を固定し、ログをマスキングする
一度に変更する項目は1つにして、同じドメイン、同じアクセス方法で再テストします。サブスクリプションの更新、ノードの切り替え、DNSの変更、TUNの有効化を同時に行うと、アクセスが回復しても本当の原因を特定できません。
- 元の設定をバックアップし、問題が発生した時刻と該当するエラー行を記録します。
- リクエストがカーネルに届いていることを確認し、次にルールで想定どおりの出口が選ばれているか確認します。
- ログに基づき、名前解決、接続、認証、TLSをそれぞれ確認します。異なる段階の問題を混同して推測しないでください。
- 項目を1つ変更するたびに設定を再読み込みし、同じリクエストの新しいログを確認します。エラーが消えたか、内容が変わったかを見てください。
- 調査後は通常のログレベルに戻し、ブラウザーと普段使うターミナルアプリの両方で動作を確認します。プロキシの経路を一方だけ直して終わらないようにしてください。
開発者に問題を報告する際は、クライアント名、クライアントとカーネルそれぞれの実際のバージョン、OS、動作モード、TUNの有効・無効、再現手順、関連ログの前後約20行を添えてください。バージョンは「バージョン情報」またはカーネルの起動ログで確認し、クライアントのバージョンとカーネルのバージョンを混同しないでください。
送信前に、サブスクリプションURL、アクセストークン、プロキシのパスワード、コントロールAPIキーのほか、個人情報につながる可能性のあるドメイン名やIPアドレスを削除してください。マスキング後も、判断に必要な項目の構造、ポート、エラーの種類、ルールの関係は残します。サブスクリプションファイル全体を公開したり、元の問題を隠すために証明書検証を無効化したり、ファイアウォールを長期間停止したりしないでください。