目次
Telegram が OpenClash へまったく入っていないことを確認する
この記事で扱うのは、非常に具体的な迂回です。同じ端末の Web ページは OpenClash 経由で利用できるのに Telegram へ接続できません。Telegram を更新しても Dashboard に該当する接続がまったくなく、WAN 側では直接送信されていることが確認できます。
公式 issue #5283 には、ImmortalWrt 25.12.1 と fw4/nftables の環境でこの現象が記録されています。報告内の空の lan_ac_traffic 項目は、早い段階で RETURN するルールを生成し、大部分の TCP と UDP を Mihomo へ入る前に返していました。
Dashboard に Telegram が表示され、ルール、ポリシーグループ、送信ノードも示される場合、通信はすでにカーネルへ入っています。この場合はノード、ルール、UDP、DNS の確認へ移り、送信元アクセス制御を削除し続けないでください。
まず接続記録に沿って切り分ける
| 観察結果 | 可能性が高い段階 | 次の手順 |
|---|---|---|
| Web ページは正常、Telegram の記録はなく、WAN へ直接送信される | 透過プロキシへ入る前に RETURN している | 空の送信元トラフィックアクセス制御を確認する |
| Telegram の記録はあるが DIRECT に一致する | ルールの選択 | 対象の接続に一致したルールとポリシーグループを確認する |
| Telegram の記録があり、ノードでエラーが出る | プロキシからの送信 | ノードを固定してから、プロトコル、UDP、ネットワークを確認する |
| すべてのアプリに記録がない | OpenClash による引き継ぎが機能していない | 動作状態、モード、ファイアウォールの読み込みを確認する |
設定を保存し、ルーターの管理経路を残す
ファイアウォール関連の項目を変更する前に、OpenClash の設定と現在の構成をエクスポートし、動作モード、プラグインのバージョン、カーネルのバージョン、送信元トラフィックアクセス制御の画面を記録します。リモートから保守する場合は、独立した LAN 管理経路があることも確認してください。
今回調査するのは空の項目一つだけです。サブスクリプションの更新、カーネルの切り替え、DNS の変更、ルールの書き換えを同時に行わないでください。一度に変更するのは一項目だけにすることで、再起動前後の Dashboard と WAN の経路から結果を判断できます。
ロールバック可能な経路を用意する
現在の設定をエクスポートする
プラグイン設定と現在の構成をルーター外へ保存し、有効なアクセス制御を誤って削除しても復元できるようにします。
空の項目がある画面をスクリーンショットに保存する
項目名、有効状態、プロトコル、アドレスファミリー、アクション、すべての一致条件を記録します。
ローカルの管理経路を確認する
LAN 内からルーターの管理画面を開きます。リモート経路しかない場合は、ファイアウォールと OpenClash を直接再起動しないでください。
テスト端末を固定する
まず、元の問題を再現していた一台の端末だけで Telegram をテストし、ほかの端末の設定は変更しません。
空の送信元トラフィックアクセス制御項目を確認する
OpenClash の送信元トラフィックアクセス制御画面を開き、有効なままでアクションが return またはプロキシを使用しない設定になっているにもかかわらず、送信元アドレス、接続先アドレス、ポート、インターフェースなどの一致条件がない項目を探します。このような空の項目だけが、この記事の条件に該当します。
項目が特定の端末、ネットワーク範囲、ポートを明示的に指定している場合は、実際の直接接続要件を担っている可能性があります。名前が同じという理由だけで削除しないでください。条件と想定用途を記録してから、残すべきかを判断します。
uci show openclash | grep lan_ac_trafficopenclash.@lan_ac_traffic[0]=lan_ac_traffic
openclash.@lan_ac_traffic[0].enabled='1'
openclash.@lan_ac_traffic[0].proto='both'
openclash.@lan_ac_traffic[0].family='both'
openclash.@lan_ac_traffic[0].target='return'空の項目と判断する条件
- section の種類が lan_ac_traffic で、現在の enabled が 1 である
- アクションが return で、プロトコルとアドレスファミリーが TCP、UDP、IPv4、IPv6 を対象にする場合がある
- 送信元 IP、接続先 IP、ポート、インターフェース、その他の実際の一致条件がない
- 特定の端末向けに残した明示的な直接接続ポリシーではない
ランタイムルールで全通信を RETURN していないか確認する
設定に空の項目があっても、実際にランタイムルールが生成されたことを確認する必要があります。公式報告のルールは 0 から 65535 までの送信元ポートへ一致し、Fake-IP のアドレス範囲を除外していました。redirect または TPROXY より前にあるため、接続が早い段階で返されます。
fw4 の OpenClash チェーンを読み取り専用で確認し、lan_ac_traffic のコメントがあり、条件がほぼすべての TCP または UDP を対象にする RETURN を探します。ルールの handle は生成のたびに変わるため、issue にある 803、805 をコピーして直接削除しないでください。
nft -a list chain inet fw4 openclash
nft -a list chain inet fw4 openclash_mangleほぼ全通信を対象とする lan_ac_traffic RETURN がある
出力を保存し、画面へ戻って対応する空の項目を削除します。一時的な handle へ直接依存しないでください。
明示的な送信元または接続先の条件を持つ RETURN だけがある
空の項目から生成された全通信向けルールではないため、そのポリシーの実際の用途を先に確認します。
lan_ac_traffic ルールがない
この記事の操作を中止し、OpenClash による引き継ぎ、ルールの一致、ノード、DNS を確認します。
端末に nft コマンドがない、またはチェーン名が異なる
チェーン名を推測してルールを削除しないでください。バージョンとファイアウォールの情報を保存し、該当するファームウェアのドキュメントに沿って確認します。
- Telegram が接続を開始する端末のリクエストは本来 OpenClash の透過プロキシへ入る
- 空の lan_ac_traffic 項目送信元、接続先、ポート、インターフェースの条件がない
- 全通信を対象とする RETURN ルールredirect または TPROXY より前に返される
- WAN へ直接送信される通信が Mihomo を迂回し、Dashboard に記録されない
空の項目を削除して OpenClash を再起動すると、新しいファイアウォールルールに、この全通信向け RETURN が含まれなくなるはずです。Telegram の接続は Mihomo へ入り、Dashboard に表示される必要があります。
空の項目を削除し、OpenClash を再起動する
OpenClash のメンテナーは、この issue への対処として送信元トラフィックアクセス制御の削除を提案しています。一般利用者は、空であることを確認した項目を LuCI 画面から削除し、保存・適用してから OpenClash を再起動し、nftables ルールを再生成する方法を優先してください。
画面から一時的に削除できない場合は、該当する section の無効化でも復旧できることを報告者が確認しています。以下のインデックスが使えるのは、uci show で空の項目が第 0 項目と明確に表示された端末だけです。インデックスが異なる場合は、実際の値へ変更する必要があります。
最小限の範囲で対処する
項目が空であることをもう一度確認する
送信元、接続先、ポート、インターフェースの条件が一つもなく、業務上も直接接続に使う必要がないことを確認します。
LuCI からの削除を優先する
その空の項目を削除して保存・適用し、ほかのアクセス制御や振り分け項目は変更しません。
OpenClash を再起動する
設定検証、カーネル、ファイアウォールルールがすべて再読み込みされるまで待ちます。Dashboard を更新するだけでは不十分です。
nftables をもう一度読み取る
以前の全通信向け lan_ac_traffic RETURN が消えたことを確認してから、Telegram のテストを開始します。
uci set openclash.@lan_ac_traffic[0].enabled='0'
uci commit openclash
/etc/init.d/openclash restartTelegram が Mihomo へ入るようになったことを検証する
同じテスト端末で Telegram をもう一度開き、同時に OpenClash Dashboard を確認します。接続が一覧へ表示され始め、一致したルール、ポリシーグループ、実際の送信先が示される必要があります。アプリが復旧したことだけでは、直接接続でなくなったとは証明できません。
さらに WAN の経路と通常の Web ページを確認します。目標は、Telegram が迂回しなくなり、以前の Web ページも引き続き利用でき、ほかの端末に必要な明示的な直接接続ポリシーを誤って削除していない状態です。再起動直後だけ復旧する場合は、設定同期によって空の項目が再び書き込まれていないか確認してください。
修正の完了基準
- 再起動後、無条件の lan_ac_traffic RETURN が表示されなくなる
- Telegram のデスクトップ版またはモバイル版で実際の接続を一度完了できる
- Dashboard に該当する接続、ルール、ポリシーグループ、送信先が表示される
- WAN 側で、この通信が Mihomo を迂回して直接送信されたと表示されなくなる
- 通常の Web ページ、DNS、ほかの端末が予定どおりに動作し続ける
検証に失敗した場合の確認先
| 失敗時の症状 | 説明 | 対処する方向 |
|---|---|---|
| Telegram が引き続き Dashboard に記録されない | 通信の引き継ぎ前に、まだ迂回している | ほかの RETURN、端末のアクセス制御、透過プロキシの入口を確認する |
| 記録は表示されるが、接続に失敗する | 通信の引き継ぎは復旧済み | ノード、ルール、UDP、接続先ネットワークを確認する |
| 再起動すると項目が再び表示される | 設定の生成元が引き続き書き込んでいる | バックアップの復元、同期スクリプト、画面に残った設定を確認する |
| ほかの端末で以前の直接接続が機能しなくなる | 有効なポリシーを削除している | バックアップを復元し、明示的な条件を持つ項目を作り直す |
一致しない場合は元へ戻し、別の診断経路へ切り替える
削除後に以前の直接接続端末へ影響した場合は、設定のバックアップを直ちに復元して OpenClash を再起動し、直接接続が必要な送信元、接続先、ポートを明示的な条件として記述します。説明可能な複数のアクセス制御を、無条件の return 項目一つで置き換えないでください。
空の項目も全通信向け RETURN もない場合、または Telegram が最初から Dashboard に表示されている場合、この記事の根本原因は除外できます。以後は接続記録に基づき、ルール、ノード、UDP、DNS、アプリ自身のネットワークを確認し、nftables を変更し続けないでください。
この issue は記事の公開時点でもオープンで、公式から修正を収録済みとする安定版の境界も示されていません。そのため、この記事では空の設定を削除するというメンテナーの提案を採用し、特定バージョンへの更新だけで自動的に直るとは述べません。
ロールバック後に再確認する
- ルーターの LAN 管理経路と通常のネットワークが復旧している
- 有効な送信元アクセス制御が、明示的な条件を持つ形で再構築されている
- OpenClash の再起動後、設定検証とファイアウォールの読み込みに成功している
- Dashboard とログの証拠に基づいて、次の調査方向を決める