本文目錄
確認 Telegram 根本沒有進入 OpenClash
本文處理的是一種很具體的繞過：同一台裝置上的網頁可以透過 OpenClash，Telegram 卻無法連線；重新整理 Telegram 時，Dashboard 完全沒有對應連線，WAN 側卻能看到它直接出站。
官方 issue #5283 在 ImmortalWrt 25.12.1、fw4/nftables 環境記錄了該現象。報告中的空 lan_ac_traffic 項目產生了提前 RETURN 的規則，讓大部分 TCP 和 UDP 在進入 Mihomo 前就回傳。
如果 Dashboard 能看到 Telegram，並顯示規則、策略群組和出站節點，流量已經進入核心。此時應轉查節點、規則、UDP 或 DNS，不能繼續刪除來源存取控制。
先按連線記錄分流
| 觀察結果 | 更可能的階段 | 下一步 |
|---|---|---|
| 網頁正常，Telegram 無記錄，WAN 直接出站 | 透明代理前被 RETURN | 檢查空的來源流量存取控制 |
| Telegram 有記錄，但命中 DIRECT | 規則選擇 | 檢查該連線命中的規則與策略群組 |
| Telegram 有記錄，節點發生錯誤 | 代理出站 | 固定節點後檢查協議、UDP 與網路 |
| 所有應用都沒有記錄 | OpenClash 接管未生效 | 檢查執行狀態、模式與防火牆載入 |
儲存設定並保留路由器管理入口
修改防火牆相關選項前，先匯出 OpenClash 設定和目前設定，記錄執行模式、外掛程式版本、核心版本及來源流量存取控制頁面。遠端維護時還要確認有獨立的 LAN 管理入口。
本次檢查只處理一個空項目，不同時更新訂閱、切換核心、改 DNS 或重寫規則。一次只改一項，才能用重啟前後的 Dashboard 和 WAN 路徑判斷結果。
準備一條可還原路徑
匯出目前設定
把外掛程式設定與目前設定儲存到路由器之外，避免誤刪有效存取控制後無法還原。
截圖空項目頁面
記錄項目名稱、啟用狀態、協議、位址族、動作以及所有匹配條件。
確認本機管理入口
在 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 之前，所以連線提前返回。
只讀查看 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 restart驗證 Telegram 已進入 Mihomo
在同一台測試裝置上重新開啟 Telegram，同時觀察 OpenClash Dashboard。連線應開始出現在清單中，並顯示命中的規則、策略群組和實際出站；只看到應用恢復還不足以證明不再直連。
再檢查 WAN 路徑與普通網頁。目標是 Telegram 不再繞過、原有網頁仍能存取，而且沒有誤刪其他裝置需要的明確直連策略。若只有重啟後的短暫恢復，應重新檢查空項目是否被設定同步寫回。
修復完成標準
- 重啟後不再出現無條件的 lan_ac_traffic RETURN
- Telegram 桌面端或行動裝置能夠完成一次實際連線
- Dashboard 能看到對應連線、規則、策略群組和出站
- WAN 側不再顯示該流量繞過 Mihomo 直接出站
- 普通網頁、DNS 與其他終端仍按原計劃工作
驗證失敗時看哪裡
| 失敗表現 | 說明 | 處理方向 |
|---|---|---|
| Telegram 仍無 Dashboard 記錄 | 接管前仍被繞過 | 檢查其他 RETURN、裝置存取控制與透明代理入口 |
| 已出現記錄但連線失敗 | 接管已經恢復 | 檢查節點、規則、UDP 與目標網路 |
| 項目重啟後重新出現 | 設定來源仍在寫入 | 檢查備份恢復、同步指令碼或介面殘留 |
| 其他裝置原有直連失效 | 刪到了有效策略 | 恢復備份並重建帶明確條件的項目 |
不匹配時還原並更換診斷方向
刪除後若影響了原有直連裝置，立即恢復設定備份，重啟 OpenClash，並把需要直連的來源、目標或連接埠寫成明確條件。不要用一個無條件 return 項目替代多條可解釋的存取控制。
沒有空項目、沒有全量 RETURN，或者 Telegram 本來就出現在 Dashboard 時，本文根因已經排除。此後應根據連線記錄轉向規則、節點、UDP、DNS 或應用自身網路，不再繼續改 nftables。
該 issue 截至本文發布時仍為開放狀態，官方也沒有給出已收錄修復的穩定版邊界。因此本文採用刪除空設定的維護者建議，不宣稱升級某個版本即可自動修復。
還原後重新確認
- 路由器 LAN 管理入口和普通網路已經恢復
- 有效的來源存取控制已按明確條件重建
- OpenClash 重啟後設定檢查與防火牆載入成功
- 新的檢查方向由 Dashboard 和日誌證據決定