Clash First-Launch Setup: Ports, Subscription Import, and Proxy Modes Across Platforms

First-launch checklist: configure first, route traffic second

When using Clash for the first time, import and activate your subscription, confirm the core is running and the port is available, then choose a rule mode and a node. Only then enable the system proxy or VPN routing. On desktop, start by testing your browser with the system proxy. Use TUN mode only if an app does not honor the system proxy. Each step has a clear check, so you can narrow down problems without troubleshooting your subscription, DNS, and virtual network adapter all at once.

The Clash client provides the interface, the core handles connections, and the subscription supplies nodes, proxy groups, and sometimes rules. Clients using the mihomo (also known as Clash Meta) core do not support exactly the same configuration fields as the original Clash core. A successful download and an open client do not mean the subscription is active or the proxy is working.

1. Check the core status: The home screen should show that it is running. The logs should not repeatedly report configuration parsing or port binding failures.
2. Import the subscription: After it updates successfully, select the corresponding configuration card and make it the active configuration.
3. Check the port: Note the actual mixed port, such as 7890. Do not copy a port number from another guide without checking.
4. Choose an outbound: Switch to Rule mode, then select an available node in a proxy group referenced by the rules.
5. Route and verify: Enable one traffic-routing method, visit a webpage, and check the connection log and matched rule.

Import the subscription, then activate the configuration

Know the difference between subscription URLs, node links, and webpage URLs

A subscription URL is usually an HTTPS link containing a token that the client uses to fetch a configuration. A provider dashboard, payment page, or setup guide is not a subscription URL. An individual node link may not import as a complete Clash configuration; it depends on whether the client supports conversion or node management.

In common desktop clients, the workflow is usually “Subscriptions” or “Profiles” → “Add/Import” → paste the subscription URL → “Save/Download.” Menu names vary by client, so follow the labels in your app. Once the download completes, select the entry in the configuration list. “Update successful” alone does not switch the active configuration from the default, so your nodes will not switch automatically.

• No nodes listed: Check that the newly imported configuration is selected and that the response uses a format supported by the client.
• HTTP 401 or 403: First check whether the subscription has expired, its token is invalid, or the server restricts requests. Do not start by changing DNS settings.
• Configuration parse error: Check the field name and line number in the log. A configuration containing mihomo-specific protocols or fields may not run with the original Clash core.
• Download timed out: First confirm that the subscription domain is reachable. If the client supports updating subscriptions through a proxy, you need a working configuration before you can use that option.

Check these three things after importing

First, the configuration card is marked as active. Second, the Proxies page shows nodes or proxy groups. Third, the log confirms that configuration loading completed instead of repeatedly restarting the core. The configuration provider determines which rules and automatic selection groups are included. A large number of nodes alone does not mean traffic routing is configured correctly.

Mixed port: check 7890 rather than memorizing it

The mixed port (mixed-port) accepts both HTTP proxy and SOCKS proxy connections on the same listening port. 7890 is common, but it is not a fixed value across all clients. Find the actual port under “Settings” → “Ports” or “Settings” → “Mixed Port,” then use that value in the app's proxy settings.

The snippet below shows basic fields for reference; it is not a complete subscription you can import directly. Existing clients may override these fields at runtime, so check the effective values. Do not overwrite existing nodes, rules, or proxy groups just to match the example.

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

If a port is in use, check for an old process first

A log message such as address already in use or a port binding failure usually means another process is already using that port on the same address. Quit any older proxy client, then start the current one. If the conflict persists, change the mixed port to 17890 and update any app proxy addresses you entered manually. If you change only the core's port while an app still connects to 7890, its requests will fail.

For your first setup, leave “Allow LAN” turned off. When a phone uses a computer's proxy, 127.0.0.1 on the phone points to the phone itself, not the computer. Sharing a proxy over your LAN requires separate setup for the listen address, access controls, and firewall. Avoid troubleshooting that at the same time as your first launch.

Proxy modes: Rule, Global, and Direct

Use Rule mode for everyday browsing. Rule mode routes connections according to the rules in your configuration, choosing direct access, a proxy group, or another outbound action such as reject. It does not mean “all overseas sites use the proxy.” The result depends on rule order and proxy group selections. Rules are generally matched from top to bottom, with MATCH often handling connections that do not match earlier rules.

• Rule: For everyday traffic routing. Check both which rule matched and which option is currently selected in its proxy group.
• Global: Sends connections entering the core through the global proxy policy. Use it briefly to compare rule and node behavior; you still need to select a specific outbound in the global group.
• Direct: Sends connections entering the core directly. Useful for temporary troubleshooting, but it does not mean the proxy is enabled.

The mode determines how connections are routed after they enter the core; the system proxy or TUN determines which connections enter the core. So there is no contradiction when you switch to Global mode but an app still bypasses the proxy: it may not be using the system proxy at all.

A node latency test does not replace a real connection test

Latency tests usually contact only a specific test endpoint. A result of 120 ms does not guarantee that a particular website, video, or UDP service will work. For a manually selected group, make sure the node is actually selected; for an automatic group, check which node it is currently using. During troubleshooting, pin one candidate node so the outbound does not change between tests and make the results hard to compare.

Route traffic across platforms: desktop system proxy and mobile VPN

Windows and macOS: route your browser through the system proxy first

First disable any proxy configured separately in your browser extensions to avoid conflicts with the system proxy. A Windows Firewall prompt does not mean you must allow inbound connections on every network; grant access only on the networks where it is needed. For a local loopback proxy, do not disable the entire firewall just to troubleshoot.

Linux: a working browser does not mean your terminal is configured

Terminal download tools, package managers, and developer tools may each use their own proxy settings. First specify a proxy explicitly in a command to confirm the core works, then decide whether to set environment variables. When setting HTTPS_PROXY, HTTPS refers to the type of request being made. A typical HTTP proxy URL can still be http://127.0.0.1:7890; do not change it to https:// without a reason.

Android and iOS: check for VPN conflicts and app scope

Android proxy clients that use the VPN service generally cannot run alongside another VPN of the same kind. If the app list is set to “Proxy selected apps only,” make sure your test browser is included. On iOS, confirm that the VPN is connected and check whether the client has bypass rules. Do not rely on the VPN icon alone to tell which node handled a particular request.

Test connectivity by cross-checking the port, connection log, and webpage

Change only one setting at a time while testing. First confirm that the core logs look normal, then visit a site that should connect directly, followed by a service that needs the intended outbound. Open the client's “Connections” or “Logs” view and check the target domain, matched rule, and outbound policy. If a site loads but there is no connection entry, the request may have gone direct, come from a cache, used another proxy, or bypassed the current core.

Use an explicit proxy command to rule out system proxy issues

The commands below assume the mixed port is 7890. On Windows, use curl.exe in PowerShell to avoid differences caused by the curl alias in some environments. On macOS and Linux, use curl. If your port is different, replace the number in the command.

curl.exe -I --connect-timeout 10 --max-time 20 -x http://127.0.0.1:7890 https://example.com

curl -I --connect-timeout 10 --max-time 20 -x http://127.0.0.1:7890 https://example.com

Here, 10 seconds is the connection timeout and 20 seconds is the maximum time for the entire request; neither is a latency result. The example domain checks the request path. To test a specific service, replace it with that service's HTTPS URL. In HTTP proxy output, 200 Connection established only means the tunnel was created. Check the destination server's response and the client's connection log as well.

• Immediate failure connecting to the local port: Check that the core is running, the address is correct, and the port numbers match.
• Explicit proxy works, but the browser does not: Check the system proxy, the browser's own proxy settings, and its extensions. Do not start by replacing the subscription.
• Connection entry appears, but the request times out: Check the selected node, matched policy, and destination service. Compare the result with another node.
• Only domain names fail: Check DNS alongside the logs. One resolution error alone is not a reason to enable TUN.
• The webpage reports a certificate error: Check the system time, certificate issuer, and destination domain. Do not disable certificate verification and continue signing in.

Save your setup and keep a way to roll it back

After testing, configure subscription auto-updates and startup on boot. Restart the client manually once to confirm that it restores the active configuration, mode, and proxy group selection. Desktop clients may have separate options for “launch the interface,” “start the core,” and “enable the system proxy automatically”; these behaviors are not necessarily linked.

• Record the working setup: Client name, core type, active subscription, mixed port, proxy mode, and traffic-routing method.
• Protect local changes: Subscription updates may overwrite direct edits. For persistent changes, use the client's supported override or merge features.
• Check what happens on exit: After a normal exit, the system proxy should be disabled or restored to its previous settings. Otherwise, apps may keep connecting to a port that is no longer listening.
• Keep useful troubleshooting details: Save the time of the error and redacted logs. Do not share subscription tokens, authentication details, or complete browsing records.

When you have confirmed all five steps—configuration active, port listening, proxy group selected, traffic entering the core, and the request using the correct outbound—you have a complete first-launch test. If an app later bypasses the proxy, adjust the routing method for that app instead of toggling every setting again. For more on configuration fields and rules, see the Clash Configuration Guide. If you encounter a specific error, start with the Frequently Asked Questions to narrow down the cause.