なぜ「タイムアウト」「購読失敗」「ノードがすべて赤」の三点セットがセットで現れやすいのか
日本語フォーラムで繰り返し見られる相談は、見かけが似ていても原因の束が異なることに気づきにくい、という一点にまとめられます。接続タイムアウトは上流のレイテンシやドロップのほかに、名前解決の失敗や TLS レイヤでのブロックでも起きます。購読プロファイル更新の失敗は URL 側の権限だけでなく、クライアントが送るヘッダや証明書検証、ローカルキャッシュまで含めて一度に検査する必要があります。
遅延テストでノードが一斉に赤く見える現象は、「サーバーがすべて同時に落ちた」というより共通の上流条件（DNS、fake-ip とアプリ要件の相性、アンチウィルスの HTTP 検査、企業ゲートウェイの介入）によってチェックだけがすべて失敗したように見えていることが多いです。ここでの赤は「そのクライアントの計測手順での失敗」であり、ユーザー体験での接続可否と常にイコールではありません。
そのため復旧でもっとも効くのは、チェックリストをなぞることよりログに沿って上流から順に挟み込んでいく手順の固定化です。本稿は Mihomo を背負える近年のグラフィカルフロントに寄せつつも、共通する観察点だけを書きます。利用は各国の法令とサービス提供者の規約に照らしたうえでの自己責任でお願いします。
症状マップ｜体感とログで位置づける
まず手元の状態を三段階に分けると調査が速くなります。
- レイヤーA（外向き総体）：Wi‑Fi ルータや ISP が落ちている、企業 captive portal に捕まっている、など物理／契約側の問題
- レイヤーB（名前解決と証明書）：
dial tcpより前で止まっている、証明書警告がコンソールに出る、時間が数時間ズレている、など TLS／DNS／時計の問題 - レイヤーC（YAML とノード）：購読は取れるが一部プロトコルだけ不安定、cipher と実装世代の組み合わせがずれている、など設定とノード品質側
A が壊れている間に B や C をいじっても再現しないため、ブラウザで一般的なサイトが開けるか、テザリングに一度だけ差し替えられるかなど広い視点での比較実験から入るのが安全です。
接続タイムアウトを潰す優先順位
タイムアウトログに i/o timeout と出たからといって即座に「遠くのサーバーが遅い」と決めないでください。ループバック側の競合ポートや競合している別の仮想 NICが原因で、アプリ側がタイムアウト判定に達するだけの事例も現場であります。
実務的な順です。
- ポート占有の確認：開発用プロキシや古い残骸がミックスポートや指定ポートと衝突していないか
- システム時刻とタイムゾーン：TLS が一括で不安定になります。自動同期をオンにします
- アンチウィルスの HTTPS スキャン一時無効による再現確認：許可があればだけ短時間試し、恒久対応は製品側のホワイトリスト設計へ
- 名前解決の置き換え：LAN の DNS がフィルタを返している場合、DoH がブロックされていない別経路での比較
- ノード側のポートとプロトコル：UDP 依存アプリがあるなら、そのノードタイプでの UDP を購読と実ログの両面から確認します
ひとつのノードだけがタイムアウトなら上流のサービス状態やリージョンを疑ってよい一方、グループ単位ですべて同じ秒数で落ちるなら共通の上流（DNS と証明書）を先に詰めるほうが再現試行回数を減らせます。
購読更新が失敗するとき読むログの型
自動更新だけ失敗している場合、ユーザーがブラウザで同じ URL を開けるケースがあります。しかし自動更新経路では UA 制限／リファラ必須／短時間でのレートリミット／リダイレクト先のみ TLS 異常などが絡むため、体感と機械処理が食い違うのはよくあります。
# Example log fragments (illus.)
GET https://example.com/clash/profile?token=***
- status: 403 Forbidden
TLS handshake failure: certificate signed by unknown authority403 ではトークンの失効、アクセス元 IP のブロック、アクセス頻度制限などを並走で確認します。証明書エラーでは会社端末に入った独自 CAがクライアントプロセス側に適用されていない、など環境依存の地雷もあります。手動ダウンロードで済ませられるなら応急処置にはなりますが、恒久対応としては証明書ストア側の是正か、サービス側のチェーン更新待ちになります。
また購読のマージ順で既存ファイルが壊れていると、その結果として更新ジョブが一度に止まっているように見えることもあります。最後に適用できた構成を退避フォルダに残しておく運用だけで復旧時間を短縮できます。
ノード検査が全部赤になる／一部だけ異常になる
多くのクライアントは HTTP または TCP レイヤの簡易チェックで色分けしています。そのためICMP が通らない環境だけでも赤くなる実装があります。まずチェック機構が何を叩いているかを製品側ドキュメントで押さえるのが要点です。
もしチェックだけ赤で実運用ブラウザは通るのであれば、ルールセットの適用優先順位や、fake-ip と対象サイトの証明書ピニングの相性まで見に行く必要があります。逆にチェックも実運用も落ちるなら上流の共通障害確度が跳ねます。
グループ自動選択アルゴリズムを使っている場合名前に「自動」と付いていても毎回流れる先が偏る／偏らないなど挙動差が出やすく、体感速度とログの両方が揃って初めて納得感が得られます。このときに Global への短期固定が切り分けとして有効なことはありますが、日常運用に据え置くと国内通信も遠回りするため長時間にはしないほうがよいです。
DNS まわりの典型パターン
国内実装寄りのアプリでも、CDN のエッジ選択は名前解決に強く依存します。fake-ip はレイテンシ体感を安定させやすい一方、対象サービス側がローカライズされた名前解決を前提にしているときにギクシャクすることがあります。購読提供者が明示した推奨 DNS セットから大きく外れない運用が基本です。
ローカルの ブラウザ拡張型 DNS／セキュア DNS が OS とは別レイヤで効いていると、ログ上は Clash が正しく見えても実アプリが別解を持ってくる、という状態も起きえます。その場合でも「ログを疑う」のではなく、各レイヤでの実名前解結果を並べて比較するだけで視界が変わります。
システムプロキシだけでは効かないアプリがある
環境によっては規定が「ポート開放のみ」だったり、開発ツールが独自環境変数を参照していたりします。チェックリストとしてはポート番号・PAC の有効／無効、macOS であれば関連フレームワークの許可ダイアログの再読み込み、Windows であれば一度だけ昇格権限での起動、など環境ごとの項目を並べます。
UDP を伴う音声通話などは TUN とセットでしか期待どおりにならないこともありますが、本章の「エラー」の多くは TUN が無くても解ける種類です。上流の DNS と証明書に問題が無い状態で初めて TUN が効いた／効かなかったの判定が明快になります。
YAML の破損とマージ競合への対処
手編集後にインポートだけ落ちている場合は、バリデータに通していないだけで済むこともあります。一方で自動マージ機能がオンだとユーザーが読んでいない末尾にだけ文法地雷が増えていることがあります。最後に正常起動できた構成と差分だけを並べれば、復旧は桁早くなります。
# Broken example (illegal YAML)
proxies:
- name "tokyo-ss" # missing ':' after key
type: ssname 行のような小さな打ち間違いでも全体読み込みが止まるため、体感では「すべてのノードが死んだ」のように見えます。自動整形ツールでの救済が効くときと、コア側の許容構文との差異で二度手間になるときがあります。ひとつの黄金律は自動生成ブロックだけを単体で読み込み試験することです。
キャンティブポータルと社宅回線での注意
公共 Wi‑Fi や寮回線ではリダイレクトが強く、証明書の差し替えを伴うログインでもめます。その間は自動更新だけがサイレントに失敗し、ユーザーは「タイムアウトが増えた」と感じます。ログイン済みフラグが付くまで自動更新頻度を下げたり、その場では手動取得に切り替えると摩擦が少ないです。
短文チェックリスト（印刷して貼れる版）
- ブラウザ一般サイトと購読 URL の両方を開ける／開けない
- タイムゾーンと自動時刻／手動ピンクの有無
- アンチウィルスの HTTPS 検査
- 他社 VPN と仮想 NIC の競合の有無
- 自動更新だけ失敗するときは UA／レート制限／トークンの失効順
- ノード検査のみ赤／実運用も赤の二分
mixinやプラグインマージの順序確認
よくある質問
Q. すべてのサーバーが同時停止したと考えればよいですか？
A. まず共通上流条件を疑います。特に名前解決と証明書、ローカルのセキュリティ製品の三点は一斉失敗様に見えやすいです。
Q. 自動購読だけ失敗するときの第一候補は？
A. UA またはアクセス頻度制御、およびリダイレクトチェーンでの TLS の途中異常です。ログの HTTP コードと証明書メッセージをセットで読みます。
Q. Rule と Global で変わらないのは終わりですか？
A. アプリ側がプロキシ設定を読まず direct に出している、ピニングに引っかかっている、YAML 自体が読み込めていない線を再度疑います。
まとめ｜ログで挟み込んでから機材を換える
体感では「すべてのサーバーが同時ダウン」になりがちでも、ログで挟み込むとだいたいは少数の共通原因に収束します。だから復旧でもっとも時間を食うのは、症状の名前を増やしすぎることより上流の固定化を怠ることです。この順序さえ決まれば同じような相談に何度でも短時間で戻せます。
ブラウザ拡張型の細切れプロキシや、プラットフォームごと別々の構成ファイルを増やしていく運用では、更新たびに「どのレイヤが嘘をついているか」を追うコストだけが増えがちです。Mihomo コアを背負ったクライアントでは購読・ルール・DNS・モード・検査ログまでが一枚のコンソールに寄りやすく、異常調査での往復クリックも減らせます。古い単体構成を抱え込んでいる場合は、検証環境だけでも正規の最新系へ寄せることで、この記事前半のチェックリスト通過率がぐっと上がります。
プラットフォーム別の署名付きビルダルと変更履歴をまとめて確認したい場合は各 OS 向けの公式導線から入手すると安全です。