Clash Setup for All Platforms

General Setup and Configuration Basics

Understand the Client, Core, and Subscription

Clash GUI clients import configurations, manage proxy groups, set the system proxy, and display connections. Cores such as mihomo parse configuration files, listen on local ports, and apply rules. A subscription is the source of the configuration and may include proxies, proxy groups, rules, and DNS settings. Installing a client does not provide a working remote proxy by itself. Before you begin, make sure you have a subscription or configuration file you are authorized to use, and check the provider's format, usage terms, and update instructions.

This guide focuses on Clash Plus on Windows, macOS, Android, and iOS; Linux desktop users can choose Clash Verge Rev or FlClash. Clients differ in their support for subscription formats, extended fields, and configuration overrides, so a filename alone cannot tell you whether a file is compatible. Before downloading, review the platform download options and system requirements, then check your device architecture. Don't assume a desktop client's buttons match the mobile UI, or that fields supported by an older core are supported across the entire ecosystem.

What to Prepare and Back Up

Keep the full subscription URL, including query parameters, but never share it in public chats, screenshots, or issue reports. These links often grant access; if one is exposed, ask the provider to generate a replacement. Before installing a new client, note how to quit your existing proxy app, the current system proxy settings, and any custom DNS configuration. You can keep the old app installed temporarily, but run only one traffic-routing tool at a time while testing. If your device is managed by an organization, check whether its policies allow proxy changes, network extensions, or virtual interfaces.

For your first import, keep the original configuration intact and change only what's needed to run it. Changes made in the client may be stored in an app database, an override file, or the in-memory runtime configuration; they don't necessarily modify the original subscription. Back up the subscription source, your custom overrides, and any essential app settings. Copying a cached YAML file alone may miss the selected proxy group or service state. Before moving to another device, export a local backup and store it somewhere secure, since it may contain sensitive information.

Establish a Repeatable Test Baseline

After starting the core, check the logs for configuration parse errors, port conflicts, or insufficient permissions before switching proxies. The ports in the table below are common examples, not requirements; use the values your client actually listens on. The control interface manages the core—it is not a browser proxy endpoint. Pointing a browser at it won't forward traffic, even if the port accepts a connection. Keep the listening address on the local loopback interface to reduce the risk of exposing the service to your LAN.

Test in four stages: start the core, send an explicit proxy request, enable the system proxy, then try TUN. On desktop, first route a single command through the proxy port to verify the configuration, then enable the system proxy. Add TUN only if apps ignore the system proxy or you need to route other traffic. This makes it easier to identify which layer introduced a problem. A successful speed test only confirms the result for its test target; it doesn't prove that every site, protocol, or app works. Always check the connection logs too.

Use one target address and one app for testing. Change one setting at a time and record the logs before and after. Browsers may reuse existing connections, so make a new request after changing modes and close old connections if needed. Sites that require an account may also be affected by region, time, or service policies; don't assume every access restriction is caused by the proxy. The goal of an initial setup is a stable, understandable configuration you can restore—not enabling every advanced option at once.

Windows Setup

Install the Client and Check the Core

Visit the Windows downloads section and start with Clash Plus. If you need a different interface or workflow, compare Clash Verge Rev, FlClash, and Clash Nyanpasu. Clash for Windows is archived and no longer maintained, so it isn't recommended for new setups. Check your system type in Settings to confirm the device architecture, then verify that the installer supports it. If Windows displays a security warning, verify the download source and release details first; don't permanently disable system security just to continue the installation.

After installing, launch the app as a standard user. Check that it opens, can write to its configuration directory, and can run the core. If the UI opens but the core keeps exiting, look for the first error in the logs instead of repeatedly clicking Connect. Startup can fail if an old configuration references a missing file, another proxy is using the port, or the app is in a restricted directory. Grant elevated permissions only when the client asks for them to install a service or enable TUN; there's no need to run the entire app as an administrator every day.

Import a Subscription and Select the Active Configuration

On the configuration or subscription page, add a remote profile, paste the complete URL, give it a recognizable name, then download or update it. Once the profile appears, make sure it is selected as the active configuration. Some clients can store multiple subscriptions, but only the selected profile and its overrides are usually used at runtime. If proxies appear in the list but the main screen still shows an old group, check the active profile name and whether the core reloaded successfully. Don't import the same URL repeatedly and create duplicate entries.

When an import fails, first distinguish a network request error from a content parsing error. A connection timeout means no valid response was received; a YAML line-number error means content arrived but its format or fields may be invalid. If the URL returns a login page, access notice, or JSON error, a successful download doesn't make it a usable configuration. Compare proxy group names and logs before and after an update instead of relying on the last-updated timestamp. If the provider changed the format, use the corresponding import option rather than deleting fields at random.

System Proxy, App Behavior, and TUN

Choose Rule mode, select an available proxy in the main group, then enable the system proxy. Browsers usually use the Windows user proxy settings, but some command-line tools, background services, and apps with their own network settings do not. Run this command in PowerShell to test the proxy explicitly. It uses curl.exe to avoid differences caused by command aliases; if your port isn't 7890, update it here too. Check the client's connection log to confirm the request's actual route.

curl.exe --proxy http://127.0.0.1:7890 --head https://example.com
Get-NetTCPConnection -LocalPort 7890 -State Listen

If the first command works but the browser doesn't, check the system proxy address and port, as well as browser extensions. If the browser works but a command-line tool doesn't, check its proxy options or environment variables. Windows user proxy settings and the WinHTTP settings used by some services are separate mechanisms; don't change the global service proxy as a first step. On a work PC, organizational policies may override settings, causing the proxy toggle to reset or the address to be rejected. Check permissions and management policies first.

TUN routes traffic from more apps and typically relies on a service component, a virtual interface, and the necessary permissions. First confirm that the system proxy works, then follow the client's service installation and authorization steps. If all connections stop after enabling TUN, check that the virtual adapter was created, the default route is intact, and no other VPN is running. Don't keep installing network drivers from different sources. Turn off TUN to return to the system proxy baseline, then check DNS, routes, and excluded networks one at a time.

UWP, Cleanup, and Updates

Some Microsoft Store apps are affected by loopback restrictions and can't connect directly to a proxy on the local machine. Use the client's loopback utility if available, and exempt only the apps that need it. For details and commands, see the Windows UWP loopback exemption notes. A loopback exemption only addresses local access restrictions; it won't fix an expired subscription, an unreachable proxy, or incorrect rules. If the app is already routed through TUN, check whether its connections reach the core before troubleshooting—don't conflate the two routing methods.

Before quitting or uninstalling, turn off the system proxy and TUN, then confirm that Windows settings have been restored. If the client crashes and your browser says the proxy server refused the connection, check whether Windows is still pointing to a local port whose client has shut down. Keep your overrides and subscription source before upgrading, then check startup and service status afterward; an open UI doesn't mean the background service is healthy. After issues resume from sleep, reconnect and reload the configuration before considering a reinstall.

macOS Setup

Choose the Right Build and Complete First-Run Authorization

Check your chip type in About This Mac, then choose the matching installer from the macOS downloads section. Start with Clash Plus, or choose Clash Verge Rev or FlClash to suit your workflow. ClashX Meta is an archived, unmaintained option; assess compatibility carefully before relying on its older workflow. Don't choose an Apple Silicon or Intel installer based on file size. Even if translation lets some apps run, use a build that matches your Mac's architecture whenever possible.

If installing from a disk image, move the app to Applications before opening it rather than running it from a temporary mounted volume. If macOS blocks the first launch, check the source and the specific message in Security settings; don't remove security attributes from your entire Downloads folder. When the client asks to change network settings, install a helper, or add a network extension, verify that the request comes from the app you just opened. If the helper installs but won't start, check the app logs and system authorization status—a successful password prompt alone doesn't confirm that it is working.

Import a Subscription and Preserve Custom Settings

Add a remote subscription in configuration management and wait for it to download and parse. Select it before opening the proxy selection page. A running indicator in the menu bar only means the client or core is active; it doesn't confirm that the new profile is selected. After the first import, check that proxy groups and rules are present. If the profile references external rule sets or proxy providers, wait for those resources to load too. A failed resource request may not stop the app, but it can affect the associated rules or proxy groups.

Keep local changes in the client's supported override mechanism rather than editing a subscription cache that will be replaced on the next update. Check whether overrides apply before subscription parsing or after the runtime configuration is generated; clients may merge lists differently. If multiple DNS sections or proxy groups share a name, use the runtime configuration to determine the final result. After an update, check the logs and confirm that required fields remain. A saved file doesn't necessarily mean the core is using its contents.

Test the System Proxy and Terminal Separately

Once the system proxy is enabled, browsers usually connect through the proxy settings for the active network service. A Mac may have Wi-Fi, Ethernet, and other network services at the same time; after switching networks, make sure the client updated the right service. Terminal tools typically need explicit options or environment variables and may not read all settings from the GUI. A one-off command is easier to undo than an immediate change to your shell startup file. The commands below show the system proxy status and check which process is using the port.

scutil --proxy
lsof -nP -iTCP:7890 -sTCP:LISTEN
curl --proxy http://127.0.0.1:7890 --head https://example.com

To use a proxy in the current terminal session, temporarily set http_proxy and https_proxy. The latter can still point to an HTTP proxy endpoint; HTTPS requests use CONNECT to establish a tunnel. Tools differ in their support for uppercase variables and SOCKS, so check each tool's documentation. Add the variables to your shell configuration only after confirming you need them, and note where to remove them. Otherwise, a port change or quitting the client can leave the terminal using stale values, creating a split where the browser works but every command fails.

TUN, LAN Access, and Waking from Sleep

Use TUN or the client's enhanced routing feature only if you need to capture traffic from apps that ignore the system proxy. These features may require installing a helper service or approving a system network component. Authorization steps vary by macOS version and client, so follow the prompts you see rather than copying instructions for another app. After enabling the feature, check DNS and connection logs, then test LAN devices, remote desktop, and development services to make sure local addresses aren't being sent to a remote proxy by mistake.

If printers, router admin pages, or local development sites stop working, check LAN bypass and route exclusions rather than switching straight to Global mode. Corporate networks often use internal DNS for private hostnames; a public resolver can't replace it. After moving between office, hotspot, and home networks, retest internal hostnames and direct-connection rules. In these environments, logs and DNS results from before and after a network change are more useful than repeatedly switching proxies.

After waking from sleep, existing TCP sessions may no longer be valid. Make a new request or close old connections before deciding whether to restart the core. If the menu bar looks normal but all new connections fail, check that the network is back, the system proxy points to the current port, and the helper service is running. Before uninstalling, turn off the system proxy and traffic-routing features, then use the client's procedure to remove its helper service. Deleting the app icon alone doesn't restore every network setting.

Android Setup

App Installation, System Permissions, and the VPN Interface

Visit the Android downloads section and start with Clash Plus; you can also compare Clash Meta for Android, FlClash, and Surfboard. Clients differ in supported subscription formats and features—in particular, Surfboard syntax is not interchangeable with mihomo YAML. Most devices use ARM, but check your OS and installer requirements. If installation fails, verify the architecture, Android version, and signing relationship with any existing app. Don't repeatedly overwrite the app with APKs from unverified sources.

When installing from a browser or file manager, Android may ask you to allow installs from that source. Grant permission only to a source you trust, and revoke it afterward if that fits your device management practices. The VPN permission prompt on first connection is part of Android's traffic-routing system; after authorization, Android usually displays a VPN indicator. This doesn't mean Android provides the subscription, or that every app is being routed as intended. The actual routing scope depends on the client's app filters, routes, and active configuration.

Import a Subscription and Connect for the First Time

On the configuration page, add a URL profile or import a file. Wait for the download to finish, select the profile, then check that proxy groups are available. When importing through the share menu, make sure it passes the full subscription URL, not a web page title or truncated text. Other apps may be able to read your clipboard, so don't leave a sensitive URL there. If the link only works in a logged-in browser, ask the provider for a subscription URL supported by the client; a browser login session can't replace the app's request credentials.

For your first connection, use Rule mode, choose a specific proxy, and approve Android's VPN request. Open a test site in your browser and check the client's connection log. If no new connection appears, check that the VPN service is running, the browser isn't excluded, and the active profile is correct. If the request reaches the core but fails, use the logs to check DNS, the remote handshake, or rule selection. The VPN key icon in the status bar alone doesn't prove that the remote proxy works.

Per-App Routing and Background Operation

Android clients commonly offer two app selection modes: include only selected apps, or bypass selected apps. The lists mean opposite things. Test one app in the list and one outside it to confirm which mode the client uses. Per-app routing and domain rules operate at different layers: an app excluded from the VPN never reaches the core's rules. Changing MATCH or switching proxy groups won't help in that case; fix the app routing scope first.

If the connection drops when the screen locks, check battery optimization, background activity limits, auto-start, and system cleanup policies. Menu names vary by manufacturer; look under the app's system settings for battery and background permissions. Adjust settings only for clients that need to run continuously; there's no need to disable system-wide battery saving. Test a full lock, wait, wake, and reconnect cycle. Check whether the service restarts, the configuration reloads, and background tasks face separate network restrictions.

DNS, Other VPNs, and Network Changes

Most Android devices allow only one standard VPN service per user at a time. Ad blockers, firewalls, and other networking tools may use the same interface, so starting one app can disconnect another. Disable other VPN-style tools while testing instead of assuming the client stopped at random. Android's Private DNS setting can also change the resolution path. Note its current value, then temporarily switch to Automatic for comparison. Once you identify the cause, choose a lasting setting rather than disabling every security feature permanently.

When switching from Wi-Fi to mobile data, DNS resolution, IPv6 reachability, and existing connections can all change. If only old connections fail, disconnect and reconnect. If all new connections fail, check whether the subscription restricts networks, Android allows the app to use mobile data, and the network requires a captive portal sign-in. Complete the local network login first. Changing proxy group order won't fix this; confirm that the underlying network can reach its sign-in page.

Always-on VPN and Block connections without VPN in Android settings change what happens to network access when the client stops. If blocking is enabled, losing connectivity when the service stops may be expected protection rather than a separate failure. Note where to restore these settings before asking someone to troubleshoot remotely, so you can remove restrictions if needed. Background updates may also be delayed by a locked screen, battery saving, or mobile data limits. For details, see subscription update failures and auto-refresh settings.

iOS Setup

Install Clash Plus from the App Store

Clash Plus is the recommended option for iPhone and iPad. Visit the iOS downloads section to open the store, or go directly to the Clash Plus App Store page. The project website is clashplus.io. Before installing, review the system requirements and feature details listed in the store. Options with the same name on desktop may work differently—or may not exist—on iOS. Follow the current app UI and system authorization prompts.

Connecting for the first time usually requires permission to add a VPN configuration, confirmed with your device passcode or system authentication. This configuration lets iOS route applicable traffic through the app's network extension; it is not your Wi-Fi password or subscription account. Check which app is requesting permission before approving. Devices managed through a profile or by an organization may block personal VPN configurations. That's a device policy issue; pasting the subscription URL again won't help. Check the management status and permitted network configurations in Settings.

Import a Subscription and Confirm It's Active

Import using the subscription URL or file option in the app, then select the profile you want to run after the download finishes. If you open a link in Safari, distinguish a subscription resource from the provider's account page. A page displaying content doesn't mean the copied address is a subscription URL. Preserve the full link, including query parameters; text replacement or a sharing tool that truncates the URL can cause requests to fail. Don't upload screenshots that expose private subscription links to public support forums.

After importing, check the proxy groups and selected options before connecting to the VPN. If multiple profiles are stored, make sure the selected one isn't an old local test file. An update may replace the proxy list, but the app's saved selection may no longer match an old group name. After updating, confirm that the main proxy group points to the option you expect. If the connection log shows DIRECT, don't assume the proxy is broken: check whether the rule calls for a direct connection and whether the app is in Rule or Direct mode.

How Traffic Routing Works on iOS

iOS clients usually route traffic through a system network extension. Don't follow the Windows workflow of entering a local port and enabling the system proxy. The HTTP proxy setting in Wi-Fi details is separate; don't fill it with a desktop example address to make the app connect. On an iPhone, 127.0.0.1 refers to the phone itself, not a computer on the same network. Copying a desktop client's loopback address to your phone won't create a proxy connection between devices. LAN sharing also requires the server to allow connections and have appropriate access controls.

Desktop documentation describes TUN, service mode, and system proxy to explain different routing methods; it doesn't mean iOS needs a button with the same name. The client and system interfaces together determine which traffic is routed, how DNS is handled, and which rules are available. If only one app fails, first check whether it opened a new connection or uses its own proxy or network policy, then review the rules. After switching proxies, an existing long-lived connection may still use its previous route; start a new request to compare.

Cellular Data, On-Demand Connections, and Recovery

For your first test, turn off other VPN configurations and connect manually on a stable network. Confirm the basic connection before trying automation such as on-demand rules. Those rules can react to network changes and reconnect after you manually disconnect; note the relevant settings and temporarily disable automatic triggers while troubleshooting. If another system or third-party privacy network feature is running, test each one separately so multiple layers don't obscure the request path. Change one feature at a time and keep results you can compare.

If the connection fails when switching from Wi-Fi to cellular, check that iOS allows Clash Plus to use cellular data, that the network is working, and that the remote address resolves on that network. Network extensions and the main app behave differently while the screen is locked, so the app not being visible doesn't prove the service has stopped. If connections keep dropping, use the app's diagnostics and the system VPN status to determine whether the disconnect is local or remote. Avoid adding more resources to a large rule set while troubleshooting; first verify a smaller known-good configuration.

If the entire device loses internet access after connecting, disconnect in the app, then check the VPN status in Settings. Temporarily disable on-demand connection if it reconnects as soon as you disconnect. After restoring basic network access, review the latest subscription update, rule overrides, and DNS changes. Before deleting the app, export any configuration you need and confirm that the subscription source is accessible from another device. For more troubleshooting steps, visit the Help Center. When sharing diagnostics, include only the error type, necessary fields, and logs with sensitive information redacted.

Linux Desktop and Server

Choose a Desktop Client or Headless Setup

Desktop users can choose Clash Verge Rev or FlClash from the Linux downloads section. Check the package format, architecture, and dependencies for your distribution. GUI clients manage subscriptions and system tray interactions, but desktop environments differ in their system proxy support; settings applied to the desktop aren't necessarily read by every app. On a headless server, run mihomo directly and manage it with a configuration file and systemd. Choose one primary management method to avoid a GUI client and a separate service competing for the same port.

After installing a GUI client, import a subscription, select the active profile, check the logs, then configure the desktop proxy. If terminal commands don't use the proxy, test the route with a one-off command before changing global environment files. For a server deployment, prepare the configuration directory and permissions first, and make sure the service account can read the configuration and any referenced rule resources. Don't expose your entire home directory to the service or recursively grant everyone write access to work around a permission error; that increases the risk of exposing configurations and subscriptions.

Starting from the Command Line and Testing Configuration

The examples below assume the mihomo executable is installed at /usr/local/bin/mihomo and the configuration is at /etc/mihomo/config.yaml. These are example paths; your deployment may differ, but the commands and service file must match. Test in the foreground before setting up a persistent service. The minimal configuration below only tests local listening and direct forwarding; it contains no remote proxy. It is not a substitute for your subscription and can't verify that a proxy endpoint works.

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

/usr/local/bin/mihomo -t -d /etc/mihomo -f /etc/mihomo/config.yaml
/usr/local/bin/mihomo -d /etc/mihomo -f /etc/mihomo/config.yaml
curl --proxy http://127.0.0.1:7890 --head https://example.com

Run the configuration test command first to catch parse errors, then start mihomo in the foreground and watch its listening logs. Rule resources, geolocation databases, and proxy providers may need additional files or network requests. A valid configuration doesn't mean every external dependency is available. If you're using a provider configuration, save it intact, test it again, and check referenced paths and the working directory. Stop the foreground process when testing is complete, then hand it over to systemd. This avoids a port conflict at service startup that could be mistaken for a broken configuration.

Manage a Standard Proxy Service with systemd

Create a dedicated system user named mihomo and give it read access and only the necessary write permissions for its working directory, then create the service file below. This example runs a local proxy as an unprivileged user and doesn't enable TUN; don't use it unchanged for a service that needs virtual interface permissions. User creation commands vary by distribution, so use the account management tools provided by your OS. If configuration and cache files share a directory, decide which files need write access to avoid permission problems when subscriptions or rules refresh later.

# /etc/systemd/system/mihomo.service
[Unit]
Description=mihomo local proxy
Wants=network-online.target
After=network-online.target

[Service]
Type=simple
User=mihomo
Group=mihomo
WorkingDirectory=/etc/mihomo
ExecStart=/usr/local/bin/mihomo -d /etc/mihomo -f /etc/mihomo/config.yaml
Restart=on-failure
RestartSec=5
NoNewPrivileges=true
UMask=0077

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now mihomo
systemctl status mihomo --no-pager
journalctl -u mihomo -b -n 80 --no-pager

After changing the configuration, test it with the same account and paths used by the service. Then restart the service and check its startup logs. The effect of network-online.target depends on whether the distribution has a corresponding network-wait service configured; it can't guarantee that every remote resource is reachable. This unit doesn't update subscriptions either. Use a clear download, test, and replace process, and keep the previous file if the new configuration fails validation so a scheduled task can't replace a working configuration with an error page.

TUN Permissions, Containers, and Terminal Environments

Linux TUN requires an available virtual interface device, network management permissions, and suitable routing. Setting enable: true in YAML alone doesn't grant the required permissions. Containers add restrictions involving device mappings, network namespaces, and capabilities. Understand the network path on the host before designing a container setup. A standard proxy service and a TUN-enabled service need different permissions. Assess the required capabilities and their scope; don't run the entire deployment with elevated privileges just to hide a permissions issue.

Set proxy variables in a terminal session as needed, but background services don't automatically inherit the full environment of an interactive shell. Conversely, don't point mihomo's own subscription or resource requests at a proxy endpoint that hasn't started yet. Before changing the default route on a remote server, keep a second management session open and prepare a rollback path so you don't lose SSH access. For a detailed comparison of desktop and headless setups, see the Linux mihomo deployment guide.

Common Configuration Issues and Recovery

Configuration Parsing and Rule Names

YAML uses spaces for indentation; don't mix in tabs. Keep indentation consistent at each level and place list items under the correct parent field. When an error cites a line number, inspect both that line and the one before it for colons, quotes, and indentation. Rich-text editors can introduce full-width punctuation or invisible characters, so use a plain-text editor. Don't hide an error by deleting the entire rules section: starting the core successfully and routing traffic as intended are separate goals, and removing rules can change the path for every connection.

Rules are matched in order, so specific domain rules usually go before general fallback rules. The snippet below is only an example: PROXY must match a proxy or group that already exists in the active configuration. If the subscription uses another group name, update the reference instead of creating an empty group. Names usually need to match exactly; differences in capitalization, spaces, or punctuation can make the target impossible to find. Check rule matches and the final group selection separately—a rule hitting a proxy group doesn't mean that group isn't currently set to DIRECT.

rules:
  - DOMAIN-SUFFIX,github.com,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

System Proxy Works, but TUN Doesn't

The system proxy relies on apps honoring proxy settings. TUN uses a virtual interface and routes to capture a wider range of connections, with different permission requirements, DNS paths, and failure modes. If the system proxy works but TUN doesn't, check permissions and routes before changing subscriptions. The snippet below shows mihomo TUN fields; it isn't a standalone configuration. A client may generate or override these fields through its UI. TUN also needs a complete DNS setup; copying this snippet alone won't guarantee consistent behavior across platforms.

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

DNS hijacking snippets apply to the relevant traditional DNS requests; they don't mean all encrypted DNS traffic will enter the core the same way. Browser secure DNS, Android Private DNS, IPv6 routing, and app-specific resolvers can all affect what you observe. First determine whether DNS resolution or the connection is failing, then decide whether to adjust the resolver, fake-ip, or route exclusions. For more context, see TUN Mode vs. System Proxy. Avoid changing multiple network layers at once to fix an issue in a single app.

Subscription Updates, Overrides, and External Resources

When a subscription update fails, keep the last working configuration and record the status code, timeout type, or parse error line. An expired URL, missing access, a response replaced by a web page, and a failed network request each need different fixes. If the subscription can only update through a proxy that itself depends on the subscription, prepare a reliable update path in advance to avoid a startup loop. Set the update interval according to the provider's limits and your needs; repeated high-frequency requests won't fix a temporary error.

Rule providers and proxy providers may each have their own caches and update schedules. A successful main subscription update doesn't prove that every resource updated. After changing overrides, check the final runtime configuration, especially ports, DNS, group names, rule order, and listening addresses. If the client can preview or export configurations, remember that they may include subscription URLs and credentials; redact sensitive data before sharing. For a recurring parse error, a minimal reproducible snippet is usually more useful than an entire private configuration.

Choose the Next Step Based on What You See

A useful troubleshooting report should include the platform, client name, current mode, routing method, stage where the error occurs, and one relevant log excerpt with sensitive details redacted. Don't treat a proxy speed test, browser request, and background update as the same test; they may use different targets and request paths. If only one site fails, consider the site's own status, exit-region policies, and account restrictions. First verify that the request reaches the intended policy, then check whether the remote endpoint is reachable. That's more effective than switching modes at random.

After resolving the issue, carry only the smallest verified change into your long-term configuration and update your backup. When upgrading the client, switching cores, or moving to a new device, run the basic checks again instead of assuming the old setup still applies. For troubleshooting by symptom, visit the Help Center; for field definitions, see the Glossary. This page focuses on cross-platform differences. For a first setup, follow the quick start guide step by step, rather than adding advanced features before the basic connection works.