1. Import a Subscription and Select the Configuration
Before you begin, install a client and get either a Clash-compatible subscription URL from a trusted provider or a local YAML configuration file. The client reads the configuration, lets you choose policies, and handles connections; installing it alone doesn’t give you a working proxy. Subscription URLs often contain access credentials, so protect them like passwords. Don’t post them in public comments or paste full URLs into online converters you don’t trust.
Open Profiles and Add a Remote Subscription
Launch the client and find “Profiles,” “Subscriptions,” or a similar option in the navigation. Click “Add,” “Import,” or the plus button. If prompted to choose a type, select “Remote Profile” or “URL.” Paste the full subscription URL from your provider into the address field. Check that it has no leading or trailing spaces, line breaks, or punctuation added by a messaging app. Give it a recognizable name, such as “Everyday,” then click Save or Import.
After you save, the client usually downloads and then parses the content. Wait for the process to finish; a profile card should appear with its name, last-updated time, or an update control. If parsing fails, don’t keep clicking Connect. First make sure you copied a subscription URL, not the provider’s homepage, account page, or a node share link. Formats aren’t always interchangeable, so for your first setup use a subscription the provider explicitly supports for your client or mihomo.
Import a Local File and Confirm the Active Profile
If you have a .yaml or .yml file, choose “Import from file” on the same page and open it with the system file picker. Keep a copy of the original file after importing; there’s no need to change ports or DNS yet. Successful parsing is only the first step: select the imported profile card or open its menu and choose “Use” or “Activate.” A selected indicator or updated active profile name confirms the client is ready to use it.
Next, open the Proxies page. You should see the policy groups defined in the profile, along with their nodes, other policy groups, or Direct options. If the list is empty, return to Profiles and confirm you selected the right entry, then check that its download completed. Some profiles use remote proxy sets, which may show no available nodes until they finish loading. Use the client’s update control to fetch them; don’t fill the list by adding arbitrary node names.
You don’t need to update the subscription repeatedly before your first test. Run through the full setup with the current profile, then set an update interval based on your provider’s recommendations. For the difference between local and remote profiles, see the configuration structure section in the glossary. If you need to edit YAML manually, consult the configuration reference.
2. Choose a Proxy Mode and Node
Once the profile is active, decide how connections should be handled. Find the mode selector on the client’s home screen, Proxies page, or settings. It usually lists Rule, Global, and Direct, though some clients show Rule, Global, and Direct. For your first setup, choose Rule mode so the rules in your subscription decide which requests use a proxy and which connect directly. This avoids changing several behaviors at once.
Start with Rule Mode and Understand What It Controls
Rule mode checks connections against the rules in your configuration, in order, and applies the policy specified by the first matching rule. Some sites may connect directly while others go through a proxy group, so “connected” doesn’t mean all sites use the same route. Routing depends on your subscription; the mode name alone can’t tell you how a particular site is handled. To verify, check the matched rule and policy in the connection log.
Global mode sends connections that reach the core to the global policy. It can help you temporarily check whether rules are affecting access, but you still need to check which policy the global mode uses. Direct mode connects those same incoming connections straight to their destinations, which is useful for troubleshooting or when you specifically want a direct connection. “Global” refers to the core’s routing decision; it doesn’t automatically capture every app on your device. Whether an app’s traffic reaches the core depends on the connection method, such as the system proxy, VPN, or TUN.
Choose an Available Node in the Main Policy Group
Stay in Rule mode and find the policy group used for most proxied traffic in your subscription. It may be called “Proxy,” “Node Selection,” or something else; the name doesn’t have to match this guide. Expand the group. If it’s a manual selection group, choose an available provider node and confirm that a selection indicator appears beside it. If the current selection is another policy group, open the next level until you can tell whether the final route uses a manual node, an automatic selection group, or Direct.
Some groups, such as “Auto Select” or “Failover,” choose a member based on the conditions in your configuration, so you don’t need to pin a node manually. For your first test, you can keep the provider’s defaults or choose a node in the main group if manual selection is available, making it easier to compare results later. A group’s test button usually checks reachability only for a specific test address; it can’t guarantee access to every site. Even if the test succeeds, finish by verifying access in a browser.
If the selected policy is DIRECT, connections handled by that policy go straight to their destinations; it isn’t a proxy node. Don’t rename policy groups just to make their names match this guide, as rules may refer to them by name. Just confirm that Rule mode is active and the main group has the expected options, then continue to the connection step. For more on modes and rule-based routing, see Running Modes and Rule Routing in the glossary. You don’t need to learn the entire configuration syntax first.
3. Connect and Approve System Permissions
After the first two steps, the client knows which profile to use and how to choose a policy, but app traffic may not yet be reaching the core. Now enable the connection method for your platform. Before your first setup, quit other proxy or VPN apps that are running to prevent them from changing system proxy settings, routes, or DNS at the same time. There’s no need to enable multiple traffic capture methods at once. Start with the simplest option, verify it works, then consider connecting other apps.
Desktop: Confirm the Core Is Running, Then Enable the System Proxy
In a Windows, macOS, or Linux client, first check the home screen to see whether the core is running. If there’s a separate Start or Connect button, click it first. If the core starts automatically with the client, find and enable the System Proxy toggle. This setting directs requests from apps that honor the system proxy to a local proxy port. Most browsers work well for an initial test, but not every app uses the system proxy.
When you enable it, your system may ask you to allow proxy changes, install a helper service, or enter an administrator password. Confirm that the prompt comes from the client you just installed, then follow the system instructions. After granting permission, return to the client and make sure the toggle stays on instead of switching off again. If the logs report a port conflict, check whether an older client is still running in the background. Don’t change the port in just one place while another app still points to the old port.
Some macOS clients require permission for a network extension or helper component. Follow the client’s prompts and approve it in System Settings. Linux desktop environments vary in their system proxy support; if your browser generates no connection logs, check whether it uses the system proxy. You don’t need to enter an address and port manually in every app right away. First make sure one browser can connect through the current setup, then configure other apps as needed.
Mobile: Connect and Approve the VPN Configuration
On Android or iOS, return to the client’s home screen and tap Connect, Start, or the main toggle. The first time you run it, the system usually asks to add a VPN configuration or establish a VPN connection. Verify the app name and allow it; iOS may also ask you to confirm with your device passcode. Return to the client and check that the connection stays active. VPN icon visibility in the status bar varies by OS version and screen area, so don’t rely on the icon alone to confirm the connection.
If the connection drops right away, open the client logs and look for a configuration parsing error, incomplete permission, or another VPN in use. If your Android client has per-app proxying enabled, make sure the browser you’re testing is included in the selected apps. Otherwise, the client may show as connected while the browser still uses your regular network. For your first test, keep the default app scope to avoid accidentally excluding the browser and then trying to fix DNS instead.
TUN is another way to route traffic and is often used on desktop to cover more apps. It may require service mode or additional permissions. It isn’t required to load a web page for the first time, and it’s not the same as Global mode in the proxy mode selector. Keep the connection method that already works. If you need to route apps that don’t follow the system proxy, see the configuration reference for TUN, DNS, and routing settings. Avoid changing several network settings at once during your first connection.
4. Verify Web Access and Connection Logs
A lit connection indicator only means the client or system tunnel is running; it doesn’t prove that a specific site is reachable. Keep the current profile, mode, and node unchanged. Open a new browser tab and visit a site you can normally access to confirm your basic connection still works. Then visit a site you expect to route through the proxy. Testing a new request is more useful than watching an existing page: it may be showing cached content, or an existing long-lived connection may not have picked up your recent policy changes.
Check the Connection Log to See How Requests Are Routed
While the target page is open, switch to the client’s Connections, Active Connections, or Logs page. Search for the target domain and inspect the newly created request: check its matched rule, policy group, and any outbound route information the client provides. A site opening after a Direct rule matched doesn’t mean it used a proxy. To confirm the route matches your setup, make sure the log shows the request going through the expected proxy policy. Clients display different fields, so focus on the information available instead of looking for identical column names.
If the page loads but there’s no matching client entry, first confirm that the page actually made a new request. Then check whether the browser uses the system proxy or, on mobile, whether it’s excluded from per-app proxying. Browser extensions can also override the browser’s proxy settings, so try disabling them during the test. If you’re viewing active connections rather than a history log, a request may disappear soon after it finishes. Reload the page while watching the list; don’t assume the client isn’t working just because the list is briefly empty.
To check your outbound IP, you can visit a trusted IP lookup service and compare the result with the client disconnected. Treat this as a secondary check. In Rule mode, your rules may send the lookup site directly. Browser cache and a site’s location data can also affect what you see. Don’t assume all proxies are broken just because the displayed location hasn’t changed. First check which policy handled the lookup request, then decide whether to adjust the rules or node.
If It Fails, Check These in Order
If the target site still won’t load, return to Profiles and confirm that the active profile hasn’t changed and that its subscription and proxy sets have loaded. Then check the Proxies page to make sure the main group isn’t set to Direct or an unavailable member. Next, confirm that the desktop system proxy is still enabled or the mobile VPN is still connected. After those checks, review the logs from the time of the error to identify whether the problem occurred during subscription download, node connection, DNS resolution, or the target site’s response.
Change one thing at a time. For example, choose another provider node in the same policy group, send the request again, and check the result. Don’t change nodes, switch to Global, enable TUN, and rewrite DNS all at once; even if access comes back, you won’t know which change fixed it. If switching temporarily to Global restores access, take a closer look at your rules or policy selection. Still check whether the global policy and original group use the same node before concluding that DNS is the problem.
If you need to understand DNS or Fake-IP before troubleshooting, start with the glossary. To edit fields, rule order, or override behavior, use the configuration reference. When contacting your provider, include the client name, OS, step where the error occurred, and redacted error details. Don’t send your full subscription URL or an entire configuration file containing access credentials.
After your first successful test, configure automatic updates, startup behavior, and access for other apps as needed. Each time you add a setting, repeat the browser and connection log checks, and keep a copy of the configuration that already works. That gives you a known-good setup to return to if something goes wrong, instead of having to rebuild everything from scratch.