Clash: Beginner to AdvancedSetup, Subscriptions, and Routing Rules

Stage 01 / Understand the Connection Flow

Core Concepts: Client, Core, and Configuration

Start with the Home Screen

A Clash client typically has sections for configuration, proxies, logs, and a start/stop control. For now, avoid changing settings in several places at once. The client is the app that provides controls, notifications, and system permissions; the core is the program that reads rules, establishes connections, and forwards requests. mihomo is a common core in the Clash ecosystem, not a particular app interface. The same configuration may run with different cores or startup parameters in different clients, so similar-looking interfaces do not guarantee identical features.

A configuration file describes how network traffic should be handled and is usually written in YAML. YAML uses indentation to express structure, so spaces are significant. A configuration can contain proxy nodes, groups, DNS settings, and routing rules. A subscription is a way to fetch this content, usually through a link. The downloaded file might be a complete configuration or just a list of nodes. Whether it can be imported directly depends on the format the client supports—not on whether the link includes the word Clash.

Know the Difference Between Nodes, Groups, and Rules

A node is a proxy endpoint, with a server address, port, protocol, and any required credentials. A proxy group chooses among one or more outbound options—for example, by manual selection, test results, or failover. Rules answer a different question: which outbound option should handle this request? A rule sends a request to a group, and the group selects a node. If a rule specifies DIRECT, the request does not use a remote proxy node. Changing nodes alone may not affect a request that a rule has already sent direct.

You can break a request down into steps: an app makes a request, the system passes its traffic to the client, the core identifies the destination, a rule selects an outbound route, and the client connects to the destination or proxy server. DNS resolution happens along the way, translating names into addresses. A failure at any step can look like a webpage simply will not load. To troubleshoot, first check whether the request reached the client, then inspect the matched rule, and finally check the outbound connection. This is more useful than repeatedly changing subscriptions.

A Local VPN Interface Is Not a Remote Service

The VPN icon on Android means the system has allowed an app to handle the relevant traffic. VpnService is Android's local VPN interface, which the client uses to capture and process traffic. The icon only confirms that the local interface is active; it does not prove that the subscription is valid, a node is available, or a destination website can be reached. Starting the proxy service and connecting to a remote server are separate checks, and the steps below cover both.

System proxy settings are another commonly confused concept. A desktop system proxy gives apps a proxy address to use if they choose to follow the setting; a virtual network interface captures traffic at a lower network layer. Android clients may also let you choose which apps use the VPN. If a browser works but another app does not, first check the apps included in the VPN and the failing app's own network settings. A browser test alone does not tell you how all device traffic is routed.

This guide focuses on mihomo-based clients with the relevant features. Whether a configuration field is supported depends on the core in use and how the client processes configuration. A graphical client may generate additional fields at startup or override fields with the same name in a file. So when this guide says to check the configuration, that means both the saved source file and the runtime configuration actually loaded by the app. This distinction explains why editing a file may not change what the client does.

Stage 02 / Match the Client to Your Device and Needs

Choose a Client: Platform, Architecture, and Core Features

Choose by Platform, Then Compare Features

Open the client downloads page, choose your device's operating system, and read the installation notes. For Android, Clash Plus is our first recommendation. You can also choose Clash Meta for Android, FlClash, or Surfboard based on configuration compatibility. That does not mean configurations are interchangeable: Surfboard uses a different configuration format from Clash YAML, and changing a file extension does not convert the file. If you already have a configuration from a service provider, first check which clients and subscription formats it officially supports.

Start by answering three questions: Can the device install the app? Can the client read your subscription? Does it support the features you need? If all you need is to import a subscription and switch nodes, there is no reason to migrate your entire configuration for a setting you do not use. If you need rule overrides, per-app proxying, or specific DNS behavior, check whether the client exposes those options. Read the setting descriptions, too: identical labels can refer to different implementations, so screenshots alone do not establish compatibility.

Match the Installer to Your Device Architecture

In Android package names, arm64, arm, and universal refer to builds for different processor architectures and runtime environments. Most newer phones use a 64-bit ARM environment, but do not infer that from the purchase date alone; some devices have additional system userspace restrictions. Check your system information or the download page first. A universal package is often larger and does not bypass minimum OS requirements, signature conflicts, or device policy restrictions.

Computer builds also depend on processor architecture. Choose the macOS build for Apple Silicon or Intel, and make sure a Linux package matches your distribution. Do not treat a core archive as a regular graphical app installer. The mihomo core section on the downloads page is for servers, routers, or users who specifically need a command-line deployment. It typically does not provide the full interface needed to import a subscription on a phone, and it will not configure all system traffic routing for you.

Keep a Rollback Option Before Migrating

Clash for Windows and ClashX Meta are no longer maintained; the downloads page keeps archived versions for existing setups. For a new deployment, favor an actively maintained alternative. When migrating, do not export only your node list. Also note your selected proxy groups, per-app scope, local rules, and startup settings. A new client may read your subscription without inheriting the old app's system permissions or battery settings, which you will need to check again.

You can install multiple clients on one device for comparison, but run only one traffic-capturing service during each test. Two apps competing for the system proxy or VPN interface make results hard to interpret. Stop the old client, import the same configuration source, and test the same destination on the same network. Compare observable behavior—for example, whether a rule matches—instead of drawing conclusions from a single page load time.

When sharing a subscription between mobile and desktop, keep common nodes and rules, but leave device-specific settings local. Android app package rules cannot replace desktop process rules, and desktop listening ports may not need to be copied to a phone. For background on moving from discontinued clients, see Alternatives to discontinued mihomo-based clients. By the end of this chapter, you should be able to explain why you chose your current app and confirm that it supports the configuration format you plan to use.

Stage 03 / Install and Authorize the App

Android Installation, VPN Permission, and Background Settings

Verify the Installation First

Choose an installer for your device from the Android downloads section. Once it has downloaded, open it from your browser's download list or the system file manager. If Android says installs from this source are not allowed, open the relevant permission page, allow the browser or file manager you are using to install apps, then return to continue. This permission applies to the app opening the installer, not your network as a whole. You can revoke it after installation if that fits your device management preferences.

If Android says the app was not installed, start with the specific reason shown. Free up storage if space is low; choose a compatible build if the architecture or OS is unsupported. If an app with the same name has a different signature, do not uninstall the old app straight away. Export your configuration and local settings first, and make sure you can restore them before changing installation sources. Uninstalling usually deletes the app's private data, and system backups may not preserve subscription links, rule overrides, or proxy group selections.

Grant Only the Permissions You Need at First Launch

When you open the client, confirm its name and find the configuration section. Import a valid configuration, then start the service. The first connection usually triggers an Android VPN request. Check that it comes from the client you are using, then approve it. This permission lets the app create a local network interface; it does not purchase or provide a remote proxy service. If no prompt appears and startup fails, check whether another VPN, a work profile policy, or device management settings are blocking the connection.

Android generally allows only one active standard VPN service per user or profile. If another proxy, corporate access, or firewall app is running, a new connection may replace it or be blocked by policy. Decide which service you need, stop the conflicting app, and try again. Do not blame a node timeout for a startup failure: traffic may not have reached a remote node at all. First resolve local permissions, then check the logs for connection attempts.

If the Connection Drops When the Screen Locks, Check Battery and Background Limits

Long-press the app icon, open App info, and find Battery or background usage settings. If the service needs to run continuously, allow background activity or set the app to unrestricted; exact labels vary by device. Some manufacturers also have separate settings for auto-start, background protection, and locking an app in recent tasks. These settings do different things, so enabling one does not mean you have covered them all. After changing them, test with the screen on, then lock it for a while and check whether the notification and service remain active.

Notification permission and VPN permission are separate. Allowing notifications makes it easier to monitor and stop the service, but a hidden notification does not necessarily mean the service has stopped. Likewise, a visible notification does not prove the remote connection is working. To troubleshoot background issues, compare the service toggle, system VPN state, and log timestamps before and after locking the screen. If Android kills the app, reopening it often rebuilds the service. If the service remains active but requests fail, investigate network changes and node connectivity instead.

For the first test after installation, use an ordinary home network and avoid enabling router proxying or complicated workplace network policies at the same time. Open a website that normally works without a proxy, then visit a destination that requires one, and record both results. If you need to test both mobile data and Wi-Fi, change one network at a time; do not also switch nodes and configurations. This makes it easier to identify where a failure occurs and distinguish installation issues from network restrictions.

After granting permission, use VpnService permissions and battery optimization settings to check for any manufacturer-specific options. The chapter is complete when the configuration loads, the service starts, basic browsing works, and the system does not immediately stop the service when the screen locks—not merely when a VPN icon appears. Enable auto-start only after these conditions are met, to avoid a chain of hard-to-diagnose issues after a reboot.

Stage 04 / Set Up an Updatable Configuration Source

Import Subscriptions, Check Configuration, and Understand Update Limits

Identify What You Have

Open the configuration page, choose Add configuration or Import from URL, and paste the subscription address from your service provider. Save it under a local name that identifies its source; do not display the full URL as the name. A subscription URL may contain personal authorization details, and anyone who can access it may be able to retrieve your proxy configuration. Hide identifying query parameters in screenshots, support requests, and synced notes. Do not paste a private subscription into an unfamiliar online converter to check its format.

After importing, check the download result, then select the configuration as active. Seeing a new entry in the list only means the content was saved; it does not mean it has been loaded. The client may require you to select, enable, or reload it. Next, open the proxy screen and check for the expected groups and nodes. If you see nodes but no rules, you may have a node list rather than a full configuration. If the result is webpage text, a login page, or a parsing error, check with the subscription provider about the link's purpose before changing local DNS.

Check YAML Structure First

If configuration parsing fails, note the reported line number and the surrounding content. Common causes include tabs instead of spaces, inconsistent indentation between items at the same level, missing list markers, and unescaped special characters in strings. The reported location may come after the actual problem—for example, an unclosed quote on the previous line. Restore the latest working copy first, then review your edits section by section. Avoid bulk replacements that change indentation throughout the file.

The minimal direct-connection configuration below illustrates the structure and contains no remote proxy nodes. It helps distinguish whether the core can read a configuration from whether a proxy service can connect, but it is not a substitute for your subscription. A graphical client may manage listening ports and DNS itself. Before importing, check whether it accepts full configurations; do not append this example to the end of a subscription and create a second set of fields with the same names.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
rules:
  - MATCH,DIRECT

The mixed port accepts supported proxy requests from the local device. Disabling LAN access prevents other devices from using that listener. Rule mode routes requests according to rules, and the log level controls routine logging. The final rule sends requests that did not match earlier rules direct. If another process already uses the port, the core may still fail to start—valid syntax does not guarantee the environment is ready. Resolve a port conflict by closing the other process or changing the port in the client, if supported.

Keep Remote Updates Separate from Local Changes

Updating a subscription usually replaces its downloaded configuration. Direct edits to that file may be lost on the next update. Prefer the client's override, merge, or local rules features to store personal changes separately, but check when they run and how they merge content. Some tools append lists; others replace an entire field. Do not assume every feature called “merge” will preserve existing proxy groups and rule order.

Set update intervals according to provider limits and how often the configuration changes. Frequent updates may trigger request limits and generate repeated errors on an unstable connection. First update manually and make sure the configuration reloads, then enable scheduled updates. If an update fails but the old configuration still works, preserve that working state and check the subscription's validity, URL permissions, and download network. Do not delete the only working configuration just to refresh the list.

For Multi-device syncing, sync the configuration source and any essential personal rules rather than overwriting all app data on every device. Phones and computers can use the same subscription, but keep system routing, listening ports, app scope, and file paths device-specific. See How to share a subscription between a phone and computer for options. By the end of this chapter, you should know which configuration is loaded, where it updates from, and which local changes need separate backups.

Stage 05 / Decide Where Requests Should Go

When to Use Rule, Global, and Direct Modes

Use Rule Mode for Everyday Routing

In the client's mode settings, choose Rule for everyday use. The core evaluates the configuration's rules in order to decide whether to connect direct, reject the request, or send it to a proxy group. Rule mode does not proxy every request, and it is not limited to browsers; it handles requests that have already reached the core. If an app is excluded from the VPN or a desktop program ignores the system proxy, changing to Rule mode will not automatically capture its traffic.

On the proxy screen, find the group the matching rule actually points to and select an available outbound. A configuration may have a main selector, an automatic selection group, and groups for particular services. Changing one of them may not affect your destination. Check the logs or connections screen to see which group the request matched, then change that group. Similar group names do not necessarily indicate a connection, so do not assume the most prominent button controls all traffic.

Use Global Mode for Comparison, Not to Check Whether Traffic Is Captured

If a destination fails in Rule mode, briefly switch to Global and confirm the global proxy group has the intended node selected, then retry the same destination. If it works now but failed in Rule mode, investigate the matched rule, group selection, and DNS differences first. This narrows down the cause but does not prove the original rule is wrong, because the two modes may also use different outbounds. Keep the network, destination, and node unchanged during the comparison to avoid adding variables.

Global mode does not guarantee that every device packet goes through a remote proxy. Per-app exclusions, local routing, system restrictions, and the client's implementation all affect which traffic is captured. If the target app's requests still do not appear in the logs after switching to Global, changing nodes is unlikely to help. Check whether the app is included, the system VPN is active, and the app has its own proxy or direct connection setting. The key is to assess the selected mode separately from the traffic capture scope.

Direct Mode Is Not the Same as Stopping the Service

Direct mode sends requests that have reached the core through a direct outbound. The client's local interface and DNS processing may still be active. Stopping the service can change the system's network path. So if direct mode works but stopping the service does not—or vice versa—check the interface, name resolution, and system settings that block connections outside the VPN. Direct mode does not restore every network setting to its original state. Do not delete the system VPN configuration without knowing why.

After changing modes, create a new connection before testing. Browsers reuse connections, and apps may keep long-lived sessions open; existing connections usually do not restart automatically when you switch routing policies. Close and reopen the relevant page, or end only the affected connection if the client supports it. Clearing all connections can interrupt active tasks, so save your work first. Check the new connection's outbound and matched rule instead of refreshing a page that may still be using an old session.

A node test result only reflects a particular test destination and method; it does not prove that every website is reachable. Real requests may use different protocols, ports, or address families. After selecting a node, make a real request from the target app and check for connection errors. If one app works and another does not, first compare whether both are captured, use the same group, and need the same network capabilities before switching nodes.

After the comparison, switch back to Rule mode and note any temporary changes. Staying in Global mode can mask routing problems that should be fixed, or send local services through the wrong outbound. For differences between desktop browsers and terminal apps, see How to troubleshoot system proxy issues in browsers and terminals separately. The next chapter connects the matched requests you see here to specific rules.

Stage 06 / Start with One Rule

Routing Rules: Match Order and Local Overrides

Find Existing Rules Before Adding New Ones

Open the logs or connection details, make a request to the destination, and find its domain, matched rule, and final policy. Rules are generally evaluated from top to bottom; the first match determines the outbound. Put specific exceptions before broader rules. Anything appended after a catch-all rule may never take effect. Before editing, check whether the active configuration includes rule providers, a local merge layer, or client-inserted rules: runtime order may differ from the source file.

Exact domain matching applies to a specific hostname; domain suffix matching can cover that domain and its subdomains; IP range rules match the destination address. They solve different problems, and an app's displayed brand name is not necessarily a domain rule. An app may access multiple domains or connect to a fixed IP address. Use logs to identify the actual destination, then test with the narrowest rule that works. Avoid routing a broad domain range through one outbound just to fix a single page.

Understand Order with a Complete Minimal Example

The example below contains no remote nodes and shows the order of local domains, private addresses, and a catch-all rule. It can serve as a standalone direct-connection test configuration. To move its rules into a subscription, use the client's local rules or override feature and keep the rest of the configuration intact. It covers some common local addresses, not every private network range, and may not fit special corporate network plans.

mode: rule
rules:
  - DOMAIN,localhost,DIRECT
  - DOMAIN-SUFFIX,home.arpa,DIRECT
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,DIRECT

The final MATCH catches requests that did not match earlier rules. In a real subscription, it may point to a proxy group; use a group name that actually exists in that configuration, or the reference will fail. no-resolve after an address rule means the rule does not actively trigger DNS resolution for matching; it does not prevent resolution elsewhere in the request flow. Understanding this distinction prevents mistaking it for a global DNS switch.

Manage Rule Providers and Proxy Groups Separately

Rule providers manage sets of matching conditions; proxy groups manage outbound selection. They are not interchangeable. If a rule provider update fails, nodes may still work. If a node subscription updates successfully, remote rules may still be out of date. When checking a rule provider, verify the source format, behavior type, download result, and local cache. A device with no successful first download may behave differently from one with an older cached copy, so account for that when testing a migration.

If you need per-app routing, first check whether the client offers per-app VPN scope or core-level process rules. Excluding an app from the VPN may prevent it from reaching the core at all; routing an app direct may still let the core handle it. The two approaches can differ in log visibility and DNS behavior. Android app identifiers also differ from desktop process names, so copying a desktop rule to a phone does not make it compatible.

Add one rule at a time, save and reload, then test a new connection. If the interface reports success but behavior is unchanged, check in order that the intended configuration is loaded, the override is enabled, the rule appears before the catch-all, and the connection is not being reused. Then investigate domain identification and DNS mapping. Repeatedly adding duplicate rules usually makes the configuration harder to read and increases the chance of merge conflicts at the next update.

If several destinations show the same error, look for a shared proxy group or DNS path before adding an exception for each domain. Overly granular rules can hide an outbound problem. For more background, see the Rule glossary entry, or jump to the FAQ for common configuration issues. You are done with this chapter when you can explain why a request uses its current outbound and change the result with a single, reversible edit.

Stage 07 / Understand DNS Before Capturing More Traffic

How TUN, VpnService, and DNS Work Together

What a Virtual Network Interface Does

TUN is a virtual network interface used to capture network-layer traffic. On desktop, it is often used when system proxy settings are not enough—for example, when a program ignores proxy settings or specific non-browser traffic needs handling. TUN is a different layer from Rule and Global: TUN determines how traffic reaches the core, while Rule and Global determine which outbound handles it. You can use Rule mode with TUN enabled; a virtual interface does not mean you must proxy every request globally.

Android clients generally use VpnService to capture system traffic, but do not copy every desktop TUN setting to a phone. A mobile client may create the interface, routes, and file descriptors before handing traffic to the core. Desktop automatic routing may rely on additional permissions and system commands. Start with the client's own controls and defaults, and confirm it supports custom fields before changing them. This helps avoid conflicts between client-generated and manually configured settings.

Check Routes and Permissions Before Enabling TUN

Enabling a virtual network interface on desktop may require administrator or service permissions. After granting access, confirm the interface exists, then test regular websites, local network devices, and proxy destinations. If the proxy node's own traffic is sent back through the virtual interface, it may create a loop. If another VPN also changes the default route, some traffic may take the wrong path. In either case, first disable the new capture method to restore connectivity, then check route exclusions and the client documentation.

Test local network access separately. Printers, router admin pages, and network storage may depend on local addresses, multicast discovery, or device name resolution. Being able to open a public website is not enough to verify them. Keep the client's recommended local routing behavior where possible, then check whether an exclusion is actually needed. Do not disable every firewall or let the entire LAN use your local proxy just to access one device temporarily; those changes affect a separate set of permissions.

DNS Turns Names into Addresses

DNS resolves domain names. When you enter a name in a browser, it needs an address—or the proxy needs to resolve it—before a connection can continue. Successful resolution does not guarantee that the address is reachable, and a failed connection does not necessarily mean DNS failed. Distinguish name resolution errors in the logs from connection timeouts and authentication errors before changing DNS settings. The DNS path used to download a subscription may differ from the path used when the proxy is running, so a subscription update failure and a website failure may have different causes.

Some clients offer fake-ip mode: the app first receives a virtual address, while the core keeps track of the mapping between that address and the domain. This can preserve domain information, though some apps that rely on real address behavior may need exceptions. Do not assume a non-public response address means DNS is broken. First check whether fake-ip is enabled, whether the request is still handled by the same core, and whether the app bypasses the usual resolution path.

Encrypted DNS protects DNS traffic in transit, but does not automatically ensure the correct outbound is used. The DNS server itself must be reachable. If startup depends on a proxy path that is not yet available, resolution and connection setup can get stuck waiting on each other. Keep one path that can perform basic resolution, then adjust upstream servers and routing gradually. Browser secure DNS, Android Private DNS, and client DNS may all be involved. Record which settings are active rather than changing all of them at once.

Use a consistent validation order: confirm the interface exists, the request appears in the logs, the domain is handled as expected, a rule matches, and an outbound connection is established. If every step succeeds but one app still fails, check address families, UDP support, or app-specific limitations. A node's support for a particular transport cannot be inferred from a single webpage test. By the end of this chapter, you should know when TUN is needed—and why a configuration reference error alone does not justify routing the entire device through a virtual interface.

Stage 08 / Build a Repeatable Maintenance Routine

Updates, Backups, and Layered Troubleshooting

Handle Three Kinds of Updates Separately

Client updates, core updates, and subscription updates are three separate actions. A client update may change the interface, system permissions, or configuration handling. A core update may change field support or network behavior. A subscription update mainly changes nodes, proxy groups, or rules. If you update everything at once and something breaks, it is difficult to identify the cause. Back up the current working state, make one change at a time, and test basic connectivity after each change before moving on.

At minimum, back up the configuration source, local rules, proxy group selections, and relevant system settings. Store files containing subscription URLs or credentials somewhere secure that you control, and share only redacted snippets when asking for help. An app export may contain personal data and may not include system VPN permissions; read the export notes before restoring it. Being able to restore a YAML file does not mean the entire device is backed up—battery restrictions and per-app lists may still need to be set again.

Start with Recent Changes and Scope

When you lose internet access, note when it started, what changed beforehand, and whether one app or all apps are affected. Then compare Wi-Fi and mobile data, and direct and proxied destinations. If basic connectivity also fails with the service stopped, fix the network connection or sign-in portal first. Testing nodes repeatedly in the client while the network itself is unavailable will only produce a string of failures, not reliable information about the nodes.

A node timeout means a particular connection did not complete within the allowed time; it does not by itself mean the server is offline. An expired subscription, DNS errors, network restrictions, an incorrect system time, or an unsupported protocol could all be involved. First confirm the node details came from the latest successful update, check that the device time is set automatically, then try a different network. See Troubleshooting node timeouts and widespread connection failures for a detailed sequence. Do not change the server address, port, and protocol all at once and hope for the best.

Increase Logging Only to Answer a Specific Question

Use an appropriate log level for everyday use. When troubleshooting, prepare a reproducible action—for example, opening one destination—and briefly increase the logging detail. Restore the original level once you have captured the issue to avoid generating excessive logs. Before sharing, check whether domains, addresses, subscription parameters, or credentials need redacting. A single final error line may not be enough to diagnose the problem, but posting an unchecked full runtime log publicly is not appropriate either.

Read logs by stage. A DNS error happens before an address is obtained; a connection refused error usually means the destination or an intermediary explicitly rejected the connection; a timeout means it did not complete within the wait period. These are different symptoms. For certificate errors, first check the system time, server name, and network environment—do not hide the issue by disabling security checks. A configuration parsing error points back to file structure and usually occurs before any actual network connection is attempted.

After each fix, record the specific result—for example, the destination worked after restoring a particular rule—instead of writing a vague note like “internet fixed.” Then test subscription updates, recovery after locking the screen, and network switching to make sure the fix did not break another scenario. Keep a recent working configuration and a short change log so you can roll back to a known state next time. For common interface issues, go straight to the FAQ by topic instead of searching the whole guide.

Stage 09 / Make a Working Configuration Maintainable

Advanced Workflow: Validate, Separate Layers, and Minimize Changes

Create Your Own Test Checklist

Advanced use is not about enabling every feature. It is about being able to explain the current behavior and verify that changes produce the expected result. Choose a few stable test cases: a direct-connection website, a destination that requires a proxy, a local network device, and an app you use regularly. Repeat them after every change, checking that traffic capture, rules, and outbounds behave as expected. Use tests that match your needs; you do not need to add protocols or rule providers you never use just to make the configuration look complete.

You can organize configuration into three layers: remote subscription, local policy, and device settings. The subscription provides nodes and general rules; local policy holds a small set of personal exceptions; device settings cover VPN scope, listening ports, and startup behavior. Give each layer a clear purpose so you can tell what should change during an update. If the same DNS field is changed in the subscription, an override, and the client interface, identify which value actually takes effect before deciding which setting to keep.

Use the Core to Validate Configuration Edits

If you are comfortable with the command line, use mihomo's configuration test feature to check a local file. Run the command below in an environment where the core is installed and the configuration file exists in the current directory. It tests the configuration; it does not set up system-level traffic capture. Android users with a graphical client can continue using its built-in checks and logs. There is no need to install a separate command-line environment on the phone just to run this command.

mihomo -t -f ./config.yaml

A successful check mainly shows that the core can read the configuration and pass the checks it performs. It does not prove that every remote node is reachable or that routing and permissions are correct. For external rules, providers, and resource files, also check the working directory, relative paths, and download requirements. A terminal and a graphical client may start from different directories, so a local file that loads in one may not work from another launch method.

Save a copy before editing a configuration. After making a change, check the syntax, reload it in the client, then inspect a new request. If something goes wrong, undo the last change rather than layering on more patches. When comparing files, focus on the necessary fields and avoid pasting credentials into public diff tools. For complex, subscription-generated configurations, prefer a local override whose merge behavior you understand. Do not delete references you do not yet understand just to make the file look cleaner.

Set Boundaries for Remote Control and LAN Sharing

Some cores support a control interface that dashboards or clients use to read status and switch groups. It is separate from the proxy listening port. For ordinary single-device use, there is no need to expose the control interface on every network adapter. If you do need remote management, consider authentication, network isolation, and firewall scope together. Do not share control endpoints, subscription URLs, or privileged dashboard links publicly, and do not mistake an admin page that opens in a browser for a site suitable for public deployment.

Plan LAN proxy sharing separately, too. Once other devices can connect, your device becomes their network exit, so check the listening address, port, and allowed clients. Mobile hotspots, public Wi-Fi, and home networks have different trust levels; do not leave the same open settings enabled on all of them. Test with one device on a trusted network before sharing, then restore the original scope afterward. Check what authentication and access restrictions your client actually supports.

Choose Your Next Topic Based on What You Need

For Multi-device maintenance, learn how to separate subscriptions from local overrides. For app compatibility, study how DNS, address families, and transport protocols interact. For router deployment, look into interfaces, routing, and service management. Server and router setups also involve startup services, file permissions, and network firewalls. A configuration that works on a phone is not automatically a complete deployment plan. Test in an environment you can restore before moving to a device relied on for everyday connectivity.

Keep a short runbook noting which client you use, where its configuration comes from, what you changed locally, how to verify it works, and how to roll back. This is more useful than a long list of parameters you cannot explain. To repeat the basics, return to the Quick Start Guide. When switching devices, check the platform requirements again on the downloads page. Being able to reproduce, diagnose, and restore a working setup is the goal of this learning path.