On this page
When web pages use the proxy but a chat app cannot connect, a missing domain rule is not necessarily the cause. If the connection is absent from the dashboard, check whether the traffic reaches the proxy before changing nodes. An empty access-control entry can cause traffic to bypass proxy handling; handle that entry only when both the configuration and runtime rules match this case.
Webpages use the proxy, but Telegram connects directly
Keep the same device and network, and inspect Dashboard and router WAN (external-network) records while Telegram retries its connection. Check the empty access control described below if web traffic uses OpenClash but Telegram has no matching record and goes out directly. The app failing to connect alone does not establish the cause.
Official issue #5283 records this behavior on ImmortalWrt 25.12.1 with fw4/nftables. In that report, an empty lan_ac_traffic entry generated a RETURN rule (an early return), causing most TCP and UDP traffic to return before reaching 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.
Connection records show where traffic stops
| 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
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.
Keep the settings and management access needed for recovery
Export the current settings
Export the OpenClash settings and current configuration, save them outside the router, and record the operating mode and plugin and core versions. This lets you restore valid access controls if you delete them by mistake. Keep a separate LAN management entry point when working remotely.
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 OpenClash source traffic access control page. Look for enabled entries whose action is return or bypass proxy but which have no matching conditions, such as a source address, destination address, port, or interface. The rule checks below apply to these empty entries.
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
Check for a RETURN rule covering almost all traffic
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.
Run the following nft commands in the router terminal to inspect the fw4 OpenClash chains without changing them. Look for a RETURN rule marked lan_ac_traffic that covers almost all TCP or UDP traffic. Its handle is the runtime rule identifier and may change when regenerated; do not copy 803 or 805 from the issue to delete rules.
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
- A RETURN rule covering almost all trafficReturns 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 overly broad RETURN. Telegram connections should enter Mihomo and appear in Dashboard.
Delete the empty entry and restart OpenClash
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 |
What should you do if there is no empty entry or a valid rule was removed by mistake?
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 are no empty entries or blanket RETURN rules, or Telegram already appears in Dashboard, an early return caused by an empty entry has been ruled out. Use the connection records to investigate rules, nodes, UDP, DNS, or the application's own network behavior; stop changing nftables.
The issue remained open at publication, and the official records did not identify a stable release containing a fix. Removing the empty configuration is the maintainer's suggested remedy; do not claim that upgrading to a particular version will fix 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