Running the Clash Core on a Router: Bypass Gateway Deployment and Hardware Requirements

Running the Clash or mihomo core on a router is not about moving a desktop client interface onto a network device. The goal is to let the router centrally handle rule matching, DNS processing, and traffic forwarding. TVs, game consoles, mobile devices, and other endpoints that cannot easily run a client can use the same rules through a gateway or policy-based routing. At the same time, the router becomes a critical point in the forwarding path. A configuration mistake can affect the entire LAN, so define the topology, rollback path, and device load before deployment.

Here, “running Clash on a router” mainly means running a Clash-compatible core on OpenWrt, a derivative system, or a general-purpose Linux gateway. mihomo is the most common implementation today. It retains the Clash configuration structure while adding capabilities such as TUN, rule providers, and traffic sniffing. Management plugins wrap configuration files, service scripts, and firewall rules, but the underlying process still has three essential parts: the core listens on ports, the system sends target traffic into the core, and the core selects a direct or proxy exit according to its rules.

Choosing Between a Main Router and Bypass Gateway

Run the Core Directly on the Main Router

The main-router setup runs the Clash core on the device that handles the broadband connection, DHCP, NAT, and Wi-Fi access. Endpoint traffic naturally passes through this device, giving it the shortest forwarding path and making centralized DNS interception relatively easy. For users with sufficient hardware, a maintainable system, and solid firewall knowledge, the layout is straightforward: the upstream interface connects to the ISP network, the downstream interface connects to the LAN, and the proxy only processes traffic redirected by the firewall.

The main drawback is the larger blast radius when something fails. A core that exhausts memory, a failed firewall-rule load, or a DNS port conflict can disrupt the broadband connection, LAN resolution, and management page at once. System upgrades may also change how nftables, iptables, or plugin-generated rules work. Main-router deployment is therefore better suited to environments with recovery access through a serial console, rescue mode, or backup device. It is not ideal for a first experiment on the only home internet gateway.

Use a Bypass Gateway as a Separate Router

A bypass-gateway setup keeps the existing main router responsible for the broadband connection and basic networking, while running the Clash core on a second device. The most common single-arm bypass gateway shares the same LAN as the main router—for example, the main router is 192.168.1.1 and the bypass gateway is 192.168.1.2. Endpoints that need proxy rules use 192.168.1.2 as their default gateway; after applying its policies, the bypass gateway forwards traffic to the main router.

This design makes phased migration easy. Start by changing the gateway and DNS on one test computer, verify rules, UDP, and domain resolution, then decide whether to distribute the bypass gateway to more devices through DHCP. If the bypass gateway goes offline, endpoints can switch their gateway back to the main router without changing the broadband configuration. The maintenance boundary is also clearer: the main router provides basic connectivity, while the bypass gateway handles transparent proxying and additional policies.

A single-arm bypass gateway does not mean entering only one gateway address. If the bypass gateway forwards packets without source NAT, return traffic may be sent directly from the main router to the client, creating an asymmetric path in which the outbound leg passes through the bypass gateway but the return leg does not. Whether this causes problems depends on the transparent-proxy method, connection tracking, and the main router’s routing table. Common fixes include applying suitable NAT on the bypass gateway’s exit, or adding an explicit route on the main router to the client subnet so both directions follow the intended path.

Dual-NIC Bypass Gateway

A device with two independent network ports can also operate as an inline gateway: one interface connects to the main router, and the other connects to a separate downstream switch or wireless access point. The bypass gateway creates an independent subnet for downstream devices and handles DHCP, forwarding, and proxy processing for that subnet. Compared with a single-arm design, the upstream and downstream boundaries are clearer, return traffic normally passes back through the bypass gateway, and applying policies to the entire subnet is easier.

The trade-off is an additional network layer. Port forwarding, LAN discovery, casting, and cross-subnet access require extra configuration; if both the main router and bypass gateway perform NAT, double NAT is introduced. When home devices rely on mDNS or broadcast discovery, assess whether a relay service is needed instead of blaming every cross-subnet issue on the Clash core.

CPU, Memory, and Storage Requirements

The Clash core’s actual hardware requirements depend on throughput, rule-set size, connection count, protocol encryption overhead, and whether TUN is enabled. The fact that the core starts successfully does not prove that a device is suitable. The router must also reserve resources for system services, DNS caching, firewall connection tracking, and the management interface. Once memory is exhausted, service restarts or an unresponsive system are often harder to diagnose than a simple speed reduction.

Processor Performance and Encryption Throughput

The CPU sets the ceiling for rule matching, encrypted transport, and user-space forwarding. Older single-core MIPS devices can handle lightweight rules and a small number of connections, but they quickly become bottlenecks with fast broadband, multiple endpoints, or complex protocols. Modern ARM64 or x86_64 platforms are generally better suited to running mihomo continuously. The core binary must match the system architecture; common identifiers include arm64, armv7, mipsle, and amd64. With the wrong architecture, the program will usually report that it cannot execute.

Hardware NAT or traffic offloading may bypass the firewall chains required by transparent proxying. If speeds become abnormal after enabling the proxy, first check compatibility between software offloading, hardware offloading, and the transparent-proxy plugin. Before trying to saturate the interface, test direct traffic, rule-based proxy traffic, and UDP from one wired endpoint, and watch whether a single CPU core remains near its limit.

Memory and Rule-Set Size

Devices with 64 MB of memory are generally limited to very lean systems and small configurations. Large domain rules, GeoIP data, a control panel, and multiple auxiliary services leave little headroom. 128 MB is a reasonable starting point for a basic deployment, but rule providers and concurrent services still need to be controlled. 256 MB or more is better suited to running mihomo alongside enhanced DNS mode, larger rule sets, and a web management interface. Increase the margin further when connection counts are high, rule providers update frequently, or traffic sniffing is enabled.

Swap can ease temporary memory pressure, but flash storage is slow and swap should not replace sufficient physical memory. If the core exits periodically, first check system logs for memory-reclaim activity or process termination, then consider reducing rules, disabling unused services, or moving to a device with more resources.

Storage Capacity and Write Strategy

The core itself, GeoIP data, rule sets, subscription caches, and logs all consume storage. When the router’s built-in flash is limited, place the data directory on expanded storage or an external disk, but ensure the mount point is ready before the service starts. Do not leave debug logging enabled permanently. Detailed logs are useful for short-term diagnosis, but continuous writes consume space and add wear to slow flash storage.

Transparent Proxying, TUN, and DNS Traffic Flow

One of the easiest things to confuse in a router deployment is “the core is running” with “LAN traffic is reaching the core.” mixed-port, an HTTP port, or a SOCKS port is only a listening entry point for endpoints configured with a proxy manually. To route devices without proxy settings automatically according to rules, you also need a capture method such as REDIRECT, TProxy, or TUN, along with the corresponding firewall and policy-routing configuration.

REDIRECT and TProxy

REDIRECT is commonly used to intercept TCP connections and is relatively straightforward to configure, but it has limitations with UDP and scenarios that must preserve the original destination address. TProxy can handle both TCP and UDP, using policy routing to send transparent traffic to the core’s listening port. It depends on firewall marks, policy-routing tables, and related kernel modules. If any link is missing, the result may be working TCP with UDP timeouts, or LAN traffic being redirected incorrectly.

Firewall rules should exclude local management addresses, private LAN ranges, multicast, broadcast, and connections originating from the proxy server itself. Otherwise, a proxy loop may form: outbound connections created by the core are captured by the transparent rules again, causing failures or high CPU usage. Plugins usually generate these exclusions, but custom scripts should still be checked item by item for target ranges, processes, and firewall marks.

TUN Mode

TUN mode receives IP traffic through a virtual network interface, providing a more unified approach for environments that must handle TCP, UDP, and complex applications together. mihomo’s TUN configuration can enable auto-route and interface detection, but router platforms already have WAN, LAN, policy routing, and firewall zones. Automatically generated routes may not match the existing topology. During deployment, verify the default route, TUN routing table, and LAN forwarding chain instead of checking only whether the configuration syntax is valid.

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

This configuration only indicates that TUN, auto-route, and DNS interception are intended to be enabled on the mihomo side. It does not mean that the router firewall already permits LAN traffic into TUN. Firmware, plugins, and network-management components handle interface names and rule chains differently. If a management plugin already generates the TUN configuration, declaring it again in the main configuration may cause settings to be overwritten or routes to be duplicated.

DNS Request Path

When rules depend on domain names, the DNS path must align with the proxy policy. A common approach is to have endpoints send DNS requests to the router, with dnsmasq or another local resolver forwarding them to mihomo’s DNS listening port. Another is to use the firewall to intercept LAN requests to port 53. The first design is easier to understand; the second can handle endpoints that manually specify public DNS servers, but encrypted DNS applications do not use ordinary port 53.

In fake-ip mode, domains resolve to reserved addresses, and the core restores the original domain from its mapping so domain rules can be applied. Some LAN services, gaming platforms, or applications that rely on the real address may need to be added to fake-ip-filter. redir-host mode is closer to traditional resolution, but differs in matching efficiency and certain connection flows. After switching modes, clear the endpoint DNS cache to prevent old results from affecting tests.

A DNS loop is a common bypass-gateway failure: mihomo sends queries to dnsmasq, while dnsmasq sends them back to mihomo. To identify a loop, inspect the listening ports and upstream addresses of both services and ensure the resolution chain has one clear direction. The bypass gateway’s own queries, LAN client queries, and proxy-node domain resolution should also be considered separately. Node domains must resolve before the proxy channel can be established.

Do Not Overlook IPv6

When only IPv4 is intercepted, IPv6-capable endpoints may obtain an IPv6 default route directly from the main router, bypassing the intended policy for some connections. You can configure IPv6 forwarding and rules fully, or temporarily avoid distributing IPv6 routes to test endpoints during the initial deployment. The final choice should match the needs of the home network. When investigating why the same website sometimes follows rules and sometimes connects directly, check A and AAAA records, IPv4 and IPv6 default routes, and the IPv6 switch in the core configuration separately.

Bypass Gateway Deployment Steps and Validation Order

1. Assign a fixed management address to the bypass gateway.

   Set a static address in the same subnet as the main router, outside the DHCP pool, and point the default gateway to the main router. First confirm that the bypass gateway itself can synchronize the time, resolve domains, and reach software repositories.

2. Install the Core and Management Components for the Correct Architecture.

   Confirm the CPU architecture, system libc environment, and available storage. Run the core directly first to check its version and configuration-loading result, then hand it over to the service script. This prevents binary compatibility issues from being mistaken for firewall failures.

3. Import the Configuration and Verify Egress.

   Check whether the proxy groups, rule providers, and node protocols generated by the subscription are supported by the current core. Test core egress first through an explicit HTTP or SOCKS proxy. Once that succeeds, configure transparent interception so node problems can be separated from routing problems.

4. Enable IP Forwarding and Transparent Proxying.

   Choose TProxy or TUN based on plugin support, and confirm that LAN-to-WAN forwarding, firewall zones, and policy routing are active. Do not enable multiple transparent-proxy scripts at the same time, as they may apply duplicate marks or redirects.

5. Migrate Only One Test Endpoint.

   Manually point the test endpoint’s gateway and DNS to the bypass gateway. Verify LAN access, direct sites, rule-based proxying, video, voice calls, and sleep/wake behavior in order. Change the DHCP settings only after stability is confirmed.

6. Create Exclusion and Grouping Policies.

   Add printers, NAS management addresses, the main router’s management page, and required LAN ranges to the direct or bypass list. Group TVs, game consoles, and guest devices by fixed addresses associated with their source IP or MAC address so it is clear which endpoints use the proxy.

7. Set Up Update and Recovery Procedures.

   Schedule subscription and rule-set updates outside periods of high device load, and retain the most recent working configuration. If the service fails to start, fall back to a basic configuration while the main router continues to provide DHCP and internet access.

When validating transparent proxying, do not simply open one webpage. A browser may use cached data, HTTP/3, or its own secure DNS, so the result says little about the complete path. A more reliable sequence is to check the endpoint’s address, gateway, and DNS; confirm that the bypass gateway receives the connection; verify rule matches and egress selection; and finally test UDP, IPv6, and LAN access.

ip address
ip route
ip rule
nft list ruleset
logread
ss -lntup

These commands are used to inspect interface addresses, routing tables, policy rules, firewall rules, system logs, and listening ports. On systems using iptables, inspect the corresponding rule tables instead. The goal is not to copy and run a large batch of commands, but to follow the data path: does the endpoint hand packets to the bypass gateway, does the firewall mark or redirect them, does the core receive them, and does egress go to the main router?

Common Failures and Maintenance Boundaries

The Bypass Gateway Can Reach the Internet, but Clients Cannot

First check that the client’s default gateway actually points to the bypass gateway and that IPv4 forwarding is enabled there. Then inspect the LAN forwarding zone, NAT, and return path. Successful access from the bypass gateway itself only proves that its OUTPUT traffic works; it does not prove that FORWARD traffic from the LAN is permitted.

Web Pages Work, but Games or Voice Apps Time Out

This usually requires checking UDP. A REDIRECT setup may handle only TCP, or the modules and policy routes required by TProxy may not be loaded. Check whether the rules send UDP into the core, and confirm that the selected node protocol and proxy server can carry the required UDP traffic. If only one game is affected, also check the NAT type, port mappings, and the game platform’s regional rules.

LAN Devices Become Unreachable After Enabling the Proxy

The transparent-proxy exclusions may be missing private addresses, multicast addresses, or local service ports. Ensure that common LAN ranges and the router’s management address use the local path. Cross-VLAN or cross-subnet access also requires checking firewall zones; do not simply mark every private address as permanently direct. If proxy resources are located on an internal subnet, create precise rules for the actual topology.

High CPU Usage with Low Throughput

First disable debug logging and watch single-core load, then compare the speed of direct traffic and proxied traffic. If direct traffic is also significantly slower, hardware offloading may have been disabled by transparent forwarding, or packets may be processed repeatedly in the firewall chain. If only proxy connections are slow, inspect the encryption protocol, node path, and MTU. An unsuitable MTU in a TUN setup can cause fragmentation, intermittent website stalls, or large-file connections to hang.

The Service Fails to Start After a Subscription Update

Common causes include configuration fields unsupported by the core version, failed rule-provider downloads, invalid YAML indentation, or changed permissions on the data directory. During maintenance, distinguish the raw subscription content, the runtime configuration generated by the plugin, and the configuration actually loaded by the core. A management plugin may merge templates, overwrite ports, or add DNS fields, so inspecting only the subscription file may not reveal the final error.

Deployment Takeaway: Define the Path Before Choosing Components

The difficult part of running the Clash core on a router is usually not starting the program, but ensuring that traffic enters, leaves, and returns as intended. The main-router setup has a simple path but concentrates maintenance risk. A single-arm bypass gateway works well for gradual testing but requires NAT and return-path handling. A dual-NIC gateway provides clear boundaries while adding the cost of an independent subnet and cross-subnet administration. Hardware selection should account for CPU architecture, single-core performance, memory headroom, rule-set size, and log storage together.

In a real deployment, verify the core and nodes with an explicit proxy first, then enable transparent forwarding. Start with one endpoint using the bypass gateway before changing DHCP. Confirm IPv4, TCP, and basic DNS before moving on to UDP, TUN, and IPv6. Layered validation along the data path separates subscription, core, firewall, DNS, and LAN-topology issues, and makes the impact of configuration changes easier to identify.