こんなときに読む記事です

タスクトレイやメニューバーでは Clash／Mihomo 系クライアントが「動いている」ように見えるのに、ブラウザだけ真っ白のまま進まない。しばらくするとまた繋がるが、数分おきに不安定になる——この手の症状は、原因が「この PC の設定・ポート」なのか「購読しているノードや回線」なのか、最初の切り分けが難しいことがあります。

本記事では、ログに出てくる短い英語フレーズを手がかりに、まずローカル側の失敗を疑うべきか、外向きの dial tcp やタイムアウトからノード側を疑うべきかを順に整理します。GUI によってログ画面の名前は違いますが、中身のパターンは世代をまたいで似通います。

ログを読む前の 2 点だけ

意味のある行を拾うには、一時的に ログレベルを上げるのが近道です。info だけでは接続失敗の理由が省略されることがあるため、調査中だけ debug に寄せる、という運用が現実的です。あわせて、ブラウザや OS のプロキシ設定が「本当にその mixed-port や socks-port を指しているか」を確認してください。指し先が古いポートのままだと、クライアントは元気でも通信がそもそも届きません。

用語の整理は ドキュメント も参照すると早いです。DNS や名前解決が絡む切り分けは DNS 漏洩防止ガイド、体感速度の調整は 高速化のテクニック と併読すると全体像が掴みやすくなります。

まず疑う：ポート占有とリッスン失敗（本機側）

設定ファイルに mixed-port（HTTP と SOCKS が同居する代表例）や socks-port、場合によっては port（HTTP のみ）や外部コントローラ用の external-controller など、待ち受けポートが並びます。ここで別プロセスが同じ番号を掴んでいると、起動直後またはリロード直後にエラーが出ます。

典型的なキーワードは次のようなものです。bind、address already in use、listen failed、only one usage of each socket address など。行の中に 7890 のような具体的な番号と一緒に出ることが多く、その番号が YAML の mixed-port や socks-port と一致していれば、ほぼ間違いなくポート競合です。古い Clash プロセスがゾンビのまま残っている、別のプロキシツールが同じポートを使っている、仮想化ソフトや開発サーバーが偶然かぶっている、といったパターンが多いです。

対処の方向性はシンプルで、競合プロセスを終了するか、YAML 側のポート番号を空いている値に変え、ブラウザ／OS のプロキシ設定も同じ番号に合わせるかのどちらかです。片方だけ直すと「設定は合っているつもりで実は違うポート」という状態が残りやすいので、数字はメモしてから一括で揃えてください。

dial tcp の行を読む：宛先で意味が変わる

ログに dial tcp と出たとき、それが必ずしも「海外ノードが悪い」ことを意味しません。コロン右側のホスト名または IPを見てください。例えば 127.0.0.1:xxxx やループバックに向いている場合、上流チェーンの relay やローカル側の別コンポーネント、誤った proxy 参照など、自分のマシン上のサービスへの接続試行であることがあります。

一方、dial tcp の先が購読サーバーのドメイン、あるいはノードの IP／ホスト名になっているなら、そこから先は外向きの TCP 接続です。connection refused は「そもそもポートが開いていない／ファイアウォールで落とされている」寄り、i/o timeout や context deadline exceeded、日本語 UI では「接続タイムアウト」に近い表現は、パケットは出ているが返ってこない・極端に遅いときに出やすく、ノードの混雑、ルーティング、ICMP 制限、一時的な回線劣化などが疑われます。

同じノードでだけ失敗し、別グループや DIRECT では通るなら、設定全体ではなくそのプロキシ行を疑うのが筋がよいです。逆に、どのノードでも同じ時刻に一斉にタイムアウトするなら、ローカルの DNS 解決や TUN／ルートの異常、セキュリティ製品の挿入も視野に入れます。Windows の TUN まわりは TUN／Wintun の記事 が参考になります。

接続タイムアウトと断続的な切断の読み分け

接続タイムアウトという言葉はログでも UI でも広く使われますが、実務では次のように整理すると判断が速くなります。初回の TCP 確立で時間がかかり切って落ちるのか、TLS ハンドシェイクの段階で止まるのか、すでに確立した後にアイドルで切れるのか。行の前後数行にプロトコル名やプロキシ名が出ていれば、どのホップで詰まっているかの当たりを付けやすくなります。

断続的な症状では、同じサイトでもリソースごとに別接続が張られるため、一部だけ読み込めて全体は止まる、という見え方になります。ここでポート競合が原因の場合、たいてい起動時や設定再読み込み時に必ずエラーが出る一方、ノード劣化の場合は時間帯や負荷に依存してランダムに出ることが多いです。この「再現性」の差も、ログを眺めるときの補助線になります。

実践チェックリスト（上から順に）

1. 起動直後のログに listen／bind／already in use がないか確認する。
2. YAML の mixed-port・socks-port と、OS／ブラウザのプロキシ指定が一致しているか確認する。
3. 失敗行の dial tcp 先がループバックか外向きかを見分ける。
4. 外向きでタイムアウトが続くノードだけを切り替え、他ノードで再現するか比較する。
5. 全ノードで同様なら DNS・TUN・セキュリティソフトの層を疑い、関連記事とログを突き合わせる。

この順序を守ると、「いきなり購読を疑って何度も入れ直す」という手戻りを減らせます。ログは一度に全部は読まず、エラーと警告だけをフィルタしてから読み進めるのがおすすめです。

よくある取り違い

「タイムアウト＝ノードが悪い」と決めつける

ローカルでプロキシチェーンが循環参照になっている、誤った proxy-groups で常に死んだ上流へ飛ばされている、といった場合もタイムアウトに見えます。dial tcp の宛先と、実際に選ばれているグループ名を対応づけて確認してください。

ポートを変えたのにブラウザだけ古い

システムプロキシは更新されたが、拡張機能や別ブラウザが独自の固定ポートを握っている例があります。症状がブラウザ依存ならその可能性を疑ってください。

まとめ

Clash 系クライアントのトラブルでは、画面の「繋がっている」表示と実際の通信経路が一致しないことがあります。ログの一行に出るポート番号・ホスト名・エラー種別を手がかりに、本機のリッスン失敗か外向きの dial tcp 失敗かを先に分けると、次に打つ手（ポート変更、プロセス整理、ノード切替、DNS／TUN の見直し）がはっきりします。

コアの挙動やライセンスを追う場合は GitHub 上の公式リポジトリが有用ですが、日々のインストールと更新は検証済みパッケージが揃った公式の入手導線に寄せた方が、設定試行錯誤のループを短くしやすいです。関連トピックは 技術ブログの一覧 から辿れます。→ Clash を無料ダウンロードして、ログに沿った切り分けを手元の環境で試す