What to Use After Clash Client Development Ends: FlClash vs. Clash Verge Rev Migration Guide

First, separate the discontinued client from the configuration format

The original Clash core and Clash for Windows are no longer maintained. The commonly cited final release of Clash for Windows is v0.20.39. An old installer may still launch, but continued use brings three practical problems: compatibility issues with new operating systems will not be fixed, newer rule capabilities cannot be added, and subscription services gradually moving to mihomo may introduce unsupported fields. The goal of migration is not to find an identical interface, but to move subscriptions, override rules, proxy modes, and system integration smoothly to a maintained client.

Most commonly used alternatives now rely on the mihomo core. mihomo extends the Clash configuration model with rule providers, process matching, TUN, traffic sniffing, and more complete DNS controls. Most standard YAML configurations remain usable, but client-specific interface settings do not transfer directly. For example, Clash for Windows window state, startup options, and Mixin scripts will not migrate automatically with a subscription URL.

Separate four types of data before migrating

• Subscription URL: The URL provided by the service, usually available in the old client's Profiles or configuration page.
• Configuration file: A YAML file containing fields such as proxies, proxy-groups, rules, and dns.
• Client settings: Local options such as launch at startup, system proxy, TUN, LAN access, and theme.
• Overrides: Mixin, Parsers, scripts, or manually added rules from the old client that must be rebuilt separately.

If you normally just paste a subscription link and choose a node, migration usually takes about ten minutes. If you changed DNS, rule order, or ports, export the active configuration first and restore each change individually. Because subscription updates can overwrite local files, custom settings belong in the new client's override feature rather than directly in subscription-generated YAML.

Choosing Between FlClash and Clash Verge Rev

Both can run mihomo configurations, but they focus on different workflows. FlClash supports Windows, macOS, Linux, and Android, with a relatively consistent interface across desktop and mobile. Clash Verge Rev primarily targets Windows, macOS, and Linux desktops, concentrating configuration management, tray controls, system services, and desktop TUN workflows in one place.

When FlClash is the better choice

• You use Clash configurations on both a computer and an Android phone and want a similar menu structure.
• Your main tasks are adding subscriptions, switching nodes, viewing connections, and enabling or disabling the system proxy.
• You need to manage proxy groups on a touchscreen device and do not want to maintain two completely different workflows.
• You work with local YAML files and want to import them directly, then review error messages and rule matches.

When Clash Verge Rev is the better choice

• Your main device is a Windows, macOS, or Linux desktop computer.
• You frequently switch between multiple subscriptions and want centralized DNS, rule, or proxy-group overrides.
• You want quick tray controls for switching the system proxy, TUN mode, and proxy mode.
• You need applications that ignore the system proxy to use TUN, and want a system service to reduce how often elevated actions are required.

Do not choose based only on interface screenshots. More reliable criteria are your device platforms, whether you depend on TUN, whether you maintain custom rules, and how many subscriptions you use. Either client will handle one subscription on a single Windows PC; choose FlClash first when Android is involved. For multiple desktop configurations and complex overrides, Clash Verge Rev usually offers a more direct management workflow.

Moving Subscriptions and Configurations from Clash for Windows

Step 1: Save the subscription URL and local YAML

Open Clash for Windows and go to the Profiles page. Record the name, update time, and URL for each subscription still in use. If the full URL is not shown directly, check the configuration source or copy it again from the subscription service's management page. Then open the configuration directory and copy the active YAML file to a separate folder.

Saving only config.yaml is not enough. Clash for Windows may store subscription files in the profiles directory and use an index to track the current selection. If you use Mixin or Parser, copy the related text into separate plain-text files as well. During migration, understand and rebuild these pieces; do not overwrite the new client's entire data directory with the old one.

1. Turn off automatic configuration updates so the subscription file is not refreshed during the backup.
2. Copy each subscription URL and label its purpose, such as “daily,” “testing,” or “backup.”
3. Export or copy the currently active YAML.
4. Note the ports and toggle states shown on the General page.
5. Save custom Mixin, Parser, and hand-written rules.

Step 2: Add the subscription to the new client

After installing the new client, start by adding only the primary subscription. In FlClash, open “Profiles” → “Add,” choose the URL type, paste the subscription URL, and update it. In Clash Verge Rev, open “Subscriptions” → “New,” enter a name and subscription URL, save, and click update. Menu names may vary slightly by version, but choose a remote subscription rather than pasting the URL as local YAML content.

After a successful update, check that all proxy groups are present, then select a node for a latency test. Latency only measures the response time of the probe target; it does not prove that every website is reachable. Open one direct-connection site and one proxy-required target, then inspect the rules, proxy group, and actual outbound node on the “Connections” page.

Step 3: Check ports to prevent duplicate listeners

Legacy Clash configurations often use HTTP port 7890, SOCKS5 port 7891, and the external controller port 9090. mihomo configurations also commonly use mixed-port: 7890 to share one entry point between HTTP and SOCKS. If both clients run at once and listen on 7890, you may see “address already in use,” “port is already occupied,” or a system proxy that cannot connect.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
external-controller: 127.0.0.1:9090

During migration testing, fully quit the old client and confirm it is no longer running in the system tray before starting the new one. If you must compare them side by side, temporarily change one client to 7892, but point the system proxy only to the port under test. Restore a consistent port after testing so browsers, terminals, and development tools do not retain different proxy addresses.

Moving Custom Rules, Proxy Groups, and DNS

Preserving rule order is the key to a successful migration. Clash and mihomo match rules from top to bottom and stop at the first match. Placing a specific domain rule after broad GEOIP or MATCH rules means it will not work even if the syntax is valid. Move exact-match rules first, then rule-provider references, and finally verify the catch-all rule.

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - DOMAIN,api.example.net,Proxy
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

Proxy group names must match

The final item in a rule references a policy name. In the example above, Proxy must exist in proxy-groups. If the subscription actually uses “Node Select” or “Proxy,” copying the rule as-is will produce a missing-policy-group error or fail during loading. Chinese and English group names, including capitalization, must match exactly.

Node names may change after a subscription update, so custom proxy groups should preferably reference stable policy groups or use the client's supported override mechanism. Do not hard-code dozens of node names into a long-lived rule file; otherwise, every server-side rename requires manual maintenance.

Do not copy the old Mixin wholesale

Clash for Windows Mixin can modify the configuration with JavaScript, while Parser may transform the subscription before it reaches the core. The new client may not support the same script interfaces. First determine what the old logic actually did: add rules, modify DNS, change ports, or insert proxy groups. Rewrite anything expressible in standard YAML as a global extension, merge override, or script override supported by the new client.

For example, if the original Mixin only changed the log level to info and enabled LAN access, keeping the script is unnecessary. Adjust those options directly under “Settings” → “Core Settings” in the new client. If LAN access is enabled, also restrict the listening address and check the system firewall so the controller port is not exposed to an untrusted network.

Start with the subscription's default DNS

DNS is the part of migration most likely to produce the symptom “the node works, but websites do not open.” The old configuration may use fake-ip, while the new client may enable traffic sniffing by default. These settings can interact differently with security software, LAN domains, and virtual machine networking. Start with the DNS section supplied by the subscription, confirm that proxying works, and only then restore custom nameservers, fallback settings, or fake-ip-filter.

dns:
  enable: true
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 1.1.1.1

198.18.0.0/15 is a benchmarking address range commonly used by Fake-IP mode for local mapping. A connection record pointing to this range does not mean the remote website actually uses that IP. If LAN devices, printers, or a particular application resolve incorrectly, first check whether the domain belongs on the Fake-IP exclusion list instead of disabling the entire DNS module.

Migration order for system proxy and TUN

The system proxy works well for browsers, chat tools, and applications that explicitly read the operating system proxy settings. TUN takes over more traffic at the network layer and is useful for game launchers, command-line programs, some store apps, and software that ignores the system proxy. Neither is a speed setting, and they do not have to be enabled together.

Complete the basic checks with the system proxy first

1. Quit the old Clash client and disable any system proxy it left behind.
2. Start the new client and select a working node.
3. Set proxy mode to “Rule”.
4. Enable “System Proxy” and leave TUN disabled.
5. Visit both direct and proxied targets, then check the matched rules in the connection list.

If this works, the subscription, ports, and basic rules are functioning. Enabling TUN immediately expands the troubleshooting scope to virtual adapters, routing, DNS, and permissions. On Windows, also check “Settings” → “Network & Internet” → “Proxy” and confirm that the manual proxy points to 127.0.0.1 and the current listening port.

Enable TUN only when full traffic capture is needed

The Clash Verge Rev desktop client typically requires installing or enabling a service component, while FlClash also triggers system authorization the first time TUN is enabled. On Windows, allow the network component to finish installing. On macOS, approve the prompt under “系统设置” → “网络” or the related Privacy & Security settings. On Linux, you may need to configure permissions and routing capabilities. Restart the client after authorization, then enable TUN.

Watch the time required to establish a usable connection, not just the latency number. On the same network and node, a first web connection of about 180 ms through the system proxy and 190–230 ms through TUN is normal variation. If TUN consistently takes more than two seconds or DNS queries repeatedly time out, check DNS hijacking, IPv6, MTU, and other virtual adapters instead of replacing every rule.

Troubleshoot migration failures by symptom

Subscription update fails or returns an empty configuration

• Copy the URL again from the subscription service dashboard and make sure no trailing spaces were added.
• Confirm that the subscription has not expired, and check whether the server limits update times or request frequency.
• If the old client updates successfully but the new one does not, compare User-Agent requirements and network paths.
• Disable overrides first. Once the raw subscription loads, restore additional configuration one item at a time.

The configuration reports a YAML parsing error

YAML uses spaces for indentation. Tabs, full-width colons, and incorrect indentation can all cause parsing failures. If the error points to line 48, the real problem may be an unclosed quote on line 47. Reduce custom content to the smallest possible section and add it back block by block. Quote node names that contain colons, hash signs, or other special characters.

System proxy is enabled, but the browser still connects directly

• Check whether the browser has a separate proxy extension that may override system settings.
• Confirm that the listening address is 127.0.0.1 and that its port matches the system proxy.
• Check the connection list; no new connections usually means traffic is not reaching the client.
• If the match is DIRECT, check rule order. If a proxy match fails, check the node.

Domains cannot be resolved after enabling TUN

Disable TUN first and confirm that system proxy mode works again. Then check whether DNS is enabled, whether the nameserver is reachable, and whether Fake-IP exclusions cover LAN domains. On Windows, run ipconfig /flushdns in a terminal to clear the system cache; on macOS, switch the network connection once and test again. Do not change DNS, MTU, IPv6, and rules in the same troubleshooting step, or you will not know which change helped.

Post-migration acceptance checklist

A completed migration means more than seeing green nodes. Validate configuration updates, rule matches, system takeover, and recovery after reboot. Only uninstall the old client and delete unused configuration copies after every item below passes.

• The subscription updates manually, and the proxy groups and nodes appear normally afterward.
• In rule mode, direct targets match DIRECT, while proxied targets match the expected policy group.
• Traffic goes direct when the system proxy is disabled and through the new client when it is enabled.
• Applications that require TUN can connect, while LAN devices and printers remain accessible.
• After rebooting, startup and automatic connection behavior work as expected.
• Subscription updates do not overwrite local overrides, and hand-written rules retain the correct order.
• The old client no longer remains in the system tray and is no longer listening on ports 7890 or 9090.

For most users, the safest path is to back up the old data, install a maintained mihomo client, import only the primary subscription, verify it with the system proxy, restore rules and DNS, and enable TUN only if needed. FlClash is better suited to workflows spanning desktop and Android; Clash Verge Rev is better suited to desktop configuration management and system integration. Once you choose one, keeping configuration sources clear is easier to maintain than running several clients in parallel.