PLATFORM SETUP / CONFIG REFERENCE

Clash Setup Guide for All Platforms

Find installation steps by OS and troubleshoot by connection stage: subscription → configuration → listening port → traffic routing → DNS → rule matching.

Before You Start: Clients, Cores and Subscriptions

Choose What to Install and Where to Get Your Configuration

The graphical client imports subscriptions, lets you select proxy groups and changes system settings. The core listens on ports, handles protocols and matches rules; these are separate layers. mihomo is a core project, while Clash Verge Rev and FlClash provide graphical interfaces. Apps branded Clash may use different configuration implementations. For platforms covered here, start with Clash Plus, then explore other clients based on your needs. Don't assume a YAML field works just because its name appears in the software: support depends on the core in use and how the client generates its configuration.

Get a subscription URL from your service provider or a configuration file known to work. Clients generally don't include a service you can connect to. A subscription may return a complete Clash configuration or just a server list in another format; the latter cannot be used as a complete YAML file. Check which formats your provider supports. If you need to convert a subscription to Clash format, prefer a trusted local solution. Query parameters in subscription links may grant account access. Don't post them publicly or upload your full, unredacted configuration for troubleshooting.

Start with a State You Can Roll Back To

Before installing, note any existing VPN, system proxy and manual DNS settings, and temporarily quit other traffic-routing software. When multiple tools change the default route or proxy port, log errors are often symptoms, not causes. For the first connection, use one client, one configuration and one traffic-capture method. Once it works, enable extras such as launch at startup, auto-update or LAN sharing. Export a backup of existing configurations, keeping the original filenames and purpose clear so a test override doesn't become your permanent setup.

Check the system clock, available disk space and device architecture. A badly incorrect clock can break HTTPS certificate validation; the wrong installer architecture may prevent the app from running or add compatibility overhead. A failed subscription update doesn't necessarily mean the proxy is broken: a captive portal, expired URL or account may need attention. Sign in to the network and complete any required authorization before opening the client. During troubleshooting, noting what you did and the exact error text is more useful than repeatedly clicking Connect.

MethodScopeWhat to Verify
System ProxyApps that follow the system proxy settingsSystem address and port match the client's listening address and port
Per-App ProxyIndividual apps configured with a proxy manuallyHTTP or SOCKS proxy type matches
TUN / VPN RoutingTraffic routed through the virtual network interfacePermissions, routes, DNS and bypass settings

Know What a Minimal Configuration Does—and Doesn't Do

The following is only a local listening snippet for mihomo. It doesn't include nodes, proxy groups or rules, and isn't a substitute for a subscription. mixed-port accepts both HTTP and SOCKS proxy connections. Binding to the loopback address and disabling LAN access is suitable for testing on one device. The port doesn't have to be 7890, but the client, system proxy and test commands must all use the same port. Don't expose an external control interface on a first run, or bind to all network interfaces to fix a local connection issue: that increases exposure and may not solve the problem.

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

Rules in a complete configuration are generally matched from top to bottom, and processing stops at the first match. A policy name must correspond to an existing proxy group or node; don't copy example names blindly. After importing, confirm the configuration is selected and the core has started. “Download successful” only means the file was retrieved—it doesn't confirm valid syntax or that traffic is being proxied. Verify each of these states separately to avoid going in circles during troubleshooting.

Windows: Installation, System Proxy and Service Mode

Download the Right Build and Complete First-Run Setup

Choose a client from the Windows downloads. Clash Plus is the recommended starting point, followed by Clash Verge Rev, FlClash and Clash Nyanpasu. Clash for Windows is no longer maintained. Archived clients are only suitable for older environments with specific compatibility needs; for a new setup, choose a client that's still maintained. Go to Settings → System → About to check your system type, then select a matching build on the downloads page. For ARM devices, don't assume a standard desktop installer is right just because of the OS name—check the client's supported platforms first.

Install to a stable local directory. Don't run a program long-term from a temporary downloads folder, inside an archive or from a location that may be automatically cleaned up. On first launch, you may be asked to authorize firewall access or install a service; first verify the app's source and purpose. For use on this device only, you don't need to allow inbound LAN connections. If Windows blocks the app, check its source, system requirements and security software alert. Disabling all protections is not a general installation fix.

Import a Subscription and Check the Configuration and Listener

In the client's subscription or configuration screen, add a remote profile, paste the full URL and update it. If several profiles appear, select the one you just imported and check its update time and node list. If you see a profile name but no nodes, review the update log to distinguish a failed request, a login page in the response or a configuration parsing error. Don't change DNS first: if the server returned the wrong content, no parser can turn an HTML page into a valid configuration. Enter sensitive URLs only in the client, and keep them out of troubleshooting screenshots.

Choose Rule mode and select an available node in the proxy group you'll actually use. Check the local proxy port in the client settings, then enable the system proxy. In Windows proxy settings, confirm the manual proxy points to the loopback address and the same port. Some apps use their own network stack and don't follow the system proxy, so a working browser and a failing terminal aren't necessarily contradictory. Start with an explicit proxy test in PowerShell to check client connectivity separately from system-wide routing.

Test-NetConnection 127.0.0.1 -Port 7890
curl.exe -I --proxy http://127.0.0.1:7890 https://example.com/
Get-NetTCPConnection -State Listen -LocalPort 7890

The first command only checks whether a TCP connection to the port can be established; the second sends a request to a website through the proxy. Use curl.exe to avoid parameter differences caused by the same-named alias in some PowerShell environments. The third command checks whether anything is listening. If access is denied, rerun the query in an elevated terminal only when appropriate. If another program has taken the port, close the duplicate client or change the current client's port and update the system settings too. Changing only one side creates another problem.

When to Enable TUN and Windows-Specific Issues

Try TUN only after the system proxy works. Some clients require a service component and administrator permission to create a virtual interface and add routes. Service mode doesn't mean you must run the entire UI as administrator every time. Follow the client's instructions to install or start its service, check the logs for virtual device initialization, then enable TUN. If the connection drops immediately, turn TUN off to restore the previous network state and check for conflicts with security software, other VPNs or virtual adapters. Don't change the network stack, DNS and MTU all at once.

WSL, Docker and virtual machines are separate network environments. On Windows, 127.0.0.1 isn't a universal host address for them; the right way to connect depends on the network mode and system settings. If another environment needs to reach the local proxy, configure a reachable address, access controls and firewall scope. Don't expose the proxy to the entire LAN just to get one container online. For games and voice apps that use UDP, verify that the upstream supports it too—enabling TUN doesn't add capabilities to a node.

Turn off the system proxy and TUN before quitting the client. If the app exits unexpectedly and every browser reports a proxy error, open Windows proxy settings, remove any leftover manual proxy, and confirm basic connectivity is restored. Enable launch at startup and auto-connect only after verifying the entire connection path; then reboot to confirm the service is ready before the UI. After waking from sleep or switching Wi-Fi networks, reconnect the active configuration first. If that doesn't help, check routes and DNS before reinstalling and losing useful diagnostic evidence.

macOS: Chip Architecture, Network Permissions and Proxy Recovery

Choose the Right Build and Handle macOS Permissions

Check About This Mac for the chip or processor, then visit the macOS downloads. Clash Plus is the recommended choice; Clash Verge Rev and FlClash are alternatives. ClashX Meta is no longer maintained and should be treated as an archived option for compatibility. Choose the build that matches Apple Silicon or Intel. Don't overlook native architecture just because an app can launch through a compatibility layer. Check the client's system requirements too: being able to download an installer doesn't mean it can run on an older macOS version.

For apps distributed as disk images, drag the app into Applications, eject the image and launch it from the installed location. This avoids update, permission and login item references pointing to a temporary mounted volume. On first launch, verify the developer and source against the system prompt. If macOS blocks the app, read the specific reason under Privacy & Security and follow the project instructions. Don't run commands from unknown sources to remove file attributes in bulk, and never disable system-wide app security checks.

Import a Configuration and Check the Active Network Service

Add a remote subscription in the client, update it and select it as the active configuration. Then check that the proxy groups include the expected nodes. If you're using local YAML, confirm where the client reads the file and how it handles updates: some clients save an imported copy, so editing the original file won't change the running configuration. For long-term custom rules, use the client's supported override or merge feature and verify the generated configuration. Direct edits to cached subscription files are usually lost at the next update; saving a change doesn't mean it will persist.

After enabling the system proxy, check HTTP, HTTPS or SOCKS proxy entries in the network service details in System Settings. macOS proxy settings are usually tied to a specific network service, so recheck them after switching between Wi-Fi and Ethernet. The menu bar icon alone isn't enough. Use the commands below to inspect the current state, then make an explicit proxy request. These commands are diagnostic only; they don't change the system proxy. If your port isn't 7890, replace it in the test commands too.

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

scutil --proxy shows system proxy settings, but doesn't prove that every app follows them. If a browser works but command-line tools don't, check whether those tools need explicit proxy arguments or environment variables. If only one browser behaves differently, check its extensions, its own proxy settings and Secure DNS. Multiple proxy layers can cause a request to bypass the client or pass through two proxies. Reduce the test to one browser window and one terminal command, then re-enable extensions one at a time.

TUN, Helper Services and Network Changes

Enabling TUN may require a helper service, administrator authorization or a network extension; the exact mechanism depends on the client. When a system prompt appears, confirm the app name. After granting permission, check the client logs—having clicked Allow doesn't prove the service is running. If the service path points to an old app that has been removed, an update may require reinstalling the helper using the client's instructions. Permission errors and node connection errors happen at different stages: fix device creation first, then investigate rules and DNS.

macOS split DNS and network service order can affect name resolution. Company intranet domains may rely on a resolver attached to a specific interface. If internal sites stop working after enabling global traffic routing, check which DNS server handled the domain before and configure targeted resolution or bypasses as needed. Don't apply a public resolver to every case. After waking from sleep, switching hotspots or connecting a dock, interfaces and routes may change. Check the active network service before reconnecting; the underlying network may still need authentication.

Once basic connectivity is restored, decide whether to enable launch at login. A menu bar icon, a login item and a background service are three different states: seeing the UI doesn't guarantee the core loaded its configuration, and a running service doesn't guarantee the subscription updated. A reliable check includes verifying the selected configuration, proxy listener and a target request after reboot. For a client you no longer use, first quit and disable its traffic routing, then remove helper services according to its uninstall instructions to prevent old services competing for the same port.

Android: VPN Permission, Background Operation and Per-App Routing

Choose an APK and Import a Subscription

From the Android downloads, Clash Plus is the recommended choice. Alternatives include Clash Meta for Android, FlClash and Surfboard. Import formats and supported features vary by app; don't assume Surfboard supports every mihomo YAML field. Check which clients and formats your service provider supports before choosing an app. Most newer devices use ARM64, but select a build based on the device's actual architecture. Choose a universal package only if the downloads page offers one for that client.

When installing through a browser or file manager, Android may ask you to allow app installation from that source. Grant permission only to the source you're using, then revoke it in Settings if you no longer need it. If you see a signature mismatch, check whether an app with the same name from another source is already installed. Don't uninstall the only copy that holds your subscription without backing up exportable configuration and settings first. Backups usually aren't portable between clients, so save subscription URLs and custom rules separately.

Add the subscription in the app, update it and select it as the active configuration. If the update keeps spinning, pause the connection and use a network that can reach the subscription URL. Check whether the app reports an HTTP or parsing error. Some subscriptions require an existing proxy connection; follow the provider's instructions for the update route, but avoid a loop where you need the configuration to fetch that same configuration. If necessary, import it over another authorized network, then test how future updates will work.

Android VPN Routing and Background Operation

Most Android proxy clients use the system VPN interface to route app traffic. The first time you start one, Android displays a permission prompt. This VPN is an OS-level way to route traffic; it doesn't mean the protocol has become a traditional VPN protocol. Typically, only one VPN service can run in the same user profile at a time, so ad blockers, work VPNs and other proxy apps may conflict. Stop other traffic-routing apps first, then start the client and confirm both the system status bar and client log show an active service.

If the connection works for a few minutes but fails after the screen locks, check battery optimization, background activity permissions and manufacturer-specific auto-start restrictions. Allow the client to keep running in the background, and check whether Android shows a foreground service notification. Don't disable permissions required to keep the service alive just to hide the notification. Some devices also terminate apps when you clear them from Recents; whether you need to lock the app in the background depends on the device. The real test is to lock the screen for a while, reopen a webpage and confirm the client process, VPN interface and configuration are still active.

Always-on VPN and Block connections without VPN are system-level policies, not settings to enable together during initial setup. The latter blocks network access if the client hasn't started, an update fails or Android stops the service, which can look like a broken phone connection. First test after a reboot, with the screen locked, and when switching between Wi-Fi and cellular data. Then enable these policies if they meet your security needs. If you lose connectivity afterward, check the blocking policy in Android's VPN settings and disable it temporarily if needed to restore subscription updates and troubleshoot.

Per-App Routing, Private DNS and Mobile Networks

Per-app settings typically offer either “Proxy only selected apps” or “Bypass selected apps”—opposite behaviors. Check which mode is active before saving. Excluded apps won't follow the client's domain-based routing rules. If your browser is excluded, changing its domain rules won't have any effect. Start by testing one browser included in the VPN, then add more apps. System components, work-profile apps and cloned apps may run in separate environments; check whether the selected client can route each one.

Android Private DNS, browser Secure DNS and a client's built-in DNS may all affect name resolution. If DNS fails, note the original settings, compare with system Automatic DNS and the client's default configuration, then restore settings one at a time. Don't assume disabling a feature is always the right fix. Mobile networks may also use IPv6 or a different NAT path. If Wi-Fi works but cellular data doesn't, check connection logs, address family and node reachability separately instead of assuming the Wi-Fi result applies to mobile data.

Finish with a real network-switch test: connect over Wi-Fi, switch to cellular data and request the same site, then lock the screen and resume. At each step, check reachability and logs; a single connectivity test result doesn't guarantee an app will work. If only one app fails, check its per-app routing, network restrictions and protocol requirements first. If all apps fail at once, investigate the VPN service, subscription and DNS.

iOS: App Store Installation, Configuration Permissions and On-Demand Connections

Install Clash Plus and Save Your Subscription

Clash Plus is the recommended iOS client. Install it from the Clash Plus page on the App Store; see clashplus.io for product information. The iOS downloads section links to the same listing for easy comparison with other devices. Check the App Store compatibility details before installing. Confirm that your iOS version is supported and that device management policies allow the app before importing a configuration, so you don't mistake an installation restriction for a subscription issue.

Get a subscription URL supported by your chosen client, add it under configuration or subscription management, and check the update result. Screen labels may change between releases; look for the three actions: add a remote configuration, update it and select it as the active configuration. After importing, don't enable every automation feature right away. First check the server list and proxy groups to confirm the content was parsed correctly. If your provider supplies a format for a specific client only, ask them about compatibility—changing the file extension won't convert it.

When copying a URL from another device, note that messaging apps may insert spaces, truncate query parameters or turn symbols into a rich-text link. After pasting, check the protocol prefix and make sure the URL is complete, but don't show a URL with access credentials in a screenshot. Scanning a QR code with the camera reduces input errors; it doesn't verify that the content is trustworthy. Before switching subscriptions, back up the configuration name and custom rules. If multiple remote profiles are present, check which one is active—a new subscription can be updated while the old configuration remains in use.

Distinguish System VPN Status from the Actual Proxy Route

On the first connection, allow the app to add a VPN configuration. You may need to confirm with your device passcode or biometric authentication. Return to the app to check the connection, then open VPN settings to confirm which app provides it. A VPN icon means the tunnel interface is established; it doesn't prove the upstream node is reachable or that every destination uses the proxy. Next, use a browser to visit one site expected to bypass the proxy and one expected to use it, while checking any connection or rule logs the app provides.

Don't apply the desktop workflow of setting a local port and then enabling the system proxy to iOS. Apps usually handle traffic through a system network extension, and rule mode, global proxy mode and the connection toggle operate at different levels. Rule mode selects a policy based on domains, addresses or other conditions; global mode routes more traffic through the selected proxy policy. Both still depend on a working node. If switching to global mode fixes the issue, that narrows it to rule matching or policy selection—it doesn't prove DNS, permissions and the network are all configured correctly.

If the device has another VPN, content filter or organization-managed network configuration, check whether it's enabled. Managed devices may block adding or changing configurations; contact the device administrator about those restrictions. Don't repeatedly delete configuration profiles to troubleshoot: they may include work networks, certificates and access requirements. On a personal device, disconnect an old client before removing its configuration, and follow the client's instructions so you don't delete network settings that are still in use.

On-Demand Connections, Wi-Fi and Background Limits

Enable on-demand connections only after manual connections work reliably. They can start or restore a connection when conditions are met, but won't fix an expired subscription or complete captive portal sign-in for you. On hotel or public Wi-Fi, temporarily disconnect the proxy to open the sign-in page, then reconnect. After switching between Wi-Fi and cellular data, test the same destination on each network. DNS, IPv6 and carrier routing may differ, so a connection indicator in the app isn't enough to tell whether traffic works.

iOS background behavior isn't the same as a desktop process that stays in the menu bar; you don't need to keep the app open on screen. Check the system VPN status and a real network request to verify the extension is working. If it only recovers when you bring the app to the foreground, check client logs, Low Power Mode and auto-connect conditions, and note the network in use. Complex configurations, oversized rule sets or failed downloads of remote resources can also prevent the extension from starting. Test with a minimal configuration supported by your provider, then add local rules and other resources gradually.

For DNS troubleshooting, also consider browser or system privacy features that may change resolution and the network exit path. Make one reversible change at a time: note the original setting, adjust one item temporarily, reconnect and request the same destination, then restore the setting. The resolver name shown on a test page doesn't by itself prove that traffic is leaking; consider the client's routing method, DNS query path and destination connection logs too. For more details, see DNS Leak Tests and fake-ip Troubleshooting Notes.

Linux: Desktop Clients and mihomo Service Deployment

Choose Between a Desktop App and Headless Deployment

For desktop use, choose Clash Verge Rev or FlClash from the Linux downloads. Check the distribution, CPU architecture and package formats actually offered. Desktop clients suit setups that need subscription management and interactive proxy selection; standalone mihomo is a better fit for servers or routers. Don't assume that every Linux environment is the same: desktops, minimal containers and router systems can differ in graphical dependencies, permissions, service managers and available memory.

Install the graphical client using your distribution's package manager and the matching package format. If it reports a missing shared library or graphical component, read the specific dependency error; don't download individual libraries from unfamiliar websites. Import a subscription through the UI, select the configuration and test the local proxy listener. Linux desktops don't have a single system-wide proxy entry point: GNOME, KDE, terminal tools and standalone apps may each use their own settings. So “system proxy enabled” doesn't prove that every program is routed through the client.

Test Terminal and Desktop Proxy Settings Separately

The commands below affect only the current terminal and processes started from it; they don't change system-wide routes. Here, the HTTP and HTTPS environment variables both point to a local HTTP proxy. The name https_proxy describes the type of request, not a requirement for the proxy URL to use HTTPS. ALL_PROXY uses SOCKS, and socks5h asks compatible tools to resolve destination hostnames through the proxy. Support varies by tool, so check its documentation.

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

Set these temporarily first, then decide whether to add them to your shell startup file after testing. System services don't automatically inherit variables from an interactive shell, and sudo may remove them, so a command can work one way and fail another. Package managers, container builds and version control tools may have their own proxy settings; don't add another layer without noting where it comes from. To test explicitly, use curl --proxy and check whether older variables in uppercase are still set in the environment.

Test the Configuration Before Starting a Standalone Core

This example is for a systemd host and assumes you've placed a mihomo executable built for your system architecture at /usr/local/bin/mihomo. Create a dedicated account and private configuration directory, save your existing complete configuration as /etc/mihomo/config.yaml, and grant the account read access to the required files. The example doesn't enable TUN; it provides a local proxy only, avoiding elevated process permissions on first deployment. Database and rule resources also need a known source and appropriate directory permissions.

sudo useradd --system --home-dir /etc/mihomo --shell /usr/sbin/nologin mihomo
sudo install -d -m 750 -o mihomo -g mihomo /etc/mihomo
sudo chown mihomo:mihomo /etc/mihomo/config.yaml
sudo chmod 600 /etc/mihomo/config.yaml
sudo -u mihomo /usr/local/bin/mihomo -t -d /etc/mihomo

Save the configuration before running the file-permission commands; skip account creation if the account already exists. The path for a non-login shell varies by distribution, so adjust it to match your system. After the configuration passes its test, save the following unit as /etc/systemd/system/mihomo.service. Don't put subscription URLs in service startup arguments; they may appear in process listings and diagnostic output. Keep normal log verbosity initially and increase it briefly only when investigating a specific issue.

[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
UMask=0077
NoNewPrivileges=true

[Install]
WantedBy=multi-user.target
sudo systemctl daemon-reload
sudo systemctl enable --now mihomo
sudo systemctl status mihomo --no-pager
sudo journalctl -u mihomo -n 80 --no-pager
ss -lntp
curl -I --proxy http://127.0.0.1:7890 https://example.com/

This unit doesn't update subscriptions automatically or configure transparent proxying. After changing the configuration, run the syntax test again and restart the service only if it passes. If the startup log reports a port conflict, check for a desktop client or an old service before changing ports. For local use on a server, bind to the loopback address. For remote access, use a controlled secure channel with access restrictions—don't expose an open proxy to the public internet.

Configuration Troubleshooting: Follow the Request Path

Subscription Updates, Configuration Overrides and YAML Parsing

Before troubleshooting, save the last known working configuration and note the step where the current error occurs. For a failed subscription update, check the HTTP status and response type. For a configuration load error, check the line number and field. For a core startup failure, check ports and file permissions. For a destination connection failure, check the node, rules and DNS. Treating all of these as “no internet” can lead to repeatedly changing local routes when the subscription server is actually returning an error. Follow the Connected but Can't Access the Internet Checklist to work through each layer, changing one variable at a time.

YAML uses spaces for indentation; don't mix in tabs. Check list item hyphens, the space after each colon and special characters in strings. Avoid defining dns or rules more than once at the same level; don't rely on the parser to decide which block to keep. Client-side overrides may replace subscription values, so use the running configuration to determine what actually took effect. If custom rules disappear after an update, check whether you edited a remote cache and move long-term changes to the client's supported override feature.

How DNS, fake-ip and Rules Work Together

This snippet shows how mihomo DNS settings relate to TUN. Merge it into an existing complete configuration and confirm the port, permissions and core version support the settings. IPv6 is disabled here to narrow the test; that isn't a permanent recommendation for every network. dns-hijack intercepts traditional DNS requests entering the relevant TUN path. It doesn't mean encrypted DNS requests made directly by a browser are intercepted too. Verify the system proxy first. If something regresses, turn off TUN to restore a baseline for comparison.

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  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
    - tcp://any:53

fake-ip returns a mapped address so the core can retain the domain association for the subsequent connection. It doesn't spoof a node or prove that system DNS is being intercepted. Seeing a reserved test address isn't automatically an error; what matters is whether the following traffic reaches the same core. If an app has cached an old result, restart it and test again. Add a domain to the appropriate filter rules only when there's a genuine compatibility issue. Excluding every domain from the start defeats the feature.

respect-rules makes relevant DNS connections follow traffic rules. You also need to consider how the proxy server's own hostname is resolved, or you may create a dependency loop. This setting isn't a one-click fix for every DNS leak. Don't infer a simple primary-and-backup order from the names nameserver, fallback and their filter conditions. Before combining these options, read the mihomo DNS Settings Guide, understand the request path and then decide how to configure them.

Rule Matching, Protocol Support and Recovery Order

In Rule mode, put specific domains before broad geographic rules and leave a catch-all rule at the end. DOMAIN-SUFFIX needs domain information; GEOIP relies on the destination address and its database. If a request uses an IP address, a domain rule may not match as expected. The existence of a proxy group doesn't mean its current selection works—check that it points to a reachable node. If database loading fails, check the resource path or download first. For background, see GeoIP and GeoSite Database Updates.

What You SeeCheck FirstNext Step
Local Port Not ListeningConfiguration parsing, process status and port conflictsCheck the startup log; don't change system DNS yet
Explicit Proxy Works, Regular Requests FailSystem proxy, app proxy and bypass settingsCompare whether both requests appear in the connection log
Domain Fails, Direct Address WorksDNS path and resolution resultsCheck DNS logs and address family
Web Pages Work, Voice or Games FailUDP support, rules and routing scopeConfirm node protocol support and the app's traffic path
Can't Connect After Closing the ClientStale system proxy, blocking policies and routesRestore basic network access before reconnecting

Roll back in reverse order: first turn off newly added TUN or auto-connect, then clear any leftover system proxy, restore the DNS settings you recorded and confirm basic connectivity. Re-enable the minimal configuration only after that. Once the issue is reproducible, add per-app routing, rule overrides and background startup one at a time. When reporting a problem, include your OS, client name, error time and redacted logs—never share a full subscription URL or account credentials. To repeat the connection setup, return to the Quick Start Guide; for answers by symptom, visit the FAQ.