Clash Subscription Formats: Base64 Proxy Lists, YAML Configs, and Share Links

Start with the terms: Clash, proxy, VPN, and subscription are different things

Clash is best understood as a proxy client and traffic-routing engine, not as a VPN service by itself. A desktop or mobile client provides the interface for importing configuration, selecting policies, and starting a core such as mihomo. The core accepts traffic from applications, evaluates configured rules, and sends each connection to a selected proxy, directly to its destination, or to a rejection policy.

A VPN service is usually a provider-operated network reached through a VPN protocol. Its app connects your device to a remote VPN server, and the operating system can route some or all network traffic through that connection. A VPN provider commonly supplies the server infrastructure and account access. Clash does not automatically include either a remote server or an account. You need a usable configuration and, if you intend to proxy traffic, an available proxy endpoint.

A proxy is an intermediary for a connection. With a conventional per-app proxy setting, only applications that use that setting may send requests to it. A Clash rule can choose whether a connection uses a proxy node, but the word “proxy” does not guarantee that every application on the device will use Clash. How traffic reaches the local core depends on the operating system, client settings, and the way each app handles networking.

A subscription is a way of obtaining configuration data, often through a URL. It may provide proxy nodes, a complete YAML configuration, or data that a particular client knows how to convert. The subscription is not the same thing as Clash, a VPN tunnel, or a proxy protocol. Importing a URL successfully does not prove that the returned configuration is valid, that its nodes are reachable, or that every traffic rule behaves as you expect.

• Clash client: The application you operate, such as a desktop GUI or an Android client.
• Core: The engine that reads configuration, manages connections, and applies routing policies; many current clients use mihomo.
• Proxy node: A remote endpoint and its connection settings, supplied by your configuration or provider.
• Subscription: A delivery method for configuration or proxy data, which may be refreshed over time.
• VPN mode or TUN mode: A way for the client to capture system traffic through a virtual network interface; it does not by itself provide a remote VPN service.

Compare the traffic paths before choosing a tool

The practical difference is not simply “VPN encrypts, proxy does not.” Encryption depends on the protocol used between your device and the remote endpoint, and the destination website may add its own HTTPS encryption. Instead, compare which traffic is captured, where routing decisions happen, and who operates the remote server. A VPN app commonly creates an operating-system tunnel to its provider. Clash can use an application proxy, a system proxy, or a TUN interface to bring traffic to its core, then apply its own rules.

For example, imagine a browser connection to example.com. If the browser uses the Clash system proxy, the connection reaches the local proxy port. The core checks the rules, selects a policy group, and the group chooses either a remote node or DIRECT. With a TUN setup, the operating system instead sends eligible IP traffic to a virtual interface; the core still needs to determine how to route it. With a VPN app, the operating system sends eligible traffic into the VPN tunnel to the provider’s server, where it exits according to that provider’s network design.

These paths can overlap in what they achieve, but their control points differ. A VPN is often simpler if you want one provider app and a relatively broad device-level tunnel. Clash can be more flexible when you want per-domain or per-IP routing, different policy groups, and the option to send selected destinations direct. That flexibility also means there are more settings to verify: rules, DNS behavior, proxy-group choices, and the method used to capture traffic.

Do not use the presence of an Android VPN icon or a “TUN running” status as proof that all traffic uses a remote server. The indicator may only mean that the local client has created a virtual interface. A connection that matches a direct rule can still leave the device without going through a proxy node. Likewise, a latency test to one node checks only a particular test target; it does not verify every site, app, or DNS request.

Understand rules, DNS, and encryption in everyday use

Rules are the part of Clash that answers “which route should this connection take?” In rule mode, the core checks rules in order and uses the first applicable match. A rule may match a domain, IP range, process, or other supported attribute, depending on the core and configuration. The action can direct the connection to a proxy group, send it to DIRECT, or reject it. A final catch-all rule commonly handles traffic that did not match an earlier entry.

mode: rule

proxy-groups:
  - name: Choose route
    type: select
    proxies:
      - Example node
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,Choose route
  - DOMAIN,local.test,DIRECT
  - MATCH,Choose route

This is an illustrative fragment, not a complete working configuration: Example node must exist in the configuration, and the supported fields depend on the core. It shows why a proxy node alone does not define behavior. The node describes a possible remote connection, while the group presents route choices and the rules decide which group or action receives a connection. If a group has DIRECT selected, traffic assigned to that group may go direct even though a proxy node is also listed.

DNS is related to routing but is not the same setting. A domain name must be resolved to an address for a connection to be made. Depending on the client, core, DNS mode, and rules, a lookup may be handled locally or through configured DNS servers. A wrong DNS setup can make a site fail to resolve or can make domain-based routing less predictable. If a site fails, check whether the core logs a DNS error and whether the connection history shows a selected policy; do not immediately conclude that the proxy node is down.

Encryption also has layers. A connection from your device to a remote proxy endpoint may be protected according to the selected proxy protocol and its configuration. A browser session using HTTPS has a separate encrypted connection to the website. These are not interchangeable guarantees. A proxy node does not automatically encrypt every local link, DNS request, or application connection, and a VPN tunnel does not make a destination website trustworthy. Check the protocol and provider documentation, and use HTTPS for websites that support it.

• Destination routing: Confirm which rule matched and which policy group was selected for the connection.
• DNS: Check the configured DNS mode and the client or core log when domains fail but direct IP access behaves differently.
• Capture method: A system proxy may not capture apps that ignore system proxy settings; TUN can capture more IP traffic but may need permissions and routing support.
• Direct routes: DIRECT is a valid policy, not an error. It means the connection does not use the selected remote proxy node.
• Provider trust: The operator of a remote endpoint may be able to observe connection metadata. Review the provider’s terms and privacy practices before using it.

Choose a beginner setup that matches your goal

Before downloading a client, decide what you need it to do. If you want a provider-managed, device-wide tunnel with minimal routing choices, a VPN service may be the simpler starting point. If you already have a compatible Clash or mihomo configuration and want to choose routes by destination, a Clash client may fit better. If you only need to proxy one browser, a browser or operating-system proxy setting may be enough, provided the browser actually honors that setting.

For a first Clash setup, keep the test narrow. Install a client compatible with your operating system, import a configuration from a source you trust, and confirm that it parses without errors. Check that the active configuration contains at least one usable proxy node and that each referenced policy group exists. Start with Rule mode and select a known node in the relevant group. Do not begin by enabling several capture methods or editing DNS, TUN, and rules at the same time; changing one variable at a time makes errors much easier to isolate.

1. Identify what you received. A subscription URL, a complete YAML configuration, and a list of proxy share links may require different import methods. Use the client’s subscription or configuration import feature that matches the supplied format.
2. Check the active profile. Confirm that the imported profile is selected, refresh it if necessary, and inspect the client log for parse errors or unsupported fields.
3. Choose a route deliberately. Select a policy group and an available node rather than assuming that importing a profile automatically selects the route you want.
4. Enable one traffic path. On a desktop, test the system proxy first if that is the client’s intended mode. On Android, grant the VpnService request when prompted. Enable TUN only when you need broader system traffic capture and understand the platform permissions it requires.
5. Test more than one result. Open a site that should use the proxy and inspect the connection history or logs. Then test a destination expected to go direct. Check both actual page loading and the policy shown for each connection.

If you choose a desktop system proxy, remember that enabling it does not transform every network connection into a tunnel. It typically configures supported applications to use a local HTTP or SOCKS proxy. Some games, command-line tools, and apps with custom networking stacks may ignore it. If broad application coverage is important, investigate the client’s TUN support and its trade-offs before enabling it. TUN can require administrator approval on desktop platforms and can conflict with another VPN or network filter.

On Android, Clash clients commonly use the system VpnService API to create a virtual interface. The permission dialog authorizes the app to establish that local interface; it does not grant a subscription, make a node reachable, or guarantee that a remote proxy is selected. Android generally permits only one active VPN service per user profile, so another VPN, firewall, or ad-blocking app may need to be disconnected during testing. Battery restrictions can also stop a client in the background, but background behavior is separate from whether the current route is correct.

Whichever option you select, keep access details private. A subscription URL may contain a credential or act as a bearer link: anyone who obtains it could be able to retrieve or use the associated configuration. Do not post it in screenshots, public forums, or diagnostic logs. When a subscription stops working, confirm its expiration and account status with its provider rather than repeatedly changing local routing settings. If a subscription update changes nodes or rules, review the active configuration again; remote updates can change what routes are available.

Make the choice based on control, coverage, and trust

Choose a VPN service when the provider’s managed tunnel and simpler server selection match your needs. Check which devices and protocols it supports, what its application routes by default, whether it offers split tunneling, and how it handles DNS. A VPN provider is still a party you must trust with traffic that reaches its servers. A tunnel can protect traffic between your device and the VPN endpoint, but it does not erase the provider’s role or protect you from every risk on the public internet.

Choose Clash when you need configurable routing and have a reliable source for compatible configuration data. Its advantage is policy control: different destinations can use different groups, direct access can be retained for selected traffic, and the client can expose logs and connection details for troubleshooting. The cost is setup responsibility. You need to understand which core is running, how the selected client captures traffic, what the rules do, and who operates the remote proxy endpoints.

Neither option should be judged by a single label or icon. “VPN mode” in a client may describe the local operating-system interface used to capture traffic, not a paid VPN service. “Connected” may describe a local core or interface that is running, not the reachability of every proxy. A fast latency result does not prove that the correct route is used for your apps. Verify the path from application to local capture method, through the rules, to the selected remote endpoint or direct destination.

• If you want fewer configuration decisions, compare reputable VPN services and read their routing and privacy documentation.
• If you need destination-based policies, select a maintained Clash client with a core compatible with your configuration and learn its system proxy or TUN controls.
• If you only need one application to use a proxy, first check whether that application supports an explicit proxy setting.
• If you do not have a valid configuration or provider endpoint, installing Clash alone will not create remote access.
• If traffic takes an unexpected route, inspect the active profile, matching rule, selected group, DNS result, and capture method before changing several settings at once.

The most useful beginner question is therefore not “Is Clash a VPN?” but “What captures this app’s traffic, which rule handles it, and who operates the remote endpoint it reaches?” Once those three parts are clear, choosing a client becomes more straightforward, and troubleshooting becomes a matter of checking a visible traffic path rather than guessing from a VPN icon.