Choose the architecture and package before downloading
FlClash is a multi-platform client built around Clash Meta/Mihomo, and the official project repository explicitly lists Windows support. A Windows release can contain a setup executable and a ZIP archive. Names containing amd64 or x64 are intended for the common 64-bit Intel and AMD platform; arm64 is for Windows on Arm hardware. These labels describe the processor architecture, not the language of Windows or the number of CPU cores.
Open Settings, System, and About in Windows and read the System type before choosing an asset from the official release page. Most conventional desktop and laptop PCs need x64, while Arm-based devices need ARM64. A mismatched build may be rejected by Windows or appear to do nothing when launched. Checking this one field is faster and more reliable than repeatedly trying similarly named downloads.
Match the exact asset on the official Releases page. A third-party mirror may rename a file, lag behind the project, or add content. It also removes the clearest evidence that a package really is the setup or portable artifact produced by the FlClash project.
Keep the downloaded filename until installation is finished. The version, platform, architecture, and suffix form a useful audit trail if the app does not start. Renaming every download to something generic such as flclash.exe makes later troubleshooting unnecessarily difficult.
Understand what installer and portable mean here
The setup build is the straightforward choice for a client that will remain on one PC. Its installer places program files in a managed location and normally gives Windows a standard application entry and uninstaller. The portable download is a ZIP archive: you extract the complete folder and launch the application from that folder. It is useful for evaluation, for keeping two program versions isolated, or when you deliberately do not want to run a setup wizard.
| Decision | Setup package | Portable ZIP |
|---|---|---|
| First launch | Run setup.exe, then use the installed shortcut | Extract everything, then run the app in that folder |
| Program management | Uses an installation location and uninstall entry | You are responsible for keeping the whole folder |
| Version change | Exit FlClash before running the official upgrade | Extract the new build into a separate folder first |
| Best fit | Regular use on one Windows account | Testing or intentionally isolated app versions |
The word “portable” should not be stretched into a promise that every setting, cache, service, or operating-system integration remains inside the extracted directory. It reliably tells you that the program is distributed as an archive rather than a traditional installer. If keeping all user data beside the executable is a requirement, launch the build once and verify the actual data location and behavior on your system before relying on that assumption.
Neither package type improves node quality or subscription speed. It changes how application files are delivered and maintained. Choose the setup build for the least manual housekeeping; choose ZIP when controlling the application directory matters more and you are comfortable managing upgrades yourself.
Install the setup build cleanly
Exit an older FlClash build before installing, including its tray process. A background process can keep DLL or core files open and leave a partially replaced installation. If the current profile matters, create a backup through the application or record the subscription name and custom settings first. Treat the full subscription URL as a secret: it can contain an account token and should not appear in screenshots or public notes.
- Download the Windows asset whose architecture matches System type and whose filename ends in a setup executable.
- Start the installer and check the application name and origin shown by Windows security prompts. Stop if the file cannot be tied back to the official release.
- Select a stable, writable installation location and finish the wizard. The ordinary interface does not need to run permanently as administrator merely because installation requested elevation.
- On first launch, open the About or version view and confirm that the running version matches the package you downloaded.
- Load one known-good profile and verify that the core starts before enabling system proxy or TUN features.
If Microsoft Defender SmartScreen displays a warning, do not make “Run anyway” an automatic step. Return to the browser download record and verify the github.com host, the chen08209/FlClash repository, and the exact asset name. Delete and redownload anything that does not match. This check matters more than the visual appearance of an installer window.
After the first successful start, close FlClash normally and open it again from the Start menu. That small test confirms that the shortcut points at the installed copy instead of an older portable executable still sitting in Downloads.
Extract the portable build before running it
The most common portable-build mistake is launching the executable inside the ZIP preview. Windows may temporarily extract only the selected file, while the DLLs, assets, and core files expected beside it remain in the archive. The result can look like a broken build even though the download is intact.
- Save the ZIP to a local disk, right-click it, and choose Extract All. Do not launch the app from the archive window.
- Move the entire extracted folder to a stable, writable path. Avoid temporary folders, cloud-sync conflicts, and locations that are routinely cleaned.
- Run FlClash from inside that folder and allow the interface and bundled resources to initialize.
- Exit and launch it again. Confirm that the profile and settings you created remain visible before treating the folder as a long-term environment.
Do not mix-extract a new release into a live portable folder. Extract the new package into a new directory, prove that it launches, and then move data using FlClash's supported backup and restore flow. Combining old and new DLL or core files can create startup failures that no longer correspond to either official package.
Shortcuts to a portable copy are just pointers to that folder. Moving or deleting the folder later breaks the shortcut. If you need a predictable Start-menu entry, uninstaller, and routine upgrades, the setup build is usually the clearer choice.
Verify the first launch and isolate failures
A visible FlClash window is only the first checkpoint. A complete installation means the app can restart, its core can load, a selected profile remains available, and the proxy switch produces the expected network behavior. Test one layer at a time: leave TUN off, load a known-good configuration, start the core, then enable only system proxy and visit a page whose route you can verify.
| Symptom | Check first | Next action |
|---|---|---|
| Windows says the app cannot run | x64 versus ARM64 asset | Download the matching official build |
| The app closes when run from ZIP | Whether every file was extracted | Extract all files into a new folder |
| UI opens but the core fails | Quarantined files and write permission | Read the app log and security history |
| Settings disappear after changing builds | Whether both builds use the same data location | Return to the old build and export a supported backup |
For a useful support report, keep the official asset filename, Windows System type, FlClash version, and the first concrete error in the log. Remove subscription URLs, server addresses, account identifiers, and real names embedded in user-directory paths before sharing it. A screenshot saying only “failed” is much less actionable than a short sequence describing which package started, whether the core loaded, and which single switch caused the failure.
If the setup build works and the portable build does not, it is reasonable to keep using the setup build while investigating the archive path and permissions. Do not simultaneously change the core, profile, DNS, and proxy mode; doing so hides which layer the package choice actually affected.
Official sources and version scope
Version numbers, filenames, and interface labels can change. Confirm them in the linked project documentation before making changes.