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

OpenWrt などの常時稼働ルーターで OpenClash（Mihomo／Clash コアを LuCI から扱うスイート）を動かしていると、購読の「更新」ボタンや定期更新で取得タイムアウト、証明書エラー、YAML／設定の解析失敗といったメッセージが出ることがあります。PC やスマホ単体のクライアントとは違い、メモリが少ない ARM ボード、電源断後の時刻ずれ、ルーター自身の DNS とプロキシ経路が絡みやすいのが特徴です。

本記事では、検索やサポート掲示板で散らばっている対処を、再現性の高い順序に並べ替えます。最後にチェックリストもあるので、まずは上から順に当てはめてみてください。用語の整理は ドキュメント索引 も併せて参照すると理解が速くなります。

ステップ 0：エラーの種類で大枠を決める

ログや LuCI の表示はバージョンで文言が違いますが、大きくは次の三つに分けられます。(A) HTTP 層で届かない（タイムアウト、接続拒否、名前解決失敗）、(B) TLS で落ちる（証明書がおかしい、中間者、時刻不正）、(C) ダウンロードはできたが中身が壊れている（圧縮形式、途中欠損、実は HTML のエラーページ）。このどれに近いかだけ先に決めると、後の「メモリ」「時刻」「URL」のどこを重点的に見るかがはっきりします。

たとえば EOF や突然の切断は (A) と (C) の両方に見えますが、同じノードでブラウザは通るのにルーターだけ失敗するなら、(A) のうちルーターからの経路・DNSを疑う価値が高くなります。逆に、購読サーバーは健全でも、ルーターの時刻が 2010 年のままなら (B) が一気に濃厚です。

ステップ 1：メモリとストレージ（OOM・スワップ・書き込み失敗）

小容量 RAM のデバイスでは、コアの再起動や購読マージの瞬間にメモリピークが乗り、out of memory でプロセスが落ちたり、ダウンロードした一時ファイルが不完全なまま解析に回って「壊れた YAML」のように見えることがあります。症状が「たまにだけ成功する」「負荷の高い時間帯にだけ失敗する」なら、まず dmesg や logread に OOM Killer の痕跡がないかを見ます。

実務的には、(1) 同時に抱える購読本数やルールプロバイダを減らしてピークを下げる、(2) 可能ならスワップや zram を検討する、(3) 不要な LuCI プラグインや常駐を減らす、の三本柱です。オーバーレイ（フラッシュ）側の空き容量が極端に少ないと、一時ファイルの書き込みで黙って失敗することもあるため、df -h で /overlay や /tmp の残量も合わせて確認してください。

ヒント：メモリ逼迫は「購読 URL が悪い」ように見えがちです。URL を何度入れ直しても直らないときは、一度リソース状況から疑うと早いです。

ステップ 2：システム時刻と NTP（証明書検証の前提）

HTTPS の購読は、ルーターのシステム時刻が大きくずれていると証明書の有効期間チェックで失敗します。電源を長く抜いた直後、オフライン起動、NTP がブロックされている環境、といった条件とセットで起きやすい典型です。LuCI の「システム → 時刻同期」や ubus call system info、date の出力で、現実の時刻と一致しているかを確認してください。

修正の方向性は、信頼できる NTP サーバへ届くこと、必要なら起動直後に手動で一度合わせること、そしてファイアウォールで UDP 123 が外向きに通ることです。IPv6 だけ有効で NTP が片方のスタックで失敗しているケースもあるため、同期ログを併せて見ると取り違えを防げます。

ステップ 3：購読 URL そのもの（形式・認証・リダイレクト）

ブラウザで開ける URL が、そのままルーターの HTTP クライアントでも成功するとは限りません。リダイレクト連鎖、User-Agent 依存、短時間だけ有効なトークン、Basic 認証やクエリ必須など、サーバー側の振る舞いが絡みます。OpenClash 側で「更新時にプロキシを通す／通さない」などのオプションがある場合、その設定と URL の性質が噛み合っているかも確認ポイントです。

手元の PC で curl -v などを使い、最終的に返るボディが本当に Clash 互換のテキストか、それとも運営側の注意ページやログインフォームの HTML かを見分けると、(C) の切り分けが一気に進みます。文字コードや改行が混ざったミラーも稀にあるため、「同じプロバイダの別ミラー URL」で試すのも有効です。

ステップ 4：DNS と「自分自身経由」のループ

ルーター上の Clash では、ルーター自身が発行する DNS クエリがコアに流れ込み、購読先ドメインの解決がコア経由になり、さらにそのコアがまだ健全でない、という鶏卵問題に陥ることがあります。典型的には、購読ドメインを海外 DNS にだけ投げたい設定にした直後や、fake-ip と redir-host の切り替え直後に表面化します。

切り分けの基本は、(1) 一時的に購読取得だけ DIRECT 相当の経路に固定できるか、(2) ルーターの resolv.conf が指すローカル DNS（dnsmasq 等）が応答しているか、(3) DoH／DoT をルールで誤ってループさせていないか、を順に見ます。DNS 全般の設計は DNS 漏洩防止ガイド と思想が通じるので、PC クライアントで慣れた読者ほど「ルーターは自分自身のクライアントでもある」点だけ意識をずらすと理解が早いです。

ステップ 5：fw4／経路・ポリシールーティング

OpenWrt 22.03 以降の nftables ベース fw4 では、意図せずルーター自身の外向きトラフィックが制限されていると、購読だけが黙って失敗します。VPN ポリシールーティングやソースベースのルーティングを入れている環境では、「LAN からは通るがルーター本体からは別テーブル」という差が出やすいです。

確認の手順は、ルーターのシェルから購読ホストへ ping／curl を打ち、LuCI 上の診断ツールと結果を突き合わせる、が素直です。IPv4 と IPv6 のどちらで出ているかも取り違えポイントなので、失敗ログに AF_INET 系の示唆があればスタックを揃えて再試行してください。

ログと OpenClash 画面で見るべき行

コアのログレベルを一時的に上げ、購読更新の直前後だけを切り出すと、どのホストのどの段階で止まったかが残りやすくなります。TLS 失敗なら時刻と SNI、タイムアウトなら到達性と MTU、解析エラーならダウンロード結果の先頭数十バイト、という対応表を頭に置いて読むと迷子になりにくいです。

PC 側で Clash ログの読み方を既に知っている場合は、概念は同じで、違いは「失敗主体がルーター OS と共存している」点だけです。応用として ログ診断ガイド の切り分け枠組みを参照すると、dial 系の行の読み方がそのまま活きます。

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

  1. dmesg／logread に OOM やディスクエラーがないか確認する。
  2. date と NTP 同期が現実と一致しているか確認する。
  3. PC から curl し、返るボディが本物の購読テキストか確認する。
  4. ルーター自身から同ホストへ到達するか（必要なら curl -4／-6 を試す）。
  5. 購読更新を一時的に直結経路に固定できる設定になっているか確認する。
  6. fw4／ポリシールーティングで本体発の通信が遮断されていないか確認する。

この順を守ると、「とりあえず購読を削除して入れ直す」回数を減らせます。症状が再現するたびに URL だけを疑うクセは、ルーター運用では特に手戻りが大きいので注意してください。

ルーター以外の Clash との位置づけ

同じ購読でも、PC やスマホのクライアントでは成功してルーターだけ失敗する場合、原因はほぼルーター固有のリソース・時刻・DNS・経路に寄ります。逆に、どの端末でも同じ時刻に失敗するなら購読サーバー側や ISP の挿入を疑うべきです。LAN 共有や Windows ファイアウォールまわりは LAN 共有の記事 が対象を分けてくれます。

まとめ

OpenWrt 上の OpenClash で購読更新が不安定なとき、メモリとストレージ → 時刻と TLS → URL と到達性 → DNS のループと経路の順に見ると、原因の当たりが付きやすくなります。ルーターは常時稼働かつリソースに余裕が少ないため、PC 向け記事の対処をそのまま持ち込むより、デバイス本体から外向きの通信という視点を先に置くのがコツです。

コアの挙動や Issue を追うときは GitHub 上の公式リポジトリも有用ですが、日々のクライアント導入と更新は、検証済みパッケージが揃った公式の入手導線に寄せた方が試行錯誤のループを短くしやすいです。関連記事は 技術ブログの一覧 から辿れます。体感チューニングは 高速化のテクニック も参考になります。→ Clash を無料ダウンロードして、ルーターと端末の役割分担を含めた運用を試す