hq450/fancyss: a transparent proxy plugin for ASUS Merlin routers

What fancyss actually installs on your router

fancyss is not a proxy client you run on a laptop. It is a plugin that lives inside the firmware of an ASUS router, and it works by intercepting traffic at the router rather than at each device. The README describes it as a project providing tools to cross the GFW on asuswrt and asuswrt-merlin based routers, specifically those with a software center firmware at version 384 or above. That last clause matters more than anything else on the page. Without a software center, there is no place to install the plugin.

The intended user is someone who owns a supported ASUS router, has already replaced the stock firmware with a Merlin or official-mod build, and wants every device on the LAN to route through a proxy without configuring each one. Phones, consoles, smart TVs and guests inherit the routing decision from the router. That is the whole value proposition, and it is also the reason the project is tied so tightly to a hardware list.

fancyss covers seven platforms according to the README: arm, hnd, hnd_v8, qca, mtk, ipq32 and ipq64. The support table in the README lists specific models such as the RT-AC68U, RT-AC86U, RT-AX88U, GT-AX6000 and ZenWiFi Pro XT12, each mapped to a platform and a fancyss build name. If your router is not in that table, the project does not claim to support it.

Protocols, DNS splitting and the pieces that do the work

The plugin is a front end and a set of scripts around several proxy cores. The README lists support for SS, SSR, VMess, VLESS, Trojan, NaiveProxy, TUIC and Hysteria2, plus custom Xray or V2Ray JSON nodes. Those are not implemented by fancyss itself. The repository layout shows a binaries directory with its own Makefile target, and the top-level Makefile runs update_binaries before build, which means the proxy executables are pulled in as prebuilt artifacts rather than compiled from source during a normal build.

Node input has three paths: manual entry, URI import, and online subscription. Subscription handling includes filtering, QR code sharing and user-agent adaptation for the subscription endpoint. On the DNS side there are two separate schemes, chinadns-ng and smartdns, and the README says the plugin supports different splitting strategies plus a switch between dynamic resolution and pre-resolution.

Routing modes are the other half of the design. The README names gfwlist, mainland whitelist, game, global, mainland-return and Xray node-based splitting. Rules can be maintained online, node splitting rule sets can be synced, and geosite and geoip assets are packaged with the plugin. Transparent proxying covers TCP and UDP, with QUIC blocking, access control, and IPv6 handling for both proxying and DNS. There is single-node latency testing, batch web latency testing, a running-state probe, simple failover, and scheduled updates for subscriptions, rules and binaries.

Checking your model before you flash anything

The README gives no shell install procedure. Installation happens through the router's software center, and the project points readers to firmware downloads at fw.koolcenter.com and to per-model pages on koolcenter.com. Because the README does not document a command-line install, the honest first step is a lookup in the support table, not a command.

Start by identifying your platform from that table. The build name determines which package you need, and picking the wrong one is the most likely way to waste an evening. The README maps the RT-AC68U to armv7 and fancyss_arm, the RT-AX88U to armv8 and fancyss_hnd_v8, and the TUF-AX3000 to armv7 but fancyss_hnd. Architecture alone does not settle it; the firmware generation column does.

Once the correct package is installed through the software center, the plugin appears as a page in the router UI. From there you add a node by URI, by subscription URL, or manually, then choose a routing mode. The README does not show the exact UI labels for these steps, so the first real use is best done with the node URI in hand and the subscription filter left at its default until the connection works.

Where fancyss stops being the right tool

The hardware constraint is the obvious one, but it is worth being precise about it. fancyss requires a router on the support table running a firmware with a software center at version 384 or higher. A stock ASUS router out of the box does not qualify. Neither does a router from another vendor, and neither does an x86 box running a general-purpose Linux distribution, even though the README's topics list includes x64.

The second limitation is the update model. The README documents scheduled updates for subscriptions, rules and binaries, and the Makefile separates binary fetching from the build. That means the proxy cores inside the plugin are prebuilt artifacts shipped by the project. You are trusting the project's binary pipeline, and you are dependent on it continuing to publish builds for your platform. There are no releases recorded for this repository, so the plugin's distribution channel is the firmware ecosystem rather than a tagged release page.

The third is that fancyss is a transparent proxy at the network edge. Every device behind the router is affected by the routing mode you pick. If you want per-application control, split tunneling by process, or a proxy that follows you onto mobile networks, a client-side tool is a better fit. fancyss decides for the whole LAN.

Merlin Clash and the difference in approach

People searching for fancyss often arrive alongside Merlin Clash, and the two are worth separating. Both target ASUS Merlin routers. The difference is what sits at the center. fancyss is built around a set of individual proxy protocols (SS, SSR, VMess, VLESS, Trojan, NaiveProxy, TUIC, Hysteria2) with per-node configuration and a choice of chinadns-ng or smartdns for DNS splitting. Merlin Clash is built around the Clash configuration model, where a YAML profile defines proxies, proxy groups and rules, and the core consumes that file.

That changes the workflow. With fancyss you add nodes and pick a mode in the plugin UI, and the README lists online rule maintenance and geosite/geoip packaging as built-in features. With a Clash-based plugin you typically bring a profile from a subscription provider and the rule logic lives in that profile. If your provider hands you a Clash YAML, the Clash route is less translation work. If you have individual node URIs and want the plugin to manage rules and DNS for you, fancyss is the more direct fit. Neither is a superset of the other, and the choice usually follows the format your subscription already uses.

Licence, maintenance and what upgrading costs you

fancyss is licensed under GPL-3.0. In practical terms that means the source is available and modifications you distribute carry the same licence. It also means the project can bundle or link against other components only where those licences are compatible, which is one reason the proxy cores are fetched as separate binaries rather than vendored into the tree. This is a description of the licence, not legal advice; if you plan to redistribute a modified build, read the licence text in the repository.

The repository is not archived, and the last push was on 2026-06-01. There are no releases recorded for it, so versioning happens through the repository and the firmware distribution channels rather than through tagged releases. Upgrading is therefore a matter of replacing the plugin package and letting the scheduled binary, rule and subscription updates do their work, or triggering them manually. The cost of staying current is mostly operational: proxy cores change, rule sets change, and the plugin's update mechanism exists precisely because those pieces move independently of the plugin code.

One thing to verify before you commit: the README's support table is the contract. A model that is not listed is not covered, and the platform naming (fancyss_arm, fancyss_hnd, fancyss_hnd_v8) is not intuitive enough to guess from the CPU alone.

Editorial conclusion

Adopt fancyss if you already run asuswrt-merlin or an official-mod firmware with a software center on one of the listed models and want per-device traffic routed without touching each client. Do not adopt it if your router is not on the support table, if you cannot flash a compatible firmware, or if you expect a desktop or mobile app, because the README describes a router plugin only. Before installing, verify three things: your exact model and firmware generation appear in the support table, the platform string (fancyss_arm, fancyss_hnd, fancyss_hnd_v8) matches your CPU, and you have a way to restore the router if the plugin fails to start.

Frequently asked questions

Official sources

1. hq450/fancyss on GitHub
2. Issues
3. License: GPL-3.0
4. README