接続トラブルシューティング · Clash 技術ブログ

OpenClash で IPv6 ノードのドメインを名前解決できない場合は？

OpenClash でノードの名前解決が失敗し、公開 IPv6 DNS が 198.18.x を返す場合は、OUTPUT のカウンターと v0.47.156 の修正を確認します。更新後は名前解決、プロキシ、直接接続を検証し、異常時は元の設定に戻してください。

本文を読むブログへ戻る
  • OpenClash
  • IPv6
  • DNS ハイジャック
  • SmartDNS
  • ノードの名前解決
目次
執筆者
Clash 公式
公開日
更新日時
読了時間の目安
約 9 分

ルーター自身の名前解決エラーと、家庭内の端末が接続できない問題では、確認する証拠が異なります。外部の名前解決サーバーへ問い合わせた結果が、プロキシの仮想アドレスになっていないかを調べます。応答とファイアウォールのカウンターが一致してからプラグイン更新や一時回避へ進み、関係する機能をすべて同時に無効にしないようにします。

公開 IPv6 DNS への問い合わせで 198.18.x が返る

OpenClash の IPv6、ルーター自身のプロキシ、ローカル DNS ハイジャック、Fake-IP の状態を確認します。これらが有効な場合、ルーター上の SmartDNS などが外部の IPv6 DNS に問い合わせて 198.18.x を受け取るか、ドメインをサーバーアドレスに使うプロキシノードが同時に接続できなくなっているかを調べます。

一般的な端末で Web ページを開けない、LAN 内の端末が IPv6 を取得できない、サブスクリプションのダウンロードに失敗する、DNS ポートが AdGuard Home に使用されている、といった状況だけでは同じ問題と証明できません。障害がルーター自身からパブリック IPv6 DNS へ送る問い合わせで起きていることを先に確認し、IPv6 が関係するという理由だけでネットワーク全体の機能を無効にしないでください。

次の条件をすべて満たす場合だけ続ける

  • OpenClash のバージョンが修正収録済みの v0.47.156 より古い、または更新後にサービスをまだ再起動していない
  • システムが fw4/nftables または legacy ip6tables を使用し、ルーター自身のプロキシが有効になっている
  • ローカル DNS ハイジャックと Fake-IP が有効で、ルーター自身でも SmartDNS などのリゾルバーが動作している
  • そのリゾルバーにパブリック IPv6 DNS の上流が設定され、ノードのサーバーアドレスにドメインが使われている

プラグインのパッケージとDNS設定を保存し、管理画面への接続を確保する

プラグインとコアのバージョン、動作モード、SmartDNS の上流サーバーを記録します。以下の手順で設定、構成、インストール用パッケージを保存し、更新に失敗した場合に復元できるようにします。

テスト中はサブスクリプション、ルール、DNS の上流、動作モードを同時に変更しないでください。一度に変更するのは一項目だけにし、変更前後の問い合わせ結果を残します。そうしなければ、ノードが復旧してもどの手順が効いたか判断できません。

ロールバック用の資料を用意する

  1. プラグイン設定をエクスポートする

    設定ファイル管理から設定と現在の構成をバックアップし、ルーター外の端末へダウンロードして保存します。

  2. 元のインストーラーを残す

    現在のバージョンに対応する公式 IPK または APK を保存し、システムのパッケージ管理が opkg と apk のどちらかを記録します。

  3. 原因となるスイッチを記録する

    IPv6、ルーター自身のプロキシ、ローカル DNS ハイジャック、Fake-IP、SmartDNS の IPv6 上流が有効かを書き留めます。

  4. 直接接続の管理経路を用意する

    LAN からルーターを管理できることを確認します。リモートで保守する場合は、予備の接続がない状態で DNS やファイアウォールを変更しないでください。

ルーターで DNS の応答とルールのカウンターを照合する

ルーターのターミナルから、現在到達可能なパブリック IPv6 DNS を一つ指定して、実在するドメインを問い合わせます。正常な結果は、そのドメインの公開 A または AAAA レコードです。198.18.0.0/16 が返り、実行前後で該当する IPv6 OUTPUT DNS Hijack ルールのカウンターが増えた場合、問い合わせは誤ってローカルの Clash DNS へ戻されています。

OpenClash issue #5251 の再現では 2400:3200::1 が使われました。このアドレスが手元のネットワークに適するかは、事前に確認する必要があります。IPv6 の経路自体が到達不能なら、タイムアウトが示すのは上流を利用できないことだけで、ハイジャックの発生は証明できません。問い合わせるドメインは、公開レコードがあると明確に分かっている一般的なドメインへ変更できます。

ルーターのSSHターミナルでカウンターを確認します。実際に使用しているファイアウォールに合わせ、fw4/nftablesなら第一のコマンド、legacy ip6tablesなら第二のコマンドを選んでください。両方のコマンドがあるだけで併用せず、クエリの前後に選んだものを実行します。カウンターのリセットやルールの削除は行いません。

fw4/nftables：ルーター自身のDNSルールを表示するだけのコマンド
nft list chain inet fw4 nat_output
legacy ip6tables：OUTPUTの正確なカウンターを読み取るだけのコマンド
ip6tables -t nat -nvxL OUTPUT --line-numbers

fw4の出力で、IPv6、UDPの53番ポート、redirect、OpenClash DNS Hijackのマーカーがそろうルールを探し、同じ行のcounterにあるpacketsとbytesを比較します。TCP/UDPをまとめたルールの場合もあります。OUTPUT全体の合計を、このクエリの証拠として扱わないでください。

legacyの出力で、OpenClash DNS Hijackと記されたIPv6 UDP/53 REDIRECTルールを確認し、同じ行のpktsとbytesを読み取ります。旧ルールの宛先範囲は::/0です。修正後は::1だけに一致するため、公開サーバーへのクエリでこのルールのカウンターが増えてはいけません。

該当ルールが見つからない、またはカウンターを読めない場合は、バージョンとクエリ結果を保存し、この障害と決めつけてアップグレードしないでください。198.18.xという応答だけでは同じ問題とは証明できません。ルールの出力にはネットワーク情報が含まれることがあるため、公開で相談する前に機密情報を伏せてください。

ルーターから実際に到達できるパブリック IPv6 DNS を指定する
nslookup www.nic.ad.jp 2400:3200::1

結果に応じて次の手順を決める

問い合わせ結果ルールのカウンター結論
198.18.x が返るIPv6 OUTPUT のカウンターが増える確認済みのルーター自身に対する IPv6 DNS ハイジャックと一致する
実際の A または AAAA が返るカウンターが増えないこの経路は正常なので、サブスクリプション内のノード名前解決用 DNS を確認する
問い合わせがタイムアウトするカウンターが増えないまず IPv6 の経路と、選択した DNS へ到達できるかを確認する
LAN 内の端末に異常があるが、ルーターの問い合わせは正常該当する変化がないRA、DHCPv6、RDNSS、ブラウザのセキュア DNS を確認する

SmartDNS の問い合わせだけに異常があり、Mihomo の上流は正常

プロセスの所属グループと問い合わせ先を確認します。Mihomoは通常、ルールの対象外にされたGID（ユーザーグループの識別番号）を使いますが、ほかのローカルリゾルバーの問い合わせはOUTPUTルールに一致する可能性があります。

すべての DNS で connection refused が返る

ローカルのリッスンポートと上流設定を確認し、この記事の IPv6 ルール修正を適用しないでください。

指定した IPv4 DNS は正常だが、指定した IPv6 DNS から 198.18.x が返る

この比較結果とカウンターの変化を残し、バージョン更新へ進みます。

ルーター自身からパブリック IPv6 DNS へアクセスする際の誤った経路
  1. SmartDNS などのローカルリゾルバーパブリック IPv6 アドレスへ 53 番ポートの問い合わせを送る
  2. OpenClash の OUTPUT ルール旧版では ::/0 により、すべての IPv6 DNS 接続先へ誤って一致する
  3. ローカルの Clash DNSリダイレクトされた問い合わせが Fake-IP モードで 198.18.x を返す
  4. プロキシノードのドメイン誤った結果により、ドメインを使用するノードが接続を確立できない

修正では、ルーター自身に対する IPv6 DNS ハイジャックの範囲をすべてのアドレスからループバックアドレス ::1 へ絞りました。この変更で LAN 内の端末に対する DNS 引き継ぎルールは削除されていません。

パブリック IPv6 DNS がローカル問い合わせとして扱われる理由

旧ルールが本来引き継ぐべきだったのは、ルーター自身からループバックアドレスへ送る DNS だけでしたが、IPv6 の接続先範囲に ::/0 が指定されていました。この範囲にはすべての IPv6 アドレスが含まれるため、SmartDNS からパブリック IPv6 DNS の TCP または UDP 53 番ポートへアクセスした場合も、ローカル DNS へリダイレクトされていました。

問題は PR #5209 が ::/0 を新たに追加したことではありません。このコミットで IPv4 と IPv6 のルールを個別に識別した結果、それまで早い段階でスキップされていた古い分岐が安定して実行されるようになり、v0.47.117 以降で欠陥が表面化しやすくなりました。PR #5252 は nftables の二か所と legacy ip6tables の四か所をすべて ::1 へ変更し、LAN 側の DNS 引き継ぎは維持しています。

修正を収録した v0.47.156 へ更新する

OpenClash v0.47.156 に #5252 が含まれることは公式の公開記録で確認できます。以下の更新手順はこの固定バージョンを基準にしています。すでに新しい版を使っている場合は、同じ問い合わせ結果とカウンターの変化があるかを先に確認し、手順を合わせるためだけに旧版へ戻さないでください。

古い::/0ルールがファイアウォールでまだ有効になっている可能性があります。ルールを再生成して初めて、ソースコードの::1が実際に反映されます。

ロールバックに備えた更新手順

  1. システムのパッケージ形式を照合する

    opkg のシステムでは公式 IPK、apk のシステムでは公式 APK を選び、入手元が v0.47.156 Release であることを確認します。開発ブランチのファイルや異なるパッケージ形式を混用しないでください。

  2. 追加の変更を一時停止する

    元のカーネル、サブスクリプション、動作モード、DNS 設定を維持し、OpenClash プラグインだけを更新します。

  3. インストールしてサービスを再起動する

    インストール完了後に OpenClash を再起動し、ファイアウォールと DNS のルールが再生成されるまで待ちます。

  4. 通信を始める前にログを確認する

    設定テスト、カーネルの起動、DNS のリッスンに成功したことを確認します。失敗した場合は、元のパッケージとバックアップを復元してください。

公開サーバーへの問い合わせ、ローカルループバック、ノード接続を再確認する

更新前と同じルーター、同じドメイン、同じパブリック IPv6 DNS を使ってもう一度問い合わせます。修正が反映されていれば、実際の A または AAAA が返り、パブリックへの問い合わせで IPv6 OUTPUT DNS Hijack のカウンターは増えません。ルーター自身のループバック ::1 への問い合わせは、引き続き OpenClash で引き継げます。

修正の受け入れ確認リスト

  • OpenClashのバージョンにv0.47.156の修正が含まれ、インストール後にサービスを再起動している
  • 指定したパブリック IPv6 DNS から実際の A または AAAA が返り、198.18.x は返らない
  • パブリック IPv6 DNS への問い合わせで、ルーター自身の IPv6 ハイジャックルールのカウンターが増えない
  • ::1 への問い合わせではローカル DNS の引き継ぎが正常に機能し、LAN 内の端末の名前解決も損なわれていない
  • 元のノードの少なくとも一つで名前解決、接続、実際のページ表示が完了し、対応する接続記録がある

すぐに更新できない場合の回避方法とロールバック

すぐに更新できない場合は、SmartDNS からパブリック IPv6 DNS の上流を一時的に削除し、到達可能と確認済みの IPv4 上流へ変更できます。また、ルーター自身のプロキシまたはローカル DNS ハイジャックの原因となる項目を一時的に無効にする方法もあります。どの方法もルーター自身の通信または DNS の引き継ぎを変えるため、項目ごとにテストし、長期的な修正として扱わないでください。

更新後に問題が広がった場合は、まず管理画面で OpenClash を無効にします。DNS の参照先が停止したサービスのままなら、到達できる上流へ戻してください。LAN から管理画面に接続できることを確認してから、元のプラグインパッケージと設定バックアップを復元してサービスを再起動し、更新前の IPv4/IPv6 の問い合わせ結果と比較して元の状態に戻ったか確認します。

パブリック IPv6 DNS から実際の結果が返るのにノードが失敗する場合は、proxy-server-nameserver、サブスクリプションの内容、TLS、ノードサーバーを確認し、OUTPUT ルールを変更し続けないでください。

一時的な方法の影響

実施内容適する状況必ず再確認する項目
SmartDNS を到達可能な IPv4 上流へ変更するすぐに更新できないが、ノードの名前解決を復旧する必要があるローカルドメイン、キャッシュ、ノードのドメインをすべて正常に名前解決できる
ルーター自身のプロキシを一時的に無効にするルーター自身の DNS だけが影響を受けているルーターの更新、サブスクリプション、プラグインダウンロードの送信経路
ローカル DNS ハイジャックを一時的に無効にする端末が DHCP で配布された DNS を使ってもよい場合LAN 内の端末が、想定した振り分けと DNS ポリシーを迂回していないか
元のパッケージと設定を復元する更新後にサービスを起動できない、または LAN で通信できないバージョン、DNS のリッスン、ファイアウォールルール、実際のアクセス

参考資料