Clash Setup Guide for Every Platform

Before you start

Clients, cores, and connection settings

The Clash ecosystem has three distinct layers: the client handles the interface, configuration management, and OS integration; the core handles protocol connections, rule matching, and DNS; and a subscription or local configuration provides servers, proxy groups, and rules. Installing the app only means it can run—it doesn't mean a working proxy route is configured. Desktop examples in this guide target mihomo. For other implementations, check which fields they support rather than assuming compatibility based on similar names.

Start with Clash Plus, then compare other clients based on your operating system and preferred workflow. Windows, macOS, Android, and iOS each have dedicated downloads; on Linux, consider Clash Verge Rev or FlClash. Different interfaces may call the same feature a configuration, subscription, or profile. Focus on what it does: a configuration source stores a remote URL, a proxy group selects an exit, and traffic-routing settings determine which apps use the proxy.

Check your system architecture and configuration source

Check your OS, processor architecture, and available storage in system settings. Intel and AMD desktop processors generally use x64 or AMD64 packages; Apple Silicon uses ARM64. Check Windows ARM devices separately. A file extension only indicates the distribution format, not the architecture. If an app won't run, first confirm that the installer matches your system rather than changing network settings.

Get a Clash-compatible subscription URL from a trusted provider, or use a verified YAML file. Subscription URLs may contain account identifiers. Remove query parameters and server credentials before sharing logs, screenshots, or configuration files. Opening a URL in a browser doesn't guarantee that a client can import it: the response might be a login page, usage notice, or unsupported format. Check the client's parse results and the actual configuration fields.

Establish a clear connection baseline

For your first test, quit other proxy clients, temporarily disconnect any unnecessary VPNs, and note your original system proxy and DNS settings. After importing a configuration, select rule mode and manually choose a known working route. In the same browser, visit one site that normally connects directly and one that requires a proxy, while checking the connection logs. Testing both paths is more informative than relying on a single latency reading.

The system proxy gives apps that honor OS proxy settings—typically desktop apps such as browsers—a way to connect through the proxy. TUN uses a virtual interface and routing to capture more IP traffic, and may require administrator privileges or involve DNS interception and conflicts with other VPNs. Neither changes your proxy route or fixes an unavailable server. Verify the proxy exit first, then expand the traffic-routing scope to avoid mistaking an exit problem for a virtual adapter issue.

This minimal configuration is for local diagnostics only. It includes no proxy nodes and lets supported connections go direct. Use it to check whether YAML loads and a listening port can be opened, not to test access to overseas proxy servers. For actual use, load the configuration from your provider and check whether the client overrides the ports. If a top-level key already exists, edit it in place rather than appending a duplicate at the end of the file.

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

A backup should also capture the traffic-routing method and permission status, not just the proxy nodes. After this section, go to the chapter for your platform; you don't need to run commands for all five platforms. To learn terms such as core, proxy group, and fake-ip, see the glossary, then match each term to the relevant option in your client.

Windows setup

Choose an installer and launch the client for the first time

Choose Clash Plus from the Windows downloads. If you prefer another interface, compare Clash Verge Rev, FlClash, and Clash Nyanpasu. Clash for Windows is no longer maintained; consider it only for legacy setups, not as the default for a new device. When switching clients, quit the old one first to prevent multiple processes from changing system proxy settings or competing for local ports.

Check your system type in Settings > System > About to identify whether your device is x64 or ARM. Use a recognizable installation path, then confirm that both the main window and system tray icon work. If Windows shows a security warning, verify the download source and release information, then follow the instructions shown by the OS. Don't disable security protections wholesale just to launch the app. Managed devices may also restrict installation or service registration; follow your organization's device policies.

On first launch, check the core status and configuration list. Some clients need you to select a configuration after the interface opens before the core becomes available. If the window opens but logs keep reporting a port conflict, quit other proxy apps and check for leftover background processes. Reinstalling repeatedly usually won't fix a port conflict caused by another running service.

Import a subscription and choose a proxy group

Open configuration or subscription management, add a remote configuration, enter a name and subscription URL, and save. Once it has downloaded and parsed, select it; adding a configuration doesn't always switch to it automatically. Check that nodes and proxy groups appear on the proxy page, then select a route in the group referenced by your rules. If you see only built-in options such as DIRECT, check the subscription content in the configuration logs instead of enabling the system proxy.

When a remote update fails, first determine whether the download or parsing failed. Download failures usually involve an invalid URL, authentication, or access restrictions. Parse errors often mean the response is a web page, the YAML has invalid indentation, or the core doesn't support a field. Keep the last working configuration rather than deleting it immediately. If the client offers an option to update through the proxy, try it only when the current proxy is already working; otherwise, you'll need a connection to download the configuration needed to establish a connection.

System proxy, TUN, and permissions

Enable the system proxy first and test rule mode in a browser. The proxy address must point to the port actually used by the local listener; 7890 in this guide isn't a universal default. Windows manual proxy settings and automatic configuration scripts are separate options, and an old script may override your intended settings. After turning off the client's proxy switch, make sure the OS settings have also been restored, especially if the app exited unexpectedly.

If you need to route traffic from apps that ignore system proxy settings, check whether your client supports TUN. It may require installing a service or launching a component with approved elevated privileges; installing a service isn't the same as running the entire interface as administrator every time. Prefer the client's service management tools and follow its instructions to restart the core. After enabling TUN, check the virtual interface, default route, and DNS logs rather than relying on the toggle's color.

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

This example shows only mihomo TUN settings; it isn't a complete subscription. The client may manage these fields, so check whether the interface will overwrite manual changes before editing a file. auto-route adds routes, auto-detect-interface identifies the outbound interface, and dns-hijack sends matching DNS traffic to the core. If enabling TUN cuts off your connection, disable it to restore the baseline, then check routes and DNS one at a time.

Windows-specific issues and shutdown steps

If a browser works but the command line doesn't, the command-line tool may not be using the system proxy. Specify a proxy for a single request to distinguish an app configuration issue from a proxy-node failure. This command uses the curl executable included with Windows; replace the port with the one currently in use. The test URL alone doesn't confirm that traffic exits through the expected route, so check the logs to see which policy handled the request.

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

After waking from sleep or switching between Wi-Fi and Ethernet, the outbound interface may change. If system proxy mode works but TUN doesn't, restart the core so it can detect the interface again, then check other VPNs, virtual machine networks, and firewall rules. When quitting, disable traffic routing first, confirm the system proxy has been restored, and then exit the app. Don't delete virtual adapters or reset all network settings; that can make the problem worse and erase useful diagnostic information.

macOS setup

Choose the right chip architecture and installation method

Check the chip information in Apple menu > About This Mac. Apple Silicon uses ARM packages; Intel Macs use x64 packages. Choose Clash Plus from the macOS downloads; other options include Clash Verge Rev and FlClash. ClashX Meta is no longer maintained. You can keep it to refer to an old configuration, but don't assume its core supports every current configuration field.

If you downloaded a disk image, open it and move the app to the Applications folder as directed by the distributor, then launch it from there. Running the app directly from the mounted image can cause issues with updates, helper components, or paths after a restart. If macOS blocks the first launch, read the relevant notice in Privacy & Security and verify the app's source. Don't run terminal commands from unknown sources to remove system security restrictions in bulk.

Some desktop clients stay open in the menu bar, so closing the window doesn't necessarily stop the core. Check the menu bar and Activity Monitor before configuring the app to make sure another proxy isn't running in the background. If the interface doesn't show a configuration, first check whether the current user can access the app's data directory; the Applications folder and configuration directory are not the same. When moving to another device, export the configuration or back up the specified directory rather than copying only the app.

Import a subscription and keep your configuration

Add a remote URL in configuration management, wait for the full download, then set it as the active configuration. Confirm that nodes and proxy groups appear, then choose a route. Menu bar shortcuts in macOS clients often switch proxy groups rather than configuration sources. If the nodes haven't changed, check which configuration is active instead of clicking the same proxy group repeatedly. Give subscriptions distinct names to avoid selecting the wrong one.

Relative paths in local YAML files are usually resolved from the client's configuration directory, not necessarily the Downloads folder. If your configuration references rule sets, certificates, or other files, make sure the core can access them. Keep remote subscriptions on their update schedule and manage custom fields through the client's supported override options. After each update, check the final rule order so local rules haven't ended up after MATCH, where they would never be reached.

Network service proxy settings and helper components

Enable the system proxy first and test a connection in a browser. macOS proxy settings are tied to network services, so Wi-Fi, Ethernet, and other services may each have their own settings. If the proxy stops working after switching connections, check that the active service still points to the right local address and port. If the network remains broken after quitting the client, check that service's proxy settings before changing DNS.

Use this read-only command to check a summary of the current system proxy, including its enabled status, host, and port. It doesn't change settings or show how every app handles its own proxy. If the summary doesn't match the client interface, try turning the system proxy off and on, then check whether another network tool is continually changing the settings. A configuration profile managed by your organization may also lock these options.

scutil --proxy

TUN usually relies on a privileged helper component to manage virtual interfaces and routes. Read the system's authorization prompt and confirm that the request comes from the client you're using. If authorization fails, check the specific service error in the app logs instead of repeatedly entering your password. School or work devices may restrict network extensions and system services; use an approved traffic-routing method rather than attempting to bypass management policies.

Wake from sleep, LAN access, and app differences

After waking from sleep, check whether the current network needs authentication again and whether the core has detected a different outbound interface. If only TUN has stopped working, restart the core first; there's no need to re-import the subscription. If printers, network storage, or other LAN services are unavailable, check whether those connections are being routed through the proxy and review their matching rules. Add accurate direct-connection rules for your network rather than sending every private address range through a remote proxy without checking.

Whether terminal apps use a proxy depends on the apps and environment variables, not the menu bar icon. Test a single request with an explicit proxy parameter before deciding whether to configure the terminal environment. When you're done, turn off TUN and the system proxy before quitting the client, then check that network service settings have been restored. Before uninstalling, use the client's tools to remove any helper services you no longer need; deleting only the app could leave components running.

Android setup

Installation source, architecture, and updates

Choose Clash Plus from the Android downloads, or compare Clash Meta for Android, FlClash, and Surfboard. Apps don't all support the same configuration formats or advanced fields; in particular, don't assume every app can use a complete mihomo YAML file. Choose an app compatible with your subscription format first, then consider interface preferences. This can save you from extra conversion and troubleshooting later.

Most recent phones use ARM64, but older devices, emulators, and specialized systems may differ. Check your device specifications or the download page's compatibility notes if you're unsure. When installing an app package, grant installation permission only to the browser or file manager you're using, then revoke it afterward if you like. If Android reports a conflict with an installed app, check the package name, signature, and source. Don't rush to uninstall the old app and lose its configuration or local rules.

Before upgrading, note your subscription URL, proxy group selection, and per-app settings. Whether an in-place upgrade preserves data depends on the app ID and signing key; don't judge compatibility by the icon or display name alone. Settings usually can't be fully migrated between different clients. Even with the same subscription, check VPN authorization, app exclusions, and background permissions again. Save the old client's working state before importing anything.

Import a configuration and grant Android VPN access

Add the subscription URL in configuration management. Once the download is complete, select the configuration and check the route on the proxy or policy page. If the response can't be parsed, check which formats the client supports and ask your configuration provider how to use it. Don't submit a URL containing account information to an unknown conversion site. Importing a local file can help diagnose download issues, but it won't automatically follow remote subscription updates, so plan how to maintain it.

When you tap Connect, Android usually asks you to approve a VPN connection. This lets the app create a local virtual interface; it doesn't mean your phone has connected to a traditional VPN provider. The actual exit is determined by the configuration's proxy policy. A VPN icon in the status bar only confirms that the interface is up. Open a webpage and check the connection logs to make sure the target app is using the selected route.

Android usually allows only one regular VPN service to run at a time, so another VPN app may replace the current client. Local firewalls, traffic filters, and some network-accelerator apps may use the same mechanism. If the connection drops immediately, check those apps and Android's always-on VPN setting before switching proxy nodes. Desktop system proxy instructions don't apply directly to phones; they use a different traffic-routing method.

Per-app proxy settings and background operation

Per-app settings usually offer two opposite options: proxy only selected apps, or exclude selected apps from the proxy. Read the current mode before changing it, then test with one app. An excluded app may bypass the core entirely, so its connections won't appear in the logs; that's expected, not evidence that the rules failed to load. After changing the app list, you may need to recreate the VPN interface by disconnecting and reconnecting as prompted.

If the connection works with the screen on but drops when locked, check battery optimization, background activity limits, and the manufacturer's autostart settings. Grant only the permissions needed by the client and see if that resolves the issue; there's no need to relax restrictions for every app. Some systems may still stop services in power-saving mode, during extended idle periods, or when memory is low. Compare disconnect times with system activity rather than blaming every interruption on the proxy route.

Mobile data, DNS, and hotspot limits

Switching from Wi-Fi to mobile data may change the underlying address and routes, interrupting existing connections. Wait briefly for the client to reconnect, then check whether it has detected the new network. If it fails only on one network, distinguish network authentication, DNS reachability, and proxy server reachability. Networks at airports and hotels may require web-based sign-in before a proxy can connect; until you authenticate, every node may appear unavailable.

Android Private DNS, an app's own secure DNS, and the client's DNS settings can all be active at once. Changing one setting doesn't mean that all DNS requests now follow the same path. Use client logs and test results to identify which component handles lookups. Don't treat the location shown by a DNS test page as proof of a leak: the proxy server's network, recursive resolver, and the test site's detection method can all affect the result.

Before relying on the connection, check three things: whether it reconnects after the screen locks, whether switching networks requires a manual reconnect, and whether excluded apps go direct as expected. Keep a regular rule-mode configuration as your baseline. If something goes wrong, disable per-app and other optional settings first, then re-enable them one at a time. This helps identify whether the issue is with the basic connection, background restrictions, or app-selection rules.

iOS setup

App Store installation and feature limits

For iPhone and iPad, start with Clash Plus. Install it from the Clash Plus page on the App Store, and check the product information on the official clashplus.io website. Downloads are also listed on the iOS downloads page. Check the App Store's system requirements before installing and rely on the information shown for your device, not assumptions based on the client name.

iOS apps are subject to the system's network extension and sandbox restrictions, so they work differently from desktop clients. This guide uses terms such as configuration, policy, and connection to describe the workflow; exact button names depend on the current interface. A mihomo field in a desktop configuration doesn't mean a mobile app can interpret it the same way. Check the import results, app documentation, and actual connection behavior. In particular, don't paste a desktop TUN block in place of the phone's connection settings.

Import, select, and update a subscription

Get a subscription URL supported by the app, then choose Add from URL in configuration management. Enter a recognizable name and save. After the configuration downloads, select it and check that the expected proxy groups and routes appear. If the app supports file imports, make sure the file's encoding and formatting are intact; copying from a chat app can remove line breaks. Don't save links containing account information in public notes or share them in group chats.

Importing a configuration doesn't automatically make it the active one. After adding it, check which item is selected, then confirm that the proxy group points to a working route. A subscription containing only nodes may also require a supported ruleset or configuration template. If the app reports missing rules, follow its instructions rather than concatenating an entire configuration from another client. Re-importing won't fix unsupported fields and can make similarly named configurations harder to tell apart.

Keep the last working configuration when updating a subscription. First check whether the update succeeded, then see whether the nodes or policies changed. If updates require an active connection, check which route the update request uses. If no route is working, you'll need to retrieve the configuration over a reachable network first. Manual edits may be overwritten by the next update, so use a persistence method explicitly supported by the app and verify your changes afterward.

Connection authorization and traffic coverage

On the first connection, iOS may ask permission to add a VPN configuration and require device authentication. Approve it, return to the app, and start the connection while watching the system status and app logs. The VPN indicator means the network extension is active, not that the proxy node is reachable or that every app's traffic is handled the same way. Test one direct connection and one proxied connection, then check the selected policy instead of relying on the toggle alone.

iOS doesn't provide the same system-wide HTTP proxy switch as desktop operating systems. The HTTP proxy setting on a Wi-Fi network's details page applies only to that network, while an app's tunnel connection is handled by the network extension. Don't confuse the two. In general, use the app's connection flow. If you also keep a manual Wi-Fi proxy, note why it's there and check that it doesn't cause double proxying or affect access after you quit the app.

Other VPNs, network filters, or managed network configurations on the device may conflict with the current connection. If the connection drops as soon as you tap Connect, check whether another configuration is enabled and read the app's error details. On a work or school device, follow its network policies; don't delete an unfamiliar configuration profile as a test. Change a profile's status only when you know where it came from and what it's for.

Network changes, DNS, and recovery

Switching between Wi-Fi and cellular may require reconnecting. First confirm that the app is allowed to use cellular data, then compare the same route on both networks. If only Wi-Fi fails, check whether web-based authentication is required. If only cellular fails, check network permissions and whether the server address is reachable. Don't change the route, mode, and DNS all at once; even if that fixes the issue, you won't know which change helped.

Interpret reported exit details in the context of how the request was routed. Under supported conditions, iCloud Private Relay may affect some Safari traffic, while an app's own DNS and connection policies can also change what you see. During troubleshooting, note the original state of these features, compare one variable at a time where possible, then restore the original settings. One browser test doesn't represent every app on the device, and it can't establish the path used by every DNS request.

If the connection drops after the screen locks, distinguish between a network change, a route timeout, and a network extension restart. Check whether it reconnects automatically when you reopen the app, then review the logs around that time. Don't force-quit the app as a routine way to keep it running. To restore the default connection, disconnect in the app first, then check the system VPN status and Wi-Fi proxy settings. If removing an old configuration, verify its name and source in Settings so you don't delete one needed for other work.

Linux setup

Desktop clients and standalone cores

For Linux desktops, choose Clash Verge Rev from the downloads page, or use FlClash. Check the distribution's package manager, processor architecture, and desktop environment before choosing an installer. A standalone mihomo core is better suited to servers, routers, or users who want to manage the service themselves. It doesn't provide a full desktop interface, so you'll also need to set up a configuration, process management, and log access.

DEB and RPM are package formats, not interchangeable archives; don't install one on an incompatible distribution. Desktop apps also depend on the desktop environment and runtime libraries. If installation fails, read the dependency errors from your package manager instead of changing file permissions. Installing a local package through the system package manager keeps dependency information and uninstall records. Don't run the entire desktop app as root to get around dependency errors.

These are common commands for installing local packages; the filenames are examples, not actual download links. Before running a command, replace the path with the package you downloaded and make sure it's right for your system. After installation, launch the app from the application menu. Check that the tray icon appears, the configuration loads, and the core starts. A visible window only confirms the GUI works; it doesn't confirm that proxy ports or network permissions are ready.

sudo apt install ./client.deb
sudo dnf install ./client.rpm

Import subscriptions and understand desktop proxy differences

Subscription setup in a Linux desktop client is much like on other desktop platforms: add a remote configuration, wait for it to parse, select it, then choose a route in the proxy group. Linux desktops differ in how they store and read system proxy settings. Some apps use environment variables; others use desktop settings or their own proxy options. If the browser works but the terminal doesn't after enabling the system proxy, that doesn't necessarily mean the core is at fault. First find out which proxy method the terminal tool uses.

You can test the local proxy for a single command-line request without changing environment variables for your whole session. These commands test the HTTP and SOCKS endpoints; the hostname form in the SOCKS example passes the destination domain to the SOCKS server for resolution. Use the port from your current configuration. If the connection is refused, check that the core is running and listening on the right address before investigating the remote node.

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

If you need proxy environment variables, test them temporarily in the current terminal and account for differences in variable names and app support. A NO_PROXY exclusion list may bypass the proxy for some requests, and sudo may remove environment variables. Record the actual command context when troubleshooting; a successful test as a regular user doesn't mean a system service or container inherits the same settings.

Standalone core configuration and service permissions

Use a dedicated data directory for a standalone core, with its configuration and any required downloaded data files. Run it in the foreground first and read the logs; set up a background service only after confirming the configuration works. Don't hide logs and enable automatic restarts right away, or syntax errors may look like repeated process crashes. These commands assume the executable is installed and the configuration directory exists. Adjust paths for your system.

mihomo -t -d "$HOME/.config/mihomo"
mihomo -d "$HOME/.config/mihomo"

-t tests the configuration and can catch syntax and reference errors, but passing the test doesn't prove that servers are reachable or routes are correct. A background service should also have an explicit working directory, run user, and file permissions. Limit access to configurations containing credentials. If another user created the configuration, make sure the service account can read the required files rather than granting broad access to the entire directory.

TUN, DNS, and distribution differences

Linux TUN needs permission to manage virtual devices and network routes. For a desktop client, use its service installation tools. For a standalone setup, grant only the permissions required by the service; don't run every program with elevated privileges all the time. Containers and restricted hosts may not provide access to virtual devices, and changing YAML can't overcome those environment limits. Check host support before adjusting core settings.

Your system may use NetworkManager, systemd-resolved, or another DNS resolver. Editing /etc/resolv.conf directly may be undone by a network service or break an existing symlink. Find out which component manages DNS before routing it through the core. If IP requests work after enabling TUN but domain names don't, check the DNS entry point, port 53 handling, and upstream reachability before changing the proxy protocol.

A local proxy doesn't automatically route traffic from containers, virtual machines, or other devices on your LAN. They have separate network namespaces, gateways, and firewall paths that require their own forwarding setup. When stopping the service, confirm that automatic routes are removed and desktop proxy settings and terminal variables are restored. Before changing the default route on a remote server, keep an alternate management connection so you don't route your own session through an untested proxy.

Configuration troubleshooting and layered diagnostics

Configuration loads, but why can't I connect?

Troubleshoot in this order: configuration retrieval, core status, local listener, app traffic routing, DNS resolution, rule matching, and remote connection. Test one thing at each layer: Did the configuration parse? Is the port listening? Does the target app produce a connection log? Which policy did the log use? Did the remote handshake complete? Find the first failing step and change the relevant setting. This is more reliable than changing subscriptions and network modes at the same time.

For parse errors, check the line number and surrounding context. YAML uses spaces for indentation; tabs won't work. Don't define dns, tun, or rules more than once in the same mapping. Quote strings containing special characters correctly. The original subscription, override snippets, and final configuration may be separate objects in the client. Confirm which one you're editing; a successful save doesn't mean the core reads that file.

Rule, global, and proxy group settings

Rule mode checks rules in order and usually stops at the first match. Global mode sends routed connections to the global policy, but doesn't bring apps that weren't routed into the core. Direct mode doesn't mean the client or virtual interface is disabled. Use the mode as a diagnostic variable: if global works but rules don't, check the matched rule and proxy group. If neither works, check the exit route and traffic routing first.

This example sends only domains matching the specified suffix to a manual selection group; everything else goes direct. The group contains only DIRECT, so it demonstrates rule structure and does not provide a remote proxy. To use it in a real setup, add existing nodes or a subscription provider to the group. The policy name referenced by a rule must match the group name exactly. For more examples of rule order, see Practical Rules for Routing Traffic by Destination.

proxy-groups:
  - name: SELECT
    type: select
    proxies:
      - DIRECT
rules:
  - DOMAIN-SUFFIX,example.com,SELECT
  - MATCH,DIRECT

DNS, fake-ip, and traffic-routing limits

DNS maps domain names to addresses; a proxy establishes connections. They work together, but operate at different layers. With fake-ip, the core returns a virtual address and restores the domain name for the subsequent connection. This doesn't mean the destination website uses that address. If an app has a stale cache, resolves names outside the core, or uses its own encrypted DNS, the information available to rules may differ. Check the connection metadata to understand what's happening.

This is a partial mihomo DNS example that listens only on the local machine. It doesn't automatically change system DNS settings, and this snippet alone won't prevent all external DNS lookups. TUN DNS hijacking primarily handles matching traditional DNS traffic. Encrypted DNS built into an app needs to be investigated alongside routing and app settings. Make sure the upstream server is reachable on your current network, or all domain lookups may fail.

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

After changing DNS mode, stale caches may make the problem appear to persist. Clear the DNS cache using a method supported by your client, reconnect the test app, and compare results. Add only the exceptions needed for affected domains; don't disable all rules to fix one app. For test procedures and their limitations, see How to Test for and Fix DNS Leaks. For virtual interface settings, see TUN Mode Setup.

Save diagnostic details and restore a working setup

Keep the timestamp, target app, network type, mode, matched rule, and a brief error summary in your logs. Remove subscription URLs, server credentials, and personal browsing records. Temporarily increasing the log level can provide more detail; restore your usual level when testing is done to limit retained data. Node latency tests cover only specific probes. They don't replace visiting an actual site or prove that UDP, long-lived connections, or every destination works.

If an issue began after an update, restore the last working configuration first, then compare changes one at a time, including policy names, rule sets, DNS upstreams, and client overrides. A failed rule-set download is different from a failed proxy connection; GeoIP and GeoSite data also have their own update mechanisms. See Updating Geodata and Using It in Rules. Reinstalling repeatedly is no substitute for identifying which layer failed.

To start over, first disable the client's traffic routing, restore the original system proxy and DNS settings, and confirm that regular network access works. Then import a saved configuration. Return to the setup guide to review the initial connection steps, or see Rule, Global, and Direct Modes Compared for an explanation of the modes. Examples in this guide explain settings and troubleshooting limits; they aren't ready-to-use connection configurations.