Clash Handbook

1. Core concepts and traffic flow

Clients, cores, nodes, and subscriptions

Clash is not the name of a single installer. In practice, a GUI client provides configuration and proxy screens, connection lists, and system controls; the core accepts connections, resolves destinations, matches rules, and establishes outbound connections. mihomo is a widely used core in this ecosystem. Similar-looking interfaces do not guarantee identical core features. To determine whether a field works, check both how the client generates the configuration and whether the core supports that field.

A proxy node is a set of parameters for connecting to a remote service, usually including a server address, port, protocol, and authentication details. A client is not itself a proxy service, and installing one does not provide a working route. A subscription is one way to retrieve or update a configuration or a set of nodes. Subscription links often contain credentials, so treat them like passwords. Never share a full link in screenshots, logs, or support requests.

A configuration brings these pieces together: inbound ports accept local traffic, nodes define remote exits, proxy groups organize exits into selectable sets, and rules determine which set handles a connection. A subscription may provide a complete configuration or only a list of nodes. After importing it, check which objects were actually created. A name appearing in the configuration list alone does not mean the connection is ready.

Check traffic capture before routing

A connection involves two separate questions. First, did the application’s traffic reach the core? This is usually handled by the system proxy, the application’s own proxy settings, or TUN. Second, once traffic reaches the core, how does it leave? Rules, proxy groups, and nodes determine that. An empty connection list and a logged connection that times out remotely are different kinds of problems. For the former, check traffic capture; for the latter, check rules, resolution, and the outbound route.

The system proxy provides an address to applications that honor system settings; it does not force all network traffic through a single path. A browser may use it, while some games, command-line tools, and background services may ignore it. TUN uses a virtual network interface and routes to capture more traffic, but routing exclusions, application behavior, and system permissions still matter. Check the connection log to verify traffic capture rather than relying on the toggle’s appearance.

Use four checkpoints to guide troubleshooting

When troubleshooting, check in order that the active configuration is enabled, the core is running, the application’s connection reaches the core, and the selected policy can complete the request. Keep an observable result for each step, such as the active status in the configuration screen, listening information in the log, or the destination and policy chain on the connections page. If evidence is missing, investigate that layer first. Avoid changing DNS, nodes, and rules all at once, since simultaneous changes can hide the cause.

Also distinguish latency tests from real-world access. A client’s test usually sends a request to one test address. The result shows whether that particular path responded; it does not prove that every website, video service, or login endpoint works. For further checks, use the application you actually need and note the time, network, and error. This makes comparisons meaningful by ensuring you are testing the same route under different settings.

2. Choosing a client and platform

Choose by operating system, architecture, and maintenance status

For a first setup, consider Clash Plus, then compare other clients for your platform. Start by identifying your operating system and processor architecture, not by choosing based on screenshots. Common Windows devices use x64, while some use ARM64. On macOS, distinguish Intel from Apple silicon. For Android, check which instruction sets the installer supports. An architecture mismatch can prevent installation or startup, or require translation; the file extension alone is not enough to tell.

Check the download page and the client’s current documentation for supported operating system versions. Do not assume that every release of Windows or Android can run the same installer. Before downloading, check installation permissions, available disk space, and whether a virtual network interface can be created. Organization-managed devices may restrict network extensions or service installation. Check with the device administrator rather than treating a permissions restriction as a node problem and repeatedly switching routes.

Desktop and mobile differences

Windows users can usually start by verifying browser access through the system proxy, then decide whether to enable TUN. On macOS, check network extension and app permission prompts as well as chip architecture. Linux desktop environments vary in their support for system proxies; enabling a toggle does not mean terminal programs will honor it. On servers or routers, mihomo can run directly, but you are responsible for service startup, configuration paths, listening scope, and log management.

Android clients usually capture traffic through the system VPN interface, so the desktop system-proxy steps do not apply. On first launch, grant VPN permission; continued background operation may also depend on battery settings. Surfboard uses a different configuration syntax from Clash YAML, so confirm that the subscription provides a compatible format rather than simply changing the file extension. See Android battery and background activity settings for related options.

On iOS, you can use Clash Plus. Check system requirements on the App Store product page; the official product site is clashplus.io. After granting VPN configuration permission, import a compatible configuration and verify that requests work. The VPN icon on your phone only indicates that the network interface is in use; it does not confirm that the subscription is valid or the selected route is reachable.

Factor migration effort into your choice

Clash for Windows and ClashX Meta are no longer maintained. Keep them as references for existing setups, not as the default choice for a new device. An older client starting successfully does not mean it supports the protocols and fields used by a current subscription. Before migrating, note your existing rules, proxy group selections, and LAN settings, then import the configuration separately in the new client. Do not overwrite the old directory; you may need it to restore your setup.

You can keep multiple clients installed for comparison, but run only one traffic-capturing instance while testing. Multiple system proxy toggles, VPN interfaces, or TUN routes make it hard to tell which component handles traffic. Find platform downloads on the client downloads page. Once you have a candidate, run a basic connection test before comparing shortcuts, overrides, and connection panels. There is no need to migrate every advanced setting at the start.

3. Installation and initial checks

Record the device’s network state before installing

First, quit any running proxy clients and VPNs, then confirm that the regular network can reach the sites you use. Note whether the system proxy is enabled, whether DNS is configured manually, and whether the device is connected to a corporate network. This gives you a clear baseline for recovery if something goes wrong after installation. If your device relies on an organization-provided proxy, do not clear its settings. Save the address and port first, and check whether other networking tools are allowed.

Get the installer for your device’s architecture from the downloads page and follow the operating system’s installation steps. Installation permissions and everyday runtime permissions are separate: installing a service may require administrator approval, while using the system proxy usually does not. Do not run the client permanently with elevated privileges just to rule out every possibility. If you need TUN, install any helper service according to the client’s instructions and verify that its source and installation directory belong to the client you are using.

On first launch, locate the configuration, proxy, connections, and log sections. The configuration page selects the active file; the proxy page selects proxy group exits; the connections page shows whether traffic reaches the core; and the log reports configuration and connection errors. See How client interface sections are organized for details. You can leave startup launch, LAN sharing, and TUN disabled for now to reduce the number of variables.

Check listening ports and the system proxy

After importing a valid configuration, check that the core starts and the mixed port is listening. A mixed port can usually accept both HTTP and SOCKS proxy requests; the active configuration determines the exact port. The standalone configuration below is for inbound and direct-connection testing only. It contains no proxy nodes and cannot verify a remote proxy service. Before using it, make sure another process is not using the local port, and switch back to your own configuration when testing is complete.

mixed-port: 7890
allow-lan: false
bind-address: 127.0.0.1
mode: rule
log-level: info

rules:
  - MATCH,DIRECT

The system proxy’s server address should point to a local listening address, and its port should match the active core configuration. Changing the port in YAML does not necessarily update the proxy settings the client writes to the system. If there is a port conflict, adjust the setting where the client supports it, then confirm that both sides match. Switching configurations may also change the active port, so do not rely on memory to keep every application pointed at an old value.

If curl is available, run the command below to explicitly use the local HTTP proxy. Receiving an HTTP response confirms that this request reached the specified inbound and completed a request; the status of the remote service still needs separate evaluation. If the command succeeds but the browser fails, check the browser’s proxy extension, independent proxy settings, and existing connections before reinstalling the client.

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

Windows UWP loopback and exceptions

Some Windows app containers restrict loopback access and cannot connect to a local proxy like regular desktop apps. A typical symptom is that the browser works but a Store app produces no connection entry. First confirm that the app uses the system proxy, then consider the client’s UWP loopback tool. Grant exemptions only to apps that genuinely need them and that you trust, and keep a record of the changes. Loopback exemptions are not a universal fix for Store app network issues.

Initial checks are complete when the configuration loads, the listening port is known, a test request appears in the log, and the network recovers after you exit. If the browser still points to a local port after the client crashes, first disable the leftover system proxy, then check for background processes. Track installation issues separately from node issues: the former concern whether the program runs; the latter concern whether the active configuration can establish the expected outbound connection.

4. Importing subscriptions and managing configurations

Identify the subscription contents before choosing an import method

On the configuration page, use an option such as Add remote configuration or Import from URL. Paste the compatible subscription link provided by your service and give it a recognizable local name. When copying, make sure you have not included spaces, line breaks, or punctuation added by a messaging app. Confirm what the link is for: a web dashboard, purchase page, and subscription URL are different resources. Opening a webpage in a browser does not prove that the core can parse it as a configuration.

After downloading, check whether the configuration contains nodes, proxy groups, and rules. Some links return only an encoded set of nodes and require explicit client support for that import method; others return a complete YAML file. If parsing fails, inspect the lines around the reported error and determine whether the response was a configuration, a login page, or an error page. Do not send a subscription containing credentials to an unknown online converter; using one gives its operator access to the subscription contents.

Importing a configuration and activating it are separate steps. After a new entry appears in the list, set it as the active configuration and wait for the core to reload, then check the proxy page for proxy groups. If loading fails, keep the previous working configuration and avoid importing several copies with the same name. First check whether the downloaded content is complete and its fields are supported, then decide whether to fix the format or contact the configuration provider.

Keep remote sources separate from local changes

Changes made directly to a subscription file may be overwritten when the remote configuration updates. For LAN rules, DNS settings, or additional proxy groups that need to persist, use the client’s supported override, merge, or script extension features where possible. Merge behavior varies: check whether rules are prepended or appended and whether lists are replaced or merged. After saving, inspect the final effective configuration rather than only the original text in the editor.

If you are not using an override mechanism yet, you can make a local copy for practice, but remember that it will not automatically receive remote node updates. Give the original subscription, test copy, and verified copy distinct names, and note why you made each change. If an update causes a problem, this makes it easier to tell whether the upstream content changed or a local rule altered the behavior, without rebuilding the configuration from scratch.

Troubleshoot subscription update failures by stage

First distinguish a download failure from a parsing failure. Downloads can fail because the network is unreachable, the device clock or certificate validation is wrong, the link has expired, or the server denied access. Parsing errors usually occur after content has been received. Check the error type and time in the log, not just a red status indicator. If the device clock is significantly wrong, correct it first. If the server reports an access or quota issue, check your account on the service dashboard instead of repeatedly changing DNS.

Also check which route the update request uses. Some clients let you update directly or through the current proxy. If the active configuration is already broken, relying on it for updates can create a startup dependency. You can try the other update route on a trusted network, but do not assume every client has the same options. Change only the update method and leave other settings alone; once downloading works, check the new configuration separately.

Do not stop checking as soon as an update succeeds. The provider may rename nodes, change proxy groups, or modify rules, leaving an old manual selection with no valid reference. Check the active configuration, proxy group options, and a real connection before resuming normal use. For a quick walkthrough, see the subscription import guide. The key maintenance principles are to keep remote sources updateable, local changes traceable, and recovery straightforward.

5. Proxy modes and proxy groups

What Rule, Global, and Direct modes do

Rule mode uses the configuration’s rules to choose an exit. It suits everyday use when local services, regular sites, and proxy destinations need different routes. Global mode usually sends connections that reach the core through a global policy, making it useful for checking whether routing rules are the problem. Direct mode sends connections reaching the core directly. Modes affect only traffic that has already reached the core: Global mode does not capture apps that ignore the system proxy or replace TUN.

For troubleshooting, briefly switch to Global mode as a comparison. If the same destination works in Global but fails in Rule mode, check the matched rule and proxy group selection first. If both fail, check the node, name resolution, and network. Keep the same node for both tests and establish a new connection. Existing long-lived connections may keep using their original exit; clicking refresh alone may not create a new connection. Close the relevant app before testing again if needed.

Direct mode does not mean the client is off. The system proxy and TUN may still be enabled, and the core may still receive and process connections. To restore the original network path without the client, disable the relevant traffic-capture features and check the system proxy and VPN interface status. Understanding this distinction helps avoid mistaking an active client path for a broken system network and explains why connections can still appear in Direct mode.

Proxy groups choose an exit, not just a node

A proxy group can contain nodes or reference other proxy groups. A manual selection group is useful for keeping a fixed exit; a URL-test group chooses from candidates based on test results; a fallback group checks options in the configured order. Automatic selection also depends on the test URL, interval, tolerance, and core implementation. It does not find the fastest route for every destination; it selects according to the configured probes.

The snippet below can be added to an existing working configuration. The example has only the built-in DIRECT and REJECT policies, so it can load but does not provide a remote proxy. For actual use, add candidates from a verified node set and make your rules reference the same group name. Preserve capitalization, spaces, and characters exactly. A rule that refers to a nonexistent group may fail validation or prevent the intended routing.

proxy-groups:
  - name: Select exit
    type: select
    proxies:
      - DIRECT
      - REJECT

rules:
  - DOMAIN-SUFFIX,example.com,Select exit
  - MATCH,DIRECT

Seeing PROXY in a configuration does not mean the core requires that specific proxy name. It is often just a custom proxy group name; it could be called Select exit or something else. Once you understand that names are separate from function, layered policies are easier to follow: a business rule routes to a service group, which selects a region group, which in turn selects a node. Troubleshooting requires expanding the full policy chain, not just checking the first group.

Choose nodes based on the intended use

When choosing a node, consider reachability, the required exit region, connection stability, and how the service charges for traffic. Low latency only means the probe path is short or responded quickly; it does not guarantee higher sustained download speeds. For video, meetings, or games, observe real-world performance over time. Do not directly compare one-off results from different times or network conditions.

Some services are sensitive to exit changes, so an automatic group switching nodes in the background may trigger reauthentication or end a session. For these services, use a dedicated manual group to keep the exit stable, while letting regular browsing use automatic selection. See How to choose a proxy node: latency, traffic multipliers, region, and protocol for more comparisons. Verify one node works reliably before adding more policy layers; it keeps maintenance simpler.

6. Rule-based routing and match verification

Read rules from top to bottom

Rule-based routing evaluates rules from top to bottom. The first match determines which policy handles the connection. Put specific exceptions before broader rules and the final catch-all last. If a domain already matches an earlier suffix rule, a more specific rule later in the list usually will not run. Check the existing order before adding a rule; adding another entry does not automatically override earlier behavior.

Domain rules rely on the core getting the destination hostname. If an app connects directly to an IP address, or the hostname is lost along the capture path, the expected domain rule may not match. The connections page may show only an address; check the DNS mode, sniffing support, and application behavior as well. Do not broaden proxy coverage to an entire network range just because a rule did not match; that could route local devices or services that should go direct through the proxy.

Start with a minimal rule set, then expand one item at a time

For practice, begin with easy-to-observe domain rules and a direct fallback. Verify the order and destination information before adding a proxy group. The snippet below is for the rules section of an existing configuration. It keeps loopback and common private addresses direct, and uses an example domain to test suffix matching. It is not a complete list of LAN address ranges and does not cover every IPv6 case; do not treat it as a universal final configuration.

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

no-resolve prevents a rule for an IP address from triggering a DNS lookup just for matching. It does not disable DNS for the entire configuration. If the destination is already an IP, it can still match an address-range rule; if only a hostname is available and no address has been resolved, the rule may not match. Geolocation rules also depend on a database and the resolved address; they do not determine location from a site’s language or the location of its operator.

For remote rule providers, also check the provider name, format, behavior type, and update time. A locally cached rule set is not proof that it updated successfully, and a successful update does not mean it covers every domain associated with a site. The main page, login, images, and APIs may use different domains. Use actual connection records to add what is needed instead of adding only the domain in the browser’s address bar.

Verify with connection records, not an IP-check webpage

After saving rules, reload the configuration and make a new request. On the connections page, check the destination, matched rule, policy chain, and final exit. An IP lookup shows the exit used for that specific lookup request; it cannot prove that another app uses the same policy. For useful comparisons, repeat one action, such as reopening a particular page or sending a command-line request, then check the match as soon as the connection appears.

If a custom rule disappears after saving, check whether you edited the remote subscription directly or whether an override was replaced during merging. If the rule remains but does not match, check its position, hostname visibility, and whether an old connection is being reused. If the right policy matched but access still fails, investigate the node and DNS rather than adding more rules. Use the layered approach in A layered troubleshooting checklist for slow speeds to avoid blaming every network issue on routing.

7. TUN and DNS configuration

Expand traffic capture after the system proxy is working

TUN is useful for capturing traffic from apps that ignore the system proxy, but it adds variables such as a virtual network interface, routes, and DNS paths. On desktop, first use the system proxy to confirm that the configuration and node work, then install a service or grant network permissions as the client directs. Mobile devices use the system VPN interface differently from desktop services, so do not look for a desktop control with the same name. Verify interface creation and traffic forwarding separately.

Before enabling TUN, note existing VPNs, virtual machine networks, and container networks to avoid overlapping routes and unexpected traffic paths. After enabling it, test a regular domain, then check LAN devices, work resources, and any existing VPN. If only LAN access fails, check direct rules, route exclusions, and the destination subnet before changing remote nodes. Access to internal corporate domains may also depend on preserving a dedicated DNS path.

DNS, Fake-IP, and destination identification

DNS translates domain names into addresses, but proxy connections are not necessarily controlled only by system DNS. Applications, browser Secure DNS, system resolution, and core DNS may all be involved. When troubleshooting, first identify which resolver handles the request, then decide which setting to change. Changing only the upstream server will often have no effect if requests never reach the core’s DNS. Encrypted DNS may also need a bootstrap lookup to establish its first connection.

In Fake-IP mode, the application receives a mapped address while the core keeps the association with the domain, allowing it to recover the destination and match rules. This is not the remote server’s real public IP and cannot be used to determine its location. Apps that depend on real addresses, broadcast discovery, or special resolution behavior may need filtering exceptions. For a comparison of the two approaches, see Fake-IP and Redir-Host explained.

The standalone direct-connection test configuration below is for desktop environments running mihomo that support these fields. DNS listens on a high local port; automatic TUN routing and interface detection still require system permissions. This configuration is for understanding the fields and checking traffic capture, and contains no proxy nodes. Assess possible conflicts with corporate networks, other VPNs, or nonstandard routes before use; do not overwrite a complete configuration that is already working.

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

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

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

rules:
  - MATCH,DIRECT

Test routing and DNS resolution separately

dns-hijack captures matching DNS traffic, but it will not automatically replace an app’s own resolution over HTTPS just because ordinary DNS port hijacking is configured. auto-route sets up the relevant routes automatically, while auto-detect-interface attempts to identify the outbound interface. Multiple network adapters, virtual networks, or a changing default route may still require manual checks. A supported field does not guarantee that the right interface will be selected in every environment.

If the browser works but other apps fail, check whether their requests appear on the connections page. If domains fail but a known IP is reachable, focus on name resolution. If all access fails after enabling TUN, disable TUN first to restore the original route, then check service permissions, the default route, and any overlapping traffic capture. After changing DNS modes, establish a new app connection and clear the relevant cache if needed; do not test new settings against an old mapping.

Final checks should cover not only website access but also waking from sleep, switching networks, and recovery after the client exits. If problems persist after disabling TUN, check whether the helper service and virtual interface exited cleanly, and whether a system proxy setting remains. The wider the traffic-capture scope, the more important a recovery path becomes. Keep a verified system-proxy configuration as a clear baseline for troubleshooting complex network issues.

8. Routine maintenance and recovery

Treat updates as three separate changes

Client, core, and subscription updates solve different problems. A client update may change the interface, services, or how configurations are generated; a core update affects protocol and field support; a subscription update changes nodes, policies, or rules. Try to update only one category at a time and verify stability before moving on. If all three change at once, it is difficult to know what to roll back and easy to mistake a configuration difference for a program defect.

Before updating, preserve the active configuration, overrides, and key settings. Record the system proxy port, current policy selection, TUN status, and installed services. A useful backup should restore the actual running state, not just preserve a screenshot. After updating, check the final effective configuration, especially fields managed automatically by the client. Some clients override YAML with their own interface settings, so comparing source files alone will not show every change.

Roll back one layer at a time as well. For subscription changes, switch back to a verified local copy; for a broken override, temporarily disable the extension; for a client update issue, follow the relevant installation instructions for the program and service. Do not overwrite a new configuration directory with an old program, since the configuration format or database may be incompatible. Test an old setup from a separate backup, and make sure two instances do not compete for the same port or network interface.

Launch at startup and background operation

Launch at startup usually means the client opens; it does not guarantee that the core, subscription, and system proxy are ready. Verify everything with a manual launch first, then enable the client’s startup option. After restarting, check in order that the program launched, the correct configuration is active, and traffic capture is enabled as expected; then test real access. If the system proxy turns on before the core is listening, network access may briefly fail during startup.

Waking from sleep and switching networks need their own tests. Moving from Wi-Fi to Ethernet, a mobile hotspot, or another router can change the default interface and DNS, requiring TUN to identify the route again. If access fails after every wake, note interface changes and log timestamps, then try restarting traffic capture or the core in order. Do not dismiss recurring issues as unstable nodes; the actual problem may be local route recovery.

For Android background operation, account for the device maker’s battery-saving settings. Allow the background activity the client needs and check whether it disconnects when the screen locks; only then consider adding it to the battery optimization allowlist. Do not grant every app every permission, or disable a foreground service required by the system just to reduce persistent notifications. Compare battery use under similar screen brightness, network conditions, and usage time, and distinguish the effects of the display, wireless signal, and proxy traffic.

Keep logs limited and maintain a recovery checklist

Use an appropriate routine log level, such as info, and increase detail temporarily only when investigating a specific problem. Record the time, target app, symptoms, and active configuration to narrow the search. Logs may contain domains, node addresses, and authentication details, so review them before sharing. When troubleshooting is complete, restore the normal log level and delete diagnostic files you no longer need to avoid retaining sensitive browsing records.

If Clash cannot connect, first disable traffic capture and check the original network. Then restore a known-good configuration and check the node and subscription status. If the original network also fails, troubleshoot the device’s connection, router, or ISP first. If only one app fails, check its proxy behavior and connection record. If all proxy destinations fail but direct access works, focus on the node, service status, and outbound connection.

Review LAN sharing regularly. Allowing LAN connections changes which other devices can reach the local listening port; being connected to home Wi-Fi does not make the access boundary irrelevant. If sharing is necessary, enable authentication, restrict the firewall’s allowed source range, and check the settings again after changing networks. The goal of maintenance is not to keep every feature enabled, but to know which features currently affect the device’s network path.

9. Advanced workflows and independent troubleshooting

Manage configuration differences before adding automation

Advanced configuration starts with being able to explain the current file, not layering on more sources. Separate subscription-managed content, client-generated content, and local changes, and choose one place to edit each. If the same DNS field appears in the client settings, subscription file, and an override, first determine which value takes precedence. Otherwise, every restart can make it seem as though your changes did not stick.

Next, learn to use proxy providers and rule providers to manage connection parameters, policy logic, and service rules separately. This can make updates more independent, but adds name references, paths, caches, and download dependencies. Start by splitting out a small set, then confirm it downloads, parses correctly, and can be referenced by a policy before migrating anything else. Do not add every remote resource at once and judge success from a single startup.

Set up automatic testing and failover based on what the service needs. For login services that rely on persistent sessions, frequent switching may be worse than slightly higher latency. For ordinary browsing, automatic selection may be acceptable even if the exit changes. Balance the test interval against traffic use and how quickly you need failures detected, and choose a test URL that reliably represents the route you care about. Multiple groups probing the same nodes can also generate unnecessary background requests.

Turn troubleshooting into a small, repeatable test

For a complex issue, first state what you expect: which app, which destination, which rule should match, and which exit should be used. Then choose one minimal action, such as opening a fixed page in a new browser window or sending a request with an explicit proxy command. Change one condition per test and record whether a connection appeared, which rule matched, and where the error occurred. Repeatable findings are easier to verify and describe to someone else.

Compare three setups: the original network with traffic capture off, a known-good configuration using the system proxy, and the same configuration using TUN. If the original network works but the system proxy does not, focus on inbound connections and the outbound route. If the system proxy works but TUN does not, focus on routing and DNS capture. If only certain domains fail, check related domains, service restrictions, and the rule chain; there is no need to reinstall everything.

Before moving to servers and remote management

When running mihomo directly, you take over tasks a GUI client normally handles, including configuration and working directories, service users, log rotation, and restarting after failures. First verify that the configuration loads in the foreground, then run it as a system service. A service starting successfully does not mean traffic capture is complete; also check listening addresses, routes, and permissions. On a router, account for storage, architecture, and existing firewall rules.

A remote control interface can show connections and change policies. Enable it only when needed, restrict access to the local device or a controlled network, and require authentication. Do not expose it to the public internet just to connect from a phone, and do not confuse its control port with a proxy inbound port. Remove credentials before sharing a configuration. If remote management fails, check the access scope and authentication before broadening the listening address.

You have completed this stage when you can explain how a request reaches the core, how its destination is identified, which rule it matches, and how it reaches an exit—and locate the failing layer when something goes wrong. For the shortest setup flow, see the connection verification guide. To explore specific mechanisms, continue with the topic articles. For each new feature, keep verification notes and a rollback method before moving on to the next configuration change.