Kernel error messages, browsers that refuse to load pages, or a subscription that was just updated but still won't connect — the root cause almost always lies in one of five areas: whether a local port is already in use, whether the system proxy toggle has actually taken effect, whether the current node is reachable, whether DNS resolution is being hijacked or poisoned, and whether a firewall or security software is blocking the kernel process. Working through these one by one saves far more time than repeatedly restarting the client. This checklist is arranged from the inside out: first confirm the kernel itself can bind and listen on its ports, then confirm the system is actually forwarding traffic to the kernel, and finally confirm that forwarded traffic can actually reach its destination.
This article uses the Clash Meta kernel (mihomo) and mainstream GUI clients (Clash Verge, Clash for Windows derivatives, ClashX Meta, etc.) as the baseline. Command-line examples are split by Windows, macOS, and Linux. Before starting, fully quit and restart the client once to rule out transient glitches.
Step 1: Check for Local Port Conflicts
The Clash kernel listens by default on a mixed port (typically 7890), a control panel port (9090), and in some clients a DNS port (53 or 1053). If another program already occupies these ports, the kernel may fail to start or silently degrade — the client interface shows "running" but no traffic actually passes through.
Windows
netstat -ano | findstr "7890"
netstat -ano | findstr "9090"The last column in the output is the process PID. Use Task Manager or tasklist /FI "PID eq <pid>" to identify the process. If a non-Clash process is holding the port, change the mixed port to a free value like 7891 in the client settings, or terminate the conflicting process and restart the kernel.
macOS / Linux
lsof -i:7890
lsof -i:9090This lists the process name and PID listening on the port. Empty output means the kernel never successfully bound the port — check the client's log panel for kernel startup errors, commonly caused by a typo in the port field or a port number outside the valid range in the config file.
Step 2: Check the System Proxy Toggle Status
The "System Proxy" toggle in the client UI writes to the operating system's proxy settings — it doesn't control the kernel directly. A toggle showing "enabled" doesn't guarantee the OS actually adopted the setting. This commonly happens when security software resets the setting, or when multiple network configurations exist simultaneously (e.g., a VPN alongside Wi-Fi), causing the proxy to be written to the wrong network interface.
Windows Verification
reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings" /v ProxyEnable
reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings" /v ProxyServerA ProxyEnable value of 0x1 means the system proxy is enabled, and ProxyServer should display an address like 127.0.0.1:7890. If the address doesn't match the port the client is actually listening on, toggle the system proxy off and on again in the client to force a refresh.
macOS Verification
networksetup -getwebproxy Wi-Fi
networksetup -getsecurewebproxy Wi-FiIf you're on a wired connection, replace Wi-Fi with Ethernet or the matching interface name (run networksetup -listallnetworkservices first to list interfaces).
Linux Verification
Most Linux GUI clients don't rewrite system-level proxy settings directly; instead, the desktop environment or browser extensions read environment variables. Check directly:
echo $http_proxy
echo $https_proxyIf empty, the system proxy needs to be declared manually in network settings or shell config files — or switch to TUN mode to take over traffic without relying on this layer at all.
Step 3: Check Node Availability
A working system proxy doesn't guarantee a working node. This is commonly seen with expired subscriptions, temporary provider maintenance, or a selected node whose latency test shows a timeout. Recommended order: check the latency values in the client's node list first, then test the target node individually via the console.
- Latency column shows "timeout" or "N/A": the node is currently unreachable — switch to a working backup node first.
- All nodes show abnormal latency: the whole subscription is likely down, or the local network connection itself is interrupted — confirm you can reach unrestricted sites without a proxy first.
- Latency is normal but the target site still won't load: the node may be individually blocked by the target site — try switching to a different exit region.
Node connectivity can also be verified via the control panel API, provided the control port is enabled in settings:
curl -x http://127.0.0.1:7890 https://www.google.com -I --max-time 5An HTTP/2 200 or 30x status code confirms the proxy chain itself is working. If the command times out or the connection is refused, the problem lies in the proxy chain — not the browser or app — so continue investigating at the node or subscription level rather than re-checking browser settings.
Subscription providers often enforce per-account device limits. If the same subscription is active on multiple devices at once, some providers randomly reject new connections — showing normal node latency but persistent request failures. If this happens, try quitting the client on other devices before testing again.
Step 4: Check DNS Resolution
Clash supports defining custom DNS servers and enabling fake-ip or redir-host mode in the config file. If the system's native DNS conflicts with Clash's built-in DNS, common symptoms include slow-loading pages or certain domains consistently resolving to the wrong IP.
Check the Currently Active DNS
# Windows
nslookup www.google.com
# macOS / Linux
nslookup www.google.com
dig www.google.com +shortWith fake-ip enabled, results typically fall in the reserved 198.18.0.0/16 range — this is expected, since the proxy re-establishes the connection at the transport layer based on the domain name, not the resolved IP. If the result is a real public IP but the site still won't load, check whether the domain hit an incorrect routing rule that sent it to direct connection instead of the proxy.
Verify Clash's Built-in DNS Is Actually Being Used
nslookup www.google.com 127.0.0.1 -port=1053The port number must match the dns.listen field in the config file. If this command times out, the kernel's DNS module never started — check the config file for whether dns.enable is set to true and whether upstream DNS servers are reachable.
Step 5: Check Firewall and Security Software Blocking
Built-in OS firewalls, third-party security software, and enterprise endpoint management tools can all block the Clash kernel process. This kind of blocking usually produces no obvious error — the connection request is simply dropped silently — making it easy to misdiagnose as a node problem.
Windows Defender Firewall
netsh advfirewall firewall show rule name=all | findstr /i "clash"No matching results means there's no firewall rule allowing the Clash kernel through. Go to "Allow an app through firewall" and manually check both private and public network access for the client executable and kernel process (commonly named clash-meta.exe or mihomo.exe).
macOS Application Firewall
Go to System Settings → Network → Firewall → Options, and confirm the Clash client and its kernel process are set to "allow incoming connections." Some security software (e.g., corporate EDR) blocks traffic separately from the system firewall and requires being added to its own allow list.
Linux iptables / ufw
sudo iptables -L -n | grep 7890
sudo ufw status verboseConfirm there's no DROP or REJECT rule targeting the proxy port. If using TUN mode, also confirm the virtual network adapter's routing entries were written correctly — use ip route to check for a default route pointing to utun or tun0.
Full Checklist
Condensing the five steps above into a checklist you can follow directly:
- The mixed port (7890) and control port (9090) are not occupied by other processes, and the kernel log shows no port conflict errors.
- The system proxy field (
ProxyServerornetworksetupoutput) matches the port the client is actually listening on. - The currently selected node has normal latency, or you've switched to a working backup node.
curl -xtesting through the proxy successfully reaches the target site and returns a valid HTTP status code.- DNS resolution results are as expected (the
fake-iprange or a correct real IP), with no incorrect routing rule matches. - Both the system firewall and any security software allow network access for the Clash client and kernel process.
- If using TUN mode, the virtual adapter's routing entries are correctly written and not overridden by another VPN's default route.
If all seven items pass but a specific site still won't load, it's most likely that the target site itself has blocked the proxy's exit IP range or is triggering CAPTCHA challenges — a site-side policy issue, not something further local network tweaking will fix.
Save this checklist locally and work through it in order whenever a connection issue comes up, instead of randomly restarting the client, switching nodes, or reinstalling. Most connection failures get resolved after the first two steps (port and system proxy); the remaining node, DNS, and firewall steps handle the stubborn edge cases.