Clash Configuration Guide

1. Core concepts and connection flow

Understand the client, core and server

Start by separating the three layers. Clash Plus, Clash Verge Rev and FlClash are examples of clients—the apps you interact with. Their interfaces import configurations, display proxy groups, control settings and manage background processes. mihomo is the core that handles proxy connections, rule matching and DNS resolution. The server is remote and receives connections forwarded by the client. Installing an interface does not provide a working server, and a client download is not a subscription purchase.

Understanding the path a request takes is more useful than memorizing every setting. An app resolves a destination or starts a connection, then sends traffic to the core through the system proxy, a manually configured proxy or a virtual network adapter. The core reads the destination domain, address and rules, then decides whether to connect directly, reject the request or pass it to a proxy group. The group selects the final outbound route. If a page won’t load, the problem could be at any stage; a lit client icon alone does not prove the whole connection path is working.

Understand subscriptions, nodes and proxy groups

A subscription link provides access to configuration or node details and often contains credentials, so treat it like a password. A node describes a remote connection, including its server address, port, protocol and authentication settings. A proxy group organizes nodes or other groups for manual selection, availability checks or fallback. The same node can appear in multiple groups, but a group name does not indicate a real location or guarantee access to a particular website.

A configuration may also include DNS settings, listening ports, rule sets and remote resource URLs. Some subscriptions return only a list of nodes, which the client supplements using a template or merge mechanism; others return a complete configuration. These formats are not interchangeable. A successful import only means the client accepted the resource—it does not mean the configuration is selected, the core has loaded it or the remote account is still active.

Verify the connection one layer at a time

A local listening port is the entry point from an app into the core, not the remote server’s port. For example, mixed-port accepts both HTTP and SOCKS proxy requests on the same listening port. A common local address on Windows is 127.0.0.1, which refers only to the current device. When configuring a proxy manually, use the address and port shown in the client. Don’t copy numbers from a screenshot or enter a subscription URL in the proxy server field.

Check a connection in four stages: make sure the core is running, confirm traffic reaches it, inspect the selected rule, then check the outbound response. If the connection list is empty, first check whether the app follows the system proxy. If a connection appears but is rejected, inspect the matched rule. If it uses the expected route but times out, check the node, remote service and destination site. This approach avoids repeated reinstalls and helps distinguish DNS issues from subscription problems.

Also distinguish transport encryption from safe browsing. A client supporting a protocol does not make the configuration source trustworthy, and routing traffic through a remote server does not protect accounts from phishing. Import configurations only from trusted sources. If your browser reports a certificate problem, stop; don’t install an unknown root certificate to fix a connection. For project history and roles, see How Clash, mihomo and Clash Verge Rev are related.

2. Choose a client and check device architecture

Narrow down your options by platform

When choosing a client, start with your device platform, processor architecture and required features, then compare interfaces. For Windows, start with Clash Plus and check the requirements on the Windows download page. Clash Verge Rev is another option if you want to follow this guide’s examples for service mode, logs and routing rules. The instructions below use common labels from its interface; in other clients, look for equivalent configuration, proxy and settings pages.

Other Windows options include FlClash and Clash Nyanpasu. Don’t run multiple clients at once while testing: their listening ports, system proxy settings and virtual adapters can conflict. Before switching, turn off the old client’s system proxy and TUN, then fully exit its process. Keep a backup of the old configuration, but don’t set every app to launch at startup just to compare interfaces. For troubleshooting, keep a single, clearly defined traffic entry point.

Check the architecture, not just the OS name

In Windows, open Settings → System → About and check System type. For an x64 processor, choose an x64 or AMD64 installer; these labels refer to the same architecture here and do not mean the package is limited to a particular processor brand. For an ARM64 device, first confirm that the download page offers a compatible build and that the client supports your version of Windows. Don’t mistake a core archive for a desktop client installer.

On macOS, distinguish Apple Silicon from Intel. On Android, choose a universal package or one that matches the device architecture. On Linux, check the package format and package manager. Being able to download a package does not mean it will install on every system. Desktop clients need a graphical environment, permissions and system components that a command-line core does not. Server and router users may need to learn how to run and manage the standalone mihomo core as a service.

Choose based on maintenance status and features

Clash for Windows and ClashX Meta are discontinued. They may be useful for looking up older instructions, but they are not a good default for new users. Older clients may lack newer configuration fields, protocols or system compatibility. If an import fails, check the configuration requirements first, then consider moving to a maintained client. Don’t remove erroring fields as a universal fix—they may be essential to the subscription.

Even clients using similar cores may differ in how they store configurations, handle enhancement scripts and install services. When migrating, reimport the subscription first, then transfer only the rules you need. Don’t copy the entire application data directory. In particular, don’t treat a generated runtime configuration as a permanent source file: it may contain temporary ports, controller addresses, absolute paths and overrides that only work in the original environment.

Finally, consider what you need day to day. For browser use, start with the system proxy. If you need to route apps that ignore it, consider TUN. If you need different routes for different domains, focus on rules and proxy group management. More features don’t make a better first setup. Establish a minimal working connection, then add one requirement at a time and verify it. That gives you a clear rollback point whenever something goes wrong.

3. Install the client and run initial checks

Clear conflicting traffic entry points before installation

Choose an installer from the download center that matches your OS and architecture. Save it in an easy-to-find local folder rather than repeatedly launching the app from a temporary archive. Before installing, exit other proxy clients and note their proxy ports and whether TUN is enabled. If your device is managed by an organization, check that its network policy allows virtual adapters and background services. Don’t bypass management restrictions by changing system policies.

When you run the installer, review the publisher and permission requests shown by Windows. Requests for administrator access should relate to the install location, a service or a network component. Pause if the source, file type or prompt differs from what you expected. Don’t assume every Windows security warning is a false alarm, and don’t leave protection disabled just to install a client. Recheck the download source, device architecture and system requirements before proceeding.

Check the core before enabling the system proxy

After the first launch, open Settings and check whether the core is running and listening ports are established. Without a subscription, the proxy page may have no selectable nodes; that’s expected, and you don’t need to reinstall. Keep the system proxy and TUN off for now, and complete basic setup and subscription import first. If the core fails to start, check the logs for the first configuration parsing error, address conflict or permission error rather than focusing on the final shutdown message.

Port conflicts often happen when an old client is still running or the same app was launched twice. Identify the process using the port before taking action; don’t terminate random system processes. This example checks port 7897; replace it with the port shown in Settings. The process ID in the output helps identify the program—it does not mean the process is faulty. Once you’ve identified it, use the app’s normal exit option to release the port.

netstat -ano | findstr ":7897"
tasklist /FI "PID eq 1234"

The 1234 on the second line is an example process ID. Replace it with the actual ID from the first command before running it. If another required program is using the port, choose an unused port in the client’s settings and update any dependent tools as well. Don’t change only the port in Windows proxy settings while leaving the core’s listening port unchanged; requests will go to a port with no service listening.

Install service mode only if needed

Clash Verge Rev service mode lets a background service handle core operations that need elevated permissions, commonly for TUN. Open Settings, find the service mode option, install it and approve the system prompt. The exact label may vary between interface versions. When installation finishes, check the service status and restart related components if the client requires it. Installing the service does not enable TUN; they are separate states.

Security software or organizational permissions may block service installation. Note the exact error and use Windows Services to check whether the service exists and can start. Don’t judge success by the color of a toggle, and don’t repeatedly run repair commands from unknown sources. If the system proxy works but service installation fails, keep using the proxy while you investigate service permissions. That way, you won’t disrupt a working connection path.

Installation is complete when the client opens normally, the core logs show no repeated startup failures, the listening port matches expectations, and exiting and reopening the app behave as expected. Enable startup launch only after verifying the connection, and distinguish launching the interface from starting the background service or restoring the system proxy automatically. For an overview of the configuration, proxy and log pages, see the Clash Verge Rev interface walkthrough.

4. Import a subscription and activate the configuration

Select the active configuration after importing

Get a subscription link that works with your client or mihomo from your service provider. Copy the full URL, without punctuation, spaces or line breaks added by a messaging app. In the client, open Configuration, paste the link into the subscription URL field and click Import. Some interfaces call this page Subscription. When the download finishes, check that the new entry appears, then explicitly select or enable it. A configuration card appearing in the list does not mean it has been activated.

Once the active configuration is loaded, open the Proxy page and check for proxy groups. If you see nodes but not the expected rules and groups, first determine whether the subscription returns node data or a complete configuration. Some clients can generate groups and rules from a template; others require a complete YAML file. Use the entry point provided by your service provider. Don’t submit a subscription URL to an unfamiliar online converter—it may expose the credentials in the link.

Tell a download failure from a parsing error

If the subscription download fails, first check whether your current network can reach its domain, then look at the HTTP status and connection errors in the logs. An authentication failure may mean the link expired or the account changed. A connection timeout may point to DNS, network restrictions or a provider outage. A page opening in your browser does not prove the client can fetch the subscription: their proxy routes, certificate environments and request behavior may differ.

If the download finishes but parsing fails, check the response content and configuration format. The server may return a login page, an error message or unsupported fields instead of the expected YAML. Check the field and line number in the error, then ask your subscription provider what is supported. Don’t post a full configuration containing personal credentials in a public forum. For help, share only the relevant error context after removing server details, authentication settings and subscription URLs.

Separate the source configuration, overrides and runtime configuration

A subscription update fetches the remote content again. Edits made directly to a downloaded file may be overwritten on the next update. Changes to a generated runtime configuration may disappear when you switch configurations or restart the core. Put persistent customizations in an override, merge or scripting mechanism supported by the client, and understand the order in which it runs. Save a small change, reload the core, inspect the final configuration, then check whether the change survives a subscription update.

YAML is sensitive to indentation and data types. Indent with spaces, not tabs; keep hyphens on list items, and quote strings when they contain special characters. Repeating a key does not mean its values will be appended; parsers may error or keep only one entry. Don’t concatenate two complete configurations. Merge nodes, proxy groups, rules and DNS settings according to their structure, and make sure every referenced group exists.

Set the subscription update interval according to your provider’s guidance; updates don’t need to run too often. Before updating, keep a recoverable copy of the configuration and local overrides. Afterward, check whether the nodes previously selected in each group are still available. If a node’s name changed, the old selection may no longer work, leaving the group on its default or changing the route. For critical use, verify rule matches and the outbound route instead of relying on a successful update notification.

At the end of subscription setup, confirm that the active configuration is clear, the core loaded it successfully, proxy groups are visible and you can select at least one working route. When migrating from a local file, make sure it comes from a trusted device and retain any required authentication settings. Consider who can access files sent through cloud storage or messaging apps. A readable configuration is not safe to share: screenshots should not show node passwords, controller keys or subscription URLs.

5. Proxy modes and connection checks

Separate the traffic entry point from the route decision

The system proxy controls how an app sends requests to the core. Rule, Global and Direct modes control where traffic goes after it reaches the core. These settings do different jobs and can’t replace each other. Global mode does not automatically capture every Windows app, and enabling the system proxy does not guarantee every request will use a remote node. First identify whether you’re changing the entry point or the route, then check the connection log to see what actually happened.

For everyday use, start with Rule mode, where the core matches requests against the configuration’s rules. In Global mode, requests that reach the core usually go to the global proxy group, where you need to choose an appropriate route; selecting a Direct option can still send traffic straight out. Direct mode sends connections that reach the core directly. None of these modes can route traffic that never reaches the core or replace checks for a valid remote account and node.

Enable the system proxy and check app behavior

Once the configuration and nodes are ready, enable System Proxy in the client. In Windows, open Settings → Network & internet → Proxy and check that the address and port point to an active local listener. Clients may manage proxy settings in different ways, and organizational policies can override them. If the status doesn’t match, first close other proxy software rather than changing settings in multiple places at once.

Browsers usually follow the system proxy, but extensions, individual proxy settings or management policies can change that. Close existing connections, open a new one and test a page while watching the client’s connection list. A refresh may reuse an old connection or local cache, so it doesn’t prove the new settings are working. Check a clearly identifiable new request, including its domain, policy chain and connection status. Don’t rely only on a notification in the browser.

Command-line tools don’t always follow the Windows system proxy automatically. To test the local HTTP proxy explicitly, specify its address. This example uses 7897 as the mixed port; replace it with the port currently in use. The command checks the destination’s response. It does not guarantee that a public site is reachable on every network or prove that all apps are being routed.

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

An HTTP response means this request completed a round trip to its destination, but check the client to see which route it used. If the local port connection fails, check the core and listener. If the local request is accepted but the remote connection times out, check the outbound route. For certificate errors, check the device clock and trusted certificate environment; don’t add an option to ignore certificate errors. Troubleshooting by layer is more effective than switching nodes and repeatedly refreshing.

Understand speed tests and global-mode troubleshooting

Node speed tests send requests to a test address configured in the client. Results depend on the test target, network path and protocol implementation. A successful test doesn’t guarantee access to other sites, and a failure doesn’t prove the node is unusable. For a real issue, test the actual destination and check for DNS failures, incorrect rule matches or a destination-side rejection. Compare nodes under the same conditions; don’t judge long-term performance by one-off results from different times.

Before closing the client, turn off the system proxy—especially if you haven’t confirmed that the app restores your settings automatically. If the browser loses connectivity after an unexpected exit, check Windows proxy settings for a local port that is no longer listening. Restore connectivity, then restart the client. Don’t reset every network adapter just to clear a leftover proxy setting. If the system proxy meets your needs, keep using it and refine route selection in the next section.

6. Routing rules and custom configuration

Understand rule matching order

Rules are generally checked from top to bottom, and the first matching rule determines the policy. Put specific rules before broader ones, and place the fallback MATCH rule last. After adding a rule, check that the request provides the information it needs: domain rules need a recognizable domain, IP range rules match the destination IP, and process rules depend on platform permissions and the core’s ability to identify processes. Don’t assume a rule will match just because you know the app’s name.

DOMAIN matches a full domain name, DOMAIN-SUFFIX matches a domain and its subdomains, and IP-CIDR matches an IP range. The built-in DIRECT policy sends traffic directly; REJECT blocks it. Other policy names usually refer to an existing proxy group or node. Names must match exactly, including capitalization and spaces. A reference to a nonexistent group can prevent loading or produce unexpected routing.

Start with one small, testable rule

The example below shows direct rules for reserved domains, loopback addresses and local network addresses. It is not a complete configuration: it contains no nodes or proxy groups and cannot replace a remote subscription. For a local rule override, insert the entries where they belong in the existing rule list and keep its original final policy. Whether all local network addresses should go direct depends on your network and security boundaries.

rules:
  - DOMAIN,example.com,DIRECT
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve

no-resolve prevents a domain from being actively resolved solely to check an IP rule; it does not disable DNS altogether. If a domain request matches an earlier domain rule, later IP rules won’t be evaluated. To troubleshoot, open the connection details, check the rule that actually matched and inspect its position in the list. Don’t move every IP rule to the top to “increase its priority”—that could change existing domain routing.

Manage larger rule sets with providers

For larger rule lists, use rule-providers to manage local or remote sets, then reference them with RULE-SET. The set’s behavior, format and contents must match. A list of domains cannot be used as a complete classic rule list without conversion. If a resource fails to load, check its download path, cached file and logs. A successful subscription update does not mean every remote rule resource updated successfully.

When choosing rule sources, consider their maintenance scope and update behavior instead of importing a large number at once. Multiple rule sets may cover the same destination; their reference order determines the result. If you add exceptions for work apps, payment pages or local devices, record why and when you verified each one so you don’t forget its purpose. After updating the source configuration, check that custom rules were merged in the intended position.

When testing routing, end existing connections and send a new request; established connections generally won’t switch routes immediately after a rule change. Browsers and desktop apps may contact several domains at once, so a rule for the page’s main domain may not cover its images, authentication or API requests. Find the missing request first, then add a precise rule. Don’t redirect unrelated traffic with an overly broad keyword rule.

Finally, consider routing and DNS separately. Rules choose an outbound route, but domain resolution may happen locally, in the core or remotely; IP rules may also depend on the resolved address. If resolution fails, don’t keep adding rules to mask the problem. Check the DNS response and connection destination first, then decide whether to adjust resolution settings. Keep a record of a request that reproduces the issue so you have a reliable baseline when testing TUN and Fake-IP settings.

7. TUN mode and DNS checks

Decide whether you need virtual network adapter routing

TUN mode uses a virtual network adapter and routes to capture traffic. It can help with apps that ignore the system proxy, but the scope depends on the OS, routes, exclusions and client implementation. It isn’t an “upgrade switch” for every problem. If your browser works but one app doesn’t, first check which network interface and protocol the app uses before trying TUN. Changing the traffic entry point won’t fix node authentication or routing rules.

Before enabling TUN, close other VPNs, virtual adapter proxies and similar traffic capture tools, and note the current system proxy state. In Clash Verge Rev, make sure service mode is installed and running before turning on TUN. For the first test, you can temporarily disable the system proxy to make the traffic source easier to identify; follow the client’s instructions if it requires a particular combination. After enabling TUN, check regular websites, local network resources and essential work apps—not just one page.

Understand common TUN fields

The example below shows the TUN section of a mihomo configuration to explain its structure; it is not a complete, runnable configuration. A client may generate the same section through its interface. Use one maintenance method to avoid conflicts between interface settings and manual edits. Supported fields depend on the core version. If loading fails, check the relevant documentation instead of deleting every reported field and enabling an unpredictable traffic capture setup.

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

enable controls whether TUN is enabled, stack selects the network stack implementation, auto-route configures routes automatically, and auto-detect-interface detects the outbound interface. The example under dns-hijack captures the corresponding ordinary DNS traffic. It does not automatically cover every DNS request sent by apps over HTTPS or other encrypted channels, and it does not replace the core’s full DNS configuration.

Verify the DNS path separately

Fake-IP mode maps domain names to reserved addresses, allowing the core to recover the original domain from later connections and apply routing rules. These are not the destination servers’ real public IP addresses. If a lookup returns an address in the Fake-IP range, don’t assume DNS poisoning. Check the core logs, connection details and final response. If an app requires real addresses or has compatibility issues, consider adding a targeted fake-ip-filter.

After changing DNS modes, system and app caches may still contain old results. Close affected apps and, if needed, clear the system DNS cache before reconnecting. The Windows command below flushes the system resolver cache; it does not clear every browser’s internal cache or fix a remote service problem. Check a new request afterward—successful command output does not prove the network issue is resolved.

ipconfig /flushdns

Pay particular attention to routing boundaries on corporate and campus networks, in virtual machines and on devices with multiple network adapters. Changes to the default interface or switches between Wi-Fi and Ethernet can affect auto-detection. Local printers, shared folders and internal domains may also need to stay on their original route. If you run into trouble, disable TUN first to see whether the connection recovers, then check routes and DNS. Don’t delete network adapters or reset the system network as a first step.

Windows UWP apps also have a separate loopback restriction. When using the local system proxy, an app may be unable to access the loopback address because of its sandbox; this does not usually affect desktop browsers. Follow the UWP loopback exemption guide to check a specific app instead of changing permissions for every app. For more on resolution flow and compatibility, see Fake-IP vs. redir-host. Understand the address mapping before expanding the filter list.

8. Routine maintenance and troubleshooting

Keep a recoverable configuration state

Once everything is stable, track four things separately: the client, core, subscription and local overrides. A client update may also change the interface or bundled core. A subscription update can change nodes and rules, while an override edit affects the final runtime configuration. Change one category at a time and note the before-and-after state. If something breaks, you can then roll back to a specific step instead of guessing which update changed the connection.

Back up secure access to the subscription, local custom rules, override scripts and essential settings. Don’t treat all logs and temporary caches as configuration backups. A runtime configuration may contain sensitive credentials and local paths, and may not work when moved to another device. Store backups in encrypted or access-controlled storage, and check whether sync software exposes them to other people. Backup files need access controls too.

Read logs by troubleshooting layer

When a connection drops, note the time, network, affected app and most recent change. Check whether the core is still running, then verify that the system proxy or TUN is in the expected state. If only one site fails, don’t immediately restart the whole system; test another app or destination first. If every app fails, check the local listener, network interface, DNS and service status to narrow down the problem one layer at a time.

Configuration parsing errors point to a field or indentation issue; a local port binding failure means you should check for a conflict; a DNS resolution failure calls for checking DNS; a remote handshake or authentication failure means checking protocol settings and provider status. A timeout alone isn’t a diagnosis—it only means a step didn’t finish within the allotted time. Use the context to determine whether it occurred during subscription download, a destination connection, rule resource update or node testing. Avoid unrelated fixes.

Temporarily increasing log verbosity can help reproduce an issue, but don’t leave extensive debug logging enabled. Detailed output may record visited domains, destination addresses and policy choices; redact it before sharing. To report a problem, include your OS, client name, enabled features, error time and the shortest steps to reproduce it. Don’t share the original subscription URL, node credentials or full controller configuration. Check screenshots for private information in address bars, sidebars and notifications too.

Follow a clear rollback sequence

If an edit to the rules causes a failure, remove the last batch and reload. If a subscription update causes trouble, check group selections and new fields, then consider restoring a previous backup. If enabling TUN breaks connectivity, turn it off and test the system proxy path. If the client crashes and the network stops working, check whether Windows still points to a local proxy. Roll back to a previously verified state instead of randomly disabling every security feature.

Enable startup launch once the setup is stable. Restart the device and check that the service, interface and proxy settings start in the expected order. If the system proxy is restored before the core starts listening, access may fail briefly at startup. Test waking from sleep and switching networks separately too, since interfaces and routes may change. If a problem occurs only after waking, logs from that moment are more useful than repeated reinstalls.

Don’t treat frequent node switching as routine maintenance. First verify that the rules and route are correct, then consider switching to another working node. Don’t remove every option based on a single speed test. For more help, search the help center by symptom and share only error context with sensitive details removed. The goal is to reduce uncertainty and keep the last known working state easy to explain and restore.

9. Advanced configuration and learning path

Start by understanding the final runtime configuration

After completing the first eight sections, don’t start by adding more fields. First understand the final configuration the client sends to the core. Compare the source subscription, local overrides and runtime output to see where the listening port, proxy groups, rules and DNS settings come from. Save a small change, check where it appears in the merged result and test its behavior. If you can’t explain who generates a field, don’t rely on it for critical work.

Next, learn how proxy groups behave. A manual selection group lets you choose an outbound route; an automatic test or fallback group chooses according to its test conditions. The test URL, interval, tolerance and lazy checks all affect the result. “Auto” in a group name does not mean it is best for every kind of traffic. Test with noncritical traffic first, then decide whether to broaden its scope. Keeping a manual fallback makes it easier to identify changes caused by automatic selection.

Then separate resource management from DNS strategy

Third, explore proxy-providers and rule-providers. The former manages proxy resources; the latter manages rule resources. Their references and update mechanisms differ. Splitting resources can reduce duplicated configuration, but adds dependencies on paths, caches and remote downloads. Check what happens when each resource fails and whether the core still loads on a first launch with no cache. Don’t judge reliability only on a device that already has cached resources.

Fourth, refine DNS. Map out when the system, browser, core and remote server each resolve domains, and check whether apps have their own encrypted DNS. Then learn settings for choosing resolvers by domain, resolving direct-connection domains and resolving proxy server addresses. These settings may depend on one another, and a bad combination can create a resolution loop. For example, resolving a proxy server address may require a proxy connection, while connecting to the proxy requires that address to be resolved first.

When you encounter a loop, return to a verified resolution path and add policies one at a time. Don’t throw a long list of public resolver addresses together; more entries don’t guarantee compatibility. Internal domains usually need the DNS environment provided by your organization, and public resolvers may not know their records. Test routing, DNS selection and local network access together so you don’t end up with working websites but broken work resources.

Finally, review the controller, scripts and LAN sharing

The controller lets clients and management tools interact with the core; it is not a proxy port for ordinary apps. If you configure external-controller, keep it accessible only from the local device at first, and understand authentication and binding scope before expanding access. Never expose it publicly for convenience, and don’t enter its port in a browser as an HTTP proxy. Any interface that can change configuration should be treated as an administrative entry point, not an ordinary web page.

LAN sharing also involves allow-lan, the bind address and Windows Firewall. Enabling one setting does not guarantee other devices can connect, and it may expose access more broadly than intended. If sharing is necessary, limit it to trusted networks, devices and ports, then test from another device. Don’t open a listener on public Wi-Fi, guest networks or organizational networks without a clear need. When finished, restore the smallest exposure scope and close any temporary entry points.

Enhancement scripts and configuration overrides can eliminate repetitive work, but scripts are executable logic. Review their source and scope first. Make sure a script changes only the intended fields and does not unexpectedly remove proxy groups, rewrite DNS or expose the controller more broadly. Test again after changing subscriptions, since a script may depend on specific group names. A script that runs without errors can still produce the wrong result if a group name has changed. Keep a baseline configuration without scripts for comparison.

Close the learning loop: use the Getting Started guide to review the shortest connection setup, this manual to understand behavior, and the logs and connection page to test your assumptions. Put lasting changes in maintainable overrides. Desktop users don’t need to jump straight to deploying a standalone core. Learn service management, file permissions and network boundaries only if you need a server, router or automated deployment. The more complex the configuration, the more important it is to keep a simple, verified and recoverable route.