Run the Clash Core on an OpenWrt Bypass Router: Transparent Proxy Setup and Gateway DNS

Deployment Basics: Running the Core Does Not Enable Transparent Proxying

Running a Clash-compatible core directly on OpenWrt involves three separate pieces: the process, the traffic path, and DNS. A successful startup only confirms that the configuration loaded. Client traffic must also pass through the bypass router and be directed by the firewall to a transparent proxy port. This guide uses mihomo to explain how the three pieces fit together.

• Process: Use a binary built for the device architecture, store the configuration at /etc/mihomo/config.yaml, and let OpenWrt's procd manage the service.
• Forwarding: Set client devices' default gateway to the bypass router, which must then be able to forward direct traffic to the main router.
• Interception: Use firewall rules to select the connections to proxy, and define a clear local DNS resolution path.

If a proxy management plugin is already installed, check whether it starts the core, generates its configuration, or manages firewall rules. Starting a second interception setup manually on the same router can cause port conflicts, duplicate redirects, or overwritten settings. Choose one control path: run the core directly or use the management plugin.

Gateway Topology: Route One Device Through the Bypass Router

These example addresses illustrate a single-NIC bypass router on the same subnet. Substitute your actual network details. The main router continues to provide internet access and DHCP; assign the bypass router a static address, then change the gateway and DNS on one test computer only.

Check OpenWrt Interfaces and Forwarding

In LuCI, go to Network → Interfaces → LAN → Edit and check the static address. Labels may vary slightly by theme; look for the interface, IPv4 address, and gateway fields. Don't enter the main router's address as the bypass router's own default gateway.

ip -4 addr show
ip -4 route show
sysctl net.ipv4.ip_forward
ping -c 3 192.168.10.1

The routing table should have a default route via 192.168.10.1, and IP forwarding should be enabled with 1. Also check that the firewall allows forwarding between the relevant interfaces. With a single-NIC bypass router, traffic may enter and leave through the same LAN interface, so don't blindly copy LAN-to-WAN rules designed for a two-NIC setup.

Same-subnet forwarding also depends on the return path: a direct connection may leave through the bypass router but return from the main router straight to the computer. Asymmetric routing, ICMP Redirects, and connection-tracking behavior can all affect the result. Source NAT can send return traffic back through the bypass router in some topologies, but it hides the original client address. Decide whether to use it based on your routing and firewall setup; don't treat it as a universal setting.

Core Binary: Check the Architecture, Configuration Path, and Startup Options

Check the hardware architecture with uname -m, then inspect system details with ubus call system board. Similar architecture names don't guarantee binary compatibility; also check CPU instruction-set requirements and the release's runtime requirements. Don't try to run a desktop client installer as a router core.

uname -m
ubus call system board
df -h /overlay
free -m

Make sure the device has enough persistent storage and RAM. Rule sets, geolocation databases, and the number of connections all affect resource usage, so there's no single memory requirement for every configuration. Don't keep your only configuration copy in /tmp, which may be cleared on reboot.

The commands below assume you've obtained a mihomo binary for your device, saved it as /usr/bin/mihomo, and placed the complete YAML configuration in the specified directory. Test the configuration before starting the service:

mkdir -p /etc/mihomo
chmod 0755 /usr/bin/mihomo
chmod 0600 /etc/mihomo/config.yaml
/usr/bin/mihomo -v
/usr/bin/mihomo -t -d /etc/mihomo -f /etc/mihomo/config.yaml

Use -v to record the core version actually in use, and -t to validate the configuration. If the logs report missing rule files or databases, or failed downloads, provide the required resources first. A passing configuration test doesn't confirm that remote nodes are reachable or that firewall interception is working.

Redir, TProxy, and TUN: Choose the Right Traffic Entry Point

This guide focuses on Redir and TProxy. Redir's TCP entry point can't replace general UDP interception: with Redir alone, UDP traffic from QUIC, games, or voice apps won't automatically use the proxy. TProxy can intercept UDP, but the selected node protocol and server must also support forwarding it.

mihomo Port Configuration Example

Merge this snippet into an existing configuration; it isn't a standalone proxy setup or subscription. Keep your existing nodes, proxy groups, and rules, and avoid defining the same top-level YAML key twice. Both transparent proxy listeners can run at once, but each flow should follow one clearly defined firewall path.

mode: rule
log-level: info
redir-port: 7892
tproxy-port: 7893

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: redir-host
  nameserver:
    - 223.5.5.5

This example uses redir-host as an easy-to-observe starting point, with DNS returning real IP addresses. 223.5.5.5 is an example upstream resolver; choose one based on connectivity and DNS requirements in your location, and verify that it can be reached directly. Add the DNS policies required for domain-based routing, node hostname resolution, and encrypted DNS separately, once the basic path is stable.

If you switch to fake-ip, make sure connections from clients to the synthetic address range reach the core, and configure filters as needed for app compatibility. Don't change the DNS mode while allowing synthetic-address traffic to bypass the router.

Firewall Interception: Know Whether You're Using firewall4 or the Legacy Ruleset

First, run the read-only command below to identify the firewall tools on your device. OpenWrt 22.03 and later use firewall4 and nftables by default, but firmware may vary or be modified; check the results on your own device.

command -v fw4
command -v nft
command -v iptables
nft list ruleset
ip -4 rule show
ip -4 route show table all

Don't paste an iptables interception script from the web into a firewall4 configuration. Even if compatibility commands are available, verify which ruleset receives the rules and whether they survive a firewall reload. TProxy also requires the right kernel modules and userspace expression support; opening a listening port isn't enough.

Interception Rules Must Cover at Least Four Things

1. Limit the source: Start by matching only the test computer, 192.168.10.100. Don't intercept the entire LAN right away, and never match arbitrary traffic coming from WAN.
2. Exclude before intercepting: Preserve access to local management addresses, LAN destinations, and necessary broadcast and multicast traffic. Define IPv4 and IPv6 exclusions separately.
3. Match the entry point: Send TCP Redir traffic to 7892 and TProxy traffic to 7893. For TProxy, also configure policy routing to match the traffic mark and deliver marked traffic locally.
4. Prevent loops: Outbound connections from the core to nodes, DNS servers, and direct destinations must not re-enter the same interception rules. Design interception of router-originated OUTPUT traffic separately.

A common TProxy setup combines fwmark, ip rule, and a local route in a routing table. Choose the mark value, mask, rule priority, and table ID to avoid conflicts with existing VPNs and policy-routing plugins. No fixed IDs are safe on every device, so this guide doesn't provide a complete ruleset to apply over a live network.

Disable relevant flow-offloading options during initial testing, then monitor the counters. Hardware or software offloading can change the path taken by subsequent packets; a successful first connection doesn't prove that all traffic is being intercepted correctly.

DNS Interception: Forward dnsmasq Port 53 to the Core on Port 1053

It's best to keep dnsmasq listening on port 53 for the LAN and have mihomo listen only on the loopback address 127.0.0.1:1053. This avoids a bind conflict between the two processes and keeps the core's DNS port off the LAN.

1. Go to Network → DHCP/DNS and find the DNS forwarding settings. Add 127.0.0.1#1053. This is dnsmasq's server-and-port syntax, not YAML syntax.
2. Check for other forwarding servers and where resolv files are sourced from. If queries must go through mihomo only, disable any path that reads additional servers from an upstream resolv file, so requests don't bypass the local forwarder.
3. Make sure mihomo's upstream isn't the bypass router's own port 53, or DNS will loop: “dnsmasq → mihomo → dnsmasq.”
4. After reloading the services, run nslookup example.com 192.168.10.2 on the test computer and check the core logs and DNS listener status.

Enter only 192.168.10.2 in the computer's DNS field, not 192.168.10.2:1053. Standard system DNS settings generally don't support specifying a port this way. DHCP's DNS option also distributes server addresses only.

If dnsmasq and the core both cache DNS responses, account for stale records after configuration changes. First test with an explicitly specified server, then flush the client cache. Don't mistake a cache hit for proof that the new resolution path is working.

Start on Boot with procd: Manage the Process Before Adding Interception Rules

You can manage a directly run core with OpenWrt's procd. Save the following as /etc/init.d/mihomo. This is a minimal process service example; it doesn't install firewall rules or change client gateways automatically.

#!/bin/sh /etc/rc.common

USE_PROCD=1
START=99
STOP=10

start_service() {
    procd_open_instance
    procd_set_param command /usr/bin/mihomo \
        -d /etc/mihomo \
        -f /etc/mihomo/config.yaml
    procd_set_param respawn 3600 5 5
    procd_set_param stdout 1
    procd_set_param stderr 1
    procd_close_instance
}

chmod 0755 /etc/init.d/mihomo
/etc/init.d/mihomo enable
/etc/init.d/mihomo start
logread -e mihomo
netstat -lnptu

Check the listener list for 7892, 7893, and 127.0.0.1:1053. Available commands depend on the tools included in your firmware. If netstat doesn't support the required options, use the installed ss -lnptu instead. Don't expose the management API on a public-facing interface.

The example service starts with the system's default permissions. Transparent proxying and routing require privileges, so only administrators should be able to modify the configuration and service script. Persist firewall rules using a mechanism compatible with the active firewall system, and define how interception is removed when the service stops. Otherwise, clients may still be routed to an unbound port after the core exits.

Verification Order: Check Routing, DNS, Interception, and Remote Connections in Stages

1. Test basic routing first: Before enabling transparent interception, confirm that the test computer can access the internet with the bypass router as its gateway. If it can't, fix forwarding and the return path first.
2. Then test DNS: Query 192.168.10.2 explicitly. If it times out, check dnsmasq, the listener on port 1053, and DNS loops. Getting an IP address doesn't guarantee that the site at that address is reachable.
3. Then test TCP interception: Visit an HTTPS site from the test computer. Check the relevant firewall counters and mihomo connection logs to confirm the source address, matched rule, and final policy.
4. Test UDP separately: Use an app that actually requires UDP and check TProxy counters and connection logs. A working website doesn't prove that UDP proxying works.
5. Check both IP versions: Test IPv4 and IPv6 separately. If IPv6 still exits directly through the main router, explicitly plan IPv6 interception, DNS distribution, and firewall rules; don't treat dual-stack behavior as an intermittent fault.
6. Finally, test reloads and reboots: Reload the firewall, restart the core, and reboot the device. Confirm that rules aren't duplicated, DNS recovers, and there's a clear fallback if the core stops.

Troubleshoot by Symptom Instead of Switching Nodes Repeatedly

• No internet after changing the gateway: Check IP forwarding, firewall forwarding, the main router's internet connection, and the return path first. Don't start by blaming the subscription.
• IP addresses work, but domains don't: Check the computer's actual DNS settings, dnsmasq's upstream, the core's DNS logs, and browser Secure DNS.
• Websites work, but some apps fail: Check UDP, IPv6, rule matches, and remote protocol support. Determine whether traffic wasn't intercepted or was intercepted but failed to connect.
• Only the router itself can't connect: Check OUTPUT rules and exemptions for core-originated traffic to prevent proxy connections from being intercepted again.
• It stops working after reboot: Check that the service is enabled, required files are stored in persistent locations, and the firewall reloads the relevant rules.

Before rolling this out across the network, record the test device's address, gateway, DNS, transparent proxy ports, matched policy, and reboot results. Once everything is stable, update DHCP; leases don't always renew immediately, and some devices need to reconnect. To roll back, first restore the main router as the client gateway and restore the original DNS settings. Then remove transparent interception and stop the core. This avoids leaving the network on an unusable forwarding path.