Clash Meta Setup Guide for All Platforms

Getting Started: Subscriptions, Core, and Configuration Basics

Know the Difference Between the Client, Core, and Subscription

The client manages configurations, provides the interface, requests permissions, and integrates with the operating system. The mihomo core listens on ports, evaluates rules, selects an outbound, and forwards connections. A subscription provides nodes or a complete configuration; installing a client alone does not provide a working proxy. Before you begin, make sure you have a valid subscription, can reach its source, and know whether it provides a full configuration or only a list of nodes.

A full configuration usually includes proxy nodes, proxy groups, rules, and DNS settings. A node list needs a client-side template to supply the rest. Both may be returned as YAML, so the file extension alone is not enough to tell them apart. If an import shows nodes but no selectable proxy groups, check the import method and template before changing server addresses. A subscription management page is not necessarily the subscription endpoint; copy the client subscription URL explicitly provided by the service.

Subscription links often grant access to your account, so treat them as sensitive. Never paste them into public conversion sites, screenshots, or discussion forums. Before sharing a configuration, remove node passwords, subscription URLs, and controller secrets. If a link is exposed, regenerate it at the subscription source. Troubleshooting screenshots should show only the error type, configuration section, and redacted domains; review full logs before sending them.

Set Up a Test Environment You Can Roll Back

Before installing, note your operating system version, processor architecture, current network, and any existing proxy or VPN software. For the first test, turn off other traffic-routing tools and keep the network path simple. Managed devices may be subject to organizational policies; do not bypass them by granting elevated permissions. Install services, virtual network adapters, or routing changes that require administrator access only after understanding their purpose.

Start in rule mode with system proxy enabled and verify access in a browser. Add TUN only if needed. This makes it easier to tell whether a problem comes from the basic outbound connection or traffic routing. Keep a working copy of your configuration and note the original system proxy settings. Change one configuration section at a time. Overwriting all DNS, rules, and routing settings at once removes a useful baseline for comparing logs.

First check that the configuration parses, then verify connectivity

The minimal direct-only configuration below checks whether mihomo can start and listen on a local port. It includes no proxy nodes and is not a replacement for a subscription. The mixed port accepts both HTTP and SOCKS connections; disabling LAN access limits the listener to the local machine. If another client is already using the same port, stop one instance or choose a different available port for testing.

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

Running the core's configuration check confirms that the syntax and some references pass validation; it does not prove that subscription servers are reachable. A graphical client may generate the runtime configuration, so check the file actually loaded by the core rather than assuming it is the subscription cache. If logs report indentation or unknown-field errors, inspect the indicated location and the lines before it; the cause may be on the preceding line.

mihomo -t -f config.yaml

YAML uses spaces for indentation; do not mix in tabs. Policy names in rules must match the names of defined proxy groups or nodes, including capitalization and spaces. Remote rule sets, proxy providers, and geodata files must also be downloadable. A full configuration can load successfully and still behave unexpectedly if these dependencies are unavailable. When troubleshooting, distinguish configuration parsing, resource loading, and request forwarding as separate stages.

Windows: Installation, System Proxy, and Service Permissions

Choose an Installer and Complete First Launch

Choose Clash Plus from the Windows client downloads. Other options include Clash Verge Rev, FlClash, and Clash Nyanpasu. Clash for Windows is no longer maintained; archived builds are mainly useful for understanding legacy setups, not as the default for a new installation. Check your processor and system type in System Information, then compare them with the architectures and requirements on the download page. An installer for another platform is not a compatible alternative.

After installation, launch the client normally; there is no need to run the entire interface as an administrator from the outset. If the client needs a service component, install it through the service manager and approve the system prompt. If your account cannot install services, you can first verify connectivity using the system proxy. A failed service installation and an unavailable subscription are separate problems; repeatedly importing the subscription will not fix the former.

If a Windows security prompt blocks the app, check the download source, file properties, and organizational security policies before deciding what to do. Do not disable system security features indefinitely just to launch a client. The installation, configuration, and core runtime directories are also separate locations. When migrating an old setup, use the client's import feature rather than copying an old core or cache directory over the new installation.

Import a Subscription and Select a Proxy

Open configuration management, add a remote subscription, paste the full URL, and save it. After the download completes, select it as the active configuration and check that proxy groups appear on the proxy page. If the subscription uses redirects or requires particular access conditions, a failure may be a network error rather than a YAML error. Check the response before treating a returned login page as a configuration file.

Choose an available node in the main proxy group and run the client's connectivity or latency test. A successful test only confirms that the test request completed; it does not mean every website, UDP connection, or terminal app is routed. An automatic group may switch outbounds later. While troubleshooting, pin a node and test the same destination, then restore automatic selection to avoid changing several variables at once.

Switch to rule mode, enable the system proxy, and check that the address and port in Windows network proxy settings match the client. The mixed port, controller port, and subscription URL are not interchangeable. System proxy settings usually apply to the current user; other user sessions, system services, and some standalone apps may ignore them. A working browser does not prove that all device traffic is going through the core.

Test the Command Line and TUN Separately

Terminal tools may read environment variables or require an explicit proxy. The command below uses the local proxy for this request only; make sure the port matches the active configuration. Use it to verify the proxy endpoint before setting terminal environment variables. Before saving variables persistently, check how your tools handle variable capitalization, proxy protocols, and exclusions. Otherwise, the terminal may keep trying to use an old port after the client closes.

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

Enable the client's TUN mode only when you need to cover programs that ignore the system proxy. First confirm the service is running, authorize creation of the virtual network interface, and check core logs for interface or routing errors. With automatic routing, pay particular attention to corporate networks, LAN printers, and other VPNs. If routes conflict, adjust exclusions or the traffic scope instead of enabling more network acceleration tools.

If connections still fail with TUN enabled, turn it off and retest with the system proxy. If the browser works again, focus on the virtual interface, default route, DNS, and other VPNs. If both methods fail, go back to the node and configuration. Use the same comparison after waking from sleep or switching networks: check interface status first, then consider restarting the core or service.

Quitting, Updating, and Stale System Proxy Settings

Clicking the Windows close button may only minimize the client to the system tray; it does not necessarily stop the core. Before uninstalling or switching clients, turn off the system proxy and TUN, then exit from the tray. If the app exits unexpectedly but the browser still connects to a local proxy, check for leftover system proxy settings. Restore the original settings before launching the client again; no internet after closing the app does not automatically mean the subscription has failed.

Before updating, export custom rules and override settings. Afterward, check the active configuration, proxy group selection, and service status. An old service may still occupy a port or point to a core that has since moved. If there is a port conflict, identify the process in Task Manager or the client logs and keep only the intended instance. For browser and terminal troubleshooting, see Troubleshooting a System Proxy That Isn't Working.

macOS: Architecture, Network Services, and Background Components

Install the Client for Your Processor

Open the macOS downloads and choose Clash Plus, or select Clash Verge Rev or FlClash if you prefer. ClashX Meta is no longer maintained, so treat archived software differently from actively maintained clients. Check About This Mac to see whether you have Apple silicon or Intel, then choose the matching installer. Running through a compatibility layer does not guarantee that background components or virtual network dependencies work with your current system.

If the installer is a disk image, mount it, move the app to Applications, and launch it from there rather than running it from the image. Verify the download source before opening it. If macOS displays a security prompt, follow the system's app-opening process instead of running commands that disable security checks wholesale. If an older client is installed, quit it normally first to prevent multiple menu bar apps from changing proxy settings at the same time.

When the client requests a helper tool, background service, or network permission, check that the app and requested action are expected. Some features use a privileged helper to set routes; the regular proxy interface does not need to run with elevated privileges continuously. If permission is denied, check the client's service status and the relevant macOS settings rather than repeatedly clicking Connect.

Import a Subscription and Check Network Services

Add a subscription on the configuration page and set it as the active configuration after parsing completes. Then check the main proxy group and pin a node for a request test. When migrating a configuration from another client, pay close attention to relative paths, cached rule sets, and provider files. Files downloaded by the old client may not migrate with the configuration, so the new client may need to fetch its dependencies again.

After enabling the system proxy, check which network service is currently in use. macOS can save separate settings for Wi-Fi, Ethernet, and other interfaces, and the service changed by the client may not be the one currently carrying traffic. Recheck after connecting a dock, wired adapter, or different network location instead of relying only on the menu bar icon. The system proxy address should point to a local listening port, not the controller address.

Start with the read-only command below to view the current system proxy settings, then compare with a request that explicitly uses the proxy. Proxy information in the output does not guarantee that an app follows it. Browser extensions, standalone app settings, and terminal environment variables may create separate paths. Record system and app settings separately so that changing one is not mistaken for changing them all.

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

TUN and Other Network Extensions

Enable TUN only when you need to route apps that ignore the system proxy, and confirm the client's background component is installed correctly. Installation and authorization vary by client, so follow its current prompts. After starting TUN, check interface and route logs to confirm more than just a change to the UI toggle. If a corporate VPN, network filter, or another proxy client is running, first find out which routes it manages.

If LAN access fails, check whether the destination is on the local subnet and which rule the request actually matches. The system proxy bypass list affects only apps that read that setting; it does not replace TUN route exclusions or core rules. Keep the DNS and direct routes needed for corporate domains and intranet addresses. Do not assume every failure to reach a private address is caused by a proxy node.

After closing the lid, waking from sleep, or switching from Wi-Fi to Ethernet, existing connections may still use the previous network path. Retry the destination and check whether a new connection appears in the logs. Reconnect the client or restart the core if needed, but do not delete the entire configuration. If only old pages fail while new connections work, connection reuse or a network transition is more likely than a subscription problem.

Terminal Environment and Clean Uninstall

Proxy environment variables affect the relevant process and its child processes; they do not change the whole system. Do not overwrite existing shell configuration without understanding what its variables are used for. If you need persistent settings, keep instructions for clearing them and add suitable exceptions for intranet destinations. Apps launched from the graphical interface may not inherit terminal variables, so test terminal and browser access separately.

Before uninstalling, disable the system proxy, TUN, and launch-at-login option, then remove any helper service using the client's recommended method. Dragging the app to Trash may leave background components or old proxy settings behind. After switching clients, check Activity Monitor for an old core that is still running, then verify the active port, configuration, and actual outbound. For a closer look at the two routing methods, read TUN vs. System Proxy: A Layer-by-Layer Comparison.

Android: VPN Permission, App Routing, and Background Operation

Check Architecture and Configuration Compatibility

Choose Clash Plus from the Android downloads. Other options include Clash Meta for Android, FlClash, and Surfboard. Check your device architecture and the client's minimum Android version before installing the appropriate package. Grant permission to install apps only to the browser or file manager you need for this installation, then restore the previous setting if desired. Managed devices must also follow their app installation policies.

Being part of the same proxy ecosystem does not mean clients support identical configuration formats. Check the exact feature support in Clash Plus, Clash Meta for Android, and FlClash. Surfboard uses a different configuration system; importing an arbitrary full mihomo configuration does not mean every rule will work. If your subscription provider offers multiple formats, choose the one specifically suited to your client.

When migrating from an older app, export any custom settings you need before installing the new one. Android generally cannot install an app over another with a different package name, and uninstalling the old app may delete its private configuration and cache. Do not rely on the clipboard to preserve a subscription. Store import details somewhere secure and confirm the new client can load the configuration before removing the old setup.

Import a Subscription and Connect to the VPN

Open the configuration list, add a remote subscription, and wait for it to download. Then select it as the active configuration. Check that proxy groups appear and that nodes can be tested before tapping Start. On first launch, Android usually displays a VPN permission prompt. This lets the app create a local traffic-routing tunnel; it does not confirm that remote nodes are trustworthy or that every app request will use a proxy outbound.

Android generally allows only one active VPN service per user profile. Other VPNs, firewalls, and filtering tools that use a local VPN may conflict with the client, causing a connection to be replaced, disconnecting it immediately, or blocking network access for an app. For testing, disable conflicting apps and keep only one traffic-routing service active. Work and personal profiles may have different restrictions, so check each one separately.

VPN routing on mobile is not the same as a desktop system proxy. You usually do not need to enter a proxy manually on the Wi-Fi settings page; adding a Wi-Fi proxy that points to the local client can create a confusing network path. A VPN status indicator only confirms that the tunnel service is active. Check connection logs to see which rules and proxy groups requests match and which outbounds they use.

Check What the App Routing List Means

Before enabling per-app routing, check whether the list means proxy selected apps or bypass selected apps. The same checked items can have opposite effects in these modes. Start with one browser, close existing tabs, make a new connection, and inspect the logs. Some clients must rebuild the VPN after list changes take effect; the checkboxes alone do not prove that the system has updated its routing scope.

The app list determines which traffic enters the client; rules determine how that traffic is handled. These are separate layers. Excluded apps usually do not reach the core for rule evaluation, while included apps may still connect directly if a rule selects direct access. To check whether an app is using the proxy, inspect the app routing list, matched rule, and final outbound—not just the connection button on the main screen.

Troubleshoot Background Operation, Battery, and Network Changes

If the connection works with the screen on but drops when locked, check whether the system restricts background activity, battery use, or auto-start. Use your device manufacturer's settings to allow the client the background access it needs, keeping in mind that this may increase battery use. Background notifications can help show whether the service is still running; do not break system requirements just to hide them. After a reboot, confirm that the client actually reconnects rather than merely restoring its interface.

After switching from Wi-Fi to mobile data, existing connections may drop and apps may need to make new requests. Check mobile data permission, whether the current node is reachable on the new network, and whether the VPN is still active. If Always-on VPN or Block connections without VPN is enabled, Android may block network access when the client disconnects. This is expected protection behavior; configure it according to your needs.

If a subscription update fails, check the phone's time, subscription status, current network, and available storage. Then see whether only the update failed while existing nodes still connect. If just one app has a problem, check its routing assignment, custom DNS, UDP use, and cache instead of clearing all client data. Restart the app and make a new connection to confirm the change affects new requests rather than an existing session.

iOS: App Store Installation, Configuration Import, and VPN Checks

Install a Client and Check Subscription Compatibility

For iPhone and iPad, start with Clash Plus. See the iOS client page on this site, or open the Clash Plus App Store page directly. The client's official site is clashplus.io. Before installing, review the App Store listing for system compatibility, features, and permissions. Do not assume desktop menu paths apply to mobile.

On iOS, traffic routing uses system-provided network extension capabilities; it does not involve installing the desktop mihomo executable. Support for rules, subscription formats, and extension fields depends on the client. A configuration that loads on desktop may not have the same effect on a phone. Before migrating, confirm that the client supports the node protocols, rule types, and DNS features you need.

If the subscription provider offers a client-specific link, use the one explicitly intended for that client. If you only have a management page, QR code, or share button, check whether it points to configuration content or an account page. A QR code only transmits an address; it does not convert the configuration format. After importing, check the configuration list, proxy groups, and node details. Seeing a new configuration name alone does not confirm a successful import.

Manage Remote Subscriptions and Local Files Separately

Add remote subscriptions by entering a link on the configuration page. After saving, wait for the download and parsing to finish, then select it as the active configuration. Import local files through the client's file import or system share option. A file import is a snapshot of its contents and may not retain an update link. If you need ongoing node updates, make sure the client saved the remote source rather than relying on repeated imports of a same-named file.

If a file appears in the Files app but cannot be imported, check whether it actually contains configuration text, is still waiting to download from iCloud, and uses a format supported by the client. Email attachments and web downloads may be archives, error pages, or documents with extra formatting; changing the extension will not fix them. Get the correct content from the subscription source and check the import error.

After importing, choose a node in the proxy group and test it before starting the connection. An automatic group's test target may differ from the destination you need. If the test succeeds but an app fails, check that app's connection logs and rules instead of cycling through every node. Pinning a node gives you a stable comparison; restore your preferred everyday policy after verification.

Understand VPN Permission and Routing Scope

On first launch, iOS may ask to add a VPN configuration and authenticate the device. Confirm the request comes from the client you just installed before approving it. Authorization and a successful connection are separate steps. If another VPN configuration exists, check which one is active. Even when the connection switch is on, make a real request and confirm the client records the connection.

Do not apply desktop system proxy habits to iOS. Unless you are specifically testing a LAN proxy, there is no need to change the manual proxy setting for Wi-Fi. Rule mode can send different requests direct or through a proxy; the VPN icon does not mean every destination uses the same node. Apps with their own networking implementations may also affect which domains and protocols appear in logs.

Devices managed by an organization may have per-app VPN, managed network settings, or access restrictions. A personal client cannot override these policies. If a work app consistently uses a different path, check the device's management scope and contact the administrator. Do not delete organizational profiles to force uniform proxy behavior; this could affect work accounts and compliance requirements.

Recovering from Lock Screen and App-Specific Issues

When returning to the app after locking the screen, wait for network access to recover and make a new request. An old connection timing out does not mean the network extension has exited, and the app does not need to remain in the foreground. If you switch repeatedly between Wi-Fi and cellular, note the network type, active policy, and VPN status when the issue occurs, then test each condition separately. Changing one thing at a time helps prevent network coverage issues from being mistaken for subscription errors.

If only a browser or one app has a problem, check whether it is reusing an old connection, using its own resolver, or matching a direct-access rule. Try quitting and reopening the app, then inspect the new connection. Do not start by resetting all network settings; that affects other network information and may not fix a remote node, broken rule reference, or unsupported configuration format.

Before updating or deleting the client, save the subscription source and custom rules. After restoring a device backup, recheck the active configuration and VPN permission; caches, subscriptions, and system permissions may not all return to their previous state. For the complete download and import workflow, see How to Get the iPhone Client and Import a Configuration. Verify that the setup works using actual connection logs and access to the destination.

Linux: Desktop Clients and mihomo Core Deployment

Choose a Desktop or Server Setup

For desktop environments, choose Clash Verge Rev or FlClash from the Linux downloads and install the package format provided for your distribution. For servers, routers, or environments where you need precise process control, use the mihomo core. When choosing a binary, check the processor architecture, distribution environment, and required instruction set. Being able to extract the file does not mean it will run on your device.

Importing a subscription and selecting a configuration and policy in a desktop client works much like it does on other desktop platforms, but system proxy support depends on the desktop environment. Browsers, terminals, containers, and background services may use different settings; a desktop proxy toggle does not route the entire system. Start with an explicit proxy request, then decide whether to set app-specific environment variables, use the desktop proxy, or enable TUN.

To deploy the native core, extract the binary, make it executable, and place it in the intended location. The examples below assume the executable is installed at /usr/local/bin/mihomo and the configuration is in the current user's home directory. Start with a basic proxy as a regular user; do not use root privileges from the outset. The runtime user must be able to read the configuration and its local rule files. Directories used for cache files also need write access.

mkdir -p ~/.config/mihomo
/usr/local/bin/mihomo -t -d ~/.config/mihomo
/usr/local/bin/mihomo -d ~/.config/mihomo

Subscription Content Is Not a Shell Command

The native core does not provide a graphical subscription manager. Save a full configuration as config.yaml in the working directory. If you only have a list of nodes, you must add proxy groups, rules, and other required settings yourself, or manage it with a client. Download through a trusted method and check the file contents and syntax first. Never pass remote response content directly to the shell, and avoid leaving sensitive subscription URLs in command history.

For automatic updates, download to a temporary file, verify it, and only then replace the active file; keep the previous working configuration. After the core's configuration check passes, perform a controlled reload or restart. Writing a remote response directly over the active file could leave an error page in place if the download fails. For remote proxy providers, also check provider names, cache paths, update intervals, and references from proxy groups.

After starting the core, check the logs and make a request through the local mixed port. Adjust the listening address, firewall, and access controls only if other devices on the LAN need to use the proxy. Do not expose the listener or controller to every network by default. On remote servers, distinguish the loopback interface, private network address, and public address to avoid turning a convenient test setting into a permanent public endpoint.

Manage the Process with a User Service

On distributions that support systemd user services, save the following as ~/.config/systemd/user/mihomo.service, creating the parent directory first. This example assumes the installation path above and a regular proxy listener; it does not grant extra privileges for TUN. The service should only run the core. Design subscription updates and permissions separately rather than hiding all maintenance operations in the startup command.

[Unit]
Description=Mihomo user proxy

[Service]
Type=simple
ExecStart=/usr/local/bin/mihomo -d %h/.config/mihomo
Restart=on-failure
RestartSec=5

[Install]
WantedBy=default.target

systemctl --user daemon-reload
systemctl --user enable --now mihomo.service
systemctl --user status mihomo.service
journalctl --user -u mihomo.service -n 80 --no-pager

User services usually run for the duration of a user session. Whether they continue after logout depends on the system's user management settings. For an always-on server, choose a system service or user lingering setup that fits your deployment policy; enabling a service does not automatically mean it will run permanently at boot. Check the configuration before restarting, then review service status and recent logs. A startup command that returns without an error is not proof of a successful deployment.

TUN, DNS, and Container Boundaries

Linux TUN requires an available virtual network device and the necessary network permissions; a regular user service does not get these automatically. Before enabling it, understand how the client or service obtains permissions, adds routes, and restores the system state on exit. The snippet below shows a common configuration section to merge into an existing working configuration. It provides no nodes, does not prepare host permissions, and should not replace the entire configuration file.

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

When checking DNS, distinguish the system resolver, core DNS, and encrypted DNS in apps. On systems using systemd-resolved, check for conflicts between the local stub resolver and listener addresses. Containers have their own network namespaces; loopback inside a container is not the host. Even if the host proxy works, a container may need its own proxy environment, route, or access path.

After stopping the service or rolling back a configuration, confirm that routes, resolver settings, and environment variables are back to the expected state. For connection problems, compare explicit proxy and TUN results before checking interfaces and the firewall; do not start by clearing rules globally. When working remotely, keep a separate management connection so a routing change does not cut off your session before you can inspect logs or roll back.

Configuration FAQ: Trace the Request Path

Subscription Update Failures vs. Configuration Load Failures

First distinguish a download failure, an invalid response, and a configuration parsing error. For download failures, check the network, URL, account status, certificates, and device time. If the response succeeds but contains a web page, check that the URL is still a subscription endpoint. For parsing errors, inspect the YAML location, field types, and core compatibility. Each error calls for a different fix; repeatedly clicking Update will not add missing configuration sections.

If the existing configuration still connects but cannot update, keep the working setup and investigate the subscription fetch path separately. The subscription domain may need direct access or may be restricted on the current network. Avoid making updates depend on a proxy group that has not loaded yet, creating a loop. Before changing which proxy method updates use, record the original setting; after a successful update, check that local rules and proxy group selections were not overwritten.

For rule set or geodata errors, check referenced names, download locations, and logs instead of deleting all rules. GEOIP relies on IP data; GEOSITE relies on domain data or corresponding configuration support. A missing resource and an unexpected rule match are different problems. After updating a resource, start a new connection to the destination and check the actual match. An existing connection is not a reliable test of the new rules.

Rule Order, Policy References, and DNS

Rules are evaluated from top to bottom, and the first match determines the policy. Put specific domain rules before broader rules and the fallback rule last. In the snippet below, PROXY must already be defined under proxy-groups, and GEOIP requires an available database. This is a rule example, not a complete working configuration. Update references to match your subscription's naming; do not paste the snippet and ignore errors.

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

Rule, global, and direct modes use different policy evaluation paths. When troubleshooting, confirm the current mode before changing rules; in global mode, editing rules will not have the expected effect. Automatic testing, failover, and manual selection groups also make decisions differently. A group name alone does not guarantee its behavior. For an expanded guide to routing traffic in and outside mainland China, see Practical mihomo Rule-Based Routing.

fake-ip associates domains with synthetic addresses using mapping records, so an address from a test range does not immediately mean DNS has been poisoned. An app may cache an old mapping, bypass the core resolver, or use encrypted DNS; this can change what information is visible to rules. Check the resolution path first, then clear the relevant cache using the client's recommended method. Adding every domain to a blocklist hides the root cause and makes domain-based routing harder to understand.

Node Test Succeeds but the Destination Is Unreachable

Latency tests use a specific destination and protocol; success only confirms that this test completed. A website may impose its own restrictions or require a different port, UDP, or region. Pin a node, access the same destination in a browser or from the command line, and check the connection logs. Compare whether the failed request reached the core, which rule it matched, and which outbound it selected. This is more useful than repeatedly changing the test destination.

If the browser works but the terminal does not, test with an explicit proxy option. If the terminal works but the browser does not, check browser extensions, separate proxy settings, and cache. If every app fails, check the core listener, node connectivity, and DNS. If only TUN fails, focus on permissions, interfaces, and routes. For the initial verification sequence, see How to Choose a Node and Verify the Proxy.

Keep useful evidence and a rollback path

When reporting an issue, include the operating system, client name, active configuration, routing method, failed destination, steps to reproduce, and most recent change. If needed, briefly increase log verbosity, reproduce the issue, then restore it to avoid collecting sensitive data over time. Reinstalling usually will not fix a remote subscription, destination service, or invalid rule. Narrow down the request path first, and save a new configuration baseline only after confirming the change works.