1 Why run Mihomo inside Termux on Android
Android users who already maintain Mihomo or Clash Meta configs on a laptop sometimes ask for the same mental model on a phone: a YAML-first core, remote profiles, and log lines they can grep instead of a carousel of tap targets. Graphical clients such as FlClash exist precisely because most people do not want to babysit a shell session—but if you prefer reproducible scripts, SSH-style maintenance, and minimal UI surface, Termux gives you a real user-space Linux environment on a non-root phone. You trade polished onboarding for transparency: every flag you set is visible in plain text, and you can version-control directories under ~/.config the same way you would on desktop Linux.
The important framing is intent. Termux is excellent for learning, automation, and keeping a Clash-compatible daemon alive on localhost. It is not a magic substitute for every feature you get from an app that speaks the Android VPN API out of the box. Stock Android keeps the power to create true device-wide tunnels behind privileged interfaces; user-land cores listen on loopback addresses unless you combine them with another layer. We will return to that boundary after we cover installation, because misunderstanding it is the fastest route to disappointment when some games or captive-portal browsers ignore your SOCKS listener entirely.
If you already follow our FlClash on Android guide but want a complementary terminal-first document, you are in the right place. Where FlClash wraps the experience in VPN consent dialogs and profile tabs, this article assumes you are happy editing files with nano or vim and restarting a binary when YAML changes. Pair the two mentally: use FlClash when you need frictionless system capture, and use Termux plus Mihomo when you need portability, scripting, or experimentation without sideloading yet another large APK from an unfamiliar mirror.
2 Install Termux, update indices, and core packages
Install Termux from a trustworthy channel—F-Droid builds track the project’s own signing keys more predictably than random repackaged storefront copies. After first launch, update packaging metadata and upgrade installed pieces so your compiler toolchain, TLS libraries, and CA bundle stay coherent. The classic sequence is pkg update && pkg upgrade, accepting prompts when libc or openssl shifts underneath other packages.
Next, pull in the utilities you will lean on for downloading Mihomo releases and editing configs: curl or wget, ca-certificates, unzip if your release ships inside an archive, plus an editor. Many users also install git so they can keep dotfiles in a private repository instead of passing secrets through chat applications. Do not paste subscription URLs into public paste bins; if you must transfer YAML between machines, use encrypted channels you control.
Storage deserves a deliberate choice. Termux historically offered the termux-setup-storage helper to expose Android shared storage, which is useful when you export a sanitized profile from desktop and copy it across USB or cloud drives. Remember that Android backups and gallery apps can index broad directories, so isolate secrets under Termux private storage unless you have a strong reason to move files outward. When in doubt, keep tokens inside the Termux home directory and restrict screenshots while debugging.
aarch64 or arm64 userlands. Download the matching Mihomo build; x86_64 tablets exist but are rare—verify with uname -m before pulling large binaries.
3 Place the Mihomo binary and config directory
Mihomo publishes release artifacts for multiple platforms; for Android-on-ARM you want the Linux arm64 tarball or package naming that clearly matches AArch64. Fetch the archive with curl -LO, verify the checksum if the project publishes one, extract it under a directory such as ~/opt/mihomo, and mark the binary executable with chmod +x. Keep the version string in a small text file so you know when to bump after upstream security fixes—kernel-level protections on Android will not save you from running an outdated parser with Internet-facing inputs.
Point the daemon at a dedicated configuration path. Conventionally you maintain config.yaml inside ~/.config/mihomo or ~/.config/clash depending on habits carried over from desktop clones; what matters is consistency between your launch command, systemd-style thoughts on Linux, and the relative paths inside YAML. Our Linux Mihomo systemd guide mirrors the same file-level discipline for servers—read it when you want parallel vocabulary between phone and VPS.
Smoke-test with a foreground invocation before you automate anything: ./mihomo -d ~/.config/mihomo (flags may vary slightly by build). Watch stdout for parser errors about unsupported keys; vendor profiles occasionally include desktop-only fields that require trimming when you run a slim build on mobile data. Fix upstream YAML on a workstation, then sync the cleaned file rather than improvising half-broken merges on a touchscreen keyboard.
4 Subscription import with proxy-providers and local files
Providers typically hand you an HTTPS URL that returns YAML or base64. On Mihomo you map those endpoints through proxy-providers with a sane interval, then reference generated collections inside proxy-groups. This mirrors desktop Meta workflows: treat the remote URL as truth, let the core refresh on a schedule, and avoid duplicating node lists manually unless you need offline operation during travel without connectivity to the provider panel.
When the provider URL is long or rotates frequently, store it once and avoid echoing it in shell history snippets—use a here-document or editor buffer instead of a one-liner that later appears in bash_history. If you must combine multiple subscriptions or patch incompatible keys, run subconverter-style tooling on a trusted machine, then copy only the merged result into Termux. Random “paste your link” web forms are unsafe; they see every token you submit.
Validate after downloads succeed. Trigger an on-demand refresh, open the group panel through whatever controller UI you prefer, and confirm nodes exist with plausible names. If DNS resolution fails on LTE, check whether private DNS settings in Android fight with your YAML’s DoH stanzas—the symptoms look like TLS handshake errors even though Wi-Fi works. A controlled experiment toggles one variable at a time: transport, DNS, then node region.
Harden the file before you treat it as production-ready
Remove experimental listeners you do not plan to expose. Every open port on localhost is still reachable to other apps on the same profile unless you firewall thoughtfully; Termux itself does not magically isolate your SOCKS endpoint from maliciously crafted local peers. If you enable mixed listeners for convenience, combine with strong authentication on the external controller and avoid binding to non-loopback interfaces without understanding Android hotspot and tethering behaviors.
5 External controller, logs, and optional dashboards
Turning on the external-controller endpoint lets you hit Mihomo’s REST API from a browser tab via an embedded dashboard or a separate static bundle like Yacd or metacubexd served locally. Keep the listen address on 127.0.0.1 unless you explicitly tunnel elsewhere; exposing the port across your LAN without authentication invites accidental reconfiguration when friends join the Wi-Fi at a café. Pair the controller with a secret token when supported; treat that token like an API password.
Logs remain your first-line observability tool on Termux. Tail the same log file you would on Linux: correlate DNS rejections, rule matches, and handshake failures without relying on a GUI spinner’s color state. When troubleshooting enterprise captive portals, remember that Android may route certain flows outside your SOCKS stack—compare what Mihomo thinks happened with what tcpdump-equivalent visibility you have (often none without elevated permissions).
For broader vocabulary on DNS alignment across cores, cross-read the Clash documentation hub—the terminology matches Mihomo log lines even when Android’s resolver quirks differ from desktop Windows.
6 .bashrc, profiles, and disciplined autostart
The Bourne-again shell reads ~/.bashrc for interactive sessions. Naive tutorials sometimes append a line that launches Mihomo unconditionally, which duplicates processes every time you open another session tab. A safer pattern guards on a PID file or uses flock around a small script stored under ~/bin/mihomo-start. The script checks whether the daemon already listens, starts it only when absent, and records failures to a rotating log. This sounds pedantic until you watch three overlapping copies fight over the same YAML on a phone that spawns shells aggressively.
Export predictable environment variables at the top of your profile: MIHOMO_HOME, path to the binary, and maybe http_proxy during bootstrap if your network requires a hop to reach the subscription host—just remember to unset temporary proxies after fetches so day-to-day traffic follows Mihomo itself rather than a stale corporate forward. Android SELinux still constrains some behaviors; when something refuses to bind, read Termux documentation on recent Android 14 changes rather than assuming arbitrary Linux sysctl tips apply.
For non-interactive use, prefer the Termux service ecosystem instead of overloading interactive shell files. .bashrc is a convenient hook for humans who open a terminal and expect the world to be ready; automation should rely on explicit unit-like scripts you can invoke from boot jobs. That separation keeps mental models cleaner when something misbehaves at 2 a.m. on hotel Wi-Fi.
# ~/.bashrc (excerpt—adapt paths)
export MIHOMO_HOME="$HOME/.config/mihomo"
[ -x "$HOME/opt/mihomo/mihomo" ] && \
pgrep -f "mihomo -d $MIHOMO_HOME" >/dev/null || \
nohup "$HOME/opt/mihomo/mihomo" -d "$MIHOMO_HOME" >> "$MIHOMO_HOME/run.log" 2>&1 &nohup redirects may capture secrets when debug verbosity is high. Drop log levels after stabilization.
7 Termux:Boot, wake lock, and keeping the process warm
Android loves to freeze background work. Two Termux add-ons matter for longevity: Termux:Boot, which runs scripts after boot completed broadcasts, and Termux:API-adjacent patterns paired with termux-wake-lock acquired inside a persistent session. Wake lock here is not marketing language—it asks the OS to keep the CPU from deep sleeping while your session runs, trading battery for stability. That trade is acceptable during debugging or short tethering sessions; it is less ideal as a permanent posture unless you enjoy charging twice a day.
Typical boot wiring looks like a shell script under ~/.termux/boot/ that calls your guarded starter with absolute paths, sleeps briefly for radio readiness, then touches a state file you can inspect manually. OEM skins from vendors such as Xiaomi or Oppo may still throttle jobs unless you exempt Termux from aggressive battery optimization in Android settings. The toggles move between OS versions, but the pattern repeats: find “battery,” locate Termux, disable restrictions, allow auto-start if the vendor offers it, and verify after reboot while watching log output rather than assuming success because the icon launched.
Notifications can be a gentler signal than wake locks. Keeping a low-priority Termux notification visible sometimes reduces surprise kills when memory pressure spikes—combine that with honest measurements of CPU idle percentage so you know whether you are solving a policy issue or simply starving the scheduler with busy loops.
bash -x before you trust reboot triggers; keep a USB debugging path to recover if Termux fails closed.
8 Understand the limits compared with full VPN clients
Running Mihomo in Termux without root usually yields localhost HTTP and SOCKS listeners plus optional mixed ports—perfect for browsers and apps that honor per-app proxy settings or the standard Android proxy knob when it exists. It does not automatically grant the same kernel-level capture that a VPN-profile app obtains through Android’s VpnService. Games, some banking stacks, and assorted SDKs ignore user-space proxies by design or accident; they may still exit directly to the carrier unless you layer another solution.
Practical stacks therefore look like: Mihomo in Termux for the core, plus a companion mechanism to steer traffic—maybe a dedicated VPN front that can chain, maybe per-app SOCKS where supported, or maybe routing through a second device on your LAN that runs a transparent gateway documented elsewhere. Readers who need one-tap, whole-device tunneling with minimal thought should default to established clients—our visual workflow remains mapped in the FlClash Android walkthrough.
None of this diminishes Termux’s niche. It shines when you script health checks, test migrations between vendors, or keep parity with YAML under git while airplanes and hotels change hourly. Choose tools for the job: VPN apps for blanket capture, Terminal plus Mihomo for honesty and control.
9 Wrap-up
You can run the Mihomo core on modern Android without rooting by treating Termux as a tiny Linux host: fetch the correct ARM64 binary, store config.yaml with subscription feeds expressed through proxy-providers, expose a secured external-controller when you need APIs, layer autostart via .bashrc or dedicated boot scripts with careful PID checks, and extend survival with Termux:Boot plus wake locks while understanding battery trade-offs. The approach rewards operators who enjoy log files more than animations—but it never replaces full VPN semantics for every program on the device, so plan your traffic path accordingly.
Compared with glossy storefront clients, a terminal workflow trades polish for openness: you see exactly what runs, where YAML lands on disk, and why a fetch failed. Compared with tossing opaque APKs onto your phone, you gain reproducible upgrades when you treat Mihomo versions like any other dependency. When you also need maintained desktop installers with editors and tun integration, consolidate downloads from the same ecosystem hub instead of hunting mirrors—Windows, macOS, and Linux builds sit alongside other resources for a coherent workflow next to your Termux experiments.
