1. まずログを開く：3つの入口
まずは実践から。どのクライアントを使っていても、ログは同じ場所——カーネルから出力されます。GUIはカーネルの出力を購読しているだけなので、各クライアントで見えるエラー文言は同一のもの。文言の読み方を覚えれば、すべてのクライアントに通用します。入口は使い方によって3種類に分かれます。
- GUIクライアントのログページ。Clash Verge Revは左側ナビに「ログ」項目があり、そこを開くと内核のログがリアルタイムで流れ、上部でレベル別に絞り込めます。Clash for Windowsも同様に「Logs」セクションがあり、レベルによるフィルタが可能です。
- カーネル設定の log-level。mihomoカーネルを直接実行する場合、ログは端末に出力され、詳細度は設定ファイルの
log-levelフィールドで制御します。選択肢はsilent、error、warning、info、debugの5段階で、デフォルトはinfoです。 - 外部コントローラAPI。カーネルで
external-controller（一般的なアドレスは127.0.0.1:9090）を有効にすると、/logs?level=infoエンドポイントからログストリームが継続的に配信されます。GUIクライアントのログページもこの経路を利用しています。
注意：画面上でフィルタレベルを切り替えても「表示内容」が変わるだけで、カーネルが実際に記録する内容には影響しません。より詳細なログを記録させたい場合は、log-level を変更してカーネルを再起動または設定を再読み込みする必要があります。
2. ログ1行の構造：時刻・レベル・接続情報
まず典型的なinfoレベルの実行ログを見てみましょう（表示形式はクライアントごとに多少異なりますが、要素は共通です）。
2026-06-19 21:03:11 INFO [TCP] 127.0.0.1:52341 --> www.example.com:443 match DomainSuffix(example.com) using 香港ノードこれを4つのパーツに分解します。
- 時刻
2026-06-19 21:03:11：トラブルシューティング時はまずこれで操作した時刻を確認します。操作前のログは今回の問題とは無関係です。 - レベル
INFO：低い順にdebug、info、warning、errorとなり、レベルが高いほど注視すべき内容です。 - 接続情報
[TCP] 127.0.0.1:52341 --> www.example.com:443：左側がローカル側の発信元アドレスと一時ポート、右側がアクセス先とポートです。 - 結果
match DomainSuffix(example.com) using 香港ノード：この接続がどのルールにマッチし、どの出口に振り分けられたかを示します——出口はノード、DIRECT（直接接続）、REJECT（拒否）のいずれかです。
なぜこのような形式になるのか。Clashの動作モデルは「接続が来る→ルールテーブルを照合→出口に振り分ける」というシンプルな流れなので、実行時ログはほぼすべてこの構文になります。ログを読むことの本質は、「宛先が正しいか」「ルールのマッチが期待通りか」「出口が正しいか」という3点を確認する作業です。この3つがすべて正しくても繋がらない場合に限って、ノードや通信経路の問題を疑います。
3. よくあるエラー5種類を1つずつ解説
① 接続タイムアウト：i/o timeout
2026-06-19 21:04:02 WARN [TCP] dial 香港ノード 127.0.0.1:52341 --> www.google.com:443 error: dial tcp 203.0.113.8:443: i/o timeout意味：カーネルがノードのサーバーに接続を試みたものの、タイムアウトまで応答が返ってこなかった状態です。context deadline exceeded も表記が異なるだけで同じ意味です。「ノード→通信経路→ローカル環境」の順に切り分けます。
- ノード一覧で遅延テストを実行：すべてタイムアウトする場合はサブスクリプションの期限切れかローカルのネット接続断が疑われ、単一ノードのみタイムアウトする場合はそのノード自体の問題です。
- 同じ宛先に対して別のノードに切り替えてアクセスし、通れば元のノードが機能していないことを確認できます。
- すべてのノードで繋がらない場合は、同じ宛先をDIRECTに変更して試します。直接接続でも繋がらなければローカルのネットワーク自体の障害です。
理由：timeoutは「応答が来なかった」ことしか示さず、ノードのダウン・経路への干渉・ローカルのネット断のどれが原因かは区別しません。そのため必ず段階的に切り分ける必要があり、タイムアウトを見た瞬間にクライアントを乗り換えるのは適切ではありません。
② サブスクリプション・設定の解析失敗
2026-06-19 21:05:40 ERROR configuration file error: yaml: unmarshal errors: line 86: cannot unmarshal !!str into map[string]interface {}意味：設定ファイルの86行目付近のYAML構造に問題があり、カーネルが起動を拒否しています。よくある原因は3つ——手動編集後にインデントが崩れている、サブスクリプションURLがYAMLではなくエラーページのHTMLを返している、現在のカーネルが認識しないフィールドが混在している、のいずれかです。もう1つよく見られる形として：
2026-06-19 21:05:41 ERROR proxy 3: unsupport proxy type: hysteria意味：4番目のノード（0番から数えます）が、このカーネルが対応していないプロトコルを使用しています。無印のClashカーネルはhysteriaやtuicなど新しいプロトコルに対応していないため、mihomo（Clash Meta）カーネルを採用したクライアントに切り替える必要があります。各社のカーネル対応状況はクライアント比較ページで確認できます。
確認手順：エラーに行番号が示されていればその行を、ノード番号が示されていればそのノードを数えて特定します。サブスクリプションの読み込みに失敗した場合は、そのURLをブラウザで直接開いてみてください——文字化けやエラーページが返る場合はサブスクリプション自体の問題、まとまったテキストが返る場合はクライアント側の解析処理に問題があります。
③ ポート占有：bind error
2026-06-19 21:06:15 ERROR start mixed(http+socks) proxy error: listen tcp 127.0.0.1:7890: bind: address already in use意味：カーネルが待ち受けようとしている7890ポートが別のプロセスに使用されていて、プロキシサービスを起動できません。Windowsでは同じ状況が「Only one usage of each socket address is normally permitted」と表示されます。確認手順：
- 最も多い原因は、前回のClashプロセスが完全に終了していないことです。タスクマネージャーを開き、残留しているclash、mihomo、clash-vergeなどのプロセスを見つけて終了させてから、再起動してください。
- 無関係なプログラムがポートを占有していることが分かった場合は、クライアント設定のミックスポート（例：7890を7897に変更）を変更し、保存してカーネルを再起動してください。
理由：待ち受けポートは排他的なリソースであり、同時に1つのプロセスしか占有できません。この種のエラーの対処法は常に2ステップです——まず占有元を特定し、そのプロセスを終了させるか、自分でポートを変更するかを決めます。
④ DNS解決失敗
2026-06-19 21:07:33 WARN [TCP] dial DIRECT 127.0.0.1:52410 --> api.example.com:443 error: dns resolve failed: couldn't find ip意味：カーネルが宛先ドメインのIPアドレスを解決できず、接続がアドレス解決の段階で止まっています。まずクライアントのDNS設定が誤って変更されていないか確認し、デフォルトに戻して再試行してください。次にシステム自体が正常に名前解決できるか確認します（プロキシを無効にした状態でブラウザからネットにアクセスできるか）。fake-ipモードを使用している場合、この種のエラーは比較的少なくなります。頻発する場合は、DNS設定に223.5.5.5や119.29.29.29などのパブリックDNSをデフォルトリゾルバとして追加してみてください。
⑤ TUNモードの起動失敗
2026-06-19 21:08:20 ERROR start TUN listening error: create tun: permission denied意味：TUNモードは仮想ネットワークアダプタを作成する必要があり、この処理には管理者権限が求められます。Windowsでは「管理者として実行」でクライアントを起動してください。macOSやLinuxではクライアントの案内に従って権限を許可します。権限を許可しても失敗する場合は、他のVPNやアクセラレーター系ソフトとの競合を確認してください——2つの仮想ネットワークアダプタが同時にルーティングを制御すると干渉が発生するため、片方を終了してから再試行します。TUNモードの詳細な設定手順は使い方ガイドに専用のセクションがあり、関連用語は用語解説で確認できます。
4. 問題を特定するための決まった手順
これまでの内容を1つの流れにまとめます。何らかの異常が発生したら、以下の5ステップで進めます。
- 問題を再現しながらログを注視するフィルタレベルをwarning以上に設定し、まずerror行があるかどうかを確認します。
- 段階を切り分ける起動時のエラー（設定解析、ポート占有、TUN作成）はクライアントを開いた瞬間に発生し、実行時のエラー（タイムアウト、DNS、ハンドシェイク失敗）はWebページにアクセスした時にのみ発生します。
- 起動時エラーは文言どおりに対処するエラーが示す行があればその行を、勝手な推測ではなく実際に確認します。
- 実行時エラーはノードとローカルを先に切り分ける遅延テストでノードとローカルネットワークのどちらの問題かを見極め、
match ... using ...でルールのマッチが想定通りかを確認します——中国本土のサイトがノード経由になっている場合は、ノードではなくルールやGeoIPデータの問題である可能性が高いです。 - 情報が足りなければdebugを有効にする現在のレベルでは原因が分からない場合、一時的にdebugに切り替えて再現し、詳細を取得したらinfoに戻します。
理由：ログは時系列に並んでいますが、障害には明確な発生段階があります。段階を先に特定してから文言を確認するほうが、数千行のログをスクロールしてキーワードを探すより格段に速いです。
5. debugレベルの使い方と注意点
手順：ログページでレベルをdebugに切り替えるか、設定ファイルに log-level: debug と記述してカーネルを再読み込みし、問題を最初から最後まで再現して、操作開始からエラー発生までの区間を抜き出します。注意点は3つです。
- debugは1つ1つの接続のマッチ詳細を出力するため流れが非常に速く、長時間有効にしたままだとUIが重くなったり、ログファイルが肥大化したりします。
- ログにはアクセスしたドメイン名が含まれるため、画面をキャプチャしてグループチャットやフォーラムで質問する前に、機微なドメインは必ず伏せてください。
- 問題が解決したらinfoに戻し、ログを「普段は静かで、問題が起きた時だけ声を上げる」状態に保っておくと、次回のトラブルシューティングでも読みやすくなります。
ここまでで、ログの読み方についての解説は終わりです。入口は3つ、構文は1つ、エラーは5種類、手順は5ステップ。次にクライアントがぐるぐる回ったりページが開かなかったりしたら、すぐに再インストールするのではなく、まずログを開いて直近のerror行から確認してみてください。