Clash FAQ and Troubleshooting

Clash generally refers to a rule-based proxy tool and its client ecosystem. The original Clash core is no longer maintained. Clash Meta extended the original configuration system and later continued development under the name mihomo. Many desktop and mobile clients now use the mihomo core while retaining the Clash ecosystem name in their interfaces.

The core listens on ports, establishes proxy connections, performs DNS resolution, and matches routing rules. The client provides the graphical interface, subscription management, system proxy controls, and log viewer. Graphical clients usually bundle a compatible core; standalone mihomo deployments are more common on servers and routers.

The service provider maintains a subscription link, allowing the client to fetch nodes and proxy groups again by URL. Users save and edit local YAML files directly, making them suitable for fixed rules, testing, or offline management. Subscription updates may overwrite direct edits, so changes that must persist should go into a supported override or merge configuration.

Rule mode evaluates traffic against the YAML rules and is best for everyday use. Global mode sends most traffic through one proxy policy and is useful for brief node testing. Direct mode connects traffic without a proxy and helps determine whether the proxy path is causing the problem. Switch back to Rule mode after testing.

mixed-port accepts both HTTP and SOCKS5 connections, which is convenient when configuring application proxies manually on desktop systems. port provides HTTP proxying only, while socks-port provides SOCKS5 only. Ports can be changed, but must not conflict with other programs. Browsers, terminals, and system proxy settings must use the address and port the client is actually listening on.

Choose a client that is actively maintained and supports your system architecture. Windows users should usually select x64, macOS users should check for Intel or Apple Silicon, and Android users should match the package to their device architecture and system version. Most users should choose a graphical client; server users can consider a standalone mihomo deployment.

First verify that you imported the complete subscription URL, not the provider's dashboard address. Then check the configuration update record and core logs. Network errors usually mean the URL is unreachable, parse errors mean the response is not valid YAML, and an empty node list may indicate a subscription or client compatibility issue. Open the URL in a browser to check whether it redirects to a login page.

Configuration directories vary by client. Use the client's Configuration, Profiles, or Open Configuration Directory entry instead of copying files to an outdated path found online. Keep the original file before importing and confirm that its extension is .yaml or .yml. After manual edits, validate the configuration before reloading the core to avoid startup failures caused by indentation errors.

TUN mode creates a virtual network interface and changes system routes. Windows may require administrator access, macOS may request a network extension or helper component, and Android displays a VPN authorization dialog. If permission is denied, the client may appear enabled even though traffic does not enter the TUN interface. Authorize it again, then check the routing state.

First make sure the installer matches your Mac's chip architecture, then move the app to the Applications folder. If security settings block launch, check the blocked item in System Settings under Privacy & Security and follow the prompt to confirm the app can open. Do not keep multiple old versions with the same name, or login items and helper components may still point to the old path.

Check whether the HTTP, HTTPS, or SOCKS proxy in system network settings uses the current address and port, then confirm that the client's listening port has not changed. Some browsers, games, and command-line tools use their own proxy settings and ignore the system proxy. Configure those applications separately, or use TUN mode after confirming compatibility.

Some UWP apps are restricted from loopback access and cannot connect to Clash's local listening port. Use the client's UWP loopback tool to enable Loopback Exemption for the apps that need network access, then restart them. Select only apps that genuinely need the local proxy; check again after system updates or app reinstallation.

Enable LAN access in the client and make sure the listening address is not restricted to 127.0.0.1. On other devices, set the proxy server to the computer's LAN address and Clash listening port, and ensure both devices can reach each other. If the connection is refused, check whether the system firewall allows inbound access to that port.

Do not put long-term rules directly in the configuration body that subscription refreshes replace. Prefer the client's override, merge script, or extension configuration features, and apply custom DNS settings, proxy groups, and rules as a separate layer. After updating, check that rule order and proxy group names still match, and keep a known-good older configuration for rollback.

First confirm that the mode change was submitted to the currently running core rather than merely changing a UI option. Then close the target app's existing connections and try again, because browser connection pools, DNS caches, and QUIC sessions may reuse the old path. If nothing changes, inspect live connections to confirm whether traffic enters Clash and which rule it matches.

Check that the subscription URL is complete, has not expired, and contains no copied spaces. Then review the update log for its HTTP status and parse details. For connection timeouts, check the current network or temporarily update through a working proxy. A login page means you need to obtain the URL again; YAML parse failures require checking the provider's response format and core compatibility.

Switch to Direct mode first to confirm that the local network can reach the internet. Then check the system clock, client logs, and subscription status. If every node fails at once, likely causes include network blocking, DNS resolution errors, a stopped core, or firewall interference. If only some nodes fail, node maintenance, protocol parameters, or route quality are more likely.

Confirm that dns.enable is enabled, then check whether nameserver, fallback, and nameserver-policy match your routing goals. Browser Secure DNS, encrypted system DNS, and other network tools may bypass Clash, so avoid overlapping resolution mechanisms. After making changes, clear system and browser DNS caches and use connection logs to verify where queries are sent.

A port conflict means another process is listening on the same port. Common causes include launching the client twice, an old core that did not exit, or another proxy tool still running. Fully quit the related programs and check for leftover processes in Task Manager or Activity Monitor. If both programs must run, change mixed-port, port, or socks-port and update the system proxy settings accordingly.

Disable TUN first and confirm that basic networking returns. Then check virtual interface permissions, the default route, DNS settings, and conflicts with other VPN software. If LAN devices become unreachable, inspect route exclusions and private-address rules so gateway, printer, and NAS traffic is not mistakenly sent through the proxy. Change one item at a time and restart the core to isolate the cause.

Allow the client to run in the background in Android system settings, and set its battery policy to Unrestricted or the equivalent background-activity option provided by the device manufacturer. Make sure the persistent VPN notification remains visible so cleanup tools do not terminate the client. If disconnections occur only when switching between Wi-Fi and mobile data, reconnect and check the logs for network interface changes or DNS timeouts.