What Is Clash? A Beginner Guide To Clients And Subscriptions

Clash is a proxy manager, not a VPN provider

The first idea to correct is simple: Clash is not a company that sells an internet connection, and it is not a VPN subscription that you activate by creating an account. Clash is a proxy management tool. It provides a way to load proxy information, choose how traffic should be routed, apply domain and IP rules, and connect applications to compatible proxy nodes.

A complete working setup normally contains several separate parts: a client application, a proxy core, a configuration file, a subscription source, and one or more proxy nodes. These terms are often mixed together because a graphical application may display all of them in one window. However, they have different jobs and may come from different developers or services.

A VPN provider usually operates the remote servers and gives you an application or protocol profile to connect to them. A Clash client generally does not include remote servers. If you install FlClash without importing a usable configuration, the application can open normally but has nowhere to send traffic. Likewise, purchasing a subscription from a provider does not automatically install a client, enable a system proxy, or grant permission to create a TUN interface.

Clients and cores: the two pieces inside the app

A Clash client is the application you see and operate. It commonly has pages for profiles, proxies, proxy groups, rules, connections, logs, and general settings. Depending on the platform, it may also change the operating system proxy, install a helper service, request TUN permissions, or provide a tray menu.

FlClash, Clash Verge Rev, Clash for Windows, ClashX, and Clash for Android are examples of client applications or client families. Their interfaces and packaging differ, but the basic workflow is similar: import a profile, select a profile as active, start the core, and decide how the operating system should send traffic through the local proxy.

The core is the network engine behind the interface. It parses YAML, creates inbound listeners, resolves DNS, checks rules from top to bottom, selects a policy group, and establishes the outbound connection to a node. A client window can appear healthy while the core is stopped, using an incompatible configuration, or unable to bind its local port. For this reason, the client status, core log, and local port status should be checked together.

How local ports fit into the connection

Most desktop configurations expose a local HTTP and SOCKS service through a mixed port. A common example is 7890, although the actual value depends on the profile. Applications that support a manual proxy can be configured to use an address such as 127.0.0.1:7890. The loopback address means that the application is connecting to the proxy core running on the same device.

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

The external-controller value is not the same thing as the traffic proxy port. It is an API endpoint used by the graphical client to query connections, change policy selections, and control the core. Leaving it bound to 127.0.0.1 limits access to the local device. Enabling LAN access or binding services to a wider address should be done deliberately because an exposed proxy or controller can allow other devices to use or control the service.

System proxy mode and TUN mode are different

System proxy mode changes the operating system’s HTTP and SOCKS proxy settings. Browsers and applications that respect those settings can then send requests to the local core. This mode is easy to inspect and is a good starting point for ordinary web browsing.

TUN mode creates a virtual network interface and captures traffic at a lower networking layer. It can cover programs that ignore system proxy settings, including some games, command-line tools, launchers, and desktop applications. TUN also introduces more variables: administrator permissions, routes, DNS behavior, exclusions, and possible conflicts with other VPN or security software.

Do not enable TUN merely because it sounds more powerful. Start with system proxy mode, confirm that the profile and nodes work, and enable TUN only when a specific application cannot use the system proxy. When diagnosing a problem, temporarily return to the simpler mode so that the number of possible causes is smaller.

What a proxy subscription actually contains

A subscription is usually a long URL containing an access token. When the client requests that URL, the provider returns configuration data. The response may be YAML, Base64-encoded content, or another format that the client or provider has prepared for a particular application type. The result can contain proxy nodes, proxy groups, rules, DNS settings, rule-set URLs, and update metadata.

The subscription link is not an installer and is not the same as a single node. It is better understood as a remotely generated configuration source. A provider may change the available nodes, remove expired servers, add a new protocol, or change policy groups without requiring you to copy a new YAML file manually.

Nodes, policy groups, and rules

A node describes one outbound connection. It normally includes a server address, port, protocol, authentication data, and optional transport or security parameters. Examples include Shadowsocks, VMess, Trojan, Hysteria2, TUIC, VLESS, HTTP, and SOCKS5. The exact protocols supported depend on the core and the configuration syntax.

A policy group organizes nodes into a choice that rules can reference. A group might contain a manually selected node, an automatic latency test, a fallback list, or another nested group. The name shown in the interface, such as “Proxy,” “Auto,” or “Streaming,” is only a label. The actual behavior is defined by the proxy-groups section.

Rules decide which policy receives a request. A configuration may send local addresses directly, route advertising domains to a reject policy, send international domains to a proxy group, and use a final fallback for anything not matched earlier. Rule order matters because many cores evaluate rules from top to bottom.

proxy-groups:
  - name: Proxy
    type: select
    proxies:
      - Auto
      - DIRECT

  - name: Auto
    type: url-test
    url: https://www.gstatic.com/generate_204
    interval: 300
    proxies:
      - Node A
      - Node B

rules:
  - DOMAIN-SUFFIX,example.local,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

This example is only a structural illustration. A real subscription may use different node names, rule providers, DNS settings, and protocol fields. Do not paste arbitrary fields into a profile simply because they appear in another client. A field supported by mihomo may be rejected by an older classic Clash core, and a profile generated for one client type may not be appropriate for another.

A practical first setup with a compatible client

The safest beginner workflow is to establish one layer at a time. Do not enable every advanced feature before confirming that the basic path works. The following process applies conceptually to FlClash and other clients, although menu names can differ by platform and release.

1. Choose a maintained client and compatible core. Confirm the operating system, CPU architecture, and core family supported by the application. If the subscription contains mihomo-specific protocols or fields, use a client that can run mihomo rather than assuming an old classic core will parse everything.
2. Obtain the subscription from the provider’s account page. Copy the complete URL, including its token and query parameters. Avoid copying a shortened link from a chat message or browser history if the provider offers a dedicated copy button.
3. Import the profile. Open the client’s Profiles or Config page, choose the URL import option, paste the link, and save it with a clear name. Keep the original URL private and do not replace it with a manually copied node list unless you have a specific reason.
4. Update the profile once. Wait for the download and parsing process to complete. If the client reports a YAML or unsupported-field error, inspect the core compatibility before changing DNS or enabling TUN.
5. Set the profile as active. Importing a profile does not always make it the running profile. Select it explicitly, then open the Proxies or Groups page and check that nodes and policy groups are visible.
6. Start the core without TUN first. Enable the client’s normal running state and confirm that the local mixed port is listening. If the client offers a system proxy toggle, enable it after the core has started.
7. Choose a policy. In the main proxy group, select a usable node or an automatic group. A group with no selected member, an expired node, or an unsupported protocol cannot forward traffic even when the profile imported successfully.
8. Test a simple request. Open a normal website, then review the client’s connection list. A request appearing in the list confirms that traffic reached the core; the selected node and log entries help determine whether the outbound connection succeeded.
9. Enable TUN only if necessary. If a particular program bypasses the system proxy, stop the test, review its permissions and route settings, and then enable TUN. Test again with only one major change at a time.

During this process, a local configuration may look similar to the following:

mode: rule
log-level: info
mixed-port: 7890
external-controller: 127.0.0.1:9090
proxies:
  - name: Node A
    type: socks5
    server: proxy.example.invalid
    port: 443
    username: user
    password: hidden

The values above are placeholders, not a working service. Never substitute a random server name or credentials and expect a connection. The provider must supply valid node details, and the protocol fields must match the core’s supported syntax.

How to evaluate a proxy subscription before paying

Because Clash itself does not provide nodes, the quality of the final connection depends heavily on the subscription service. A low price does not guarantee poor performance, and a large node count does not guarantee reliability. Evaluate the service based on transparency, compatibility, limits, and support rather than on a single advertised speed number.

Be cautious with services that promise unlimited speed, permanent access, or guaranteed compatibility with every Clash client. Protocol support, route quality, congestion, DNS behavior, and destination restrictions all affect the actual experience. A profile with dozens of nodes may still perform poorly if the nodes are overloaded or if the provider’s control panel generates fields your client cannot parse.

Use a separate profile name for each provider, keep the update interval reasonable, and avoid refreshing the subscription repeatedly during a temporary outage. Frequent requests may trigger a rate limit such as 429 Too Many Requests. If an update fails, first verify the URL and provider status, then test from another network. Do not immediately delete a working local profile before you know whether the issue is with the remote subscription or the client.

Common mistakes and a reliable troubleshooting order

Many first-time problems come from confusing a successful import with a successful connection. A profile can download correctly but contain no usable nodes. A node can pass a latency check but fail for a particular destination. The system proxy can be enabled while the core is stopped. TUN can be active while another VPN application owns the route. Each symptom points to a different layer.

• The client opens but no traffic works: Check whether the core is running, whether a policy group has a selected node, and whether the local proxy port is listening.
• The subscription fails to update: Check the complete URL, token expiry, HTTP status, DNS resolution, and whether the provider requires a particular User-Agent or update proxy.
• The profile imports but nodes are missing: Read the core log for unsupported protocol, YAML parsing, or provider-side filtering errors.
• Browsers work but one application does not: That application may ignore system proxy settings. Test its own proxy options or consider TUN after basic routing is confirmed.
• Some domains work and others fail: Review rule order, DNS mode, the selected policy group, and whether the destination is blocked or unavailable through the chosen node.
• Another device cannot use the proxy: Check allow-lan, the listening address, firewall rules, and whether the client intentionally restricts access to localhost.
• The client reports a port conflict: Stop another Clash client, VPN, or background core, or assign a different unused local port. Two processes should not listen on the same address and port.

Change one variable at a time. For example, first test a different node without changing DNS; then test the same node with another DNS mode; only afterward change TUN or rule behavior. Record the time, selected node, profile name, core version, and exact error message. This information is far more useful than repeatedly reinstalling the client.

Finally, remember that a proxy tool is not a guarantee of anonymity or security. HTTPS still matters, DNS requests may be handled by the configured resolver, and the proxy service can observe connection metadata available to it. Keep the client and core updated, restrict the external controller to localhost unless LAN control is genuinely needed, protect subscription tokens, and review permissions before enabling TUN.