OpenClash on OpenWrt: a Mihomo client inside LuCI

What OpenClash adds to an OpenWrt router

OpenClash is a LuCI application, not a standalone proxy. It packages the Mihomo core, previously known as Clash, and gives it a web interface inside the router's existing LuCI admin panel. The README describes it as a Mihomo (Clash) client that runs on OpenWrt and supports Shadowsocks, ShadowsocksR, Vmess, Trojan and Snell, with policy proxying driven by rule configuration.

The audience is narrow and specific: people who already run OpenWrt on a router and want proxy routing applied at the network gateway rather than on each device. Because the rules live on the router, a phone, a laptop and a television all inherit the same policy without installing anything. That is the actual value proposition, and it is also the source of most of the operational difficulty, since a mistake in the rule set affects every device at once.

How the LuCI app, the Mihomo core and the firewall fit together

The repository is a LuCI package, not a fork of the proxy core. The top level holds luci-app-openclash, the img directory, the announcement file and the licence. The README credits the Mihomo core to MetaCubeX, notes that the project's code is based on Luci For Clash by frainzy1477, and lists third-party components for IP checking, the zashboard and yacd control panels, and the RegionRestrictionCheck streaming test.

Traffic interception is where the dependencies become the architecture. The dependency list includes ipset and ip-full, iptables plus kmod-ipt-nat, iptables-mod-tproxy and iptables-mod-extra for the iptables path, and kmod-nft-tproxy for firewall4. dnsmasq-full is required, which means the stock dnsmasq package has to be replaced. TUN mode needs kmod-tun, and PROCESS-NAME rules need kmod-inet-diag. In other words, OpenClash is a set of firewall and DNS integration points around a core binary, and the package manager will pull all of them in whether or not you use every mode.

Installing OpenClash from an IPK or APK

The README does not give a step-by-step installation procedure. It points to the releases page for IPK and APK files, and the rest of the document covers compiling from the OpenWrt SDK. If you are not building firmware, the release asset is the entry point, and the package manager on your router decides which format applies.

The README's build instructions show how the package is assembled. This snippet clones only the luci-app-openclash directory using a sparse checkout, which is a useful detail: the repository root is not the package, and the build expects the package folder to sit under package/ in the SDK tree.

mkdir package/luci-app-openclash
cd package/luci-app-openclash
git init
git remote add -f origin https://github.com/vernesong/OpenClash.git
git config core.sparsecheckout true
echo "luci-app-openclash" >> .git/info/sparse-checkout
git pull --depth 1 origin master

The rest of the documented build path involves two optional tool steps, po2lmo for translation compilation and a CodeMirror 6 bundle for the editor, followed by the package compile target. The README shows the compile command and states where the resulting IPK lands:

make package/luci-app-openclash/luci-app-openclash/compile V=99

The README says the IPK file appears at ./bin/ar71xx/packages/base/luci-app-openclash_*-beta_all.ipk in that example SDK. For firmware integrators, the README also notes that you can copy the luci-app-openclash folder into another OpenWrt project's Package directory and select it through make menuconfig under LuCI, Applications, luci-app-openclash. What the README does not document is the first-run configuration flow, so treat the user guide linked at the top of the README as the required next step rather than optional reading.

Where OpenClash is the wrong choice

The dependency list is the clearest limitation. OpenClash requires dnsmasq-full, bash, curl, ca-bundle, ipset, ip-full, ruby, ruby-yaml, unzip, and a set of kernel modules that differ between iptables and firewall4 systems. On a router with small flash, that footprint can be the deciding factor before any proxy configuration is written. Replacing dnsmasq with dnsmasq-full alone is a change to the DNS path of the whole router.

The second limitation is that the core is not in this repository. The README credits Mihomo to MetaCubeX, and the release notes do not describe how core updates are delivered. Whatever version of the core your router downloads is a moving part outside the LuCI package's version number, so an OpenClash release tag tells you about the interface, not about the proxy engine behind it.

The third is scope. OpenClash is a router-side integration. It is not a desktop client, not a mobile app, and not a way to proxy a single machine. If your router cannot run OpenWrt, or you only need one laptop covered, the whole firewall and DNS apparatus is overhead you will pay for and never use.

OpenClash compared with PassWall and with a plain Mihomo setup

The comparison people ask about most is OpenClash versus PassWall, and the difference is in what each one is built around. OpenClash wraps the Mihomo core and exposes Clash-style rule configuration, so its natural workflow is a subscription or config file plus rules evaluated by that core. PassWall is a separate LuCI package with its own proxy handling and its own interface; the two solve overlapping problems with different configuration models, and the choice usually comes down to which rule format you already maintain.

A second comparison is OpenClash versus running Mihomo directly. A plain core install gives you a binary and a config file with no LuCI layer, no dependency on dnsmasq-full, and no ipset or nftables integration. You would write your own firewall and DNS rules. OpenClash's contribution is exactly that integration plus a web interface, so if you are comfortable maintaining nftables and dnsmasq by hand, the package is convenience rather than capability.

Maintenance, licensing and what an upgrade touches

The repository is not archived, and the last push was on 2026-09-20, the day before this article's reference point. Releases are frequent: v0.47.156 on 2026-08-10, v0.47.133 on 2026-07-18 and v0.47.116 on 2026-07-07. That cadence means the interface changes often enough that pinned versions matter on a router you do not want to debug remotely.

Upgrade cost is not only the LuCI package. The README's build section shows the package bundles a CodeMirror 6 editor build and translation files, and the runtime pulls the Mihomo core separately. An upgrade can therefore move the interface, the editor bundle and the core on different schedules. The README does not document rollback, so before upgrading, keep the previous IPK or APK and a copy of your configuration.

On licensing, the project is MIT. The README separately credits the Mihomo core to MetaCubeX, the zashboard and yacd control panels to their authors, and the streaming check to lmc999. Those components may carry their own terms, so if you redistribute a firmware image with OpenClash included, check each credited project rather than assuming the MIT label covers everything in the image. This is a description of what the README states, not legal advice.

Editorial conclusion

Adopt OpenClash if you already run OpenWrt on a router with enough flash for the package plus its dependencies, and you want proxy rules applied at the gateway so every device behind the router is covered without per-device configuration. Do not adopt it if you need a desktop or mobile client, or if your router has tight flash and RAM, because the dependency list is long and the Mihomo core is a separate download. Before committing, verify that your firmware uses firewall4 and therefore needs kmod-nft-tproxy, that dnsmasq-full can replace dnsmasq, and which release asset matches your package manager, IPK or APK.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. vernesong/OpenClash on GitHub