CONFIG.YAML / All-Platform Reference
Clash Setup and Installation for Every Platform.
Downloads and architecture choices, subscription imports, system proxy and TUN, platform permissions, and connection checks.
This complete guide is organized by operating system. Use it to check requirements before installing, compare settings when migrating, or troubleshoot connection issues step by step. New to Clash and just looking to get connected? Start with the quick-start guide. For platform-specific permission, traffic routing, or background issues, jump to the relevant section rather than reworking your configuration from scratch.
Recommended order: complete the shared setup first, then follow the section for your platform. Add TUN, custom DNS, or rule overrides only after a basic connection works. Examples use mihomo configuration syntax; interface labels and supported fields vary by client.
Getting Started: Configuration Sources and Traffic Routing
Know the Difference Between the Client, Core, and Subscription
The client provides the interface, manages configuration, and requests system permissions. The core parses configuration, matches rules, and establishes connections. A subscription supplies nodes and proxy groups, and may also include DNS and routing rules. These are three separate things. Installing a client does not provide a remote service, and having a subscription does not mean every client can import it. Before you begin, check that the subscription is active, confirm its format, and make sure the provider offers an import method for your client.
Most desktop and mobile users should start with the downloads page and choose Clash Plus, then compare other clients against their system requirements. Consider using the mihomo core on its own only if you need to manage the service process, routes, and configuration directory yourself. The names Clash, Clash.Meta, and mihomo reflect the project's evolution, but that does not guarantee compatibility with every older configuration. Check protocol, rule-field, and DNS support against the core you actually use. See Core and configuration compatibility explained.
Note Your Device and Current Network Setup
Before downloading, note your operating system, processor architecture, and installer format. On desktop, check for other VPNs, proxy apps, virtual network adapters, or corporate security software. Quit other proxy tools and test whether ordinary websites load without a proxy; if the direct connection is already broken, fix the underlying network first. Record your existing proxy and DNS settings so you can restore them later. Avoid changing routes, removing network adapters, and replacing DNS servers all at once.
A subscription URL may grant access to your configuration. Before sharing logs or screenshots, hide the full URL, user identifiers, and query parameters. Copy the complete link from a trusted source, taking care to avoid line breaks, trailing spaces, or punctuation added by a messaging app. If the link opens a webpage instead of returning configuration, check whether sign-in is required, whether the URL has expired, and whether your client supports the response format. Never submit a subscription containing personal identifiers to an untrusted conversion site.
Choose When to Use System Proxy or TUN
A system proxy directs apps that honor the operating system's proxy settings to a local listening port. Browsers are usually suitable for a basic test, but some games, command-line tools, and apps with their own network stack may ignore it. TUN creates a virtual network interface and routes more traffic through the client, typically requiring elevated permissions and additional DNS and adapter configuration. On desktop, verify the system proxy first, then switch to TUN if needed. Mobile clients typically route traffic through the system's VPN extension, so their controls do not work like desktop toggles.
| Method | Traffic covered | Check first |
|---|---|---|
| System proxy | Apps that honor system proxy settings | Listen address, port, bypass list |
| TUN routing | Traffic routed through the virtual adapter | Service permissions, routes, DNS, and other VPNs |
| Per-app proxy | An individual app explicitly configured to use a proxy | Proxy protocol and the app's own settings |
Build a Minimal, Testable Configuration
The snippet below shows basic fields only. Add them to a working configuration; it does not include nodes or proxy groups. Use the port shown in your client, as some clients override subscription values with settings from their own interface. Keep access local and use rule mode; do not expose the proxy to your LAN yet. YAML uses spaces for indentation. Leave a space after each colon and align fields at the same level. If loading fails, check the reported line number instead of deleting whole rule sections to hide a syntax error.
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
After importing, verify three things: the configuration loads, the selected node connects, and requests match the expected policies. Choose one node without enabling frequent automatic tests. Visit one site that should connect directly and one that should use the proxy, then check the policy and exit route on the connection page. Once it works, save a copy of the configuration and note the routing method. When adding rules or DNS settings later, change one thing at a time so you can identify what caused any difference.
Windows: Installation, System Proxy, and Service Permissions
Choose the Right Architecture and Keep Migration Notes
Check your system type under Settings > System > About, and distinguish common x64 systems from ARM devices. Start with Clash Plus in the Windows downloads; alternatives include Clash Verge Rev, FlClash, and Clash Nyanpasu. Clash for Windows is no longer maintained and is worth consulting only when you have a specific compatibility need. Do not choose a legacy client for a new device just because the name is familiar, or mix installers for different architectures and keep trying them at random.
Before moving from an older client, note your subscription source, manually selected proxy groups, custom rules, and per-app proxy settings. Save any exportable local configuration in a separate folder, but do not overwrite the new client's entire data directory: databases, interface settings, and service state may not be compatible. Keep the new installation's default data directory, make a basic connection, then migrate custom settings one at a time. For migration guidance, see How to migrate from Clash for Windows.
When launching the installer, verify its source and review any system warnings. After installation, open the client as a regular user; everyday use does not need to run with administrator privileges. If security software blocks it, check the blocked item and any organizational policy rather than disabling system protection. Work-managed computers may restrict proxies, drivers, or service installation. Repeatedly approving prompts will not override a policy-level restriction; contact your device administrator.
Import a Subscription and Check the System Proxy
Open the configuration or subscription manager, choose the option to add a link, paste the full subscription URL, and wait for it to finish downloading. Once the entry appears, select it as the active configuration, then open the proxy page to confirm that proxy groups and nodes have loaded. Seeing a subscription name does not mean the core has switched to it. If the list is empty, check the update result and configuration parsing logs. If an update fails, keep the existing configuration rather than repeatedly deleting and recreating it, which could remove a working cached copy.
Choose rule mode, select a node in any proxy group that requires manual selection, then enable the system proxy. In Windows Settings, open Network & Internet > Proxy and check the address and port. They should normally point to the local loopback address and the listening port shown in the client. If your browser has a proxy extension, disable its proxy controls temporarily. Otherwise, requests may use an old port saved by the extension and never reach the active core, even when the system settings are correct.
Open a test page while watching the client's connection list. If the page fails and no matching request appears, check the browser's own proxy, the system bypass list, and the local listener first. If the request appears but fails to connect, check node authentication, remote reachability, and rule selection. Some apps need to restart before they pick up system proxy changes. Command-line tools may read only environment variables, so a successful browser test does not mean every app is routed.
Enable TUN and Resolve Permission Errors
Enable TUN only when an app does not honor the system proxy. Some clients require service mode or an authorized helper process first. Follow the prompts, then check that the service is running instead of relying on an enabled toggle. For the first test, you can turn off the system proxy and leave TUN as the only routing method. If the virtual adapter fails to start, check the permission or driver error. If route setup fails, look for other VPNs, virtual machine networks, and leftover services.
If a local port is in use, check the listening process in PowerShell. This command only checks the example port; it will not stop any process. Replace it with the port shown in your settings if different. Look up the process ID in Task Manager to identify its app, then close the old tool normally and restart the current client. Do not terminate unknown processes in bulk just because a port is occupied; system services and developer tools may use local ports too.
Get-NetTCPConnection -State Listen -LocalPort 7890 |
Select-Object LocalAddress, LocalPort, OwningProcess
If the connection drops after waking from sleep or switching from Ethernet to Wi-Fi, turn the current routing method off and back on, then check whether the core has detected the default adapter again. If only TUN fails while the system proxy works, investigate routes and network adapters instead of buying a new subscription or changing node protocols at random. Limit firewall allowances to the apps and networks that need them. With allow-lan: false, you do not need to open inbound access to the entire LAN just to browse on the local computer.
Finally, check what happens when you disconnect: turn off the system proxy or TUN in the client, then quit normally and confirm that the browser can connect directly. If the entire network stops working after an unexpected exit, check for a leftover local proxy address and restore the settings you recorded earlier. Consider enabling startup only after the connection is stable. Launch at login, start as a service, and connect automatically are separate options; test them individually to avoid two clients competing for proxy settings.
macOS: Chip Architecture, Helper Services, and Network Locations
Choose an Installer and Handle First Launch
Open Apple menu > About This Mac and check whether your device has an Apple chip or an Intel processor. Then choose the matching build from the macOS downloads. Clash Plus is a good place to start; you can also compare Clash Verge Rev and FlClash. ClashX Meta is no longer maintained, so its past behavior matters mainly when migrating an older configuration. An app running through a compatibility layer is not necessarily a good long-term choice. Prefer a build for your Mac's chip to avoid extra compatibility steps.
When installing from a disk image, copy the app to the Applications folder before launching it. Do not keep running it from the mounted image or Downloads folder. Installing it in the right location helps keep updates, helper service paths, and system permissions consistent. If macOS blocks the first launch, confirm the download source, then follow the prompt under Privacy & Security. Avoid running untrusted terminal commands to strip security attributes from every app, and do not assume a launch problem is caused by your subscription.
If the client needs a helper service, distinguish the app itself from the background component it installs. Changing system proxy settings, creating a virtual adapter, or managing routes may require administrator approval once. After granting it, return to the client and check the service status. If you moved the app or switched to a similar tool, the old service path may no longer work. Use the relevant client's repair or uninstall option rather than dragging the app to Trash and leaving its background service behind.
Import a Subscription and Check the System Proxy
Add the subscription URL on the configuration page, wait for it to download and parse, then select that configuration. First check that proxy groups exist, the current selection points to a working node, and rule mode is enabled. If the subscription contains fields the client does not support, the logs usually identify the field or protocol. Ask the configuration provider for a compatible version, or use a client that supports the field. Do not simply delete the reported line; it may contain a parameter required to connect to the remote service.
After enabling the system proxy, open Network in System Settings, select the network service you are currently using, and check its proxy settings under Details. Wi-Fi and Ethernet may store separate settings, so select the service actually carrying traffic. The address is usually the local loopback address, and the port should match the client. If the browser works but the terminal does not, check whether the terminal tool reads system proxy settings. If neither works, check the listening process and whether the configuration loaded.
The system proxy bypass list controls which destinations skip the local proxy. You may need direct access to a corporate intranet, printer, or local development address, so do not permanently remove every exception just to test. Conversely, an overly broad domain or address range may bypass the client when you expect traffic to use the proxy. Record the original values before changing them, retest a specific destination, and watch for its request on the connection page. The menu bar icon alone cannot tell you which route a request took.
TUN, Wake from Sleep, and DNS Caches
Before enabling TUN, authorize the helper component and pause any other VPNs. Clients use different routing and service management implementations, and macOS permission prompts can vary; follow the documentation for your app. For the first test, temporarily turn off the system proxy and use the rule logs to confirm that traffic is entering through TUN. If startup fails with a default adapter or route error, note the network interfaces and other network extensions in use before deciding whether to restart the helper service.
After a laptop wakes from sleep, switches hotspots, or joins public Wi-Fi with a captive portal, existing connections and DNS results may temporarily stop working. Turn off the proxy, complete the network login, then reconnect. If only a few domains still resolve incorrectly, refresh the system cache after confirming the DNS settings are correct. The command below requires administrator privileges and clears only the local cache; it cannot fix a subscription, remote node, or incorrect DNS configuration. It should not be the first step for every problem.
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder
Some browsers use encrypted DNS independently, and apps may keep existing connections open. After changing DNS policies, close the relevant test tabs or restart the app before checking new requests. With fake-ip enabled, do not treat a cached virtual address as a real server address for manual connectivity tests; the corresponding core needs to interpret it. Use connection logs to check DNS behavior and the destination route rather than drawing conclusions from a single command-line lookup.
After migration, test a browser, a desktop app that should use the proxy, and a LAN service that should connect directly. Then disable routing, quit the client, and confirm that the network works normally. If only one network location has a problem, compare its saved proxy and DNS settings instead of removing all network services. Keep a configuration you can roll back to so you can separate the effects of OS updates, client updates, and subscription changes.
Android: Architecture, VPN Permissions, and Background Use
Check Your Device Before Downloading and Installing
Start with Clash Plus in the Android downloads, followed by Clash Meta for Android, FlClash, or Surfboard. Most phones use ARM64, but older devices and some systems may need a different build. Check your device information and the download page before choosing. If installation fails, read the specific system error: architecture mismatch, unsupported system version, low storage, and signature mismatch each have different fixes. Repeatedly downloading the same file will not solve them.
When installing through a browser or file manager, Android may ask you to allow app installs from that source. Grant permission only to the source you are using, then revoke it when you no longer need it. If an older and newer version have different signing keys, an in-place update may be rejected. Before uninstalling, export your subscription and local rules, and make sure you can get the configuration again; uninstalling usually deletes the app's private data. Do not store backups in public chats or cloud drives: a subscription URL may provide access to your account configuration.
Do not assume Surfboard and Clash configurations use exactly the same format. Before importing, check whether your provider offers a compatible format. Two apps supporting the same protocol name does not mean their rule syntax or subscription contents are interchangeable. Confirm that your configuration source supports the client before choosing based on interface preferences. Format conversion adds another variable, so use the provider's recommended native import method until a basic connection works.
Import a Configuration and Approve the VPN Connection
Create a remote subscription in the configuration manager, paste the URL, download it, and set the entry as active. For QR code imports, check whether the result is a subscription, a single node, or a sign-in page; a successful scan does not prove the configuration is valid. If the download fails, check the phone's clock, whether the network requires captive portal sign-in, and whether the subscription is still active. If the import succeeds but no proxy groups appear, check the format and parsing results.
On the first connection, Android usually displays a VPN connection request. The app needs this system permission to route device traffic. Confirm that the request comes from the client you just installed, then approve it. Most devices allow only one active VPN per user at a time, so another VPN, firewall, or local-VPN-based filtering app may replace the current connection. A VPN icon in the status bar means a tunnel exists; it does not confirm that the remote node or DNS is working.
Keep rule mode enabled, select a node, open a browser, and check the policy on the connection page. Mobile VPN routing does not require you to enter a system HTTP proxy as you would on desktop. The manual proxy in a Wi-Fi network's advanced settings applies mainly to that network, and combining both routing methods makes troubleshooting harder. Unless you specifically need to connect through another device's proxy, restore the Wi-Fi proxy settings first and test the client's own VPN tunnel.
Per-App Routing and Background Restrictions
Per-app proxy settings may offer two opposite options: proxy only selected apps or bypass selected apps. Read the description carefully before choosing. To start, leave app filtering off, verify that traffic is routed, then add exceptions one at a time. If an app does not appear in the connection list, check whether it is excluded, running in a work profile or another user space, or routed through a different VPN before assuming the node is at fault.
A connection that drops when the screen turns off is often caused by battery optimization, background activity limits, or the manufacturer's auto-start controls. Allow the client to run in the background and keep any required foreground service notification enabled. Menu names vary by manufacturer, so search system settings for battery and background controls. Do not remove restrictions for every app at once. After allowing background activity, test screen-off behavior, network switching, and system cleanup separately to find what interrupts the service.
Always-on VPN and blocking connections without a VPN are device-level settings. If the latter is enabled, regular network access may stop when the client disconnects, so do not enable it before the basic connection is stable. Android Private DNS, browser encrypted DNS, and client DNS can also send lookups along different paths. Record the current settings and use logs to check which path requests actually take. Changing every DNS setting at once makes it hard to compare results.
To troubleshoot battery drain, reduce frequent speed tests and unnecessary logging, then check whether ongoing transfers, repeated reconnects, or background updates are waking the device. A shorter health-check interval does not guarantee a more stable connection; running tests constantly during network changes can add extra load. Use the mobile background and battery settings guide to review options one at a time. Keep only the features you need for a reliable connection, and check background permissions again after a system update.
iOS: App Store Installation, Configuration Import, and On-Demand Connections
Check the App and Configuration Format in the Store
For iPhone and iPad, this site recommends Clash Plus. Visit the iOS downloads to open the store, or go directly to Clash Plus on the App Store. The product website is clashplus.io. Before installing, check the current system requirements listed in the store and confirm that your device is compatible. Do not follow desktop file installation steps on a phone; mobile permissions and configuration storage work differently.
Before adding a subscription, check which import formats Clash Plus currently supports. A matching file extension or an HTTPS link does not guarantee that the contents are compatible. Desktop configurations may include local paths, external scripts, or fields supported only by a particular core, none of which may work on mobile. If your provider offers a client-specific subscription, use that option. If you have only single-node details, add them through the app's node setup instead of pasting them into the remote configuration field.
iOS places clear limits on app sandboxes and background extensions. A configuration directory you can edit directly on a computer usually cannot be used the same way on a phone. To import a local file, use the app's supported file import or share option. Then check whether the app made a separate copy and whether that copy updates automatically. Seeing a file in the Files app does not mean the client will keep reading it from that location, or that changes made on a computer will sync to your phone.
Add a Subscription and Approve the VPN Configuration
Open the app's configuration or subscription manager, add a remote subscription, and wait for it to load. Confirm that proxy groups, nodes, and rules appear, then select the active configuration. If an update stalls, first check internet access on a regular connection and make sure you are not waiting on a public Wi-Fi sign-in page. Then check whether the URL has expired or requires a specific format. Avoid changing the Wi-Fi network, subscription source, and client settings in the same test; otherwise, it will be hard to tell what fixed the problem.
On the first connection, iOS usually asks permission to add a VPN configuration. Follow the system prompts to authorize it. Return to the app to check the connection status, then confirm in VPN settings that the correct configuration is enabled. If the device has an old VPN, a profile installed by an organization, or another network extension, identify its purpose first. Managed devices may restrict changes. Do not delete an unfamiliar work profile to get connected; ask your device administrator about your permissions.
An enabled connection button means the app has tried to establish a traffic-routing tunnel. You still need to select a policy and make a real request, then check the result in the app's connection or log view. Test local services that should connect directly as well. An iOS VPN extension is not the same as a desktop system proxy; you usually do not need to enter a local port in Wi-Fi settings. If a manual proxy is still configured, record it and restore the setting so it does not affect your test.
On-Demand Connections, Network Switching, and LAN Access
If the app supports on-demand connections, configure them only after the basic connection is stable, and check each trigger condition. Some policies use network type or Wi-Fi criteria; others trigger on domain requests. Do not assume how they work based on the word “automatic.” Test after waking the screen, switching from Wi-Fi to cellular, and switching back. If the connection drops briefly during a transition, first check whether the extension reconnects and DNS refreshes instead of immediately changing every rule to global mode.
On public Wi-Fi with a captive portal, pause automatic reconnection, sign in, then reconnect. Otherwise, an on-demand rule may keep routing traffic back to a network that is not ready yet. To access a home server, printer, or casting device, check the app's LAN permissions and direct-connection rules. Device discovery may also rely on broadcast or multicast, so adding a single domain rule may not be enough. Distinguish a discovery problem from a failed connection to a known address.
Do not paste a complete mihomo TUN or DNS section into a mobile configuration and assume it will work. Mobile clients may use a different configuration model or support only some fields. Check the import results and feature documentation. Browser DNS settings, system privacy features, and the VPN extension can also affect what you observe. To compare behavior, change one setting at a time, record its original value, and restore unrelated settings when you finish testing.
If the phone uses significantly more battery with the screen off, check for frequent speed tests, continuous logging, overly frequent updates, or reconnects caused by an unstable network. Background extensions also depend on system scheduling and available resources, so desktop experience cannot guarantee how a phone will behave. A reasonable update schedule is more useful for troubleshooting than repeatedly force-quitting and restarting the app. For details, read the mobile background behavior guide.
Before switching devices, save your subscription source and any essential custom rules separately. Do not assume a system backup includes every sensitive setting. After migrating, confirm the active subscription, selected policies, and on-demand conditions, then test on both Wi-Fi and cellular. If you stop using the app, disconnect inside the app and check the system VPN status. If a website behaves unexpectedly, first check whether an on-demand connection is still restarting automatically; closing the app screen alone may not stop traffic routing.
Linux: Desktop Installation, Core Operation, and Route Checks
Choose a Desktop Client and Package Format
Linux desktop users should start with Clash Verge Rev in the Linux downloads, followed by FlClash. Choose a DEB or RPM package supported by your distribution, and check the processor architecture. Package format and architecture are separate requirements; being for Linux does not make packages interchangeable. For servers, routers, or headless devices, see the core downloads, but be prepared to manage configuration directories, processes, logs, and routes yourself. A smaller download is not, by itself, a reason to use the standalone core.
Run the commands below before installation to check your architecture and distribution. Commonly, x86_64 means AMD64 and aarch64 means ARM64. Routers may also have different floating-point and instruction-set requirements, so check the device documentation. Desktop packages on the downloads page do not cover every architecture. If a package does not match, do not force installation by ignoring dependencies; that often just postpones the failure until launch.
uname -m
cat /etc/os-release
Install the local package with your distribution's package manager, and watch for missing dependencies or desktop environment requirements. Once the client window opens, configure the proxy and service permissions. This keeps display server and desktop library issues separate from network problems. If you have multiple similar tools installed, stop their instances and background services first. A port conflict or two services changing routes at once can make a client disconnect as soon as it starts.
Import a Subscription and Set Up the Desktop System Proxy
In the desktop client, add a remote subscription, download it, set it as the active configuration, and check the proxy groups. System proxy behavior on Linux depends on the desktop environment and individual app. Some browsers read desktop settings, while terminal tools may use only environment variables. After enabling the system proxy, test a browser first, then test the terminal with an explicit proxy option. This helps distinguish an unavailable core from an app that does not use the desktop proxy setting.
curl --proxy http://127.0.0.1:7890 --head https://example.com
ss -lntp
Use the port the client is actually listening on. The test URL only sends a request; receiving an HTTP status code does not mean every kind of traffic works. Check the connection logs to see whether the request appeared and which policy it matched. If you need environment variables, test them in the current terminal session before adding them globally. Tools vary in their support for variable names, SOCKS and HTTP proxies, and their own settings may override environment variables.
Running the Standalone Core with Minimal Permissions
When running mihomo on its own, start with a dedicated configuration directory. Save a complete, tested configuration as config.yaml and include any referenced resources, such as rule files. The example below assumes the extracted executable is named mihomo and the configuration is in a dedicated location under your home directory. Test the configuration, then run it in the foreground and read any errors directly. Do not create a startup service until the syntax check passes.
mkdir -p "$HOME/.config/mihomo"
chmod u+x ./mihomo
./mihomo -t -d "$HOME/.config/mihomo"
./mihomo -d "$HOME/.config/mihomo"
Basic proxy listening does not always require administrator privileges, but creating a TUN interface, changing routes, and some DNS operations do. A desktop client may provide a service management option; for the standalone core, use your distribution's service and permission system. Do not run your entire desktop session with elevated privileges, and do not give an unchecked subscription to a process with broad system access. Enable the remote control interface only when needed, and restrict its listening address and access permissions.
TUN, DNS Management, and Remote Access Recovery
Before enabling TUN, confirm that the required virtual network device is available and check existing routes, other VPNs, and firewall rules. Your system may use NetworkManager, systemd-resolved, or another DNS manager. Overwriting /etc/resolv.conf may be undone by that manager or break existing settings. Check whether the file is a symlink, identify the DNS manager, then configure DNS in a way your client supports. Do not enable multiple DNS interception methods that can override one another.
Take particular care when managing a remote server over SSH: changing the default route may send the management connection through the proxy and disconnect your session. Keep access to a console or another recovery method, set a direct route for the management host, and then test the routing scope. Use ip route and ip rule to check for changes, and confirm actual requests in the client logs. Seeing a virtual interface does not prove that policy routing or DNS is configured correctly.
Once the core runs reliably, hand it over to the service manager with fixed paths for the executable, working directory, and configuration. Avoid service references to a temporary download directory that may disappear during an update. Services use a different user, environment, and terminal from manual runs. If manual startup works but the background service fails, check its paths, file permissions, and logs before changing nodes. Finally, verify that stopping the service restores routes and DNS, and keep a working configuration. For future upgrades, change one component at a time.
Configuration Troubleshooting: Subscriptions, Rules, DNS, and Verification
Subscription Update Failures and Configuration Overrides
First distinguish a URL that will not download from a configuration that downloads but fails to parse. For download failures, check the network, system time, captive portal sign-in, subscription access, and provider status. For parsing failures, check the response format, protocol support, and YAML line number. A login or error page is not a valid configuration, even if the request returned a response. Some clients let you choose whether updates use a direct or proxied connection. Compare the two only when you already have a working configuration; do not rely on a proxy that cannot yet connect to fetch your only subscription.
If custom rules disappear after a subscription update, you probably edited the cached remote configuration directly. Move persistent settings to the client's override or merge feature, and check whether rules are prepended or appended. Rules are commonly evaluated in order, with the first match winning, so a custom rule at the end may never be reached. Keep copies of the original remote configuration and local extensions. If something goes wrong, temporarily disable the extension to test. See Common subscription update issues for more failure scenarios.
Rule Mode, Global Mode, and Node Tests
Rule mode selects a policy according to the rules. Global mode sends connections that have entered the core to the global proxy group, while direct mode usually connects them directly. These modes control traffic already reaching the core; they do not route apps that have not been intercepted. If global mode works but rule mode does not, check whether a rule selects a direct or empty policy. If both modes fail, check the node and traffic routing. Global mode will not fix every DNS or permission issue.
A node test usually measures one request to a specific test endpoint. It does not show real download speeds, access to every site, or long-term stability. If a test succeeds but your destination fails, check the matching rule, remote service restrictions, and connection protocol. If the test fails but websites load, check the test endpoint and timeout. Do not delete multiple nodes based on one result; compare the same destination on the same network first. See Understanding node latency and A layered approach to slow connection troubleshooting.
fake-ip, DNS Interception, and App Caches
fake-ip assigns virtual addresses to domains. When a connection returns to the same core, the address is mapped back to the domain for rule matching. This links domains to connections; enabling it alone does not guarantee that every DNS request follows the same route. Results can differ when an app bypasses system DNS, a browser uses its own encrypted DNS, or an old cache still contains a real address. The snippet below combines mihomo settings and must be merged into your existing configuration with regard to client support. It is not a general-purpose mobile template.
dns:
enable: true
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
nameserver:
- https://1.1.1.1/dns-query
tun:
enable: true
stack: mixed
auto-route: true
auto-detect-interface: true
dns-hijack:
- any:53
The upstream resolver in the example must be reachable on your current network and route. If the resolver itself cannot be reached, repeatedly clearing the cache will not help. Intercepting port 53 also does not capture every encrypted DNS request. If you select upstreams by domain, consider how their hostnames are resolved initially and whether resolving a remote node's hostname could create a loop. Add specific exceptions for LAN domains, device discovery, or apps when needed; avoid bypassing DNS for all domains.
Check DNS using system lookups, app requests, and connection logs. A result showing a particular region on a test page does not, by itself, prove a DNS leak. The location of a recursive resolver does not necessarily match the public IP a website sees; caching, public resolver routing, and the test method all affect results. To check for DNS leaks, first define the expected path and compare specific queries. For practical steps, see DNS leak tests and fake-ip configuration.
Troubleshoot One Layer at a Time Instead of Resetting Everything
| Symptom | Check first | How to compare |
|---|---|---|
| No request appears on the connection page | System proxy, app exclusions, TUN routes | Test with an explicit local proxy |
| Request appears, but the connection fails | Node authentication, remote reachability, policy selection | Keep the destination fixed and try another node |
| Only domain names fail | Upstream resolver, cache, DNS routing | Check DNS queries and core error logs |
| Network still fails after stopping the client | Leftover proxy settings, routes, device-level VPN policies | Restore the network settings recorded before installation |
If a connection is slow, first check whether the destination service is throttling traffic. Then compare the same node on the same network at roughly the same time. Consider MTU, UDP routing, or network equipment compatibility only if some high-volume connections are affected. Do not copy a fixed MTU value from the internet and apply it to every platform. Temporarily increasing log detail can help diagnose the issue; restore the normal level after reproducing it, and remove subscription URLs, authentication details, and personal browsing records before sharing logs.
When Should You Return to the Quick Start Guide?
If you no longer know what has changed in the current configuration, back it up first. Choose one active subscription, keep just one traffic-routing method, then rebuild a known-good setup using Import a subscription and Choose a mode. Once the basic connection works, restore extensions one at a time and test after each change. This usually preserves more useful clues than resetting all network settings.
For a final check, test five things: a proxied destination, a direct destination, a LAN service, a network switch, and disconnecting traffic routing. Record the normal listening port, active configuration, mode, and permission status so you have a baseline for future changes. This guide explains the details and limitations; for specific issues, see the Troubleshooting FAQ. Once everything works, there is no need to keep changing a configuration that already meets your needs.