Clash FAQs
Config & Connection Troubleshooting

Clash usually refers to a proxy core and its configuration ecosystem, while mihomo is an actively developed core project within that ecosystem. Clients such as Clash Verge Rev and FlClash provide interfaces for importing configs, selecting policies, and integrating with the system; the core handles traffic processing. Whether a config can be imported depends on the client’s bundled core version and supported fields, not just the app’s name. When reporting compatibility issues, include the client name and version as well as the core version.

A client can route traffic and apply rules, but installing the app does not provide a proxy service. To connect, you’ll typically need a subscription link from a service provider or proxy server details that you maintain yourself. After importing a config, make sure it’s active, then check that its proxy groups have an available outbound. Don’t mistake a regular website URL for a subscription link, or submit subscription links to untrusted online converters: they may contain credentials that grant access to your account.

Rule mode selects an outbound based on the order of rules in your config, making it useful for routing different sites and apps separately. Global mode applies a global policy to connections handled by the core; it doesn’t guarantee that apps whose traffic isn’t intercepted will use the proxy. Direct mode sends connections handled by the core straight to their destinations. You can briefly switch to Global mode for comparison while troubleshooting, but restore your original mode afterward. If Global works but Rule doesn’t, check which rule matched and which proxy group it uses.

System proxy advertises a proxy address to apps that follow system settings. TUN uses a virtual network interface and routes to capture more connections. They don’t have to be enabled together, and they don’t do exactly the same thing. For an initial setup, start with system proxy only and confirm your browser connects; try TUN afterward if needed for games, command-line tools, or other apps. Some clients support using both, but if problems occur, use only one traffic interception method at a time. This makes conflicts with other VPNs or proxy tools easier to diagnose.

Publicly shared proxy outbounds can stop working at any time, and their operators, traffic policies, and maintenance schedules are often unclear. Don’t rely on them for long-term availability. A proxy also doesn’t replace a website’s own encryption. Before signing in to sensitive accounts, make sure HTTPS is working and reject requests to install certificates from unknown sources. If a connection fails, first determine whether one outbound is down or local traffic interception is malfunctioning. Don’t repeatedly install unfamiliar clients just to switch outbounds. Follow the laws and service terms that apply where you are.

First check your provider’s account page to see whether the subscription expired or the link was reset. Then make sure the copied link has no extra spaces and includes all query parameters. A 403 usually means the request was denied, though access policies or client identification may also be involved; check your provider’s guidance. If updates fail only through a proxy, try updating directly if your client supports it. If direct access doesn’t work, use an outbound you’ve confirmed is available. If the issue persists, note the status code and time and contact your provider. Don’t share the full subscription link.

First determine whether the problem is invalid file syntax or core compatibility. YAML depends on indentation: use spaces, not tabs, and check that colons, list hyphens, and quotation marks are correctly placed. If the logs identify an unrecognized field, check the required core type and your current core version. A login or error page downloaded from a website can’t be imported as a config. Keep a copy of the original file and change one thing at a time, validating after each change. For subscription-generated configs, use your client’s override feature where possible so updates don’t erase your changes.

First confirm that your client and operating system support the selected TUN implementation. Windows clients typically require their service mode to be installed and running. On macOS, you may need to authorize a system extension or helper service as prompted. On Linux, follow the client documentation to grant the permissions needed for virtual interfaces and routes. Don’t grant elevated permissions to every program. After authorization, restart the core and check whether the interface was created. If it still fails, disconnect other VPNs and try again, noting the exact error from interface creation or route setup.

Check that the system proxy address points to your local machine and that its port matches the active config’s listening port, then confirm the core is running. Browser extensions, separate proxy settings, and organization policies can override system settings, so disable conflicting options and test again. Check the client’s connection log: if no connection appears when you visit a site, focus on how traffic enters the core. If a connection is logged but goes Direct, check the mode and rules. Don’t rely only on an IP-checking site to diagnose the issue; caching, site-specific routing, and browser behavior can all affect the result.

If a port is already in use, close any duplicate client instances or identify the process using it, then set mixed-port to an unused port and update the proxy address in your app. Don’t mix HTTP and SOCKS proxies arbitrarily; use the protocol the app supports. Terminal tools may not read the system proxy, so you might need to set HTTP_PROXY, HTTPS_PROXY, or ALL_PROXY separately. Start with a temporary setting while troubleshooting. Once it works, decide whether to make it permanent, and remove any environment variables you no longer need before closing the client.

Switching policies usually affects new connections first; existing connections may continue using their original outbound. Pause playback and reopen the page, or close only the relevant connections in the client’s connection panel, then check the policy chain on new connections. Also confirm that the destination matches the proxy group you changed: some configs use separate groups for video, downloads, and other traffic. Don’t close every connection as a routine step, since that could interrupt file transfers, meetings, or other active tasks.

In the connection log, find a recent request by destination domain or app and check the matched rule, proxy group, and final outbound. Rules are usually evaluated from top to bottom, so a broad rule near the top can take precedence over a more specific rule below it. Before making changes, note the destination and current match, then move any necessary specific rule to the right place. MATCH is typically the final fallback. For GEOSITE or rule sets, also check that the relevant data files and rule-providers loaded successfully.

If you edit a subscription-generated file directly, the next update may overwrite your changes with remote content. To keep rules long term, use your client’s override, merge, or script extension features, and check the order in which they’re applied. The options and merge behavior vary by client. Export a backup before saving, then check the final active config after an update—not just the text in the editor. Any proxy group referenced by a new rule must exist, or the config may fail to load or report an invalid outbound reference.

A latency test usually measures the round-trip time for a single request; it doesn’t indicate sustained bandwidth, congestion, or performance on a particular site. Use the same download target to compare Direct access with different outbounds, then check your Wi-Fi, background downloads, and server-side speed limits. If only one site is slow, check the outbound and resolved address used for that site instead of relying on the test button. Keep conditions consistent while troubleshooting: changing DNS, mode, and node at once makes it hard to tell what helped.

Usually not. Hotel, campus, and transit networks may require a web sign-in before access is available, and a proxy or TUN can prevent the sign-in page from opening. Temporarily turn off traffic interception, complete the network sign-in, and confirm regular websites load before restoring your settings. If some connections still fail after switching networks, reconnect them and check DNS. Don’t delete your config just because you changed networks; reimport the subscription only if the account link has actually expired or your provider says to replace it.

First turn off the proxy and confirm your basic internet connection works. Then check that the subscription updates successfully, the account is active, and your device’s date and time are correct. Try another outbound to the same destination. If only one outbound fails, contact your provider; if all outbounds fail, check your firewall, proxy port, and conflicts with other VPNs. Finally, use the logs to distinguish a server connection timeout from a DNS resolution failure or a rejection by the destination site. Repeated speed tests won’t identify the cause, and not every timeout is a client issue.

First check that the DNS upstreams in your config are reachable and that the hostname needed to connect to the proxy server can be resolved. Otherwise, DNS requests may depend on a proxy connection that hasn’t been established, creating a loop. If only certain apps are affected, check whether they use encrypted DNS, cache old addresses, or support fake-ip. After making changes, clear the DNS cache using your client’s instructions and reconnect. Don’t stack multiple DNS interception tools without a reason. Save your original config before changing DNS mode, and check whether TUN routes change as well.

Some apps isolated with AppContainer can’t access local loopback addresses by default. They may be unable to connect to a local proxy even when a browser works. First confirm the app is affected by this restriction, then use your client’s UWP loopback exemption feature to allow only the apps that need it. An administrator can run CheckNetIsolation LoopbackExempt -s to list existing exemptions. This doesn’t apply to every Microsoft Store app. If the app still fails after being exempted, check whether it reads the system proxy and whether its connections reach the core.

First check whether the system still has a manual proxy pointing to your local machine. If the core has exited, that address can’t provide a service; disable the leftover proxy or restart the client and turn off traffic interception properly. If you were using TUN, check whether the virtual interface, routes, and DNS settings have been restored. Use the client’s repair option if needed, then reconnect to the network. Some corporate networks require a specific proxy, so note the original settings before changing them. Resetting all network settings should be a last resort, since it can remove existing VPNs, static addresses, or work network configuration.

Note your operating system, client and core versions, active mode, and when the issue occurred. Reproduce it once, then capture the relevant logs from just before and after. If you temporarily increase the log level, restore it promptly to avoid recording too much browsing detail over time. Before sharing logs, remove subscription URLs, authentication parameters, server credentials, and any domains or IP addresses you don’t want public. Keep only the error type and rule chain if possible. Share the smallest config snippet that reproduces the issue and note what you removed. If a subscription link was exposed, reset it with your provider rather than just deleting the post.