本文目录
确认 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 和日志证据决定