Clash Setup Guide
for Every Platform

Before You Begin: Clients, Subscriptions, and Traffic Routing

Understand the app, core, and configuration

Clash generally refers to a family of rule-based proxy tools; to install one, you need to choose a specific client. The client provides the interface, manages configuration, and requests system permissions. The core handles connections, resolves domains, and applies routing rules. mihomo is one of the cores in this ecosystem. A client opening successfully doesn't mean its core is running, and seeing a list of nodes doesn't mean system traffic is being routed through the proxy.

For most devices, start with Clash Plus. If you need a different interface or feature set, check the platform options in the Download Center. Don't enable multiple clients to route traffic at once: they may compete for local ports, system proxy settings, or virtual network interfaces. When switching clients, note the old client's port and routing method, quit it, then enable the new client. This makes it easier to identify what changed.

Configuration files are usually in YAML format and may contain nodes, proxy groups, rules, and DNS settings. Supported import formats vary between clients, so a file extension alone doesn't guarantee compatibility. If loading fails, check the logs to determine whether the issue is a syntax error, an unsupported field, or a failed download before editing the file or changing subscription formats.

Get your subscription ready and protect access credentials

The client itself doesn't provide a working proxy service. Before you begin, get a subscription URL or local configuration that you're authorized to use, and make sure the service is still active. Use the provider's copy button to avoid including page instructions, line breaks, or trailing spaces. If you only have a node share link, first check whether your client supports that format; don't import an arbitrary webpage URL as a subscription.

Subscription links may contain access credentials, so treat them like passwords. When troubleshooting, describe the error without posting the full URL in public comments or uploading a configuration with real node passwords. If you need help, remove subscription parameters, server addresses, and authentication details, while keeping field names, indentation, and the structure around the error. Before using a subscription converter, read the subscription conversion guide.

After importing, make sure the configuration is selected and that its proxy groups contain selectable nodes. Some clients separate downloading a configuration from activating it; a successful update only confirms that the file was retrieved. If the new configuration fails to load, the client may still be using the previous one. Check the active configuration name and logs rather than relying on a success message.

Choose system proxy or TUN—avoid routing traffic twice

The system proxy directs apps that honor system proxy settings to a local listening port, making it a good first option for testing browser access. TUN uses a virtual network interface to capture more types of traffic and also involves routing and DNS. Neither is simply a more or less advanced version of the other. If the system proxy meets your needs, start with the narrower scope; consider TUN for apps that ignore system proxy settings.

Before installing, temporarily quit other VPN and proxy software, especially tools that modify the default route. Work devices may also be subject to organizational policies; don't bypass them. If your network requires a sign-in page, complete that authentication before enabling the proxy. Otherwise, a subscription request may return a login page instead of the expected configuration file.

Follow the same steps for your first connection test

Start the core, import and activate a configuration, select rule mode, choose a specific node, then enable one routing method. Open the client's connections page, visit a known destination, and check for the corresponding connection and rule. Change only one setting at a time and keep a note of its original value. Changing the node, DNS, and mode all at once makes it hard to tell what fixed—or caused—the issue.

Windows: Installation, Service Mode, and System Proxy

Choose the right build and complete the first launch

Visit the Windows downloads and start with Clash Plus, or choose Clash Verge Rev, FlClash, or Clash Nyanpasu if they better fit your needs. Clash for Windows is no longer maintained. Archived builds may help with an existing setup, but aren't recommended as the default for a new device. Similar-looking interfaces don't necessarily share configuration directories, so export any settings you need before switching clients.

In Settings, go to System > About to check your device specifications. Distinguish the processor architecture from the operating system's bitness. If the download page doesn't offer a build for your device, don't try to install one by renaming the file. Run the installer and follow its prompts to choose a folder. On first launch, use a standard user account; grant elevated permissions only when an action clearly requires them, such as installing a system service or driver.

If a firewall prompt appears, decide whether to allow access based on how you'll use the client. A proxy used only on this device doesn't need to accept connections from other devices on your local network. If you do want to share it at home, check the network type, listening address, and firewall scope first. Don't disable the entire firewall just to get the app running; that grants broader network access than the issue requires.

Import a subscription and check that the configuration is active

Open the configuration or subscription page and choose the option to import from a URL. Paste the full subscription URL and give it a recognizable local name. Once the download finishes, select the configuration and check that its proxy groups show nodes. Start in rule mode and choose a node manually to avoid automatic policy switching during initial troubleshooting. For subscription setup details, see the subscription import guide.

If the client reports a parsing error, open the logs and check where it occurred. YAML indentation must use spaces, and the hyphens before list items are part of the structure. Don't replace an entire configuration with one from another client; some extended fields are supported only by specific cores. If the new configuration won't load, switch back to the last working one and troubleshoot the new file separately to avoid losing network access across the device.

Test the system proxy first, then decide whether to enable TUN

After enabling the system proxy in the client, check the local address and port in Windows proxy settings. The client may show an HTTP port or use a mixed port; use the value shown by your client. If a browser works but another app doesn't, check whether that app has its own proxy settings or ignores the system proxy. Don't assume the node is down.

If you need TUN, install service mode or the required network components as prompted by the client, then enable TUN. A service being installed and a service running are two separate states. If the toggle immediately switches off, check the logs for permission, device creation, or route-writing errors. Once enabled, confirm that the target app's requests appear on the connections page rather than relying only on the system tray icon.

Some security software restricts virtual network adapters, service processes, or network filtering. Use specific log messages to identify the required permissions; there's no need to add the entire client folder to a broad exclusion list. If another VPN is running, quit it and try again. Before enabling TUN, make sure routes for private networks won't be captured incorrectly, especially if you rely on a company intranet, remote desktop, or printer.

No internet after quitting and port conflicts

After the client quits, Windows may still point to a local proxy that is no longer listening, causing apps that follow system proxy settings to fail. Restart the client, turn off the system proxy, then check whether Windows proxy settings have been restored. If you no longer use the proxy, remove only the leftover manual proxy entry. Don't delete an automatic configuration script or network policy provided by your organization.

If the logs show a listener failure, check whether an old client is already using the port. The command below is only an example for checking a listening port; if your actual port differs, replace it with the one shown in settings. Identify the process by its process ID and quit the conflicting app normally rather than terminating an unfamiliar system process.

netstat -ano | findstr :7890

A browser proxy extension may also keep using an old port even when system settings are correct. Pause the extension for testing, use the default network settings, and compare the results. Restarting the computer may clear some temporary state, but it won't replace checking the proxy address, service status, and configuration. Once the network is back, note the actual cause to avoid the same issue at the next startup.

Keep startup behavior observable

First confirm that the client can start, connect, and quit normally; then enable launch at startup. The GUI, background service, and automatic proxy activation may be separate options—opening the app doesn't mean traffic is being routed. After signing in again, check the active configuration and connection records. Pay particular attention to whether a service that starts before your user session can read configuration stored in your user folder. See startup troubleshooting for general checks, or the full Windows installation and firewall guide.

macOS: Installation Permissions, Helper Services, and Network Extensions

Check the processor architecture and client maintenance status

Open About This Mac from the Apple menu to check whether your device has Apple silicon or an Intel processor, then choose the matching installer from the macOS downloads. Clash Plus is the recommended option; Clash Verge Rev and FlClash are alternatives. ClashX Meta is no longer maintained and is mainly useful for compatibility with or migration from older configurations. The word Meta in a client name doesn't mean it's still actively maintained.

Open the disk image, copy the app to Applications, and launch it from there. Running it directly from Downloads or the disk image can make helper service paths, startup items, and updates unreliable. If macOS reports a conflict with an existing file, quit the running client and back up your configuration before replacing it normally. Don't keep multiple copies that can all launch at startup.

Assess first-launch security warnings based on where the app came from. Prefer downloading it again from a trusted source, and check that the download completed and is compatible with your system. Don't run commands found online that disable system protections globally. If macOS still says the app is damaged or can't be opened, follow the steps in the macOS installation and permissions guide rather than treating every block as the same issue.

Import a subscription and distinguish app permissions from configuration issues

After launching the client, open configuration management, add the subscription URL, wait for it to download, and set it as the active configuration. Once nodes appear, start in rule mode and choose a node manually. If the import succeeds but the list is empty, check whether the subscription returned a login page or error message, and confirm that the client supports its format. Network permissions won't fix subscription syntax; test these issues separately.

The client may ask to install a helper tool to set the system proxy or perform network operations that require elevated permissions. Accept only prompts that match the action you're taking, and check the app's name. Entering your macOS account password authorizes a system change; it doesn't add the password to your subscription. If authorization keeps repeating, check that the helper service installed correctly and that the app is still in its original location.

Assess Keychain prompts separately. They may relate to the app saving or reading sensitive settings; don't automatically approve every request just because you're using a proxy. A recent password change or system migration can also affect Keychain access. First confirm that the request comes from the app you're using, then follow the system prompt. Don't mistake an unrelated Keychain issue for failed node authentication.

Check system proxy settings for the active network service

After enabling the system proxy, check the active network service in the network details in System Settings. Wi-Fi, Ethernet, and other connections may each have separate proxy settings; a working setup on one network may not carry over to another. In an office network that uses an automatic proxy configuration, understand the existing setup first so the client doesn't overwrite an organization-required proxy.

For testing, use a browser that follows system proxy settings, then look for the relevant domain on the client's connections page. Terminal tools don't always read the GUI's system proxy settings, so a failed terminal request alone doesn't show that the system proxy is broken. If an app has its own proxy options, keep to one clear route to avoid a loop where the system proxy points to the client and the client is forwarded through another proxy tool.

Turn off the system proxy before quitting the client, then check that a direct connection works. If an unexpected exit leaves the local proxy address behind, reopen the client, restore the settings, and quit normally. When cleaning up manually, change only entries you can identify as belonging to this client. Keep any required auto-discovery, automatic configuration, and other network service settings to avoid fixing one issue by breaking the network setup.

TUN, Network Extensions, and Local Network Routes

macOS clients handle traffic routing in different ways, using helper services, virtual interfaces, or network extensions. Don't expect every client to show the same permission prompt; follow the instructions for your specific client. If a network extension prompt appears, allow it in the relevant Privacy, Security, or Extensions area of System Settings, then return to the client to check its status.

If TUN won't start, check system permissions and helper services first, then routes and DNS. If only some websites work after enabling it, check for another VPN, filtering software, or enterprise network component that may also be changing the traffic path. Temporarily disable nonessential tools one at a time to compare results; don't remove every network service at once. If local network devices are unreachable, check direct routes and exclusions for private address ranges.

Make a note of brief network changes after waking from sleep. The device may have a new address, default gateway, or DNS server while background connections still use stale state. Wait for the network to reconnect, then check the core logs and, if needed, restart only the routing feature. If recovery always requires a full system restart, logs from before and after wake are more useful than repeatedly changing subscriptions.

Android: App Installation, VPN Permissions, and Background Activity

Choose a build for your device and keep a copy of your configuration

Choose an installer from the Android downloads. Clash Plus is the recommended option; alternatives include Clash Meta for Android, FlClash, and Surfboard. Most recent devices use ARM64, but choose based on your device's architecture and client support. A universal build is an option when you can't identify the architecture and the download page explicitly offers one. Don't assume all phones use the same processor architecture.

When installing from a browser or file manager, Android may ask you to allow app installs from that source. Grant only the permission needed for the source you're using, then restore the previous setting when you're done. If an update reports a signature mismatch, don't immediately uninstall the old app. Back up subscription names, per-app settings, and local overrides, then check the installer source and confirm that it's the same client.

System version, manufacturer customizations, and app permissions can change menu paths, but the troubleshooting order stays the same: first make sure the app installs and launches, then configure traffic routing. If the app closes on launch, check system compatibility and installer architecture; changing DNS won't fix it. Don't install purported driver patches from unknown sources. Android clients typically use the system VPN interface.

Import a subscription and understand the first VPN prompt

Open configuration management and add a remote subscription or import a local file. Name the configuration, update it, then set it as active and check that the proxy groups contain nodes. Some clients require you to return to the main screen and start the connection after the update. If you imported a file, remote subscription refreshes won't update that local copy. Know where it gets updates so you don't keep using stale nodes.

The first time you connect, Android asks to set up a VPN connection. Here, VPN refers to Android's traffic-routing interface; it doesn't mean the device is connecting to a separate, traditional VPN service. Once you grant permission, the client can receive traffic routed to it by the system. If you cancel, the client won't route app traffic—even if its node list and rules have loaded.

Android generally allows only one standard VPN interface at a time. Another VPN, a filtering app that uses a local VPN, or some firewall apps may replace the current connection when started. If the switch turns off immediately or the status keeps changing, check whether another app is using the interface before troubleshooting subscriptions or nodes. Reimporting the same URL won't help.

Per-app proxying and local network access

Android clients usually handle connections within their VPN routing scope rather than relying on the desktop-style system proxy toggle. A per-app list may mean “proxy only selected apps” or “bypass selected apps”—the two behave in opposite ways. Read the current mode's description before changing it, test one target app, and check its connection records before adding more apps.

If an app never appears on the connections page, check whether it's excluded, running in a work profile, or being used by another user. The system may route traffic differently for personal and work profiles. After changing per-app settings, you may need to reconnect the VPN and reopen the target app; existing connections won't automatically switch to the new route.

Casting, printers, and router admin pages rely on local network access. If they stop working after enabling the proxy, check direct rules for private addresses and any local network bypass option in the client. Allowing other devices on the local network to connect to your phone's proxy is different from letting your phone bypass local network traffic. The first involves listening and sharing; the second changes routing scope. Don't confuse one toggle for both.

Adjust background settings based on what is actually disconnecting

If the connection works with the screen on but drops after locking, check battery optimization, background activity, and the manufacturer's app-cleanup settings first. Allow reasonable background activity for the client, then test again with the screen locked and check the system VPN icon and logs after reopening the app. You don't need to grant background access to every app or assume the core is broken based only on a battery warning; check whether connections actually drop.

“Always-on VPN” and “Block connections without VPN” are system-level features. Understand how to restore access before enabling them. The latter blocks network access when the VPN isn't connected, so a client or subscription problem can look like the whole device has lost internet. Confirm that the configuration is stable and know where to find the system VPN settings first. These options aren't fixes for connection failures.

After switching from Wi-Fi to mobile data, an existing connection may need to be re-established. Mobile networks may also differ in IPv6, UDP support, and the route to a node. Compare the same node on both networks before changing nodes or protocols. If only one app fails, check per-app routing; if all apps fail, check VPN status and the default network. Narrow down the issue by its scope.

iOS: App Store Installation, Subscription Import, and On-Demand Connections

Install Clash Plus and find the key features

Install Clash Plus on your iPhone or iPad from the App Store. Product details are available at clashplus.io. You can also check the iOS download guide first. After installing, open the app and locate configuration, policies, and connection status before importing an existing subscription. Don't mistake the system VPN settings page for subscription management.

Traffic routing on mobile works differently from desktop. You don't need to follow Windows service installation steps or look for a virtual network adapter with the same name. Clients generally use a system-provided network extension to create a VPN configuration. System Settings handles permissions and connection status; the client still manages nodes, proxy groups, and rules. These screens serve different purposes.

On first launch, you may see prompts for notifications, network access, or other permissions. Consider each one based on what the feature does. VPN configuration permission for your first connection is separate from notification access. If you declined permission for network routing, return to the app and start the connection again, then confirm as prompted. Enabling notifications won't activate the proxy or add a missing subscription.

After importing a subscription, check the policies before reconnecting repeatedly

Add the subscription in the app's configuration manager, paste the full URL, and update it. If you import a file through the share menu, make sure it contains a supported configuration rather than a saved webpage. Set it as the active configuration and check the available options in its proxy groups. Configuration names are local labels, so name them by purpose, but don't include account passwords or full access URLs.

If nodes are listed but you can't connect, choose a specific node and check the current mode. Rule mode selects policies based on rules; global mode sends applicable connections to a global policy but won't fix a broken node. You can temporarily reduce variables during initial testing, but choose a mode that fits your needs and local network requirements for everyday use. There's no need to rely on global mode to hide incorrect rules.

Updating a subscription and applying it to existing connections are separate steps. After a successful update, confirm that the active configuration has been applied; existing long-lived connections may still use the old route. To test the new configuration, reopen the target app and, if needed, reconnect the VPN. Then check the client's new connection records. Refreshing the same cached page isn't enough to confirm that new rules are active.

VPN status, on-demand connections, and other network tools

Start the connection, approve the system VPN configuration, then check the connection status in System Settings and visit a test destination. A connected VPN status confirms that the system tunnel is established, but doesn't guarantee that the upstream node is working. If the logs show connections but requests keep failing, check node authentication, server reachability, and destination rules rather than repeatedly deleting the system VPN configuration.

On-demand connections let the system start a connection when specified conditions are met; they don't mean the app must stay in the foreground. Conditions may include the network type or client-specific policies—check the current interface for details. Start with a manual connection, then enable on-demand rules once everything works. Otherwise, automatic reconnection may immediately restore the connection during troubleshooting and make it seem impossible to turn off.

Another VPN or a tool that also uses a network extension may affect the current route. Temporarily pause nonessential tools and check for old VPN configurations in System Settings. Delete an old configuration only when you're sure you no longer use it, and stop its connection from the associated app first. Don't try to bypass network policies on managed devices; follow your organization's device requirements.

Switching networks, DNS, and local network boundaries

Hotel and airport networks may require you to sign in through a web page. If the proxy connects automatically before authentication, subscription updates and node connections may fail. Temporarily turn off on-demand connections, complete the network sign-in, then connect manually. Don't save the redirected authentication page URL as a subscription or overwrite a working configuration just because it fails on public Wi-Fi.

Wi-Fi and cellular use different routes, so a brief reconnect after switching networks is worth observing. If the issue occurs only on one Wi-Fi network, compare its authentication status, DNS, and firewall restrictions. If it fails on every network, check the node and subscription. Note whether requests appear on the app's connections page during testing; this helps distinguish a routing scope issue from an upstream connection problem.

Local network permissions affect some apps' ability to find nearby devices, but they don't replace correct proxy rules. If you can't reach a home storage device, casting device, or router page, first confirm that the destination is a local address, then check the client's direct or bypass settings. Don't add every unreachable domain to direct rules. If the destination still requires a proxy, that change only moves the failure from the rules stage to the direct connection stage.

Logs and background behavior visible in iOS are affected by system behavior. Clearing an app from the app switcher doesn't necessarily stop the system VPN, and seeing it in the app switcher doesn't prove the connection is working. Cross-check the system connection status, client records, and actual access. When you want to disconnect, turn off on-demand connections, stop the VPN, and confirm that traffic has returned to the expected route.

Linux: Desktop Clients and the mihomo Background Service

For desktop installs, choose the right package format for your distribution

Desktop users can get the recommended Clash Verge Rev or FlClash from the Linux downloads. Choose a DEB or RPM package for your distribution, and check the processor architecture and runtime requirements. Don't install a package on a different distribution just because its file extension looks familiar, and don't replace critical system libraries to satisfy dependencies. If the GUI won't launch, run it from a terminal and inspect the dependency error.

After installation, importing a subscription, activating a configuration, and choosing a node work much as they do on other desktop platforms. However, system proxy settings may not cover every desktop environment or app. Browsers, terminals, and package managers may each use a different proxy source. Confirm that the core is listening on a local port, then configure proxy access for the programs that need it. A successful desktop setting doesn't mean every process is routed.

For headless systems, prepare the configuration and working directory first

On a server or router, you can run the mihomo core directly. Choose a binary that matches your system architecture, extract it, and place it in a managed executable directory. The examples in this section use /usr/local/bin/mihomo for the program and /etc/mihomo/config.yaml for the configuration. These are example paths; don't overwrite directories already used by other software.

Create a dedicated service account and working directory, then add your existing configuration and restrict its read permissions. The commands below apply to common Linux systems with the required tools; check that the account doesn't already exist before running them. Check permissions for rule sets, databases, and relative paths against the working directory too. Making the main file readable isn't enough if its dependencies aren't accessible.

sudo useradd --system --home-dir /etc/mihomo --shell /usr/sbin/nologin mihomo
sudo install -d -o mihomo -g mihomo -m 0750 /etc/mihomo
sudo install -o mihomo -g mihomo -m 0640 ./config.yaml /etc/mihomo/config.yaml
sudo -u mihomo /usr/local/bin/mihomo -t -d /etc/mihomo

A successful test command means the configuration can be parsed and checked; it doesn't guarantee that nodes work. The first run may also need to fetch resources referenced by the configuration, which can fail if the network is restricted or the directory isn't writable. Don't treat a successful parse as a complete deployment. Check the running process, listening port, and real requests next, and distinguish database resource errors from node issues.

Manage a standard proxy service with systemd

This service unit is for a standard local proxy listener. It doesn't enable TUN or grant extra network management privileges. Save it as /etc/systemd/system/mihomo.service and make sure the executable path matches its actual location. If your distribution doesn't use systemd, use its native service manager rather than forcing these commands to fit.

[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
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
sudo journalctl -u mihomo -b --no-pager -n 80

A network-ready target doesn't guarantee that an external subscription URL is reachable. If resource retrieval fails when the service starts, check the logs and handle resource management appropriately rather than relying on endless restarts. Keep a working copy before editing the configuration, test it, then restart. If the service enters a restart loop, stop it and fix the configuration before starting it again to avoid repeated failed requests upstream.

Terminal proxies, remote access, and TUN permissions

For temporary terminal tasks, set proxy environment variables in the current shell. The example assumes a mixed port of 7890. It affects only programs that read these variables and doesn't change system routes automatically. Use a no-proxy list for local services to avoid sending loopback addresses through the proxy. Check the tool's documentation to see whether it supports SOCKS and remote DNS resolution.

export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890
export no_proxy=localhost,127.0.0.1,::1
curl -I https://example.com

# Clear the temporary settings in the current terminal
unset http_proxy https_proxy no_proxy

When maintaining a server over SSH, keep a second management session open before changing routes. TUN needs access to a virtual network device and the necessary network management privileges; the low-privilege service unit above can't perform those operations as-is. Design permissions separately for your system and client implementation instead of simply running every service as root. On remote machines, plan SSH return traffic and management network exclusions first.

If the proxy is only for local use, keep its listening address on loopback and don't expose an external control interface. Sharing a proxy on your local network also requires careful consideration of the listening address, authentication, and firewall; changing only the LAN access setting isn't enough. For more advanced deployments, see the Linux headless and systemd guide. Once the standard proxy is stable, add TUN or remote management needs one at a time.

Common Configuration Issues: Subscriptions, Rules, TUN, and DNS

Subscription updates failing? Check the request and the parser separately

When an update fails, first check whether the request retrieved a configuration. A timeout usually points to the current network, access route, or server response. An authentication error calls for checking the subscription's validity and URL. If the response is a webpage, it may be a login, authentication, or error page. Don't immediately send the URL to a conversion service: conversion can't fix an expired service and may expose a private subscription to another party.

If the download succeeds but parsing fails, check the content format, indentation, and fields supported by the core. The client may cache the last working configuration, so “still connected” doesn't mean the latest update took effect. Keep a redacted snippet around the error line and compare it with the client's supported formats. If subscriptions need to be updated through the proxy, first make sure an existing working configuration can connect; otherwise, you can end up in a loop where you need an update to get online.

Rules and overrides: match in order and maintain by source

Rules are usually checked from top to bottom, and the first match determines the policy. The final MATCH rule catches anything that hasn't matched earlier. The example below shows the rule structure only and assumes your configuration already has a policy named PROXY. Domain rules and destination IP rules use different matching conditions. If a domain connection matches an IP rule, check domain recognition and resolution next.

mode: rule
mixed-port: 7890
allow-lan: false

rules:
  - DOMAIN-SUFFIX,github.com,PROXY
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

Don't put manual rules after the fallback rule. Subscription refreshes may overwrite direct edits, so use the overrides, merge options, or rule extensions supported by your client for lasting changes, and inspect the final merged configuration. Policy names must match exactly, including spaces and capitalization. Copying a group name from someone else's configuration without creating the corresponding policy group is a common cause of load failures.

TUN mode: permissions, routes, and loop checks

If TUN fails to start, check permissions, services, and the virtual device first. If the entire device loses internet after enabling it, check the default route, DNS, and node egress. Automatic routing must prevent the core's own outbound traffic from being sent back through TUN, which can create a loop. Desktop clients usually handle this; before editing low-level settings manually, make sure they won't conflict with routes generated by the GUI.

This is a snippet of mihomo TUN fields; it isn't suitable for pasting directly into every client. Prepare the required platform permissions before enabling it. The scope of DNS hijacking also depends on the system, routes, and implementation. Plan route exclusions first for work networks, other VPNs, and remote maintenance. Automatic routing isn't a one-size-fits-all default.

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

DNS: check resolution and proxy routing separately

DNS resolves a domain to an address; rules decide which policy handles the connection. They're related, but operate at different layers. Changing nodes may not help if DNS resolution fails, and a successful resolution doesn't mean you need to change DNS if the connection still fails. First check whether the logs show an address was resolved, then inspect the connection's rule and policy. If your browser uses encrypted DNS, check whether it bypasses the resolution path the client is meant to use.

nameserver specifies the regular DNS upstream. fallback works with filtering conditions to determine which candidate results are used, while fake-ip uses synthetic addresses to preserve domain mappings. Using an IP address for an upstream can avoid bootstrap resolution issues for its hostname, but isn't suitable for every network. The example below shows the structure; assess reachability and privacy requirements for your own setup.

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://1.1.1.1/dns-query
  fake-ip-filter:
    - '*.lan'
    - localhost

After changing the DNS mode, the system and apps may still have old cached results, and existing connections may keep using old addresses. Close old connections in the test app, then clear the relevant cache or rebuild traffic routing for your platform. Don't change several fields at once. DNS hijacking isn't the same as blocking all encrypted DNS. For a full explanation of how the fields relate, see Clash DNS Configuration Explained.

Startup and recovery: check three separate states

For startup, check the GUI, the core, and traffic routing separately. A background service may be running even if the GUI isn't open; the GUI may also be open without an active configuration. After a restart, check log timestamps, the active configuration, and the listening port, then verify the system proxy or VPN status. Startup can fail only on boot if the network hasn't authenticated, the user directory isn't unlocked, or an old client takes the port.

Keep a brief record after each change: the field, its original value, the test network, and the result. If you lose internet, turn off the newly enabled routing method, restore the previous configuration, and troubleshoot one layer at a time. If you ask for help publicly, share only redacted logs and minimal reproduction steps. For questions about choosing nodes, see how to weigh node region, protocol, and speed tests. Don't delete an entire configuration based on a single test.