Clash Meta: 10 FAQs for Beginners — Subscriptions, Proxy Modes, Ports & Core

1. How are Clash Meta, mihomo, and clients related?

Clash Meta is a core project developed from Clash and later adopted the name mihomo. The core reads configuration files, handles proxy protocols, applies routing rules, and resolves DNS. Desktop windows, subscription management, tray menus, and system proxy controls are usually provided by a graphical client. Downloading a client does not give you proxy nodes to connect to.

When troubleshooting, note the client version, core version, and operating system version separately. Saying only “the latest version of Clash” isn’t enough to determine whether a configuration is compatible. The same client may also bundle different mihomo versions in different releases.

• In the GUI: Check the client version under “Settings” → “About,” then look for the core information or startup logs. Menu names vary between clients.
• On the command line: In the directory containing the mihomo executable, run mihomo -v. In Windows PowerShell, you can run .\mihomo.exe -v.
• Check compatibility: If you see “unknown field” or “unsupported proxy type,” first verify which core is actually running instead of repeatedly reimporting the subscription.

2. Where do subscriptions come from, and why are there no nodes after installation?

A subscription is a configuration link provided by a service provider or configuration maintainer, commonly an HTTPS URL containing an access token. The client uses this address to fetch nodes or a complete configuration. The client loads and uses the configuration; it does not automatically provide servers, accounts, or traffic.

Where to look: In your service account, find “Subscription” or a format option for “Clash / Clash Meta,” then open the client’s “Subscription” or “Profiles” page. Prefer a configuration format explicitly supported by mihomo. Don’t treat text containing only links to other protocols as a complete YAML file.

An expired subscription and a failed node connection are different problems. The first occurs while downloading the configuration; the second happens when the proxy tries to connect after the configuration has loaded. First check whether the client fetched the configuration successfully, then check the node status.

3. How do you import a subscription, and why don’t updates change anything?

In desktop clients such as Clash Verge Rev, the usual flow is “Subscriptions” → “New” → select the remote subscription type → enter the URL → save. Some versions provide a URL field directly on the subscriptions page. The important part isn’t the button labels—it’s to download, select, and apply the configuration.

1. Copy the full subscription URL and check that there are no extra spaces or line breaks at either end.
2. Add the remote subscription and download it. Make sure there are no HTTP or YAML parsing errors.
3. Select the newly imported configuration, then open “Proxies” and check that the proxy groups are listed.
4. Run an update manually and check the update time and logs. Make sure you haven’t enabled a different, older configuration.

If the download returns 401 or 403, check the token, account status, and provider restrictions. If it returns a web page instead of a configuration, you may have copied the login page URL. The line number in a parsing error refers to the downloaded result, not necessarily a local override file.

Update behavior: Changes made directly to nodes or rules in the subscription cache may be overwritten during the next update. For persistent changes, use the client’s override, merge, or script features, then check the final runtime configuration.

4. Which mode should you use: Rule, Global, or Direct?

Use Rule mode for everyday browsing. The configuration’s rules are matched in order, and each connection is sent to the corresponding policy when a rule matches. Global mode sends connections entering the core to the global policy; Direct mode connects those connections straight to their destinations. In all cases, the traffic must first enter the core.

Where to switch modes: Open the client’s “Proxies” page or select a mode from the tray menu. After switching to Global, you still need to select an available node for the global policy. If the selected policy is DIRECT, connections still go direct. Global mode also doesn’t automatically route every app through the proxy.

5. What is port 7890, and how is it different from a node port?

7890 is a commonly used example of a local proxy listening port. It isn’t required, and it isn’t the remote server’s port. With mixed-port: 7890, the same local port accepts both HTTP and SOCKS proxy connections. Use the port shown in the client’s runtime configuration.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

Where to check: Look for “Port” or “Mixed Port” in the client settings, or search the active configuration for mixed-port. Don’t mistake the external controller port for a proxy port: external-controller provides a management API and can’t be used as the HTTP proxy address in a browser.

On Windows, run the command below to see whether a process is listening on port 7890. A result only confirms that something is listening; check the PID to verify whether it’s the current client.

netstat -ano | findstr ":7890"

If the startup log shows address already in use, quit other proxy processes or change the local listening port. Then update the settings of any apps that rely on that port.

6. Why don’t my terminal or games use the proxy when the system proxy is on?

The system proxy is a set of proxy settings provided by the operating system, not a way to force all traffic through a proxy. Whether an app uses it depends on the app. Browsers typically honor the system proxy; command-line tools may read environment variables or require their own proxy arguments. Some games rely mainly on UDP, which a standard HTTP system proxy alone can’t handle.

Where to check: First enable “System Proxy” in the client. In Windows 11, go to “Settings” → “Network & internet” → “Proxy” to check the local proxy address, then look for connections from the target app on the client’s “Connections” page. On macOS, check “System Settings” → “Network” → your current network service → “Details” → “Proxies.”

For command-line tools, start with a one-off test using an explicit proxy rather than changing global environment variables. The command below assumes the mixed port is actually 7890. On Windows, use curl.exe to avoid differences caused by aliases in some PowerShell environments.

curl.exe --proxy http://127.0.0.1:7890 --connect-timeout 10 -I https://example.com

On macOS or Linux, replace curl.exe in the command with curl. If the explicit proxy works but ordinary requests don’t, check whether the app reads proxy settings before reinstalling the core.

7. When should you enable TUN mode?

TUN routes traffic through a virtual network interface and routing settings. It’s useful for apps that ignore the system proxy and for scenarios that require handling more network traffic. It isn’t a node speed boost, and it won’t fix an expired subscription, a server outage, or incorrect routing rules.

Where to enable it: Turn on “TUN Mode” or “Virtual Network Adapter” in the client’s “Settings.” Windows clients may require service mode or administrator privileges. Android usually connects through the system VPN permission flow, so desktop instructions won’t apply directly.

1. Before enabling TUN, confirm that the node works with an explicit proxy.
2. Note your current system proxy, DNS, and other VPN settings, then enable TUN.
3. Test a target app and check “Connections” to confirm that it appears there.
4. If your local network or work VPN stops working, turn off TUN to compare results, then check for routing conflicts and bypass settings.

8. What are DNS and fake-IP mode? Do I need to change them manually?

DNS resolves domain names to IP addresses. mihomo’s DNS module also helps associate domains with connections. In fake-IP mode, the core returns a virtual address to the app and keeps a mapping to the domain. These addresses aren’t the destination server’s real public IPs.

Many configurations use 198.18.0.1/16 as the fake-IP range. Seeing an address in that range doesn’t automatically mean a node is compromised or a server address is wrong. First check whether enhanced-mode: fake-ip is enabled.

Where to check: Review the dns section of the active configuration and the client’s DNS override settings. A browser’s encrypted DNS, system DNS, and core DNS may follow different paths, so a single system lookup doesn’t prove which resolver an app actually uses.

• If only certain domains are affected, check the domain, matched rule, and DNS errors in the connection logs first.
• For local network services that need real IP addresses, consider fake-ip-filter for the specific domains involved. Don’t add an overly broad exclusion range all at once.
• After changing DNS, reconnect the app. Existing connections or app caches may still use the previous result.

9. Where should custom rules go, and why aren’t they matching?

Rules are usually matched from top to bottom, with MATCH often used as the final fallback. The snippet below is not a complete configuration that can run on its own. It sends the example domain direct and routes other connections to a policy named “Proxy Selection.” That policy must already be defined in proxy-groups.

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,Proxy Selection

Where to add rules: Add them through the client’s configuration override, then inspect the merged runtime configuration to confirm the new rules appear before the fallback. Reload the configuration and check the rule type, policy chain, and actual exit node on the “Connections” page.

If a rule still doesn’t match, check these three things in order: Are you in Rule mode? Does the app’s actual connection domain match what you expected? Is the traffic entering this client? IP-based connections, an app’s own DNS behavior, and existing long-lived connections can all affect what you see.

If you use rule-providers, also confirm that the rule set downloaded successfully and that rules contains a corresponding RULE-SET entry. Declaring a rule set source alone doesn’t make it part of rule matching.

10. A node’s latency looks fine, but websites won’t load. What should I check?

Latency tests usually contact only the test address specified by the configuration or client. They show the result of one specific request, not whether every website, UDP connection, or login flow works. Troubleshoot in this order: configuration → traffic entry → rules → node → destination.

1. Check that the configuration loaded: Review the logs for YAML parsing errors, missing policy groups, and port conflicts. From the command line, run mihomo -t -f config.yaml to check the configuration. A successful check still doesn’t prove the remote node is reachable.
2. Check that traffic is reaching the core: Make a request through an explicitly configured proxy, then check “Connections.” If there’s no record for the destination, verify the app’s proxy address, the actual listening port, and whether TUN is capturing traffic.
3. Check the rule’s exit: See which rule matched and which node was ultimately selected. Temporarily switch to Global mode, explicitly select the same node, and compare the results.
4. Check whether the issue is destination-specific: Test two different websites through the same node. If only one site fails, look into destination-side restrictions, DNS, and connectivity from the exit node.
5. Keep useful troubleshooting details: Record the client and core versions, error time, mode, destination domain, and redacted logs. Change one setting only after completing each test.

For step-by-step instructions, see Getting Started. To troubleshoot a specific error, use Troubleshooting. Before reporting an issue, remove subscription tokens, node credentials, and controller API keys.