1. Confirm the Configuration and Core Are Running
Opening the Clash client window doesn’t mean the proxy core is running. On first setup, verify four things separately: the configuration loaded successfully, a local port is listening, the outbound strategy works, and the target app is actually sending connections through the proxy. Checking in this order helps prevent mistaking a port issue for a broken subscription.
This guide uses the common desktop HTTP/SOCKS mixed port 7890 as an example. It is not a universal default for every client. ClashX, Clash Verge Rev, and other clients powered by mihomo may use different settings menus and override mechanisms. Check the active configuration shown by your client and its startup logs.
- Open “Configuration” or “Profiles” in the client and confirm that a profile is selected—not merely that a subscription was downloaded.
- Open “Proxies” and check that proxy nodes and groups are available. Seeing only
DIRECTdoes not confirm that your proxy subscription is active. - Open “Logs” and check the configuration parsing results, listening address, and any startup or port-binding errors.
- Note the core type, mixed port, operating mode, and system proxy status. Change only one setting at a time as you troubleshoot.
2. Mixed Port: Check the Listening Address and Owning Process
mixed-port lets HTTP and SOCKS proxies share one local port. A browser’s manual HTTP proxy can point to it, as can apps that support SOCKS5. “Mixed” does not mean all system traffic is automatically captured, or that every app on the device will use the proxy.
Here’s a minimal configuration snippet to illustrate the fields; it is not a complete subscription that will connect to the internet as-is. Don’t add duplicate top-level keys to an existing configuration. If your client generates a configuration through overrides, make changes in the relevant override settings rather than editing a cached file that may be replaced during a subscription update.
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
For local use only, leave allow-lan: false to start. Check the logs for a listening address on the loopback interface, such as 127.0.0.1:7890. The actual binding also depends on the client and core configuration, so don’t infer the listening scope from a single toggle.
Windows: Identify the Process Using the Port
Run these commands in PowerShell. The first finds the process ID listening on TCP port 7890; the second maps that ID to a process name. Replace the example ID 1234 before running the second command.
Get-NetTCPConnection -LocalPort 7890 -State Listen |
Select-Object LocalAddress, LocalPort, OwningProcess
Get-Process -Id 1234
If another proxy app owns the port, exit that app normally or assign your current client an unused port. Don’t terminate an unfamiliar system process. If you change the port to 7891, update the system proxy, any browser-specific settings, and command-line tests as well.
macOS and Linux: Check the Listener, Not Just the Window
# macOS: Show the process listening on TCP port 7890
lsof -nP -iTCP:7890 -sTCP:LISTEN
# Linux: Show the socket listening on TCP port 7890
ss -ltnp 'sport = :7890'
You may need appropriate permissions to see some process details. If no listener appears and the logs show address already in use, check which port is actually in conflict. If the logs report a configuration parsing error, go back and locate the problem in the configuration file. Switching nodes repeatedly won’t fix a core that isn’t listening.
3. Outbound Mode: Test Rule, Global, and Direct Modes Separately
The mode controls how connections are routed after they enter the core; the system proxy controls whether an app sends its connections to the core. These are independent settings. Even in Global mode, apps that ignore the system proxy and aren’t captured by TUN may still connect directly.
| Mode | What it does | When to use it for initial troubleshooting |
|---|---|---|
| Rule | Matches rules in order and uses the policy from the first match | For everyday use; check which rule matches the target domain |
| Global | Routes connections entering the core through the selected global policy | Temporarily rules out differences in rule-based routing; still check the selected global group |
| Direct | Routes connections entering the core directly | Compare the local network path; not for testing a proxy node |
- Start in Rule mode and select a specific node in the policy group that handles the connection. This reduces variables introduced by automatic selection.
- Open the target site and check its domain, matched rule, and outbound chain under “Connections.” If you see
DIRECT, first check whether that matches your rule design. - To rule out routing differences, switch briefly to Global mode and make sure the global policy isn’t set to direct. Switch back to Rule mode when testing is done.
A successful latency test only shows that a probe received a response under those specific conditions. It doesn’t mean every site, UDP connection, or application protocol will work. If one site fails, check that connection’s logs rather than assuming the entire subscription is broken based on the latency number alone.
4. Desktop System Proxy: Check the Toggle and the Actual Address
A system proxy typically provides an HTTP proxy address to apps that support it; it is not a system-wide network tunnel. For an initial test, turn off TUN and verify the system proxy path on its own. Running a browser proxy extension, another VPN, and TUN at the same time makes the connection path harder to diagnose.
Windows 11
Open “Settings” → “Network & Internet” → “Proxy” and check “Use a proxy server.” After enabling the system proxy in your client, confirm that the address and port match an active listener, for example 127.0.0.1 and 7890. If “Use setup script” is also enabled, check whether the PAC script is influencing proxy selection so you don’t mistake its result for the manual proxy setting.
Some apps use their own proxy settings or WinHTTP configuration and may not follow this setting. The command netsh winhttp show proxy displays the WinHTTP proxy; it is not a complete reflection of the current user proxy settings in Windows. Don’t reset anything blindly just because the two differ.
macOS
On recent versions of macOS, go to “System Settings” → “Network” → your active network service → “Details” → “Proxies.” Check that Web Proxy (HTTP), Secure Web Proxy (HTTPS), and SOCKS proxy, if needed, have the right settings. Also compare the system proxy option in the ClashX menu bar with the settings for the active network service.
Run scutil --proxy to view the current proxy settings. Pointing both HTTP and HTTPS proxies to the mixed port is common. The HTTPS proxy setting usually still uses HTTP CONNECT to establish a tunnel; you don’t need to enter a local proxy address like https://127.0.0.1:7890.
Linux Desktop
For GNOME, go to “Settings” → “Network” → “Network Proxy,” select Manual, and check the HTTP, HTTPS, and SOCKS addresses and ports. Other desktop environments may use different menus, and not all programs read desktop proxy settings. The HTTP_PROXY, HTTPS_PROXY, and ALL_PROXY environment variables can also affect command-line apps separately.
5. Android, iOS, and TUN: Check Which Traffic Is Captured
Mobile clients usually capture traffic through the system VPN interface, so the desktop check of “enabling the system HTTP proxy” doesn’t apply. On first connection, an Android client will typically ask to establish a VPN connection; an iOS client may ask to add a VPN configuration. Continue only after confirming the request comes from the client you just installed and are using.
- Android: Confirm that the VPN service is running, then check whether per-app proxying, app exclusions, or selected-app-only routing is enabled. Excluded apps won’t use the expected proxy path, even if the client says it’s connected.
- iOS: Go to “Settings” → “General” → “VPN & Device Management” → “VPN” and check the active connection. To review policy groups, rules, and logs, return to the client.
- Desktop TUN: This usually requires service mode, administrator privileges, or the appropriate system permission. Check the client logs for successful creation of the virtual interface and configuration of routes; don’t rely on the toggle’s color alone.
- Other VPNs: Mobile operating systems typically restrict ordinary VPN services from running at the same time. Work profiles, device management, and per-app VPNs may have different rules. Check your device’s management requirements before switching.
After TUN captures IP traffic, routing, DNS, and app exclusions still matter. With Fake-IP, DNS requests must follow the right resolution path, and traffic to virtual addresses must be routed back through the core. Don’t change system DNS, Fake-IP, routing rules, and MTU all at once to fix one app.
If the system proxy works but TUN doesn’t, check permissions, the virtual interface, route conflicts, and DNS first. If TUN works but the browser’s manual proxy fails, check the local listener and browser settings first. This layer-by-layer comparison is more useful than reinstalling every component at once.
6. Firewall Access: Distinguish Local Use from LAN Sharing
Accessing 127.0.0.1:7890 from a browser on your computer is different from connecting to your computer’s proxy over the LAN from a phone. The first usually doesn’t require opening an inbound port to the public internet to “fix the proxy.” The second requires LAN access to be enabled in the client, a suitable listening address, and firewall access for trusted networks.
- Test on the computer itself first, with LAN sharing turned off, to rule out network isolation and inbound firewall rules.
- If you need to share the proxy, make sure the phone and computer are on the same network and can reach each other, then use the computer’s LAN address. On a phone,
127.0.0.1points to the phone itself, not the computer. - In Windows, go to “Windows Security” → “Firewall & network protection” → “Allow an app through firewall” and check the app’s access. Allow it only on trusted networks where needed; don’t also open it to public networks.
- If UFW or another firewall is enabled on Linux, add rules for the trusted source address and specific port. Don’t leave the entire firewall disabled as a permanent workaround.
Security software may also block outbound connections from the core process or TUN driver operations. Check the blocked event’s executable path and timestamp before deciding whether to allow it. An open port doesn’t guarantee a working node or successful domain resolution; verify the connection in the logs as well.
7. Verify with One Specific Request
Browsers may reuse connections, load cached content, or use a proxy extension. To test the local HTTP proxy endpoint first, run this command in a terminal. It requests a public example domain used for documentation; the result doesn’t represent the performance of any proxy node.
# Windows PowerShell: Invoke curl.exe explicitly
curl.exe --noproxy "" --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com
# macOS / Linux
curl --noproxy "" --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com
--noproxy "" prevents an existing bypass list from sending this request outside the proxy. The connection timeout is 10 seconds, with a total time limit of 20 seconds to keep the test conditions consistent. Receiving response headers means this request got a response; check in the client whether it used a proxy node or went direct. Seeing only 200 Connection established does not prove that the subsequent TLS handshake and target HTTP response completed.
| Symptom | Check first | Next step |
|---|---|---|
| Connection to local port refused | Core isn’t running, or the address or port is wrong | Check the listening process and startup logs |
| Client accepts the connection, but the outbound request times out | Selected node, node server DNS resolution, and network path | Select a specific node and retry the same destination |
| Command-line request works, but the browser fails | Browser-specific proxy, extensions, cache, and system proxy | Check which proxy source the browser is actually using |
| Browser works, but some apps fail | The app ignores the system proxy, uses UDP, or has per-app routing settings | Check the app’s settings, then test TUN separately |
Keep a Reproducible Troubleshooting Record
Record the client and core versions, operating system version, port, mode, selected policy group, and test time. If you need help, sharing the relevant error lines around that time is more useful than posting the entire log. Hide subscription URLs, tokens, node credentials, and personal network details before sharing screenshots publicly.
- The configuration loaded successfully, and a specific process is listening on the local mixed port.
- In Rule mode, you can explain which rule and outbound policy matched the target connection.
- You’ve confirmed how traffic is captured—through the system proxy or VPN/TUN—and aren’t treating them as the same toggle.
- Firewall access matches the actual need, and no stale proxy is left behind when the client exits.
Once these four checks pass, gradually enable automatic selection, LAN sharing, or more advanced TUN settings. For installation and subscription steps, see the setup guide; check specific terms in the glossary.