Clash Guide:
Setup, Routing & Maintenance

1. Core Concepts: Client, Core, and Configuration

Understand the interface and the processing layer

Clash clients typically combine a graphical interface with a proxy core. The interface imports subscriptions, displays proxy groups, changes settings, and requests system permissions. The core listens on local ports, processes connection details, matches rules, and establishes outbound connections. Seeing the interface open doesn’t mean the core is running properly; seeing the core running doesn’t mean system traffic is routed through the proxy. Troubleshooting these layers separately is more effective than repeatedly reinstalling the app.

mihomo is a commonly used core in this ecosystem. Clients may bundle different cores or restrict which fields you can edit. Whether a configuration works across clients depends on protocol, rule type, core features, and platform support—not the file extension. When moving between devices, reuse the subscription and proxy-group structure first, then check device-specific settings such as ports, file paths, and network interface names. Don’t overwrite all your local preferences without reviewing them.

How a connection flows

Think of the process in four steps: an app makes a request, traffic enters a local proxy, the core chooses an outbound route based on the mode and rules, and the destination is reached directly or through a remote proxy. System proxy and TUN settings control the second step; rules and proxy groups control the third; the proxy protocol handles the fourth. A page can fail at any step, so switching nodes is only one troubleshooting option—not a substitute for checking the traffic entry point and DNS resolution.

A configuration describes how these parts work together. proxies defines individual proxies, proxy-groups organizes them into selectable or automatically tested groups, and rules routes connections to a policy in order. A subscription may contain a complete configuration or only proxy nodes. If it contains nodes only, the client needs a template to supply proxy groups and rules. A subscription that parses successfully doesn’t necessarily include complete routing logic.

A proxy node contains connection details for a remote service; a proxy group organizes nodes. They aren’t interchangeable. A group named Proxy can select a node or refer to another group. The DIRECT policy sends the connection straight to its destination without a remote proxy. Group names are usually set by the configuration author and aren’t standardized. Examples below use Proxy to illustrate references; when editing your configuration, use the names it actually contains.

Local ports and DNS

A local listening port is the entry point applications use to reach the core. A mixed port can accept common HTTP proxy and SOCKS connections on the same port, but it won’t automatically capture traffic from every app. DNS translates domain names into addresses and affects when domain-based rules can be evaluated. If a browser uses encrypted DNS while the operating system uses another resolver, the same destination may follow different routes. Review logged domain names alongside the actual connection addresses.

Before getting started, distinguish the client from the network service. Installing a client doesn’t provide a usable remote proxy; you need a configuration you’re authorized to use. Subscription URLs often contain access credentials, so treat them like passwords. Screenshots, logs, and support requests can expose them. Before sharing, remove full links, account identifiers, and node authentication details; include only the relevant fields and error information.

The goal of this chapter isn’t to memorize every term. It’s to answer three questions: Which client and core are you using? Where does the configuration come from? How does the app’s traffic enter the core? Record these details so you can choose the right checks when system proxy settings fail, rules don’t match, or a subscription won’t update—instead of changing several settings at once.

2. Choose a Client: Start with Your Platform and Needs

Choose a client you can rely on day to day

Choose a client based on your operating system, processor architecture, and use case—not its appearance. If you’re new, consider Clash Plus and choose the right installer from the platform sections on the client downloads page. Compare other clients if you need to edit configurations often, inspect connections, or use specific core features. Don’t choose based only on screenshots in an old tutorial: similar menus don’t guarantee the same support or permission flow on your current system.

Desktop users often need a persistent tray icon, system proxy support, launch at startup, configuration overrides, and TUN. Mobile users tend to care more about system VPN permission, background operation, and reconnecting after sleep. List the two or three features you actually need, then check the relevant client documentation. Advanced toggles you don’t plan to use don’t need to drive your choice. More features don’t make initial setup easier or guarantee better compatibility with other network software.

Architecture, configuration compatibility, legacy clients

Processor architecture and operating system are separate considerations. For macOS, choose an Apple Silicon or Intel installer as appropriate; don’t rely on “Mac” in the filename alone. For Android, choose between ARM64 and ARM based on your device. If your Windows device has an ARM processor, check the app’s stated support instead of assuming every desktop installer is native. Don’t guess the download URL for an architecture that isn’t listed on the downloads page.

Clash for Windows and ClashX Meta are legacy options that are no longer maintained. They can help you identify an old tutorial or migrate an existing setup, but archived builds shouldn’t be your default for ongoing use. When looking for a Clash for Windows replacement, check whether the new client can read your configuration, preserve overrides, and restore system proxy settings on exit. Remove the old client after migration to prevent both apps from competing for the same listening port.

A client’s ability to import a file doesn’t mean it supports every feature in it. Subscription protocols, rule providers, scripts, and core-specific fields may not be supported by the target app. Apps such as Surfboard also require a configuration format they explicitly support. If import fails, check the field name and line number instead of repeatedly submitting an incompatible file. Ask the configuration provider for a compatible format if needed, rather than sending credentials through an unknown conversion service.

Keep a minimal migration record

Before switching clients, note your current subscription name, mode, proxy-group selections, and any apps that rely on manual proxy settings. Save custom rules and note whether they’re written directly into the subscription file or managed through client overrides. A remote subscription may replace its file when updated, so local changes are easier to migrate when stored in the right place. Keep your notes local; don’t paste a full subscription URL into a public document or screenshot.

On iOS, you can reach the App Store listing for Clash Plus from the downloads page. The product website is clashplus.io. Mobile operating systems typically route captured traffic through a VPN configuration, which doesn’t map directly to the desktop system proxy toggle. When following cross-platform guides, focus on what each feature does. Don’t look for a desktop-only mixed-port menu on your phone or copy mobile background-permission steps to a desktop.

At this stage, choose one primary client and one fallback. Avoid installing several proxy clients that run in the background at the same time. Use your primary client for the installation and import steps ahead, and explore other interfaces only after confirming your network returns to normal when the client exits. You should be able to explain your choice in terms of device support, configuration compatibility, required features, and access to logs and an exit option—not just the app’s name or colors.

3. Installation Checks: Set Up a Recoverable Environment

Resolve potential conflicts before installing

Before installing, exit other proxy clients, game accelerators, and tools that may change system networking. Note any manual proxy settings, company VPNs, or custom DNS in use. Exit means stopping background processes, not just closing windows. When multiple apps change routes and proxy settings at once, each interface may appear normal while actual traffic goes through a different entry point. Save a screenshot of your current network settings so you can restore your setup after testing.

Choose an installer for your operating system and architecture on the downloads page, then follow the client’s installation instructions. Installed apps, portable versions, and archives may store files in different locations; portable mode doesn’t necessarily keep all data in the app folder. Before the first launch, check that the configuration directory is writable. Avoid read-only paths and restricted system folders. If installing a service, understand that it provides network permissions; it doesn’t supply credentials for a remote proxy.

Grant the required permissions for your platform

On Windows, first confirm that both the main window and system tray entry open, then check whether the core starts. Respond to firewall prompts based on how you actually plan to use the client; don’t allow access on every network just for convenience. If you only use the client on this device, you don’t need to enable LAN listening. Wait until a basic connection works before configuring the service or administrator permissions required for TUN. This makes it easier to distinguish installation issues from advanced traffic-capture issues.

On macOS, follow the app’s prompts to open it for the first time and grant system permissions. If it requests a network extension, helper service, or Keychain access, make sure the prompt comes from the app you installed before approving it. If macOS reports that the app is damaged or won’t enable an extension, check the download source, OS compatibility, and blocked-app details in System Settings. Don’t disable system security wholesale. For specific permission scenarios, see macOS Installation and Permission Troubleshooting.

Android and iOS usually request system VPN permission when you connect for the first time. If another VPN is already active, check whether it will be replaced or paused. If Android disconnects after the screen has been off for a while, check battery optimization and background restrictions; don’t grant every permission at once. On Linux, confirm that the package matches your distribution, then install the desktop dependencies and services described by the client. A working graphical interface doesn’t mean the permissions service is running properly.

Verify the local entry point before enabling startup

In settings, find and record the actual listening address and port. Ports shown in tutorials are examples; another process may already use them, or the client may have changed them. A port conflict often appears as a core startup failure or an “address already in use” message in the logs. Exit older clients first, then identify the conflicting process. Don’t change ports at random: your browser, terminal, or system proxy may still point to the old, now-invalid entry point.

# Windows PowerShell: check whether the example port is listening
Get-NetTCPConnection -LocalPort 7890 -State Listen

# macOS / Linux: find the process listening on the example port
lsof -nP -iTCP:7890 -sTCP:LISTEN

These commands are for diagnosis; they don’t start a proxy. No output may simply mean nothing is listening yet. A missing command may mean the corresponding tool isn’t installed. If you find a process, identify it before deciding whether to stop it; don’t terminate an unfamiliar system service. A loopback address makes the listener inaccessible to other devices, which is a reasonable local default. Don’t expose it to the network just to “fix connectivity.”

Finish with a rollback test. Without importing a complex configuration, confirm that the client exits normally and the original direct connection still works after closing it. Then relaunch the client and check that the core log and listening port agree. This simple step can reveal leftover system proxy settings, permission-service issues, and port conflicts. Keep this baseline intact. In the next chapter, add only a subscription; don’t also change DNS, TUN, or LAN sharing.

4. Import a Subscription: Separate Download, Parsing, and Activation

Choose an import method and identify the content

A subscription lets a client fetch configuration periodically. Common entry points are labeled “Configuration,” “Subscription,” or “Profiles.” Copy the full URL from your provider, choose import from URL, give the profile a recognizable name, and start the download. Query parameters may contain authentication credentials. Missing trailing characters, spaces, or line breaks can cause the request to fail. Never paste a subscription URL into a search engine or public online checker.

Import a local file if you already have a complete YAML configuration. Make sure it contains the configuration itself—not a login page, instructions, or a compressed archive. A successful subscription request may still return an account login page, so download success and parsing success are separate checks. If the client reports a format error, inspect the start of the file and the lines near the error. Remove authentication details before sharing any content; troubleshooting isn’t a reason to expose your entire configuration.

YAML uses indentation to represent structure and typically uses spaces, not tabs. Add the correct separation after colons and keep list items consistently indented. Preserve the original encoding and structure, and don’t use full-width punctuation as syntax. Strings containing special characters can be quoted according to YAML rules, but don’t mechanically quote every field. The reported line is often where the parser noticed the problem; the missing indentation or quote may be on the line before it.

Select the active profile after importing

Seeing a profile in the list only means the client saved it. Click “Enable,” “Use,” or the control that marks it active, wait for the core to reload, then open the proxy page and check the proxy groups. If the old group names are still there, you may have downloaded the profile without switching to it. Check the active profile name, update time, and load errors before deleting and recreating anything. If you keep multiple profiles, name them by purpose to avoid choosing the wrong one.

A complete configuration usually provides both proxies and proxy groups. Expand the main group, confirm that it contains an outbound you can select, and test a node you’re authorized to use. Seeing a node name doesn’t prove the service is available: expired credentials, an unreachable remote server, or an incompatible protocol may only become apparent during connection. A failed latency test doesn’t mean all network access is broken either; the test destination and method may differ from the service you’re trying to use.

Subscription updates and client updates are different. The first changes nodes, rules, or proxy-group structure; the second changes the app and core capabilities. Remote updates may overwrite files you edited directly, so keep long-term rules in the client’s override, merge, or local extension feature. Check the merge order before making small test changes: some mechanisms replace arrays, while others prepend or append entries. Similar names don’t guarantee identical behavior.

Trace subscription update failures by type

When an update fails, distinguish an incomplete request, an access denial, and content that can’t be parsed. For a timeout, check your network, DNS resolution, and whether the update requires a proxy. For an access denial, check the full URL, account status, and provider instructions. For a parsing failure, inspect the returned content and supported core features. Don’t assume every error is caused by a proxy node: subscription downloads may use a different network path.

If the first subscription download requires a proxy, use a local configuration import method allowed by your provider to establish a basic connection, then test the update route. Don’t send your subscription to a converter with unclear data-handling practices just to solve a download issue. Proxy providers and rule providers may also fetch external files. Even after the main configuration loads, check whether those resources are ready—especially on first launch or after recovering from offline use.

By the end of this chapter, you should be able to identify the active profile, find the main proxy group, and tell whether an update failed during download or parsing. Keep the last working configuration locally and note where custom changes are stored. The next chapter uses your existing policies to test modes before adding rules. That way, if access changes, you can attribute it to the mode switch rather than a simultaneous subscription update.

5. Proxy Modes: Check the Entry Point and Outbound Separately

What Rule, Global, and Direct modes do

Proxy mode determines how connections that reach the core choose an outbound route. Rule mode matches connections against configured rules, making it suitable for everyday traffic routing. Global mode sends connections received by the core to the selected global policy. Direct mode connects them straight to their destinations. All three modes assume traffic has already entered the core. Apps that aren’t routed through system proxy, manual proxy, or TUN won’t change their path just because you switch to global mode.

For an initial test, choose Rule mode and confirm that the main proxy group has a usable node selected. Then open one destination that should use a proxy and another that should connect directly. Testing both helps avoid mistaking one working site for a healthy network overall. If something fails, briefly switch to Global for comparison. If Global works but Rule mode doesn’t, check the matched rule and proxy-group references before reinstalling the client.

Global mode doesn’t proxy all traffic from every device, and it doesn’t guarantee that DNS requests use the same route. It changes how the core handles connections it has already received. In some clients, the global selection is separate from the everyday Proxy group. After switching, check which outbound the global policy uses. Restore your usual mode after testing and verify the services you need; don’t leave a temporary test setting in place if it doesn’t match your real routing needs.

System proxy is an entry point, not a mode

The system proxy toggle changes the proxy information the operating system provides to apps. Browsers usually follow it, but games, some updaters, terminal tools, and apps with their own networking stack may not. If an app connects directly, that doesn’t necessarily mean the rules are wrong; it may not be reaching the local proxy port at all. Look for the app and destination in the connection list. If there’s no record, check the entry point instead of changing rules that can’t affect the connection.

To test a local HTTP proxy independently, use the command below. The port shown is only an example; replace it with the client’s actual mixed or HTTP proxy port. The command specifies the entry point explicitly, so it doesn’t depend on whether the terminal reads system proxy settings. A successful test proves only that this request used that entry point—not that your browser, other protocols, or all destinations follow the same path.

curl --proxy http://127.0.0.1:7890 --head https://example.com

Verify your diagnosis in the connection log

For each request, note the source app, destination domain or address, matched rule, proxy group, and final node. If it uses DIRECT, check whether that matches the configuration. If the correct policy matches but the request fails, check the node connection and DNS. Connection lists may group entries or quickly remove short-lived connections, so open the log before reproducing the issue. Don’t rely on a tray icon or a single toggle to confirm the actual route; it may only show that the service is running.

Existing long-lived connections may not switch routes immediately when you change modes. Browsers reuse connections, and chat apps and video streams may keep using their original route. For comparisons, make a new request and, if needed, close and reopen the app. If the client offers a way to close connections, remember that this interrupts active transfers. Rapidly switching modes while observing the same old connection can produce contradictory results.

Use a consistent test order: confirm the core is listening, confirm the app reaches the core, check the mode, then check the outbound route. Direct mode isn’t a substitute for exiting the app; the system proxy entry point may remain active. When you finish testing, use the client’s shutdown procedure to stop traffic capture and verify that system settings are restored. If the client says it’s connected but pages won’t load, work through the subscription, port, and system proxy troubleshooting checklist.

6. Routing Rules: Order, Proxy Groups, and Local Overrides

Start with rules you can explain

Rules are usually checked from top to bottom, and the first match determines the policy, so both order and content matter. Put specific exceptions before broad rules and fallback rules at the end. Adding a rule without checking its position may have no effect. If MATCH comes first, later rules can’t handle the traffic you intended. Learn the boundaries of a few rules before adding large rule sets; that makes unexpected matches easier to explain.

DOMAIN matches an exact domain. DOMAIN-SUFFIX matches that domain and its subdomains, while DOMAIN-KEYWORD matches a keyword in the domain. Keyword rules cover a wider range and can route unrelated services to the same policy. IP-CIDR matches an address range; GEOIP relies on a geolocation database, which doesn’t necessarily reflect where a service actually operates. Domain rules and address rules use different information. Choose based on real connection records instead of treating them as interchangeable.

# Merge into an existing configuration; Proxy must be an existing proxy group
rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - DOMAIN-SUFFIX,google.com,Proxy
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

This example shows only a rules block. It doesn’t include remote nodes and can’t establish a proxy connection by itself. no-resolve means the address rule won’t trigger DNS resolution just to match a domain-based connection; it doesn’t disable DNS globally. Direct routing for a LAN also requires checking the actual network ranges and TUN routes. Listing one private range doesn’t cover every internal network. Enterprise networks may use custom ranges, so follow the actual network design.

Proxy groups decouple rules from nodes

When rules point to proxy groups, you can switch nodes without editing the rules. A selectable group lets you choose the outbound; an automatic testing group picks based on configured test results; a failover group checks members in order for one that works. Each serves a different purpose. Lower test latency doesn’t mean faster downloads, and a reachable test destination doesn’t prove your service’s domain is reachable. Choose groups for the job instead of changing every group to the same type.

When renaming a group, check references in rules, other proxy groups, and overrides. A name mismatch can prevent loading or break an expected reference. Copy a working configuration first, then test members and selection in one group before making broader changes. Avoid circular references between groups. If the client reports a dependency loop, trace the references one by one instead of deleting arbitrary nodes mentioned in the error.

Make customizations that survive updates

For long-term customizations, use the client’s supported override or merge feature. First check whether new rules are placed before or after subscription rules, then add one easy-to-verify test rule. If merging replaces the entire rules array, existing routing may disappear. If it only appends entries, your new rule may end up after MATCH. Review the merged result before saving; it’s more reliable than inspecting the snippet in the editor alone.

Rule providers store large rule sets in separate resources that can be referenced with RULE-SET. Before using one, understand its format, behavior type, and update process. A domain list and a complete rule set aren’t interchangeable. If a resource download fails, the main configuration may still load but route traffic differently. Check resource status and cache information in the logs to confirm the provider is ready before questioning an individual rule.

For practical troubleshooting, choose one destination and check whether its domain is visible, then inspect the matched entry and final policy. If you see only an address, consider whether the app connected directly by IP, used a DNS cache, or was captured through a different mechanism. If the rule is correct but the service still fails, it may also need other domains, content delivery addresses, or login endpoints. Don’t switch all traffic to Global to fix one app; narrow the exception and record why you changed it.

By the end of this chapter, you should be able to explain why a request matched a rule and which destinations will be affected by changing its proxy group. Save the difference before and after each rule change, reload, and verify with a new connection. If the result is unexpected, revert that change before investigating the next layer. Small, isolated changes prevent subscription updates, DNS adjustments, and routing experiments from becoming one confusing problem.

7. TUN Mode: Traffic Capture, Permissions, and DNS

When to use TUN

TUN uses a virtual network interface and routing to send traffic to the core. It’s useful for apps that ignore system proxy settings and for handling more network traffic in one place. Its main difference from a system proxy is where traffic is captured—not that it’s faster or more advanced. Coverage still depends on route exclusions, app bypasses, protocol support, and platform limitations. Enabling TUN doesn’t mean every packet uses the same remote outbound.

Before starting, verify that the subscription works, rules are reasonable, and the regular proxy entry point is working. Save your current configuration, exit other VPNs, and check whether remote work, virtual machines, or containers rely on special routes. If you manage the device remotely, changing the default route without preparation can cut off your management connection. Arrange local access or a rollback plan first. TUN troubleshooting assumes the basic proxy works; it can’t fix an unusable subscription.

Enable settings one at a time

Install the permission service or grant system permissions as prompted by the client. Once TUN is on, check the virtual interface, routes, and core logs. Some clients coordinate system proxy settings automatically; others allow both mechanisms to run. Follow the client’s documentation. For comparison, test with one traffic-capture method first and confirm the target app appears in the connection list before deciding whether to keep the other entry point enabled. Don’t turn on every networking enhancement at once.

# mihomo configuration snippet; coordinate with your existing configuration and client management
tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

In this example, automatic routing adds a traffic-capture route, interface detection finds the outbound network interface, and the DNS hijack entry receives matching DNS traffic. Supported fields and behavior depend on the core and operating system. If your client has a TUN settings page, manage it there to avoid conflicts between the interface and the file. Copying this snippet alone won’t provide a complete DNS service or ensure that every platform uses the same networking stack.

DNS determines how domains take part in routing

DNS is an important part of TUN setup. Fake-IP mode maps a domain to a virtual address so the core can associate the original domain with a later connection. Traditional resolution returns the destination’s actual address. Each approach has compatibility tradeoffs; a single page-load speed test can’t establish which is better. Devices that rely on real addresses, service discovery, or internal services may need exceptions. Before making changes, confirm that DNS mode—not rules or routing—is causing the issue.

fake-ip-filter lists domains that should receive real addresses instead of virtual ones, but it isn’t a general proxy-bypass list. Connections still go through rule matching after receiving a real address. Adding a domain to the filter doesn’t automatically route it directly; check the rules and routes if the service needs a direct connection. For details on address mapping, read Fake-IP Mode and the Virtual Address Pool, then choose the smallest necessary exception.

DNS hijacking doesn’t capture every way of resolving names. An app’s encrypted DNS may travel over regular HTTPS or another connection, so capturing traffic on port 53 alone doesn’t prove it reached the core’s DNS service. If domain rules behave inconsistently, check secure DNS in your browser, in-app resolution, and the system cache. Don’t change system DNS, the core’s resolver, and browser settings all at once. Change one thing at a time and establish a new connection.

Test network changes too: switching from wired to wireless, from Wi-Fi to mobile data, or resuming from sleep can change the outbound interface. If a regular proxy works but TUN doesn’t, check the default interface, stale routes, permission service, and DNS capture before restarting the client. For a fuller comparison, see TUN vs. System Proxy: Traffic Capture Compared. You’re done when traffic capture works, internal networks remain accessible, and turning TUN off restores normal networking.

8. Maintenance: Updates, Speed Tests, and Troubleshooting Notes

Keep configuration updates separate from app updates

Once your setup is stable, focus on controlling variables. Don’t update the subscription, client, core, and operating system all at once. Record the active profile, mode, and proxy selection, then test after each individual update before moving on. If something breaks, you can link it to a specific change. “It worked yesterday” rarely tells you enough to distinguish a remote service change from a local environment change.

Before updating a subscription, make sure local rules are stored somewhere that won’t be overwritten, and keep a working configuration. After the update, check proxy-group names, members, and key rules; the previously selected node may have been removed. Before upgrading the client, read the feature and compatibility notes, and check for changes to the configuration directory, permission service, and core parameters. Don’t run an old process alongside the new app, or the interface and actual listener may belong to different installations.

Speed tests answer only a few specific questions

Clash node tests usually target a specified URL and report how one request performed. They don’t measure sustained download speeds or predict every website’s performance. A failed test may be caused by the test destination, DNS routing, or the request timeout. Compare nodes under the same conditions, test the same destination at roughly the same time, and verify with the service you actually use. Repeated testing adds requests and can make brief fluctuations look like lasting differences.

Automatic testing groups also depend on the test target and interval. A very short interval may cause selections to change often, while long-lived connections won’t necessarily move each time. If a service needs a stable outbound, manually pinning a working route may be better; if reachability matters most, use an appropriate failover setup. A single latency number can’t tell you whether a node is suited to video, calls, or large downloads—each depends on different performance factors.

Keep troubleshooting evidence organized by connection layer

When something fails, first check whether the basic network works without the proxy. Then check the subscription, core listener, system entry point, matched rule, and DNS. Record one reproducible destination and the exact time rather than testing a dozen apps and mixing the results. Start with the normal log level and increase detail briefly only when needed. Restore the normal level when done to prevent logs from growing indefinitely and collecting unnecessary browsing data.

A connection refused error and a connection timeout mean different things. A refusal often indicates that a local port isn’t listening, a remote service rejected the connection, or a firewall actively blocked it. A timeout may involve packet loss, routing, an unreachable destination, or delayed DNS resolution. The error text is a clue, not a final diagnosis. Consider where it occurred: switching remote nodes rarely helps if the local entry point refused the connection, and toggling system proxy won’t fix authentication when a rule has matched but the remote handshake fails.

When preparing a support request, include the client and operating system, mode, reproduction steps, destination type, and redacted error details. Remove subscription URLs, account parameters in node addresses, passwords, and personally identifying information. Logs may contain visited domains, and a screenshot’s QR code may function as a credential. If you’ve exposed a full subscription URL, reset its access credentials with the provider; deleting the post doesn’t remove copies others may have made.

Periodically remove unused profiles, obsolete rules, and test system proxy settings. Keep backups of working configurations and notes on local changes. After exiting the client, confirm that system networking is restored; after sleep or a restart, check that the right profile is active. For recurring issues, check your change log first, then consult the site’s user documentation and troubleshooting articles. The goal isn’t constant maintenance, but a few useful notes that make recovery straightforward.

9. Advanced: From a Working Configuration to an Understandable One

Start with a test copy and a way to observe results

After the first eight chapters, don’t advance by piling on more parameters. Start by explaining how your current setup behaves. Copy a working configuration for experiments, and note the purpose, expected result, and rollback method for each change. Change one variable at a time, make a new connection to the same destination, and record the matched rule and outbound. You understand a parameter when you can explain the difference it made—not just when it happens to work once.

The first step is to organize the configuration: manage remote subscription content, local rules, proxy-group preferences, and device settings separately. Identify which fields the client generates, which come from remote configuration, and which are added by overrides. If you don’t know how the final configuration is assembled, learn the client’s merge order before adding complex scripts. As a configuration grows, clear ownership boundaries matter more than a shorter file.

Learn DNS and providers in dependency order

The second step is to explore DNS. Understand which part of the process uses the basic resolver, proxy-domain resolution, and target-domain resolution before looking into nameserver, fallback, and their filtering conditions. Simply adding several encrypted resolver addresses doesn’t make DNS more reliable. A resolver’s own hostname may need bootstrap resolution, and its network path may depend on a proxy that isn’t available yet. Dependency loops can make a configuration look complete while startup hangs.

For individual fields, see DNS nameserver, fallback, and hijack configuration explained. The purpose and selection behavior of fallback depend on the configuration and core implementation, so don’t assume it’s simply a backup list used only when the primary resolver fails. Start with a reproducible domain test, then compare resolution results, rule matches, and connection behavior. Don’t draw conclusions from the returned address alone.

The third step is to add proxy providers and rule providers. They separate frequently updated resources from the main configuration, but add dependencies on downloads, caches, and startup. Check each resource’s source, format, storage path, and update interval, and see whether a usable cache exists if the first download fails. Paths and permissions vary between devices; a relative path that works on desktop may need to be managed by the client on mobile or in a service environment.

Boundaries for servers, routers, and control interfaces

Only in the fourth step should you consider running the Mihomo core on a server or router. These environments don’t have a desktop interface to handle permissions, service startup, and network recovery for you. You’ll need to manage configuration paths, the run user, logs, and routes yourself. First verify an explicit proxy on the device, then plan LAN access and firewall scope. Don’t replace the default gateway without a plan. Router compatibility also depends on processor architecture, memory, and system components—not just the archive’s filename.

A control interface lets you inspect status or manage the core; it isn’t a regular proxy entry point. If you need remote access, restrict the listening scope, configure authentication, and protect the management channel with a firewall. Never expose the control interface directly to the public internet or store credentials in a public configuration repository. LAN proxy sharing also requires clear access limits and intended users. Enabling LAN connections opens an entry point; it doesn’t provide complete access control.

For corporate intranets, per-app rules, dual network paths, or IPv6, first map the expected routes: which traffic enters the core, which must stay direct, which resolver handles DNS, and what should happen when the proxy disconnects. IPv6 requires compatible addressing, DNS, and routing; enabling one field doesn’t mean IPv6 is fully supported. Get authorization before changing managed devices or workplace networks, and don’t use proxy settings to bypass existing access controls.

Aim for a personal configuration you can explain: each proxy group has a clear purpose, every exception has a reason, every background service has a shutdown procedure, and every failed update has a rollback. For your first connection, return to the quick-start guide; to switch devices, visit the client downloads page. A small set of clear rules and a stable workflow is easier to maintain than copied snippets you don’t understand—and makes it easier to locate the cause when network problems return.