OpenClash v0.47.156 makes an OpenWrt router the Mihomo gateway
OpenClash v0.47.156 is a LuCI control layer for running Mihomo on OpenWrt. It takes a proxy subscription or YAML configuration, changes the effective Mihomo settings, starts the core, and installs the DNS plus firewall rules that steer router and client traffic. The web interface covers proxy modes, device access controls, rule updates, dashboards, and core updates. Its job is network-wide routing, so mistakes affect more than one browser or workstation.
Protocol support in the README includes Shadowsocks, ShadowsocksR, VMess, Trojan, and Snell. Mihomo does the proxy work; OpenClash manages it and connects it to OpenWrt. The distinction matters when reporting bugs because the core, dashboard, subscription converter, and plugin are separate projects. OpenClash is attractive when one router should enforce policy for many devices. A laptop-only user gets less value and accepts much more network complexity.
What happened when we ran it
Our sandbox entered luci-app-openclash/tools/codemirror and installed 69 npm packages in 57 seconds, consuming 50 MB. npm audit found 0 known vulnerabilities. The subproject had no build script or target and no test script or target, so both steps were skipped. This measured the bundled editor toolchain at commit c3a33c1. It did not boot OpenWrt or send traffic through Mihomo.
The full checkout measured 23.2 MB, with 224 files and about 16,542 lines of source. We found 9 CI workflow files, no Dockerfile, and no tests directory. Those signals fit a router package made from LuCI pages and system scripts, but they leave no general sandbox test result for DNS interception, firewall rollback, subscription parsing, or reboot. A buyer should not read the clean npm audit as a health certificate for the router application.
Twenty documented dependencies stand before first routed traffic
The README lists 20 required or mode-specific packages, including LuCI, dnsmasq-full, Bash, curl, CA certificates, Ruby, Ruby YAML support, ip-full, unzip, and several firewall or kernel modules. OpenWrt's smaller dnsmasq build is insufficient for the documented DNS and IP-set behavior. TUN mode needs kmod-tun, while firewall4 uses kmod-nft-tproxy; older firewall3 paths need the matching iptables pieces.
Installation also branches by package system and firewall generation. Release v0.47.156 gives separate commands for IPK and APK packages, then separate dependency sets for iptables and nftables. After installation, the operator must confirm the Mihomo core build and place or download the clash_meta binary. A working proxy subscription or YAML file is still required. OpenClash does not provide proxy endpoints, accounts, or a safe policy for your particular network.
Six routing modes change the DNS and firewall data path
The user guide documents 6 combinations across redir-host, fake-IP, TUN, and mixed modes. Non-TUN modes use TCP redirect plus UDP TPROXY, full TUN modes send both through a tunnel, and mixed modes divide TCP and UDP. DNS can pass through dnsmasq before Mihomo or be redirected to the core directly. These are material changes to name resolution, connection tracking, and policy routing, not cosmetic toggles in LuCI.
OpenClash stores its own UCI settings, rewrites generated YAML, installs firewall chains, and starts scheduled updates plus a watchdog. Stopping the service is expected to restore firewall and dnsmasq state. That moving sequence is why the guide tells users to generate a debug log before diagnosing failures. Anyone deploying remotely should keep an out-of-band recovery path and a saved router configuration before changing the 6-mode routing setup.
Chinese documentation leaves English operators translating incidents
The repository tree at commit c3a33c1 contains one README and one large user guide, both written in Chinese. The guide is technically detailed, covering dependencies, startup order, UCI keys, generated YAML, firewall chains, DNS modes, diagnostics, and LuCI navigation. It is useful material for a Chinese reader. There is no official English README or English user guide in that tree, so an English-only administrator will translate both setup steps and failure messages.
That language gap matters more here than in a simple command-line utility. Release notes tell users that reported connection trouble often involves IPv6, browser secure DNS, modified host files, or stale dashboard assets. Each warning changes how traffic leaves an entire LAN. Machine translation can help with discovery, but incident response needs exact interpretation of a 3-way interaction among OpenWrt, OpenClash, and Mihomo. Teams should assign an operator who can read the source material confidently.
Three current issues show where router topology matters
Issue 5317 reports missing UDP return traffic with v0.47.156 in redir-host mode on OpenWrt 25.12.5, plus a watchdog check firing before one route table was ready. The reporter found the same traffic worked after switching to a mixed mode, but that single environment does not prove a general fix. Issue 5313 describes stalled SSH to a proxy-node IP through a single-arm nftables side router, tied to asymmetric routing and rule order.
Issue 5286 reports that v0.47.156 did not start automatically after reboot on an ARM64 OpenWrt snapshot and needed a manual restart. GitHub listed 74 combined issues and pull requests, while the last push was September 7, 2026, and pull request 5318 arrived September 8. That is active maintenance around an active problem queue. OpenClash is worth considering for an experienced OpenWrt operator, but the router topology and chosen mode need their own acceptance test.