Clash FAQ and Troubleshooting

The client provides graphical controls for importing configurations, choosing proxy groups, switching the system proxy, and viewing logs. The kernel listens on ports, applies rules, handles DNS, and forwards traffic. A subscription service supplies configuration content or proxy nodes. Installing a client does not automatically provide a subscription, and the subscription provider is not necessarily the client developer. When troubleshooting, first determine whether the problem lies in the interface, kernel, or subscription content.

This is an independent English-language guide covering client download sources, configuration steps, and troubleshooting methods. It does not represent any client, kernel, or subscription service. Before downloading, verify the client name, supported operating system, and maintenance status on the download page. For feature differences, rely on the settings actually available in your client and kernel versions.

No. Importing a subscription only writes the remote configuration to the client. You usually still need to select that configuration, start the kernel, choose rule or global mode, and enable a traffic interception method such as the system proxy or TUN. Then visit a page that can verify the network path and check the client log for the corresponding connection. Seeing the subscription name alone does not mean traffic is passing through the kernel.

Rule mode evaluates the configuration rules from top to bottom; the first match determines whether to use DIRECT, REJECT, or a proxy group. Global mode usually sends interceptable traffic through the selected proxy group and is useful for briefly testing whether rules are causing access problems. Direct mode sends traffic straight to its destination. Global mode is not a speed boost, so before using it long term, verify that LAN access, system services, and required direct rules are configured correctly.

Open the subscription URL in a browser first and confirm that it returns configuration content rather than a login page, renewal notice, or error page. Then check that the URL was copied in full, the subscription has not expired, the device clock is accurate, and the client can reach the subscription domain. If the browser works but the client does not, review the update log for HTTP status, TLS, or timeout details, and check whether the client uses a separate proxy for subscription updates. Do not repeatedly delete the configuration, or you may lose local overrides.

Record the reported line number first, then check the indentation, colons, hyphens, and matching quotation marks on that line and the one above it. YAML indentation must use spaces; do not mix tabs and spaces. Fields at the same level must use the same indentation. If the error appeared after a manual edit, temporarily undo the latest change and reload the file. Keep subscription configuration and local overrides separate, or an update may overwrite content written directly into the original file.

First confirm that the device itself can access the internet directly, and check the system clock, subscription validity, and whether the node information was recently updated. Then test only one node and inspect the log to determine whether the failure is DNS resolution, connection refusal, handshake failure, or a plain timeout. If every node fails at once, the cause is more likely the local network, subscription content, or kernel configuration. If only one node fails, contact the subscription provider to verify its status. A failed latency test does not necessarily mean every real connection will fail.

Some Windows apps that use app-container network isolation cannot directly access a proxy listening on the local machine. In that case, you may need to remove the loopback restriction for the target app using the UWP loopback tool provided by the client. First confirm that a regular desktop app such as a browser can access the internet through the system proxy. Then select only the affected app and restart it. If the client has no loopback tool, follow its documentation and use the corresponding Windows mechanism; do not add every app indiscriminately.

First verify that the client’s HTTP or mixed listening port is running. Then open the system proxy settings and confirm that the address and port match the client. Check whether the browser has its own proxy extension, standalone proxy settings, or a policy that bypasses the system proxy. Temporarily disable those overrides and try again, while searching the client log for the target domain. If the log contains no record at all, the browser traffic has not reached the kernel, so switching nodes will usually not help locate the problem.

Many terminal programs do not automatically use the desktop system proxy. Set HTTP_PROXY, HTTPS_PROXY, or ALL_PROXY for the current shell or specific program, using the protocol and port actually exposed by the client. Reopen the terminal, confirm that the environment variables are active, and use verbose command output to inspect the connection target. Also check that the program has not overridden the environment variables with its own proxy options. Remove temporary variables after testing to avoid affecting package managers or LAN access.

TUN creates a virtual network interface and modifies system routes, so the client may require administrator privileges, VPN configuration, a network extension, or authorization for a helper service. Follow the authorization flow shown by the current client, then restart the kernel and verify that the virtual interface was created. On macOS, pay attention to network-extension and VPN-configuration prompts. On Linux, check service permissions and whether the TUN device is available. Do not bypass normal authorization by disabling system security controls.

It depends on the client implementation. The system proxy mainly affects apps that follow the operating system’s proxy settings, while TUN uses a virtual interface to intercept more network traffic. Some clients keep the system proxy enabled after TUN is turned on for compatibility with specific apps; in other cases, only one is needed. During initial troubleshooting, verify the system proxy on its own before enabling TUN. Changing both traffic paths at once makes it harder to determine whether the problem comes from loopback, routing, or DNS.

No. no-resolve usually follows rules such as IP-CIDR and tells the kernel not to proactively resolve a domain to an IP address while evaluating that IP rule, avoiding extra lookups or changes to the rule-evaluation path. It does not disable all DNS and does not replace DNS settings such as nameserver, fallback, or fake-ip. For domain-resolution problems, check the DNS configuration, system resolution path, and logs instead of deleting every no-resolve marker.

First disable the system proxy or TUN and confirm that direct access returns. Then restart the client kernel and check whether another program is using the listening port. Choose a known-good configuration and node, and run a brief comparison test in global mode: if global mode works but rule mode fails, inspect the rules and proxy groups; if both fail, review DNS, node-connection, and handshake logs. Change only one setting at a time so that switching modes, DNS, and nodes together does not make the result impossible to reproduce.

Disable TUN first and verify whether the problem disappears immediately. Then inspect the client log for route creation, interface startup, and DNS errors. If LAN access fails, confirm that private address ranges remain DIRECT and that the TUN configuration excludes the local gateway, printers, or corporate network ranges. If another VPN, virtual network adapter, or network-filtering tool is running, temporarily disable them one by one to test for conflicts. Record the original routing settings before making changes, and confirm how to restore them before continuing.

A subscription update usually replaces the corresponding configuration with remote content, so local rules and proxy-group selections written directly into the subscription file may be reset. Check whether the client supports overrides, merging, script processing, or preserving proxy selections, and keep personal rules in a separate local maintenance layer. Record important proxy groups and rules before updating, then check whether group names changed and referenced targets still exist. If the remote structure changed, update the override rules accordingly instead of continuing to reference an old group name.

Open the client’s connection records or kernel log, revisit the target domain, and check the matched rule type, rule content, and final proxy group. If the route differs from expectations, inspect earlier DOMAIN, DOMAIN-SUFFIX, GEOIP, RULE-SET, or IP-CIDR rules, because rules are matched in order and later rules cannot override an earlier match. Use a temporary custom rule for a focused test, then add the confirmed result to a stable local override instead of editing a file that subscription updates may replace.