On this page
Confirm that Telegram never enters OpenClash
This article covers a specific bypass: webpages on the same device work through OpenClash, but Telegram cannot connect. When Telegram is refreshed, the Dashboard shows no matching connection, while the WAN side shows it going directly outbound.
Official issue #5283 records the behavior on ImmortalWrt 25.12.1 with fw4/nftables. An empty lan_ac_traffic entry generated an early RETURN rule, causing most TCP and UDP traffic to return before entering Mihomo.
If the Dashboard shows Telegram along with its rule, policy group, and outbound node, traffic has already entered the core. Investigate the node, rules, UDP, or DNS instead; do not continue deleting source access controls.
Branch using connection records first
| Observed result | More likely stage | Next step |
|---|---|---|
| Webpages work, Telegram has no record, and WAN shows direct egress | RETURN before the transparent proxy | Check for an empty Source Traffic Access Control entry |
| Telegram has a record but hits DIRECT | Rule selection | Inspect the rule and policy group matched by the connection |
| Telegram has a record, but the node reports an error | Proxy egress | Pin a node, then check the protocol, UDP, and network |
| No application has a record | OpenClash interception is not active | Check runtime status, mode, and firewall loading |
Save the settings and preserve router management access
Before changing firewall-related options, export the OpenClash settings and current configuration. Record the runtime mode, plugin version, core version, and Source Traffic Access Control page. For remote maintenance, also confirm that an independent LAN management path is available.
This procedure addresses only one empty entry. Do not update the subscription, switch cores, change DNS, or rewrite rules at the same time. Changing one item at a time lets the Dashboard and WAN path before and after the restart show the result.
Prepare a rollback path
Export the current settings
Save the plugin settings and current configuration outside the router so you can restore them if a valid access-control entry is removed by mistake.
Capture the empty-entry page
Record the entry name, enabled state, protocol, address family, action, and every match condition.
Confirm local management access
Open the router admin page from the LAN. If remote access is your only path, do not restart the firewall and OpenClash directly.
Pin one test device
Test Telegram only from one device that originally reproduced the problem; leave other endpoints unchanged for now.
Check for an empty Source Traffic Access Control entry
Open the Source Traffic Access Control page in OpenClash. Look for an enabled entry whose action is return or bypass, but that has no match conditions such as source address, destination address, port, or interface. Only an empty entry like this matches the issue in this article.
If an entry clearly limits a specific device, subnet, or port, it may serve a real direct-routing requirement. Do not delete it just because the name matches; record its conditions and intended purpose before deciding whether to keep it.
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'Criteria for identifying an empty entry
- The section type is lan_ac_traffic, and enabled is currently 1
- The action is return, and the protocol and address family may cover TCP, UDP, IPv4, and IPv6
- There is no source IP, destination IP, port, interface, or other real match condition
- The entry is not an explicit direct-routing policy you retained for a particular device
Use runtime rules to confirm whether it is a catch-all RETURN
An empty entry in the configuration must also be confirmed to generate a runtime rule. The rule in the official report matched source ports 0 through 65535 and excluded the Fake-IP range. It ran before redirect or TPROXY, so connections returned early.
Inspect the OpenClash chains in fw4 read-only. Look for a RETURN with a lan_ac_traffic comment and conditions that approximately cover all TCP or UDP traffic. A rule's handle can change every time it is generated; do not copy 803 or 805 from the issue and delete it directly.
nft -a list chain inet fw4 openclash
nft -a list chain inet fw4 openclash_mangleA near-catch-all lan_ac_traffic RETURN appears
Save the output and return to the UI to remove the corresponding empty entry; do not depend directly on the temporary handle.
Only a RETURN with explicit source or destination conditions appears
It is not a catch-all rule generated by an empty entry; verify the policy's real purpose first.
There is no lan_ac_traffic rule
Stop this procedure and investigate OpenClash interception, rule matching, the node, or DNS.
The device has no nft command, or the chain name differs
Do not guess chain names or delete rules. Save the version and firewall details, then troubleshoot using the firmware documentation.
- Telegram initiates a connectionThe endpoint request should enter the OpenClash transparent proxy
- Empty lan_ac_traffic entryNo source, destination, port, or interface conditions
- Catch-all RETURN ruleReturns early before redirect or TPROXY
- Direct WAN egressTraffic bypasses Mihomo, and the Dashboard has no record
After deleting the empty entry and restarting OpenClash, the new firewall rules should no longer contain this catch-all RETURN. Telegram connections should enter Mihomo and appear in the Dashboard.
Delete the empty entry and restart OpenClash
The OpenClash maintainer's guidance for this issue is to remove the Source Traffic Access Control. Regular users should first delete the confirmed empty entry in LuCI, save and apply the change, then restart OpenClash so the nftables rules regenerate.
If the UI cannot delete it temporarily, the reporter confirmed that disabling the section also restores service. The index below applies only when uci show clearly identifies the empty entry as item 0 on that device. If the index differs, use the actual value.
Apply the narrowest change
Confirm again that the entry is empty
Verify that it has no source, destination, port, or interface condition and that no real workflow depends on it for direct routing.
Delete it in LuCI whenever possible
Delete the empty entry, save and apply, and leave all other access-control and routing options unchanged.
Restart OpenClash
Wait for configuration validation, the core, and firewall rules to reload completely; do not merely refresh the Dashboard.
Read nftables again
Confirm that the original catch-all lan_ac_traffic RETURN is gone before testing Telegram.
uci set openclash.@lan_ac_traffic[0].enabled='0'
uci commit openclash
/etc/init.d/openclash restartVerify that Telegram now enters Mihomo
Open Telegram again on the same test device while watching the OpenClash Dashboard. Connections should begin appearing in the list with their matched rule, policy group, and actual egress. Seeing the app recover alone does not prove that it is no longer connecting directly.
Then check the WAN path and ordinary webpages. Telegram should no longer bypass interception, existing webpages should still work, and explicit direct-routing policies required by other devices should remain. If the fix lasts only briefly after a restart, check whether configuration sync recreated the empty entry.
Completion criteria
- No unconditional lan_ac_traffic RETURN appears after restarting
- The Telegram desktop or mobile app completes one real connection
- The Dashboard shows the corresponding connection, rule, policy group, and egress
- The WAN side no longer shows this traffic bypassing Mihomo for direct egress
- Ordinary webpages, DNS, and other endpoints still work as intended
Where to look when validation fails
| Failure | Description | Diagnostic direction |
|---|---|---|
| Telegram still has no Dashboard record | Traffic is still bypassed before interception | Check other RETURN rules, device access controls, and the transparent-proxy entry point |
| A record appears, but the connection fails | Interception has recovered | Check the node, rules, UDP, and destination network |
| The entry reappears after a restart | A configuration source is still writing it | Check backup restoration, sync scripts, or stale UI state |
| Existing direct routes for other devices stop working | A valid policy was deleted | Restore the backup and recreate the entry with explicit conditions |
Roll back and change the diagnostic path if the evidence does not match
If deleting the entry breaks a device's existing direct route, immediately restore the settings backup, restart OpenClash, and express the required source, destination, or port as explicit conditions. Do not replace several explainable access controls with one unconditional return entry.
If there is no empty entry, no catch-all RETURN, or Telegram already appears in the Dashboard, this root cause is ruled out. Use connection records to move on to rules, nodes, UDP, DNS, or the app's own network behavior; stop changing nftables.
This issue was still open at publication, and there was no official stable-release boundary containing a fix. This article therefore follows the maintainer's recommendation to remove the empty configuration and does not claim that upgrading to a particular version fixes it automatically.
Confirm again after rolling back
- The router's LAN management path and ordinary network access have recovered
- Valid source access controls have been rebuilt with explicit conditions
- Configuration validation and firewall loading succeed after OpenClash restarts
- The next diagnostic direction is determined by Dashboard and log evidence