# ShellCrash: managing mihomo and sing-box kernels from a router shell > ShellCrash is a GPL-3.0 shell script that installs, switches and maintains mihomo or sing-box kernels on routers, Linux servers and Docker hosts. It is a good fit when you have root SSH and no package manager worth using, and a poor fit when you want a supervised service or a declarative config. **juewuy/ShellCrash** — ShellCrash is a shell-native client for sing-box and mihomo that helps users switch kernels and manage proxy-related workflows through concise commands. - Repository: https://github.com/juewuy/ShellCrash - Stars: 13,302 · Forks: 1,868 - Language: Shell - License: GPL-3.0 - Published: 2026-08-04 · Updated: 2026-08-18 · Language: en - Canonical page: https://hysenlabs.com/projects/juewuy-shellcrash ## The problem ShellCrash solves on a root shell Installing a proxy kernel on a router is not hard. Keeping it installed is. You download a mihomo or sing-box binary for the right architecture, place it somewhere persistent, write a config, wire up iptables or nftables rules so traffic actually reaches it, add a cron entry so subscription rules refresh, and then repeat part of that whenever a kernel version changes or the flash fills up. On OpenWrt derivatives with busybox userland, several of those steps have no convenient tooling. ShellCrash packages the whole sequence into one script with a text menu. The README describes it as "a powerful script tool for the convenient deployment and management of mihomo/sing-box kernels in Shell environments." That sentence is the scope. It is a management layer, not a proxy implementation. The kernels come from MetaCubeX/mihomo and sing-box releases; ShellCrash decides which one is installed, where its files live, and what wraps around it. The target user is specific. You need SSH enabled and root privileges, per the prerequisites section. The device list covers OpenWrt and its derivatives (Xiaomi, Netgear are named), standard Linux and GNU distributions such as Debian, CentOS, Armbian and Ubuntu, Padavan in what the README calls Conservative Mode, Pandora, ASUS/Merlin firmware, other Linux or busybox systems, and Docker environments such as Synology and PVE. If you are on a desktop distribution and comfortable with systemd services, you are not the intended audience. ## What the script actually installs and how the pieces fit The repository layout tells you more than the README does. Alongside install.sh and install_en.sh sit bin/, public/, rules/, scripts/, tools/, a version file, and a ShellCrash.tar.gz archive. The Dockerfile unpacks that archive into /tmp/SC_tmp, sets CRASHDIR=/etc/ShellCrash and systype=container, and runs init.sh from inside it. So the installed footprint is a directory tree under /etc/ShellCrash, populated by an init script rather than by a package manager. The same Dockerfile shows the runtime composition. It downloads clash-linux-${K}.tar.gz from the project's update branch for the matching TARGETPLATFORM (amd64, arm64, armv7, 386 are the four handled, with anything else exiting 1), pulls mrs.tar.gz into /etc/ShellCrash/ruleset, and pulls zashboard.tar.gz into /etc/ShellCrash/ui. The dashboard is therefore a static bundle served from the install directory, not a separate service you deploy. Process supervision in the container image comes from s6-overlay v3.2.1.0, fetched as an arch tarball plus a noarch tarball. On a router there is no s6; the script manages the kernel process itself. That difference matters when you debug: inside Docker the kernel is a supervised s6 service, on OpenWrt it is something the ShellCrash menu starts and stops. The dependency table is the honest description of what the script can and cannot do on a given device. curl or wget is mandatory. iptables or nftables is listed as critical, and the README states that without them the script can only run in Pure Mode. crontab is low necessity, and scheduled tasks will not function without it. net-tools and ubus or iproute-doc are marked very low, used for port occupancy detection and for automatically obtaining the local host address respectively. Read that table before installing, not after. ## Installing ShellCrash on a Linux box and launching the menu The README gives separate command sets for standard Linux, routers, older wget versions, Alpine VMs and Docker. The standard Linux path uses wget against the jsDelivr CDN mirror. Run it as root, since the prerequisites say so explicitly. ```bash export url='https://testingcf.jsdelivr.net/gh/juewuy/ShellCrash@dev' \ && wget -q --no-check-certificate -O /tmp/install.sh $url/install_en.sh \ && bash /tmp/install.sh \ && . /etc/profile &> /dev/null ``` That writes the installer to /tmp/install.sh, runs it, then re-sources /etc/profile so the new command is on your PATH in the current session. The README also offers a curl variant that pipes the script straight from the author's private source at gh.jwsc.eu.org, and a router variant that pulls install_en.sh from raw.githubusercontent.com instead. The mirror choice is not cosmetic: the README's tip says that if you hit connection failures or SSL problems, switch to an alternative installation mirror. Once installed, the management interface is a single command. The README shows both forms. ```bash crash # Launch the interactive script menu crash -h # View the list of command help ``` crash opens the interactive menu; crash -h lists the available flags. Expect a text menu, not a subcommand CLI. The README does not document a non-interactive mode, so anything you want automated has to go through the script's own scheduled-task feature rather than your own orchestration. For Alpine VMs the README recommends an Alpine image for compatibility and lists the dependencies to add before installing: ```bash apk add --no-cache wget openrc ca-certificates tzdata nftables iproute2 dcron ``` Note nftables and dcron in that list. They map directly onto the critical and low rows of the dependency table: without nftables you are limited to Pure Mode, and without a cron daemon the scheduled-task feature has nothing to schedule. For Docker, the README points at the juewuy/shellcrash image on Docker Hub rather than giving a docker run line, so the container invocation is not documented in the README itself. ## Where ShellCrash is the wrong tool The first limitation is stated by the project itself. Without iptables or nftables, the script can only run in Pure Mode. Pure Mode means no transparent traffic interception, so every application that should use the proxy has to be pointed at it explicitly. On a router that defeats the purpose, and on a container that has no NET_ADMIN capability it is the same story. The README does not document what Pure Mode changes beyond that, so budget time to find out on your hardware. The second is the interface. Everything runs through an interactive menu. There is no documented config file format, no declarative manifest, and no dry-run flag in the README. If your workflow is "commit config, run CI, deploy", ShellCrash sits awkwardly in it. You can automate the kernel's own configuration, since mihomo and sing-box read their own config files, but the ShellCrash layer around them is menu-driven. The third is maintenance timing. The most recent release listed is 1.9.4, dated 2026-02-15, and the last push to the dev branch carries the same timestamp. Releases are not on a fixed cadence: 1.9.1 landed on 2024-12-01, 1.9.3 on 2025-12-31, and 1.9.4 on 2026-02-15. If you need a project with a predictable release train, that history does not offer one. It also means the installed kernel binary ages independently of the script, and updating one does not update the other. Finally, the dependency table is not a suggestion. Missing net-tools degrades automatic port occupancy detection; missing ubus or iproute-doc degrades automatic local host address detection. Those are small, but they turn into manual configuration on minimal router firmware. ## ShellCrash compared with running mihomo directly The obvious alternative is to install mihomo or sing-box yourself and manage it with whatever init system the device has: procd on OpenWrt, systemd on a normal distribution, a supervisor inside the container. The difference is where the logic lives. With a direct install, the kernel's config is the single source of truth and the init script is a few lines you wrote and can read. With ShellCrash, an installed tree under /etc/ShellCrash owns the kernel binary, the ruleset data, the dashboard bundle and the update path. That trade is real in both directions. Direct installation gives you a service that starts at boot through the platform's own mechanism and logs where the platform puts logs. ShellCrash gives you subscription import, kernel switching between mihomo and sing-box, a local web dashboard, and scheduled config and rule updates without writing any of it. If you have ever hand-written a subscription update cron job and an iptables restore script, you know which half of that you are buying. A second alternative is the Docker image alone. The Dockerfile shows the image bundles the kernel, the ruleset, the zashboard UI and s6-overlay, so a container deployment gets supervision that a bare router install does not. If your target is a Synology or Proxmox host, the container path is closer to a normal service than the router path is, and it is the one the Dockerfile is built for. The comparison to make is not "which is better" but "who owns the failure". When a direct install breaks, you read your own config. When ShellCrash breaks, you read a shell script, a menu, and a version file. ## Licence, upgrade cost and what a version bump touches ShellCrash is licensed under GPL-3.0, per the LICENSE.txt file in the repository root and the licence section of the README. If you redistribute it, or ship a device image that includes it, the GPL-3.0 obligations attach to that distribution. The project does not offer a separate commercial licence in the repository, so there is no dual-licensing escape hatch documented. This is a statement about what the repository says, not legal advice; take your own counsel if you are embedding it in a product. The upgrade path is the script's own online update feature, described in the README as one-click maintenance that keeps the script and features up to date. Because the script, the kernel binary, the ruleset archive and the dashboard bundle are four separately fetched artifacts, an upgrade can move any of them. The Dockerfile pins only s6-overlay to v3.2.1.0; the kernel and ruleset come from the project's update branch with no version pin, so a rebuild of the image is not reproducible in the strict sense. Operationally, the cost is that you cannot treat ShellCrash as a frozen dependency. The ruleset under /etc/ShellCrash/ruleset and the UI under /etc/ShellCrash/ui are refreshed from remote tarballs. If you need a device that behaves identically after a year of unattended operation, you have to pin or mirror those artifacts yourself, and the README does not describe how. ## Conclusion Adopt ShellCrash if you have root SSH on an OpenWrt router, an Armbian box or a Docker host and you want mihomo or sing-box installed, switched and updated from one menu. Do not adopt it if you need a supervised systemd unit or a declarative config you can review in git; the project ships an interactive shell menu, not a service definition. Before committing, verify three things on your own device: that iptables or nftables is present, since the README says the script can otherwise only run in Pure Mode; that crontab exists, since scheduled tasks do not function without it; and that the installation mirror you pick actually resolves from your network, because the README lists several and treats SSL failures as a reason to switch. ## FAQ ### Which devices does ShellCrash support? The README lists OpenWrt and its derivatives such as Xiaomi and Netgear, standard Linux and GNU distributions including Debian, CentOS, Armbian and Ubuntu, Padavan in Conservative Mode, Pandora, ASUS/Merlin firmware, other Linux or busybox systems, and Docker environments such as Synology and PVE. SSH and root privileges are required. ### How do I install ShellCrash on a router? The README gives a curl one-liner that exports url to the raw.githubusercontent.com dev path and pipes install_en.sh into sh, followed by sourcing /etc/profile. It also lists a jsDelivr CDN mirror and the author's private source as alternatives, and says to switch mirrors if you hit connection or SSL failures. ### Can ShellCrash run without iptables or nftables? The README's dependency table marks iptables or nftables as critical and states that without them the script can only run in Pure Mode. It does not document what Pure Mode changes beyond that. ## Sources - [Official README](https://github.com/juewuy/ShellCrash#readme) - [Project repository](https://github.com/juewuy/ShellCrash) - [Release notes](https://github.com/juewuy/ShellCrash/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/juewuy-shellcrash