Mihomo Router Setup: Main Router, Side Router, and Standalone Core Compared

Separate Network Position from Runtime Model

Mihomo is the proxy core that evolved from Clash Meta. When deploying it on a router, the most common source of confusion is not configuration syntax but two separate dimensions: where the device sits on the network and how the core is started and maintained. Main router and side router describe network topology; a standalone core, router plugin, or container describes the software runtime model. These choices are not mutually exclusive—for example, a side router can also run the core directly.

Before deployment, sketch the shortest data path: which default gateway receives packets from clients, where DNS queries go, which device feeds traffic into Mihomo, and which egress path carries proxied traffic back out. If these four points are unclear, issues such as unreachable websites, inefficient routing to local services, devices bypassing the proxy, or IPv6 leaks become difficult to attribute to rules, DNS, or routing.

Main Router Deployment: The Most Direct Path, the Largest Blast Radius

A main router deployment places Mihomo at the default egress point for the entire network. Clients usually receive their IP address, default gateway, and DNS server from this device, allowing a single policy to cover them without per-device configuration. TProxy, redirect rules, or a TUN interface can provide the transparent proxy entry point. The right choice depends on the OS kernel, plugin implementation, and whether UDP must be handled.

The main advantage is a clear path: LAN clients first reach the main router, where rules decide whether to connect directly, use a proxy, or block the request. DNS is also easier to centralize. Devices can be grouped by source IP, MAC-based static leases, VLAN, or subnet. For home networks that need consistent, long-term management of TVs, phones, computers, and game consoles, a main router is usually easier to keep consistent than installing a client on every device.

The trade-off is a larger blast radius. An incorrect firewall rule, invalid configuration, or DNS loop can disrupt the entire LAN. Core upgrades must account for the device architecture, executable permissions, configuration compatibility, and service restart order. On resource-constrained routers, encrypted connections, rule matching, DNS caching, and log writes all consume CPU and memory, so advertised port speed alone does not indicate real proxy throughput.

When a Main Router Setup Makes Sense

1. You can maintain the router OS and have both a local management path and a configuration rollback method.
2. A Mihomo build is available for the device's CPU architecture, with enough storage for the core, rule sets, and logs.
3. Most clients should use the same routing policy by default, rather than limiting proxy use to a few devices.
4. You can schedule maintenance windows and accept brief connection interruptions while the proxy service restarts.

Side Router Deployment: Easier Testing, More Traffic Steering

A side router usually sits on the same LAN as the main router. The main router continues to handle the WAN connection, NAT, and Wi-Fi access, while the side router provides proxying and DNS for selected clients. This model supports gradual rollout: start with one test computer, validate rules, subscriptions, and DNS, then expand to fixed devices or a dedicated subnet.

Connecting a side router to a switch does not automatically send all network traffic through it. The simplest approach is to set the side router as the default gateway and DNS server on each client. Alternatively, DHCP can issue a different gateway to selected devices, or policy routing on the main router can direct specified source addresses to the side router. The available method depends on whether the main router supports static leases, per-device DHCP options, and policy routing.

A single-arm side router uses one LAN interface: packets enter through that interface and leave through the same interface toward the main router after processing. The return path therefore requires close attention. If outbound packets pass through the side router but responses return directly from the main router to the client, the route becomes asymmetric. Basic connections may still work, but connection tracking, transparent proxying, or strict stateful firewalls can behave unexpectedly. In practice, correct gateway planning, policy routing, or source NAT where necessary keeps both directions on a consistent path.

Common Side Router Connection Methods

Disabling DHCP on a side router is not a universal rule. If the main router assigns addresses for the entire LAN, the side router usually should not run another DHCP server on the same subnet. If the side router manages a separate subnet, it can provide DHCP for that subnet. The goal is one clear, controlled address-assignment plan per broadcast domain—not blindly enabling or disabling a service.

Standalone Core: Fine-Grained Control, Manual System Integration

A standalone core deployment means downloading the Mihomo executable for the correct CPU architecture, preparing a YAML configuration, and starting it with the system service manager. It avoids configuration constraints imposed by graphical plugins and suits users who need custom rule providers, listening ports, experimental features, or automated release workflows. However, the core provides only its own proxy functions; it does not automatically perform every router integration task.

A working standalone deployment includes at least five parts: the configuration and external rule resources, persistent storage, a startup service, permissions required for transparent proxying or TUN, and DNS and firewall integration. Plan updates and rollback as well—for example, validate the configuration before an update, retain the previous binary, and restore the old service if the new process fails to start.

mode: rule
allow-lan: true
bind-address: "*"
mixed-port: 7890
tproxy-port: 7893

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  nameserver:
    - 223.5.5.5
  proxy-server-nameserver:
    - 1.1.1.1

The snippet above only illustrates listening relationships; it is not a complete router-ready configuration. Proxy nodes, policy groups, rules, rule sets, and firewall traffic steering still need to be defined separately. DNS upstreams should also match the network environment and routing goals. If DNS listens on port 1053, the system DNS forwarder must send queries to that port, or clients must be explicitly configured to use it. Adding the listener to the configuration does not automatically take over port 53 for the LAN.

Startup Order for a Standalone Service

1. Confirm that network interfaces, time synchronization, and the configuration directory are ready.
2. Validate the configuration syntax and access to external resources to prevent a restart loop.
3. Start Mihomo and confirm that the proxy ports, DNS port, and control interface are listening as expected.
4. Then load the transparent proxy and policy-routing rules so traffic is not sent to ports that are not yet listening.
5. When stopping the service, remove traffic-steering rules before terminating the core to minimize blackholed LAN connections.

Plan DNS, Transparent Proxying, and IPv6 Together

In router deployments, many issues that look like unstable proxy nodes actually originate in the DNS path. Clients may send DNS queries to the main router, which then forwards them to Mihomo, or they may query a side router directly. Verify that the query path cannot form a loop where the system DNS forwards to Mihomo and Mihomo sends the same upstream request back to the system DNS.

Mihomo's fake-ip mode returns mapped addresses from a reserved pool, then restores the domain name when the subsequent connection enters the core. This helps apply domain-based rules. Some LAN devices, local domain names, time-sync services, or applications that require real address responses may need to be added to fake-ip-filter. redir-host mode returns actual DNS results more directly, but domain detection and caching behavior must be validated for the relevant protocols. Neither mode is universally better; after choosing one, use logs to confirm that domain rules are matching as intended.

Resolving proxy server hostnames is a separate stage. A node's hostname must resolve before a connection can be established, so these queries need a reachable resolver. The proxy-server-nameserver setting in Mihomo can resolve proxy server hostnames and reduce dependence on the proxy path during startup. Rule providers and subscription URLs create similar dependencies: if downloading the configuration requires the proxy, but the proxy depends on a configuration that has not yet been downloaded, startup reaches a circular dependency.

Choosing a Transparent Proxy Entry Point

• Explicit proxy ports: Clients are configured with an HTTP or SOCKS proxy. The path is easy to verify, but applications without proxy settings are not covered.
• TProxy: Common in Linux routing environments, it preserves original destination information and supports TCP and UDP, but requires policy routing, kernel modules, and firewall rules.
• TUN mode: A virtual network interface receives traffic, providing a relatively consistent setup model. Check device permissions, routing tables, DNS hijacking, and conflicts with existing VPNs.
• Redirect: A mature method commonly used to steer TCP traffic, although UDP and original-destination handling depend on the operating system and implementation.

IPv6 cannot be managed with a single switch in the Mihomo configuration. As long as the LAN advertises an IPv6 default route and DNS servers, clients may prefer direct IPv6 connections and bypass transparent proxy rules that only handle IPv4. To proxy IPv6, verify the upstream prefix, router advertisements, firewall, TUN or TProxy support, and rule coverage together. If IPv6 will not be handled yet, explicitly disable the relevant advertisements or define a deliberate direct-connection policy instead of allowing IPv4 and IPv6 to follow different, unobservable paths.

Choose by Scope, Maintenance Capacity, and Rollback Cost

Do not start by asking which option is fastest. First determine how many devices must be covered, whether the main router can be modified, and who still needs internet access during an outage. For one TV or test computer, a side router with a targeted gateway is usually enough. For consistent whole-home rules and administrators comfortable maintaining the router, a main router is simpler. When precise control over configuration generation, service orchestration, and firewall details is required, run the core directly on either topology.

Pre-deployment Checklist

• Record the IP addresses of the main router, side router, clients, and DNS services to prevent address conflicts.
• Confirm the device's CPU architecture, available memory, storage capacity, and firewall framework used by the operating system.
• Decide which entry point will handle TCP, UDP, IPv4, and IPv6.
• Create bypass rules for LAN subnets, management addresses, and essential services that should not enter the proxy.
• Assign a static address to each test client so its connections are easy to identify in logs.
• Document how to restore normal internet access after stopping the proxy, and test the procedure before full deployment.

Layer-by-Layer Validation After Deployment

1. Basic connectivity: With transparent proxying disabled, verify that clients can reach the LAN and internet through the original egress path.
2. DNS: Check the DNS server actually used by each client, query responses, and Mihomo DNS logs to rule out loops and timeouts.
3. Traffic entry: Confirm that target connections appear in Mihomo logs with the source address, destination address, and matched rule.
4. Policy results: Test domains that should connect directly, use the proxy, or be blocked instead of relying on a single speed-test site.
5. UDP and IPv6: Test real-time communication, games, and other UDP workloads separately, then verify that IPv6 follows the intended path.
6. Failure rollback: Stop Mihomo or load an invalid configuration, then verify that the management interface remains reachable and the network recovers as planned.

Deploying Mihomo on a router is fundamentally an experiment in network paths. A main router provides a unified entry point, a side router limits the scope, and a standalone core gives direct control over configuration and system integration. Start with one fixed client and build the smallest observable, reversible path. Then add DNS interception, UDP, IPv6, and more devices in stages; this usually makes troubleshooting easier than moving the entire network at once.