The Complete Clash Usage and Configuration Handbook

Chapter 1 · Core Concepts and Traffic Flow

What the client, core and configuration each do

Clash clients typically combine a graphical interface with a proxy core. The interface imports configurations, displays proxy groups, manages system proxy settings and shows logs. The core listens on local ports, matches rules and establishes connections. mihomo is a widely used core in this ecosystem. Similar-looking interfaces do not necessarily include the same core, support the same fields or use the same permissions. Before moving settings, check the target client's documentation.

A configuration file is the core's set of instructions, usually saved as YAML. It describes local listening ports, available proxies, proxy groups, routing rules and DNS behavior. A subscription is generally a URL for retrieving a remote configuration—not a client or a service that works as soon as you flip a switch. Rules and proxy selection can take effect only after the client retrieves a valid configuration, activates it and routes application traffic through the core.

How nodes, proxy groups and rules work together

A node defines an outbound endpoint and its connection settings. A proxy group organizes nodes or other groups—for example, for manual selection or automatic selection based on periodic checks. Rules decide which outbound route a connection uses. If a site behaves unexpectedly, first check which rule matched the connection and which group it selected, then inspect the node currently selected in that group. This is usually more useful than repeatedly switching the entire configuration.

Think of browser traffic as a chain: the app reads the system proxy setting or uses its own, then sends requests to a local listening port. The core uses available domain and address information to match rules and choose an outbound route. The selected node then connects to the destination. Any link in this chain can fail. A browser timeout means only that the request did not complete; it does not, by itself, prove that the subscription expired, DNS failed or the server is unavailable.

System proxy and TUN operate at different layers

The system proxy is an operating-system setting that apps can read; it does not force every program to use it. TUN uses a virtual network interface and routing to capture traffic, which involves additional permissions, DNS and route settings. For your first test, use the system proxy to verify browser connectivity. Consider TUN only if you confirm that an app bypasses the system proxy. This avoids troubleshooting multiple layers before the basic setup works.

Local ports also serve different purposes. A mixed port accepts HTTP and SOCKS proxy requests, while the controller port lets the client manage the core; they are not interchangeable. Using the controller address as a browser proxy usually results in a connection error. For everyday use, let the client configure the system proxy automatically rather than copying a port from another device. If you need to enter one manually, check the value in the current runtime settings.

Finally, distinguish between two kinds of updates: a client update replaces the application and its core, while a subscription update fetches remote configuration content. The former does not necessarily fix an expired subscription, and the latter does not upgrade the application. Record these changes separately when documenting an issue, along with the conditions of the last successful connection. That gives you a useful troubleshooting baseline for the chapters ahead.

Chapter 2 · Choose a Client for Your Platform

Check your device first, then compare interfaces

Choose a client based on your operating system, processor architecture and the apps you need to route, then consider interface preferences. For a first installation, start with Clash Plus on the downloads page. To compare configuration management, desktop integration and core settings, see the client comparison. Do not install and run several traffic-routing tools just to find a switch shown in a screenshot.

On Windows, go to Settings → System → About to check your system type and processor architecture. On macOS, check the chip or processor name in About This Mac. Apple Silicon and Intel installers cannot be distinguished by file size alone. Choose from the architectures listed on the downloads page. If your device does not match, confirm support before proceeding; do not rename a package for another platform and try to run it.

Configuration compatibility matters more than appearance

Even on the same platform, clients may handle configurations differently. Some add an override layer on top of subscriptions, some edit local files directly, and some accept only specific formats. Surfboard in particular should not be assumed to read arbitrary Clash YAML just because it appears on the same downloads page. Check which configuration formats the client supports, then request the matching format from your provider. This helps avoid mistaking a format error for a network problem.

On desktop, if you switch configurations often, compare how clients display proxy groups, expose overrides, export logs and restore proxy settings on exit. On mobile, prioritize foreground connection status, background restrictions and per-app routing. More features do not automatically make a client a better fit. Choose one that reliably imports, connects, verifies traffic and restores settings when you quit, then use it as a consistent environment for further configuration.

On iPhone, use the downloads page to open the Clash Plus App Store listing. You can also visit clashplus.io for product information. After installing, get familiar with the configuration list and connection controls, then authorize the system to add a VPN configuration. iOS manages background activity and network permissions; desktop steps for installing services, using the system tray or configuring local ports do not apply directly to a phone.

Archived clients and the standalone core

Clash for Windows and ClashX Meta are listed here as archived, discontinued clients. They may be useful for compatibility reference in existing setups, but are not recommended for new installations. Seeing their interfaces in older guides does not mean you should still follow the same installation steps. For a new device, choose a maintained client and map the guide's concepts to its current menus. This usually avoids permission and configuration compatibility issues.

The standalone mihomo core is for users who want to manage processes, configuration directories and network rules themselves. It is not a replacement desktop interface or a complete desktop installer, and running it does not automatically provide every system integration. Servers and routers also need a service startup plan and access controls. Most desktop users can focus on the configuration itself by starting with a graphical client, rather than managing process supervision and system routes.

When migrating clients, first disable the system proxy and TUN in the old client, then quit it before launching the new one. Migrate only configurations, rules and overrides you understand; do not copy runtime directories with unclear contents. After migration, check ports, proxy group selections and DNS behavior. The same subscription can be combined with different defaults in different clients, so connection results may not match exactly.

Chapter 3 · Installation, Permissions and First Launch

Review your existing network settings before installing

Before installing, quit any existing proxy clients and check how your browser works on the unmodified network. If the device has used a manual proxy, note its address and port, then decide whether to disable it. This makes it easier to tell whether a problem after installation came from the existing network or a new setting. On work- or school-managed devices, follow the organization's device policies; do not bypass them to install a system service.

Choose a file that matches your operating system and architecture from the client downloads page. On Windows, finish the installer and launch the app from the Start menu. On macOS, if you downloaded a disk image, open it, follow the instructions to move the app to Applications, then launch it from there. Do not keep running the app from a temporary extraction folder or disk image; upgrades, helper service paths and startup items may otherwise become inconsistent.

Match each permission request to a specific feature

On first launch, look over the main interface, configuration list and logs before granting permissions. Importing a regular configuration and taking over network traffic at the system level require different permissions. TUN or service mode may require administrator approval, while notification access mainly affects status alerts. Read the app name and purpose in each system prompt before granting access. If an unfamiliar program requests permission, cancel and verify the installation source and current operation first.

If macOS says an app cannot be opened or shows a system extension warning, verify the file source first, then check the relevant Privacy & Security settings for details and follow Apple's guidance. Disabling system-wide security is not a routine installation step. Keychain or network extension authorization is separate from importing a subscription. If prompts keep appearing, check that the app remains in its original installation location and that its helper components installed correctly.

After installing on Android, import a configuration in the client, tap Connect and review the system's VPN connection prompt. If the system frequently stops the app while it runs, check its battery and background restrictions—but there is no need to change every battery setting upfront. Some systems allow only one standard VPN service at a time. Starting another VPN app may disconnect the current one, which does not necessarily mean the client itself is broken.

iOS also requires system approval to add a VPN configuration. After granting it, return to the client, confirm the intended configuration is selected and connect. On Linux, first check which package format suits your distribution, install through its desktop installer or package manager, and note any missing-dependency messages. Treat desktop startup failures separately from core configuration failures: check application startup errors first, then inspect the configuration and logs.

Set a first-launch checklist

Without a subscription, an unconnected status or empty proxy group on the main screen is usually normal. Start by locating the configuration, proxy, connections and logs pages, and confirm the app can save settings. Then note the local listening ports and whether the system proxy or TUN is enabled. For your first test, enable only the system proxy and leave other traffic-routing features off. This keeps cause and effect clear when you verify a subscription in the next chapter.

On Windows, PowerShell can show whether a sample port is listening. The number below is only an example; use the port configured in your client. If a process is listed, identify it in Task Manager and exit it normally. Do not terminate an unfamiliar system process. No listener does not mean the network is necessarily usable; it means only that no matching listener was found within the scope of this check.

Get-NetTCPConnection -LocalPort 7890 -State Listen

Finally, test whether settings are restored on exit: disable the system proxy and TUN, quit the client, and confirm that ordinary direct access behaves as expected. If the browser continues to report that the proxy server is unavailable, check for a leftover system proxy pointing to localhost. Restore the network entry point before restarting the client. Testing the rollback path during installation is more reliable than hunting for a switch during an outage.

Chapter 4 · Import a Subscription and Activate the Configuration

Know the difference between a subscription link and a configuration

Subscription links are usually generated by a configuration provider and may contain personal access tokens. Treat them as sensitive information. Do not include the full link in public screenshots, online converters or support requests. This site explains how to use configurations; it does not provide a public subscription you can rely on long term. When searching for free Clash nodes, assess the source, expiry and data risks first. Do not treat a temporary configuration as a dependable everyday setup.

Once you have a link, open the client's Configuration, Subscription or Profile page. Add a remote configuration, paste the URL, give it a recognizable name and select Import or Download. A name can describe its purpose, such as “Daily setup,” but should not include access tokens. When the import is complete, look for a profile entry, update time or available proxy groups—not just an empty entry still waiting to download.

A successful download still needs to be activated

A successful import does not necessarily switch the active configuration. Select the new entry in the configuration list and choose Activate, Use or the equivalent option. Then check the proxy page to see whether group names and options have changed. Some clients reload the core automatically; others ask you to confirm. If the old groups are still shown, return to the configuration page and check which profile is active. Do not reinstall the client or add the same subscription repeatedly.

Import a local YAML file if you already have one or need to edit it offline. Choose Import from file and make sure you select the configuration file itself—not an archive, a saved web page or a screenshot. Remote profiles can usually fetch updates; local files are generally maintained by the user. Whether edits to the original file appear in the client depends on whether it references or copies the file. Confirm the behavior with a small change and reload.

If the import reports a format error, check the error location and response type first. The subscription URL may return a login page, an access restriction notice or an expiry page; none of these is YAML, even if it opens in a browser. Check for spaces, line breaks or smart punctuation introduced when copying the URL. Do not use the subscription management webpage address as the configuration URL—they are often different.

Understand YAML structure and formatting

YAML uses indentation to express structure, typically with spaces rather than tabs. Fields at the same level must align, and list-item hyphens must be positioned consistently. The snippet below shows only basic settings; it contains no usable proxies and cannot connect on its own. It illustrates top-level fields: mode, log level and listener settings are siblings, not nested under a proxy node.

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

Before updating a subscription, understand how the client stores changes. Editing rules directly in a remote profile may be undone by the next update. Put local changes you want to keep in an override or merge mechanism supported by the client. At first, avoid complex overrides. Confirm the original subscription loads and connects, then add custom settings one at a time. Check the final active configuration after each change; seeing text in an editor does not mean it is in effect.

Do not set an overly frequent automatic update interval; follow your provider's recommendations for typical use. Frequent updates cannot restore an expired service and may trigger access restrictions. If an update fails, keep the last working configuration and test the fetch separately instead of deleting it. To distinguish timeouts, empty responses and format errors, follow the subscription parsing troubleshooting checklist.

If the same subscription works in an older client but fails in a newer one, compare supported core fields and configuration formats first. Do not share the complete configuration publicly to ask for help. Export it, redact node addresses, credentials and subscription identifiers, and include only the relevant structure around the error and its message. That is usually enough to spot indentation, unknown-field or format compatibility issues.

Chapter 5 · Proxy Modes and Connection Checks

Check the traffic entry point separately from the outbound route

Rule, Global and Direct modes mainly determine how the core selects an outbound route after traffic enters it. The system proxy and TUN determine whether application traffic reaches the core at all. Switching to Global does not automatically route every app. To test, open the client's connections page, visit a known test destination in your browser and look for a new connection. Once you see one, check the mode and node selection.

For everyday use, start with Rule mode. Open the proxy page, find the main selection group and choose a node you know works. Then enable the system proxy. Keep the browser and test URL the same; first check whether a connection is established, then inspect the matched rule and actual outbound route in the connection details. A successful node health check means only that a particular probe completed—it does not guarantee that every site, protocol or long-lived connection will work.

Use Global mode for a limited comparison

If a destination fails in Rule mode, temporarily switch to Global and check which node the global group actually selects. If the same entry point and node work in Global but not Rule mode, focus on the matched rule and its target policy group. If both modes fail, check the node, name resolution and upstream network. Switch back to Rule mode after the comparison so later tests do not run under a temporary setting.

Direct mode does not necessarily restore the system to its original state. Apps may still send traffic to the core through a local proxy port, and the client may still affect DNS and traffic monitoring. To test the network after a full shutdown, disable the system proxy and TUN, then quit the client. Treat “direct through the core” and “client fully exited” as separate test conditions to avoid misdiagnosing the scope of a problem.

Troubleshoot missing connection records layer by layer

If visiting a page in the browser creates no new record, first check whether the system proxy is actually enabled and points to the current listening port. Browser extensions, custom proxy settings and in-app network settings may override the system setting. Another client may also have just rewritten it. Temporarily disable unnecessary proxy extensions, keep only one client running and retry the request while watching the connections page.

If a record appears but the connection fails, open its details and check the destination domain, port, policy chain and error. A timeout, refused connection and name-resolution failure point to different layers; “switch nodes” is not a universal fix. Test the same destination with two configured routes, then test two destinations using the same route. Changing one variable at a time helps distinguish destination restrictions, an individual node issue and local configuration problems.

Command-line programs do not always read the desktop system proxy setting. To test the local HTTP proxy independently, use the request below with the address and port from your current runtime settings. The example domain shows how to test; it is not guaranteed to be reachable on your network. A response proves only that this request completed through the specified entry point. It does not replace checking actual connection records for your browser or other apps.

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

Existing connections may continue using the old route after you change modes or nodes. To test new settings, send a new request. If needed, close only the relevant connections or reopen the test app; there is no need to reset all system network settings. Browser cache, connection reuse and offline page content can also mislead. Look for a new connection and its timestamp rather than relying on whether an already-open page still displays.

At the end of this chapter, record a short baseline: client, active profile, selected group and node, traffic entry point, and a destination that works. Save these conditions and repeat the test after changing rules in the next chapter. If slow speeds occur only in certain situations, see the layered guide to troubleshooting connection speed. Avoid changing DNS, modes and the entire subscription at the same time.

Chapter 6 · Rule-Based Routing and Configuration Order

Rules are checked from top to bottom; the first match wins

Rule mode checks connections from top to bottom and typically applies the policy of the first matching rule. Put specific exceptions before broader rules, and keep the catch-all rule at the end. If a new rule has no effect, first check whether an earlier rule already matches, then verify the destination and policy group. Repeating the same rule at the bottom will not affect a connection already caught by a rule above it.

Domain rules are useful for routing by service name; IP range rules handle well-defined network ranges. A domain-suffix rule matches the specified domain and its subdomains. Replacing it with a keyword rule can broaden the match unexpectedly. Whether domain rules work also depends on whether the app provides the domain name to the core. If the connections page shows only an IP address, consider how DNS is handled before assuming the rule syntax is wrong.

mode: rule
rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,PROXY

This is a rule merge example, not a complete proxy configuration. DIRECT is a built-in direct policy. PROXY must exactly match the name of a proxy or proxy group in your configuration; if no such name exists, use a group you already have. The final MATCH rule catches connections not matched above it and must not go first. Check your own group names before copying; do not overwrite the full configuration just because the example looks complete.

IP rules and DNS resolution boundaries

The prefix length in an IP range rule describes the network range, not a port number. The private address range in the example illustrates direct routing on a local network, but home and office networks may use different ranges. Check your gateway and device addresses. Do not add broad public IP ranges to a direct list without a clear reason. An overly broad match can catch destinations that should use a proxy and make some sites intermittently unavailable.

no-resolve means this IP rule will not actively trigger domain resolution for matching; it does not disable DNS altogether. If a connection already has a destination IP, the rule can still match its address range. Whether to use it depends on the rule's purpose and resolution strategy. If you need to route based on resolved addresses, consider the effect of additional lookups. If you only want to handle requests that already use an IP address, it can avoid unnecessary resolution.

Remote rule providers and local overrides

As rule lists grow, use rule providers supported by the core to manage remote or local rule sets. The content format must match the declared behavior type—for example, a domain list is not interchangeable with a complete rule list. A successful download does not guarantee the content can be parsed. Check provider names, cache paths and update times as well, so a failed remote fetch is not mistaken for a loaded update when the client is still using old cached rules.

A graphical client may combine subscription rules, local overrides and merge scripts into the final configuration. The order in an editor may not match the order the core actually reads. After editing, open the final configuration or runtime preview, find the target rule and confirm its position and policy name. Then check which rule actually matches in the connections page. The cycle—edit, preview, reload, verify—is more reliable than relying on a “saved” message.

If app sign-in and web browsing use different routes, first identify the actual destinations. A single action may contact separate domains for authentication, resources and APIs; adding a rule only for the domain in the address bar may not be enough. Use connection records to confirm each required destination and prefer narrowly scoped rules. Do not switch all traffic to Global to fix one failure—that hides the missing rule instead of explaining or fixing it.

Good rule maintenance is about clarity, not maximizing the number of entries. Document the purpose and removal conditions for custom exceptions, and remove them when they are no longer needed. If the subscription already includes the same rule, decide whether an override is still necessary. By the end of this chapter, you should be able to explain a connection's route from its destination, matched rule and policy chain—not guess based only on whether a page opens.

Chapter 7 · TUN, DNS and Traffic Routing

Know why you are enabling TUN

TUN uses a virtual network interface to capture traffic, often for apps that ignore the system proxy. It is not a speed boost or a fix for an invalid node or subscription. First confirm that the system-proxy baseline from Chapter 5 works, then check whether the target app actually bypasses the core. If the issue is just a misconfigured browser proxy extension, fix the entry point rather than adding a virtual interface, system routes and DNS interception.

Before enabling TUN, note the current network interfaces, other VPNs and the client's shutdown procedure. Desktop clients may require a helper service or elevated permissions; mobile systems manage this through their VPN interface. Prefer the client's TUN switch and default settings. Do not enable traffic routing in the interface while also adding system routes manually from a server guide; that can create duplicate rules or a setup that is hard to undo.

Treat the fields as settings that work together

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

This mihomo TUN snippet must be merged with an existing configuration; it does not replace complete DNS and proxy definitions. auto-route controls automatic routing, auto-detect-interface detects the outbound interface, and the stack option should match the capabilities of your core version. Some clients generate these fields themselves, so prefer changing them in the interface to avoid conflicts between file and interface settings.

The example in dns-hijack captures matching regular DNS requests. It does not mean all encrypted DNS or app-specific resolution will be intercepted. Browser Secure DNS, encrypted resolution in apps and internal corporate domains can all affect what you observe. Start with one clearly defined resolution setup, then check whether domains follow the expected DNS path. Do not change every resolver just because you see the word “DNS.”

Understand fake-IP and local name resolution

In fake-IP mode, domains resolve to mapped addresses while the core tracks the association between each domain and its connection for routing. These addresses are not the destination server's real public IPs, so they cannot tell you where a site is hosted or which route a node takes. Some apps depend on real addresses, local discovery or specific validation behavior and may need exceptions. Use filtering mechanisms supported by your client and core rather than disabling all routing features.

Test local printers, file sharing and company domains carefully. They may rely on local DNS, routes for specific subnets or broadcast discovery; a public-domain rule alone will not solve those issues. After enabling TUN, test the gateway, local devices and common internal services before external destinations. If only internal resources fail, check direct routes and name-resolution paths instead of immediately blaming every proxy node.

Identify conflicts and plan a safe rollback

Another VPN, virtual machine network, container bridge or security app may also modify routes. If every app disconnects at once, disable TUN first and check whether the original network recovers, then rule out conflicts one by one. Automatic outbound-interface detection may not choose the expected interface on devices with multiple network adapters, especially when Ethernet and Wi-Fi are both active. If you must specify one manually, use the device's actual interface name, not an example from another machine.

If the browser works but a particular app does not, check the app's protocol and destination port, and whether the node supports that transport. UDP traffic also depends on node capabilities, core settings and the upstream network; TUN cannot supply missing support. Use the connection details to see whether the request entered the core, which protocol it used and where it failed. That tells you whether to adjust traffic capture or test a different outbound route.

After testing, practice rolling back: disable TUN and confirm the virtual interface and automatic routes return to the expected state, then restore the system-proxy baseline. Check the outbound interface and DNS again after waking the device from sleep, switching Wi-Fi or unplugging Ethernet. Use TUN as your regular setup only after these everyday scenarios are stable; a simpler entry point is easier to maintain otherwise.

Chapter 8 · Updates, Backups and Troubleshooting

Save a configuration baseline you can restore

Once the setup is stable, record the client, active profile, main proxy group selection, system proxy and TUN status, and save any necessary local overrides. A backup is more than a subscription URL; include your own rules and how they are merged. You can usually fetch a remote subscription again, but local changes may have no other copy. Before reinstalling the client, export those changes before touching the application files.

Backups may contain node credentials, subscription identifiers or controller settings. Store them somewhere access-controlled; do not upload them to public code repositories or cloud drives. Screenshots and logs can also reveal destinations and local file paths, so redact relevant details before sharing. Troubleshooting usually needs the configuration structure, error and timeline—not your full account information. Keeping only what is necessary often makes the report clearer too.

Treat updates as three separate operations

Update the client, update the core and refresh the subscription separately, verifying each one before moving to the next. Record the working state, perform one update, then check that the configuration loads and common destinations work. Only then proceed to the next change. Replacing the app, core, subscription and DNS all at once makes it harder to identify the cause—even if the problem improves—and harder to recover when it happens again.

Read the release notes before upgrading, especially for changes to configuration fields, service mode and defaults. Do not judge compatibility by the version number alone or replace the client's core files just to get the latest release. Some graphical clients depend on a compatible core; manual replacement may break the controller connection or generated configuration. Prefer the client's official update path and keep the local configuration needed for rollback.

Narrow down the problem by scope

When something fails, first determine its scope: all apps or one, every destination or one domain, only on this network or after switching networks too. Then return to the Chapter 5 baseline and compare with the same profile and outbound route. If only one destination fails, focus on its rule, service and route restrictions. If no requests appear in the logs, check the entry point and process. If the logs show repeated resolution errors, investigate DNS.

When you need detailed logs, temporarily increase the log level, reproduce the smallest relevant operation, note the exact time and then restore the usual level. Leaving debug logging on adds storage and search overhead and may capture more connection details. Do not send maintainers hours of logs. Share the relevant excerpts around the failure and describe the expected behavior, what actually happened and which comparison tests you have already run.

Troubleshoot slow speeds separately from connection failures. Downloads, Wi-Fi signal, device load, carrier routing and congestion at the far end can all affect performance. A single node probe cannot represent sustained throughput. Keep the test destination, conditions and outbound route consistent when comparing nodes or networks. Do not rely on one automatic speed test to keep switching routes; that can interrupt long-lived connections.

Recovery steps and long-term upkeep

For a serious issue, disable TUN and the system proxy first to restore basic network access, then load the last working configuration. If a subscription update caused the problem, compare against a saved local copy. If a custom override is responsible, disable that layer temporarily rather than deleting the client. Reinstall only after confirming that the application files or user directory are actually damaged, and save the necessary configuration before cleanup.

Periodically remove unused subscriptions, obsolete rules and duplicate startup entries, and check whether an old client is still running in the background. For help organizing multiple profiles and switching between them, see notes on Profile and multi-profile management. Maintenance is not about tweaking settings every day; it is about recording changes, keeping evidence of issues and having a clear recovery path.

Chapter 9 · From a Stable Setup to Advanced Management

Learn proxy groups before copying a complete configuration

Advanced setup starts with a configuration you have already verified. First learn how proxy groups reference one another, then explore automatic selection and failover. Do not start by copying a full configuration packed with unfamiliar rules, scripts and remote resources. For every feature you add, be able to explain what it solves, what it depends on, how to verify it and how to undo it. Otherwise, complexity only increases future troubleshooting costs.

Manual-selection groups give you direct control over the outbound route. Automatic testing groups compare candidate nodes against a specified probe destination, while failover groups select an available option according to their own logic. Choose a probe destination that reflects the connectivity you want to measure, but remember that no single address represents every service. If a node passes its probe but video, games or work services still fail, inspect the actual traffic instead of treating the probe as an all-purpose health check.

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - AUTO
      - DIRECT
  - name: AUTO
    type: url-test
    use:
      - daily
    url: https://example.com/
    interval: 600

This example depends on a proxy provider named daily, which must be defined in the full configuration first; copying only the proxy group will not create any nodes. Adjust the test address to suit your purpose and network reachability. AUTO is referenced by PROXY, so traffic uses its selection only when AUTO is selected. Seeing an automatic group in the interface does not mean every connection uses it.

Understand provider and override maintenance boundaries

Proxy providers separate the source of nodes from local policies; rule providers separate rule content from the main configuration. Both introduce remote fetching, caching and format compatibility concerns, so name them clearly and define their purpose. If a resource fails to download, first check for a usable local cache, then determine whether startup is affected. Do not make every resource depend on the same proxy route that has not yet been established, or you can create a startup dependency loop.

Overrides are useful for personal policies, but merge behavior depends on the client. A list may be replaced or appended, and scripts may modify content after merging, so do not assume every client applies changes in the same order. Before reorganizing a complex configuration, run a small experiment: add a recognizable group or rule, inspect its position and content in the final configuration, then decide how to structure the full setup. This avoids starting with logic that is hard to verify.

Controller access and local network connections

An external controller manages the core and has different security implications from a regular proxy entry point. If you do not need remote management, keep it accessible only from the local device and do not bind it to every network interface. If LAN management is necessary, configure authentication, the system firewall and source restrictions together, and verify the security boundaries of the management page and API. Do not disable all access controls or expose the controller to the public internet just because the interface will not open.

Likewise, enabling a LAN proxy requires you to consider the listening address, port, client devices and firewall rules together. Changing allow-lan alone does not guarantee that other devices can connect, nor does it mean every network should have access. Test with one device on a trusted network and keep the proxy entry point separate from the controller. Disable sharing when you leave that network or switch to public Wi-Fi.

Build a repeatable testing method

For each advanced experiment, keep the original configuration, a working copy and notes on what changed. Prepare a fixed set of tests: an ordinary webpage, a destination that should be routed, a LAN service and recovery after quitting. Repeat them after changing any one layer—DNS, rules or TUN—and record matched connections and errors. Keep a change only if the results meet expectations; a page opening occasionally is not enough to prove the configuration is correct.

You do not need to keep adding settings. To repeat the basic setup on a new device, return to the quick-start guide. To switch clients, see the downloads page and client comparison. For a specific edge case, browse the technical notes. A stable setup is the foundation; make advanced changes only with a clear purpose to keep your configuration understandable and maintainable.