Run the mihomo Core on Windows from the Command Line
On this page
Running the mihomo core directly on Windows — no graphical client, just the binary, a YAML file and a terminal — is the setup of choice when you want full control: hand-written configs, scripted startup, a minimal footprint on a work VM, or a clean environment for debugging a configuration before it goes anywhere else.
To be clear about the audience: if you simply want a proxy on your desktop, install Clash Verge Rev instead — it bundles this exact core and manages it for you. This guide is the manual route: download, configure, validate, run, verify, and keep it running across reboots.
Download and unpack the core
Grab mihomo v1.19.29 from the download center's Windows section. Two builds exist: amd64 for Intel and AMD machines (almost everyone) and arm64 for Windows-on-ARM devices. If you are not certain which one applies, open Settings → System → About and read the "System type" line: "x64-based processor" means amd64, "ARM-based processor" means arm64.
The download is a .zip containing a single executable — extract it to a permanent folder such as C:\mihomo and rename the executable to mihomo.exe to keep commands short. That folder will also hold your configuration and the core's data files, so keep everything together. Avoid unpacking it somewhere temporary: the core writes its runtime files next to itself, and a folder that gets cleaned out takes your downloaded rule databases with it.
If a security scanner quarantines the executable, that is the routine heuristic reaction to an unsigned networking tool. Restore it, and add an exclusion for the folder if it happens again.
Give it a config and a working directory
mihomo reads config.yaml from its working directory. Save your configuration — exported from your provider in Clash/mihomo format, or written by hand as covered in the config basics guide — as C:\mihomo\config.yaml. Then start the core from a terminal (PowerShell or cmd):
cd C:\mihomo
.\mihomo.exe -d C:\mihomoThe -d flag sets the working directory; add -f to point at a specific file when you keep several configs side by side:
.\mihomo.exe -d C:\mihomo -f C:\mihomo\test-config.yamlThese four flags are the entire command-line surface most people ever need:
| Flag | What it does |
|---|---|
-d <dir> | Sets the working directory, where the config and downloaded data files live |
-f <file> | Uses one specific config file instead of config.yaml in that directory |
-t | Parses the config, reports problems and exits without listening on anything |
-v | Prints the version, a fast way to confirm which build you extracted |
Validate the config and read the logs
Before trusting a new or edited config, ask mihomo to parse it without starting anything:
.\mihomo.exe -t -f C:\mihomo\config.yamlErrors come back with line numbers, which turns YAML debugging from guesswork into a checklist. When the test passes, start normally and watch the startup log: it names the ports the core is listening on and reports problems as they happen. On a first start, the core may also fetch GeoIP and rule data files into the working directory — let it finish.
Point something at the proxy to verify
The core listens on the ports your config defines — with a mixed-port, one port accepts both HTTP and SOCKS clients. Point your browser's proxy setting, or Windows' proxy settings, at 127.0.0.1 with that port. A quick command-line check with curl (bundled with modern Windows):
curl.exe -x http://127.0.0.1:7890 -I https://www.example.comReplace 7890 with the mixed port from your own config — commonly 7890 or 7897, but your file is the source of truth. A response with HTTP headers means traffic is flowing through the core.
Note: the bare core does not touch your system proxy settings. Unlike a GUI client, nothing is redirected automatically — you point applications at the port yourself, which is precisely the appeal for controlled setups.
When the core refuses to start
Three symptoms cover nearly everything that goes wrong here.
The window flashes and vanishes. That is what happens when you launch the executable by double-clicking it: the console dies with the process and takes the error message with it. Start it from a terminal window that is already open, and the message stays on screen where you can read it.
An address-already-in-use error. Something else is holding the port your config wants. Track down the owner:
netstat -ano | findstr 7890The last column of each matching line is a process ID; look it up on the Details tab of Task Manager to see what it belongs to. Usually it is a second copy of the core or a GUI client that never fully exited. Close it, or change the port in your config.
A parse error on startup. Go back to -t, fix the line it names, and try again. Tabs used for indentation and a colon with no space after it cause a large share of these.
Keep it running, and upgrade later
Run manually, the core lives and dies with its terminal window. For an unattended setup, Windows Task Scheduler is the standard answer: create a task that runs C:\mihomo\mihomo.exe -d C:\mihomo at logon or at system startup, and mihomo comes up with the machine — no window required.
Upgrades are refreshingly boring: stop the running core, replace mihomo.exe with the new build, start it again. Configuration and data files sit untouched next to it. The same workflow on a headless Linux box — including a proper service with auto-restart — is covered in the Linux server deployment guide, and the concepts behind the core itself are in What is mihomo?