After a Client Is Discontinued: Exporting Configs, Swapping Cores and Alternatives

Start with the category, not the app name

“Clash” and “VPN” are often used as if they describe the same product. They do not. A VPN usually refers to a network technology, a service, or an application that creates an encrypted tunnel between a device and a remote server. Clash is primarily a rule-based proxy client and configuration engine. It can connect to proxy nodes, select among them, and route traffic according to rules. With TUN mode enabled, it can also capture traffic from applications that do not understand ordinary proxy settings.

The confusion is understandable because the two can produce a similar result in daily use: a browser request leaves the device through a remote server, and the destination sees that server's address instead of the local address. The path, configuration model, encryption boundary, traffic-handling method, and level of control can nevertheless be very different.

There is also a terminology problem. People may call a paid proxy subscription a “VPN,” while a VPN provider may offer WireGuard or OpenVPN profiles that can be imported into another client. Conversely, a Clash subscription may contain VLESS, Shadowsocks, Trojan, Hysteria2, or other proxy outbounds that are not traditional VPN tunnels. Always identify the actual protocol and software layer before deciding whether two services are equivalent.

What a VPN and Clash actually do

The usual VPN traffic model

A conventional consumer VPN application normally establishes one main connection from the device to a VPN gateway. The application authenticates with the provider, negotiates encryption, creates a virtual network interface, and sends selected or all traffic through that interface. The remote gateway then forwards traffic to the public internet. Depending on the provider and protocol, DNS requests may also be sent through the tunnel.

Modern VPN protocols such as WireGuard and OpenVPN can protect traffic between the device and the VPN server. That protection is especially useful on an untrusted local network, although HTTPS still matters because the VPN provider can generally observe connection metadata and may be able to observe unencrypted application traffic after it leaves the tunnel. A VPN changes the location and network path seen by websites; it does not make the user anonymous by itself.

The usual Clash traffic model

Clash-compatible clients load a YAML profile, parse proxy definitions and rule groups, and then select an outbound for each connection. A profile may define several nodes, a group such as url-test or select, DNS behavior, rule providers, and a final fallback such as MATCH. The client often exposes a local HTTP proxy and SOCKS5 proxy, for example on ports 7890 and 7891, although actual ports vary by application.

In system-proxy mode, applications send traffic to those local ports only when they support the operating system's proxy settings or are configured manually. In TUN mode, the client creates a virtual interface and redirects more traffic into the routing engine. This is closer to the full-device experience associated with a VPN, but it still uses the selected proxy outbounds and Clash rules rather than turning the client into a generic VPN provider.

The core is important here. The user interface manages profiles, subscriptions, switches, and settings; the mihomo core parses the configuration and handles protocols, DNS, rules, and TUN traffic. A client using an old core may fail to load a modern configuration even when the interface appears to work. Features such as rule-providers, proxy-providers, tun, GEOSITE matching, or newer outbounds depend on core support.

Compare the traffic path before comparing the brand

The most useful question is not “Which name is better?” but “What happens to this connection from the application to the destination?” Consider a browser opening an HTTPS website. In a traditional system-proxy setup, the browser connects to the local Clash HTTP proxy. Clash evaluates the requested domain, chooses a proxy group, and sends the connection through the selected outbound. The remote node then connects to the destination. HTTPS encrypts the application data between the browser and the website, while the proxy protocol protects or transports the connection between the client and the node according to that protocol.

With a VPN application, the browser usually sends packets to a virtual network interface. The VPN client encrypts them and sends them to the VPN gateway. The gateway decapsulates the packets and forwards them. The application may not know that a VPN exists, because the operating system routes traffic at a lower layer.

With Clash TUN mode, the operating system also sends packets through a virtual interface, but the mihomo core must decide what to do with them. It may send a domain through a proxy group, resolve DNS through a configured DNS policy, bypass a private IP range, or reject a connection. That creates more control, but also more places for a misconfiguration to occur.

Encryption is not the same as routing

Routing decides where traffic goes. Encryption decides who can read traffic on a particular segment. A rule that sends a domain to a proxy group does not automatically guarantee end-to-end encryption. The selected outbound protocol determines how the client communicates with the node, while HTTPS, TLS, or the application's own encryption protects the connection to the destination.

This distinction matters when reading provider advertisements. “Supports Clash” says that a profile can be formatted for a Clash-compatible client; it does not describe the privacy properties of every node. “Supports WireGuard” identifies a protocol, but the provider's logging policy, server operation, and account practices still matter. A VPN label is not a substitute for checking what is encrypted, where termination occurs, and who controls the server.

DNS, IPv6, and traffic leakage

DNS is one of the most common differences between a working setup and a misleading setup. A browser may use the system resolver before Clash sees the connection, or a TUN configuration may capture DNS while leaving IPv6 traffic outside the intended route. Some applications use their own DNS-over-HTTPS implementation and bypass the operating system entirely.

• In system-proxy mode, confirm whether the application honors the system HTTP or SOCKS proxy.
• In TUN mode, review the DNS mode, fake-IP or redirection behavior, and the DNS listen address.
• Check whether IPv6 is enabled and whether the selected route handles IPv6 consistently.
• Test browsers, command-line tools, and applications separately; one successful browser test does not prove full-device routing.
• Do not disable HTTPS certificate validation to hide a proxy or DNS problem.

Hands-on: test a Clash setup without guessing

A first-time user can compare a VPN application and a Clash client with a controlled test. Do not begin by enabling every advanced option. Start with one known profile, one browser, and a small set of checks. The goal is to separate subscription access, local proxy operation, routing rules, DNS, and TUN capture.

1. Back up the profile and record the defaults. Save the subscription URL only in a secure password manager or another protected location. Note the current system proxy state, local HTTP and SOCKS ports, TUN state, DNS mode, and selected rule mode.
2. Check the core version. Open the client's About, Settings, or Kernel page. A current mihomo-based client is generally required for profiles using modern rule providers, GEOSITE data, TUN options, or newer proxy types. Do not assume that a familiar client name means a current core.
3. Update the profile while the network is still normal. Import the subscription or local YAML file, then confirm that the proxy list is populated. An empty list may indicate a download, conversion, YAML, or unsupported-protocol problem rather than a connectivity problem.
4. Test local proxy mode first. Leave TUN disabled. Turn on the system proxy or configure a test browser to use the local HTTP port, commonly 7890. Open a simple HTTPS website and check the client's connection log. The log should show the domain, matched rule, selected group, and outbound result.
5. Test a direct rule. Choose a domain that should bypass the proxy and confirm that it matches the intended DIRECT rule. Then test a domain that should use the proxy group. If both follow the same path, inspect rule order: the first matching rule wins, and a broad rule placed too early can hide later rules.
6. Inspect DNS behavior. Check whether the requested domain is resolved locally, through a configured remote resolver, or through fake-IP handling. A connection log that shows the right proxy but a DNS query escaping through the local network still indicates an incomplete setup.
7. Enable TUN only after the first tests pass. Grant the operating-system permission, select the intended stack if the client exposes one, and keep the system proxy setting consistent with the client's instructions. Test a command-line tool and one application that does not support system proxies.
8. Restore and compare. Turn TUN off, restore the previous system proxy state, and repeat the same requests. This comparison tells you whether a failure belongs to the node, the rules, the DNS policy, or the TUN layer.

curl -I --max-time 10 https://example.com
curl -I --proxy http://127.0.0.1:7890 --max-time 10 https://example.com
curl --socks5-hostname 127.0.0.1:7891 --max-time 10 https://example.com

The first command tests the normal network path, the second tests the local HTTP proxy, and the third tests the local SOCKS5 proxy with hostname resolution handled through the proxy. The exact ports depend on the client. If the direct command works but the proxy command fails, inspect the local listener, profile selection, node health, and client log before changing browser settings.

Choose by use case, control, and trust

A managed VPN is often the simpler choice for someone who wants one application, one account, and a predictable full-device tunnel. It usually has fewer routing decisions, a central server list, and support documentation written for nontechnical users. It can be a good fit for public Wi-Fi, travel, or a household where several people need the same basic connection behavior.

Clash is a better fit when selective routing matters. A user may want local banking, government websites, software update servers, and private network addresses to use DIRECT, while sending selected domains through a proxy group. Developers and advanced users may also value multiple subscriptions, fallback groups, rule providers, process-based rules, and separate policies for different applications.

• Choose a VPN first when simple setup, one-tap full-device routing, and provider-managed infrastructure matter more than granular rules.
• Choose Clash first when you need domain-based splitting, several nodes, subscription aggregation, or explicit control over direct and proxied traffic.
• Use WireGuard through a compatible client when a provider supplies a WireGuard configuration and you want that protocol's performance, but verify whether the selected Clash core supports the required fields.
• Use TUN carefully when applications ignore system proxy settings, but expect to review DNS, IPv6, local network access, and operating-system permissions.
• Avoid judging by the number of nodes. A long list does not prove speed, stability, privacy, or legal suitability. A smaller list from a transparent provider can be easier to maintain.

Check both the software and the service provider

There are two separate trust decisions. First, decide whether the client is maintained and obtained from a reliable distribution channel. Check its supported operating systems, bundled core, update history, permission requests, and whether it clearly identifies where profiles and logs are stored. A client should not require unrelated elevated permissions simply to switch a local proxy.

Second, evaluate the service that supplies the nodes or VPN gateways. Read its terms, retention statement, cancellation rules, traffic limits, and acceptable-use policy. Treat unusually cheap lifetime plans, copied brand names, unclear operators, and subscription links distributed through random messages as warning signs. A technically correct Clash profile cannot compensate for a provider that mishandles credentials or records more data than expected.

Protect the subscription URL as you would protect a password. Anyone who obtains it may be able to consume traffic quota, inspect account metadata, or access future node updates, depending on the service design. Avoid pasting private URLs into public converters, issue trackers, screenshots, or browser extensions. If a link is exposed, revoke or rotate it through the provider rather than merely deleting it from the client.

Avoid the mistakes that make the two look interchangeable

The first mistake is assuming that every application becomes protected as soon as the client window says “running.” A local proxy can be active while a particular application ignores it. The second is enabling TUN, system proxy, custom DNS, fake IP, and several rule providers at once. When something breaks, there is then no clear boundary between the working and failing layers.

The third mistake is treating a subscription update as proof that nodes work. A subscription may download successfully while a node has expired, a protocol is unsupported, a certificate is invalid, or the remote server refuses the connection. Check the connection log and test one node before changing the entire configuration.

The fourth is copying a configuration designed for a different core. A profile containing mihomo-specific fields may not run on an original Clash or Clash Premium binary. Errors such as “unsupported proxy type,” “unknown field,” or a missing rule provider usually point to a compatibility mismatch. Compare the core name and version before rewriting the YAML.

Finally, do not use a VPN or Clash client as a reason to ignore ordinary security practices. Keep browsers and operating systems updated, use HTTPS, protect account credentials, review client permissions, and do not install certificates from an unknown source merely because a guide says they are needed. If a website displays a certificate warning, stop and investigate it instead of clicking through.