01 Import and Enable a Subscription Configuration
In short: After importing a subscription, select the configuration so the core actually loads it.Before you begin, get the subscription URL from your provider or a YAML configuration file compatible with your core. A client, a subscription, and a node are three different things: the client provides the interface, the subscription provides configuration data, and a node is the remote connection endpoint. Installing a client does not automatically give you a usable node, and you don't need to change system network settings just to import a subscription.
Add a Remote Subscription
Open the client and go to “Configuration,” “Subscriptions,” or Profiles. Look for “New,” “Add,” or “Import from URL.” If the interface offers remote and local options, choose remote, paste the full subscription URL, and give it a recognizable name, such as “Daily config.” Check that no spaces, line breaks, or punctuation from a chat app were added to the URL, then click Save or Import. The first download may take a moment. When it finishes, you should see a configuration card or subscription entry.
Some providers offer separate URLs for standard subscriptions, Clash subscriptions, and other formats. Choose the format the provider specifies for your client or mihomo core. If the download finishes but parsing fails, don't keep switching proxy modes—the problem is still with the imported configuration. Check the provider's page to confirm the URL type, then review the error location reported by the client. If the subscription endpoint returns a login page, expiration notice, or other text, being able to open the URL in a browser doesn't mean it contains a valid configuration.
Enable the Configuration and Check Its Contents
After import, click Enable on the configuration card or use the client's selection control. The active configuration is usually marked as selected; if there's an Apply or Reload button, use it as well. Next, open “Proxies” or the policy groups page and confirm that group names and selectable nodes appear. Seeing the subscription name in a list without any proxy groups does not mean you're ready to connect. Return to the configuration page and check that the correct file is selected and that the core hasn't reported a load error.
If you have a local YAML file, import it from the same configuration page, save it, and enable it. Unlike remote subscriptions, local files generally don't fetch updates from the provider automatically. To update node details later, reimport or edit the configuration. Don't treat a standard node share link as a complete YAML file; support for importing individual nodes depends on the client. If the format isn't compatible, ask the provider for a suitable version. Don't submit URLs containing account details to unfamiliar online conversion tools.
You're ready to move on when the configuration is selected, the core reports no parsing errors, and the Proxies page shows the expected policy groups and nodes. You don't need to enable every network option yet; next, decide how requests should be routed. For more on configuration overrides, remote updates, and local edits, see the configuration field reference.
02 Choose a Proxy Mode and Exit Node
In short: For your first setup, choose Rule mode and select a node in the policy group your traffic will use.The mode determines how connections are routed; the node determines where proxied requests go. One doesn't replace the other. Open the client's home or Proxies page, find “Mode,” “Outbound mode,” or Mode, and select “Rule” or Rule. Then open the policy group list, find a selector group in the active configuration, expand it, and choose a node.
Understand the Three Modes
Rule mode processes requests in the order defined by the configuration. Some connections may go direct, while others use a specified policy group, making it a good choice for everyday use. Global mode sends regular proxy requests that reach the core through the global policy. It's useful for quick troubleshooting, but you still need to choose an exit in that policy. Direct mode connects straight to the destination without a remote proxy node. “Global” does not control which apps are routed: traffic that never reaches the core won't start using it just because you switch to Global mode.
If your configuration file includes the fields below, they correspond to the listening port, proxy mode, and log level. This is a generic snippet only—it doesn't include nodes or routing rules and cannot replace the full subscription configuration you're using. For a first setup, use the mode button in the interface rather than editing a file before you're familiar with its indentation.
mixed-port: 7890
allow-lan: false
mode: rule
log-level: infoChoose a Node in the Right Policy Group
A subscription may include policy groups for different purposes, such as default proxy, media services, or automatic selection. Group names are defined by the configuration author; there is no standard name used by every client. Find the selector group for the default proxy, expand it, and choose a node. If the option you select is another policy group, keep expanding until you can identify the final exit. Changing a group with a prominent name doesn't mean every request will use it—the group used depends on which rule matches each request.
A node's test button usually probes a specified address to give you a basic connectivity check. A successful test doesn't guarantee that every site will be reachable, and a timeout may be caused by the probe address or your local network. For your first setup, pick one node that responds to the test and use it for verification. There's no need to also adjust automatic selection intervals, load balancing, or multiple app-specific policies. If an automatic group won't let you choose a node manually, that's determined by its group type; try a manual selector group already included in the configuration.
When you're done, confirm that Rule mode is still selected and that the relevant policy group has an explicit exit. The configuration now knows where to send traffic, but your browser or other apps may not yet be sending requests to the client. Next, enable traffic routing. For details on modes, nested policy groups, and rule references, see the mode field reference. For common questions about choosing a mode, see the FAQ.
03 Start the Core and Route App Traffic
In short: You need all three— a running core, a loaded configuration, and app traffic reaching the core—to connect.Return to the client's home page and check that the imported configuration is still active and the core is running. Some desktop clients start the core as soon as they open; others require you to click Start. Don't assume the core is running just because the window is open. If startup fails, check the logs for a port conflict or configuration load error, fix it, and then enable the system proxy.
On Desktop, Test with a Browser Using the System Proxy
Find the “System Proxy” or “Set as system proxy” switch and turn it on. Most browsers that honor system proxy settings will send new requests to the client's local listening port. For your first test, close any existing tabs and open a fresh page to reduce interference from existing connections or cached content. Temporarily disable other extensions that change browser proxy settings, and avoid running another proxy client at the same time; otherwise, the address in use may differ from the one shown by this client.
A system proxy is usually enough for your first browser test, but it doesn't force every app to route traffic through it. Command-line tools, some games, and apps that manage their own network connections may ignore system proxy settings. If a browser works but a terminal command doesn't, that alone doesn't mean the subscription or node is broken. Complete the browser test first. To cover other apps, configure their proxy settings separately or consider the client's TUN feature. Don't change several network options at once just to route one app.
On Mobile, Approve the System VPN Request
Mobile clients usually have a Connect button on the home screen. When you tap it, the system may ask to allow a VPN connection or add a VPN configuration. Confirm that the request came from the client you just installed before approving it. Return to the client to check its connection status, and make sure another VPN app hasn't taken over. A VPN icon means the system network interface is active, not that the remote node is working; verify with a real request in the next step. If the client offers per-app proxying, make sure the browser you're testing is included.
Don't Add TUN to Your First Connection Test
TUN routes traffic through a virtual network interface and may require a service installation, administrator permission, and changes to routing and DNS. Enable it only when you need to route apps that ignore system proxy settings, and follow the client's prompts. Whether a mobile client exposes a TUN switch depends on its implementation. For an initial desktop test, use only the system proxy. Once it works, test TUN separately so you can tell which change caused any issue instead of troubleshooting multiple routing methods at once.
If the logs show that a listening port is already in use, quit the old proxy process or change the listening port in the client's settings, if supported. When entering a proxy address manually in an app, make sure the address and port match the current client settings; don't copy a sample port. You don't need to enable LAN sharing for local use. Sharing access involves the listening address and access controls, which are advanced settings. Once connected, leave the current settings as they are and move to the final step to check the route your requests actually take.
04 Verify the Connection Route and Matched Rule
In short: A webpage loading is only part of the picture—check connection records to confirm the destination, policy, and exit.Open the client's “Connections” or Connections page and leave it visible, then visit a site in your browser. Return to the connection list and find the request you just made. Check the destination domain first, rather than just watching the list scroll. Some requests finish quickly, so view recent connections if the client supports it, or open the logs and reload the page.
Tell the Difference Between Traffic Reaching the Core and Using a Proxy
Find the target request and check its matched rule, policy group, and final outbound. If it shows Direct, the request may have reached the core but been routed directly by the current rule. That's different from traffic not being routed through the core at all. The request used the proxy path only if its connection chain points to the selected policy group and node. A webpage usually makes requests to multiple domains; some going direct and others through a proxy can be normal. You don't need every row to show the same node.
A site that displays your apparent public IP can provide an additional check, but a single result can't replace connection records. The site may show different results for different address families, and browser caching or other network extensions can affect what you see. First confirm that the request went through the intended node, then interpret any change in the displayed IP. Built-in node tests, the system VPN icon, and the color of a switch each show only one part of the setup; none alone proves that the entire connection is working.
Compare Modes Once, If Needed
If a destination won't load in Rule mode, temporarily switch to Global mode, explicitly select the node you just tested in the global policy, and retry the same request. If Global works but Rule doesn't, check the matched rule and the selected node in its policy group. If both modes fail, check the node, local network, and DNS. Switch back to Rule mode when you're done so you don't leave a temporary troubleshooting setting in place. Global mode won't fix a dead node or route traffic that isn't reaching the core.
Test from a Terminal by Specifying the Local Proxy
To test from a command line, explicitly specify the client's listening address instead of relying on whether the terminal uses system proxy settings. The command below applies only if the client is listening on the local mixed-proxy port 7890; if the port is different, use the value shown in settings. The example domain checks whether a request completes. It doesn't have to use a proxy on every network, so check the connection records to confirm the route.
curl -I --proxy http://127.0.0.1:7890 https://example.comAn HTTP response usually means the request reached the destination service; interpret the status code in the context of that site. If you can't connect to the local proxy port, check that the core is running and the listening address is correct before changing remote nodes. If the client received the request and then reports a connection timeout, check the node or remote route against the logs. Before sharing logs, remove subscription URLs, credentials, and any destinations you don't want to disclose.
Troubleshoot Based on What You See—Change One Setting at a Time
If no destination appears in the connection records, revisit step 3: routing scope, browser proxy settings, and client status. If a request appears but matches the wrong group, revisit step 2: mode and group selection. If the request uses the correct outbound but still fails, check the node, system clock, and network. For a DNS error, note the exact message first; don't replace DNS, enable TUN, and update every configuration all at once. Change one thing at a time and repeat the same test to compare results.
Your first setup is complete when the subscription configuration is enabled, the mode and policy selection are clear, test app traffic reaches the core, and at least one request follows the expected route. Then configure startup, automatic updates, or app-specific rules, and note the active configuration name and routing method. For a deeper look at YAML, browse the configuration field reference. If you're fixing one specific issue, find it by symptom in the FAQ—there's no need to repeat the entire setup.