Built around your device and workflow, this guide covers client selection, subscription import, and system proxy setup. Establish a working basic connection first, then configure TUN, DNS, and rule details as needed.
A Clash client's graphical interface mainly manages configurations, switches operating modes, and controls the system network entry point. The core processes connections according to the config file, while the client organizes common actions into visible settings. The sections below break down several commonly confused parts in the order they are configured.
Clash
Profiles
config.yaml
A config file typically contains proxy providers, policy groups, routing rules, ports, and DNS parameters. When getting started, verify the source of the subscription link, then import it from the client's config or subscription page. A successful import only means the file can be read; you still need to set it as the active config. When a subscription is updated, the client fetches the remote content again, so local edits may be overwritten. Long-term custom rules are better kept in an override or merge config. If an update fails, check the link is complete, the network is reachable, the system time is accurate, and the remote service returns valid YAML.
DOMAIN-SUFFIX,example.com,ProxyGEOIP,CN,DIRECTMATCH,FinalRule mode does not send every connection through one policy. Instead, it matches the configured rules from top to bottom. Once a domain, IP, process, or rule set matches, the connection is sent to the specified policy group. Groups can be selected manually or choose an available option automatically. Before enabling the system proxy, check the current selections for groups such as Proxy, Streaming, and Final on the Proxies page. Rule order directly affects the result: more specific rules usually come first, while the final catch-all rule belongs at the end. Compared with tools that offer only one global switch, this structure makes direct, proxied, and rejected traffic easier to review in one configuration.
localhost
The system proxy points the operating system's HTTP and SOCKS proxy endpoints to the client's listening port, which browsers and most desktop apps read automatically. After enabling it, keep the client running and confirm that the active config has loaded. Some programs ignore the system proxy or maintain their own network stack, so enabling this setting alone will not change their connection path. Before closing the client, disable the system proxy to prevent the system from pointing at a local port that is no longer listening. Enable LAN connections only when other devices genuinely need access to the local proxy port, and restrict access with a firewall and trusted network environment.
TUN mode receives system traffic through a virtual network interface, making it useful for game launchers, command-line tools, and apps that ignore the system proxy. It covers more traffic than a regular system proxy, but relies more heavily on operating system permissions, routing tables, and firewall state. On first enablement, the client may request administrator access or install a network component. After setup, verify common websites and local network access before adjusting advanced options such as strict routing and interface exclusions. If the network goes offline, disable TUN first, confirm that the basic system proxy works, then check for routing conflicts among the virtual interface, other VPN software, and security tools.
dns:
enable: true
enhanced-mode: fake-ip
nameserver:
DNS settings affect how domains are resolved and whether some rules match as expected. With built-in DNS enabled, the client can select a nameserver, fallback, and enhanced mode according to the config, reducing inconsistencies between the system and proxy resolution paths. fake-ip suits transparent routing scenarios, but LAN devices, special domains, or some apps may need to be added to an exclusion list. When troubleshooting, change one parameter at a time: first confirm that the config syntax loads, then check whether queries pass through the client, and finally observe which rule matches the target domain. If other DNS tools are running, also check for conflicts on listening ports and network interfaces.
Import and enable the config file first, select a regular exit in the policy groups, then enable the system proxy and test browser access. Configure TUN only when an app does not follow the system proxy. Adjust DNS after the basic connection is stable so any issue can be clearly traced to the subscription content, proxy entry point, routing, or resolution path.
Rule mode evaluates the config file line by line to decide whether traffic goes direct, through the proxy, or is rejected, making it suitable for everyday use. Global mode sends most connections through the current global policy and is useful for briefly checking whether rules are missing a match. Direct mode bypasses the proxy. Switching modes does not repair an invalid subscription or automatically fix a disabled system proxy, so check the config state and entry-point state separately.
Installation formats, system permissions, and proxy entry points vary by platform. The download page lists available graphical clients, archived clients that are no longer maintained, and core files intended for servers. The homepage provides platform links but does not distribute installers directly.
Graphical client with system proxy and TUN support. Check your system architecture before installing, and review loopback settings if UWP apps bypass the proxy.
Go to downloadsChoose the Apple Silicon or Intel build. First launch may require security approval; command-line tools may need environment variables or TUN mode.
Go to downloadsUses Android's VPN interface. Approve the VPN prompt after import, and allow background activity so battery-saving settings do not pause the client.
Go to downloadsUses the iOS network extension. Approve VPN access on first connection, import your subscription, and verify policy groups after changing configs.
Go to downloadsUse a graphical client on desktops or Mihomo core on servers and routers. Match the architecture and package, then configure TUN or TProxy, DNS, and startup services.
Go to downloadsGraphical clients provide config import, policy switching, log viewing, and system toggles for personal devices. The core reads the config and handles connections, making it suitable for users familiar with command-line tools, service management, and network routing. They are not the same installation form; starting with a graphical client is usually easier for diagnosing initial issues.
Clash is not a single fixed installer for one platform. It is an ecosystem made up of a core, graphical clients, rule projects, and configuration tools. Understanding these boundaries helps identify where an update came from and prevents client interface issues from being confused with core configuration problems.
The early Clash core established a workflow based on YAML configuration, rule matching, and policy group selection, followed by graphical clients for Windows, macOS, Android, and other platforms. Some early projects are no longer maintained, but their config structures and usage patterns remain widespread. When choosing what to use today, do not rely only on the client name in an old guide; also check the project's maintenance status, target system support, and the core branch in use.
Mihomo continues and extends capabilities associated with Clash Meta. It parses configs, opens listening ports, processes rules, runs policy groups, and handles DNS logic. A graphical client provides the interface around it, and different clients may use different update methods, override structures, and system integration approaches. The entry-point names for the same subscription may therefore vary, but the troubleshooting path remains consistent: verify the config, verify that the core is running, verify that system traffic reaches the listening endpoint, and verify that rules select the expected policy.
Subscriptions are usually generated by service providers, while rule sets may come from independently maintained open-source projects. The client only reads and executes this content; it does not fix format errors in a remote subscription. Before importing, verify the link's source and purpose, and never expose a subscription URL containing personal access information in logs, screenshots, or code repositories. For long-term custom rules, store personal overrides separately from the remote subscription to avoid redoing edits after every update.
Client updates, core updates, and subscription updates are three separate paths. A client update changes the interface and platform integration; a core update may add configuration capabilities or fix network handling; a subscription update changes proxy providers, policy groups, and rules. When an issue appears after an update, first identify which layer changed, then review the corresponding logs and config differences. During stable use, there is no need to change every layer at once; staged updates are easier to roll back and troubleshoot.
A YAML file can clearly define listening ports, DNS, policy groups, and rule order. Keep a working copy before making changes and adjust one category of parameters at a time, making it easier to identify which section caused an error.
A failed connection does not necessarily mean the node is the problem. Logs can distinguish config parsing failures, DNS resolution errors, rule-match results, port conflicts, and a system entry point that was not taken over. Start troubleshooting with the specific error message.
Subscriptions, rule sets, the core, and graphical clients each have distinct boundaries. If a graphical client is no longer maintained, you can migrate to a compatible client; before migrating, export personal overrides and recheck platform permissions and system proxy settings.
These technical notes cover first-time setup, DNS, port conflicts, and platform-specific issues. Each article explains where to make a change, what a command does, and what order to check things in, making it useful alongside the basic guide when investigating a specific symptom.
Answers cover how to choose a client, import a subscription link, distinguish rule mode from global mode, understand why the system proxy is not working, and verify the result after switching policies. Each answer points to the relevant setting in the client.
Read the full article →Start with browser tests and command-line queries to confirm whether DNS bypasses the client, then explain the relationship between enhanced-mode, nameserver, and fallback. Change one parameter at a time to avoid altering the resolution and proxy paths simultaneously.
Read the full article →Learn how to identify the process listening on a port in Windows, macOS, and Linux, determine whether it is a leftover client or another network tool, and update both the client's listening port and the system proxy settings so changing only one side does not leave connections failing.
Read the full article →