目次
Web ページはプロキシを使えるのにチャットアプリが接続できない場合、ドメインルール不足とは限りません。ダッシュボードに接続がなければ、ノードを変える前にプロキシに通信が届いているか確認します。空のアクセス制御項目によって通信がプロキシの処理を迂回する場合があるため、設定と実行中のルールの両方が一致する場合にだけ、その空の項目に対処します。
ページはプロキシを使うのにTelegramは直接接続する
同じ端末とネットワークを保ち、Telegram が接続を再試行する際の Dashboard とルーターの WAN（外部ネットワーク）の記録を確認します。Web 通信は OpenClash を通るのに Telegram の記録がなく直接外へ出る場合、後述の空のアクセス制御を調べます。アプリが接続できないだけでは原因を特定できません。
公式 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 による引き継ぎが機能していない | 動作状態、モード、ファイアウォールの読み込みを確認する |
設定を保存し、ルーターの管理経路を残す
今回調査するのは空の項目一つだけです。サブスクリプションの更新、カーネルの切り替え、DNS の変更、ルールの書き換えを同時に行わないでください。一度に変更するのは一項目だけにすることで、再起動前後の Dashboard と WAN の経路から結果を判断できます。
復旧に必要な設定と管理画面へのアクセスを確保する
現在の設定をエクスポートする
OpenClash の設定と現在の構成をエクスポートしてルーター以外の場所に保存し、動作モード、プラグインとコアのバージョンを記録します。有効なアクセス制御を誤って削除しても復元できるようにするためです。遠隔作業では、別の LAN 管理経路を確保してください。
空の項目がある画面をスクリーンショットに保存する
項目名、有効状態、プロトコル、アドレスファミリー、アクション、すべての一致条件を記録します。
ローカルの管理経路を確認する
LAN 内からルーターの管理画面を開きます。リモート経路しかない場合は、ファイアウォールと OpenClash を直接再起動しないでください。
テスト端末を固定する
まず、元の問題を再現していた一台の端末だけで Telegram をテストし、ほかの端末の設定は変更しません。
空の送信元トラフィックアクセス制御項目を確認する
OpenClash の送信元トラフィックのアクセス制御画面を開きます。有効なままで、動作が戻る、またはプロキシを使わない設定なのに、送信元アドレス、宛先アドレス、ポート、インターフェースなどの一致条件がない項目を探してください。以降のルール確認は、この空の項目を対象にします。
項目が特定の端末、ネットワーク範囲、ポートを明示的に指定している場合は、実際の直接接続要件を担っている可能性があります。名前が同じという理由だけで削除しないでください。条件と想定用途を記録してから、残すべきかを判断します。
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 より前にあるため、接続が早い段階で返されます。
以下の nft コマンドはルーターの端末で実行し、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 を再起動する
画面から一時的に削除できない場合は、該当する 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 とログの証拠に基づいて、次の調査方向を決める