Proxy Connected but No Internet? Check System Proxy, DNS, and Rules

1. Distinguish Client Status from Actual Requests

A Clash client showing “Connected” may only mean that the Mihomo core is running, the system proxy is enabled, or an Android VPN interface has been established. It doesn't prove that browser requests are reaching the core or that the selected node can connect to the site you're trying to reach. Trace the request through each step: “app → local listener → rules and policy groups → outbound node → destination service.”

First, note three things: Can no websites load, or only some? Is the problem limited to the browser, or do other apps fail too? After disabling the proxy, do sites that normally connect directly work again? Retest the same full URL each time so you're comparing like with like.

2. Check That the System Proxy Actually Points to Mihomo

The system proxy tells apps that follow system settings which proxy endpoint to use; it doesn't automatically route traffic from every program. Some browser extensions, terminal tools, games, and other VPN software may use their own network settings. Temporarily disable browser proxy extensions and other proxy clients, leaving just one proxy endpoint active.

Check System Settings and the Local Address

• Windows 11: Open Settings → Network & internet → Proxy and check the address and port under “Manual proxy setup.” If you use a setup script, make sure it still controls browser traffic.
• macOS: Open System Settings → Network → your current network service → Details → Proxies. Check the web proxy, secure web proxy, or SOCKS proxy. Menu names may vary slightly between OS versions.
• Android: The system VPN indicator means a VpnService interface is active. Also check that the client hasn't excluded your browser from per-app proxying.

The examples below use 127.0.0.1:7890 as the local mixed-proxy endpoint. 7890 is only an example, not a fixed port for every client. Check the active configuration or the client's port settings for the actual value. external-controller is the control interface, not a web proxy port.

Test Without Relying on System Proxy Settings

On Windows, use curl.exe in PowerShell to avoid differences caused by an alias with the same name in older environments. On macOS and Linux, replace curl.exe below with curl. The example targets https://example.com/; if that address isn't reachable on your network, use a known-working HTTPS URL instead.

curl.exe -v --connect-timeout 10 --max-time 20 --noproxy "" -x http://127.0.0.1:7890 https://example.com/ -o NUL

On macOS and Linux, replace the output target NUL with /dev/null. --noproxy "" prevents any bypass list in your environment from affecting this explicit proxy test. The 10- and 20-second limits are troubleshooting parameters, not measured node speeds.

• If the command succeeds but the browser fails, check the system proxy, browser extensions, separate proxy settings, and cached connections first.
• If you see a connection error for 127.0.0.1, check the local port first—not DNS.
• If CONNECT succeeds but a TLS or remote connection error follows, the request has at least reached the proxy endpoint. Continue checking the outbound connection.

3. Port Conflicts and Core Startup Failures

An open client window doesn't mean the core loaded its configuration successfully. Check the core logs for address already in use, configuration parsing failures, rule set loading errors, or permission errors. If an old process is occupying the local port, your browser may even be connecting to a different proxy.

Identify the Listening Process

In Windows PowerShell, query the TCP listening port, then use the returned process ID to identify the program. These commands only query information; they don't stop any processes.

Get-NetTCPConnection -LocalPort 7890 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

Get-Process -Id 1234

1234 is an example process ID. Before running the second command, replace it with the actual OwningProcess value returned by the first. On macOS, run lsof -nP -iTCP:7890 -sTCP:LISTEN; on Linux, run ss -lntp 'sport = :7890'. You may need additional permissions to view details for processes owned by other users.

Keep the System Proxy in Sync with the Active Configuration

# Example local mixed-proxy listener; shown to illustrate the relevant fields
mixed-port: 7890
allow-lan: false
bind-address: 127.0.0.1
mode: rule

This isn't a complete subscription configuration; don't use it to replace your nodes and rules. If you change the port to 7891, update the system proxy and test command too. Some clients generate the final configuration by applying overrides or merging settings, so check the “active configuration,” not just the original subscription. Keeping the loopback address limits access to the local machine; you don't need to enable LAN access to fix local internet connectivity.

4. DNS Troubleshooting: Distinguish Destination and Node Hostnames

“DNS failure” can mean at least two things: the destination site's domain failed to resolve, or the proxy server's own hostname couldn't be resolved. The latter can cause timeouts across multiple sites even when their DNS responses are fine. When checking logs, note the exact domain involved; don't assume the node is down just because you see timeout.

Check System Resolution, Then Core Logs

nslookup example.com

nslookup usually queries the DNS server selected by the system; with TUN interception or network redirection, the request may be intercepted as well. Its results don't represent every DNS path used by Mihomo. Browser secure DNS, encrypted system DNS, and the core's built-in DNS may also take different routes.

• Check whether DNS is enabled: Confirm the value of dns.enable in the active configuration and that the configured nameserver is reachable from your current network.
• Check encrypted DNS dependencies: DoH or DoT upstreams specified by hostname need a working bootstrap resolution path. default-nameserver can resolve DNS server hostnames, so check how it relates to your upstream addresses.
• Check proxy node resolution: proxy-server-nameserver is used to resolve proxy node hostnames. If it's configured, make sure those resolvers are available; otherwise, the node may depend on itself to resolve its hostname before it can connect.
• Check rule dependencies: If settings such as respect-rules make DNS connections follow routing rules, review the associated proxy and direct resolvers too. Avoid creating a circular dependency between DNS resolution and proxy routing.

After switching from Fake-IP to another resolution mode, apps may still hold old addresses. On Windows, run ipconfig /flushdns to clear the system cache, then fully close and reopen the browser. Clearing the system cache doesn't necessarily clear the browser's own cache, DoH cache, or existing connections. Make a new request and compare it with the logs.

Don't change the DNS mode, every upstream, and the TUN setting all at once. First confirm one known-working resolution path, then restore settings one by one. For field definitions, see the DNS configuration guide.

5. Rule Matches and Policy Groups: Check the Actual Route, Not Just the Mode

Mihomo's rule mode evaluates rules in order. Usually, the first matching rule determines where a request goes; the final MATCH catches requests not handled by earlier rules. If an earlier rule sends the destination domain to DIRECT, a later proxy rule won't reroute it.

Check These Four Details in the Connection View

1. Does the destination domain and port match the site you just tested? HTTPS usually uses TCP 443.
2. The matched rule type and rule content, especially domain rules, rule sets, and fallback rules.
3. The policy group that matched, and the node or DIRECT ultimately selected by that group.
4. Whether the failure occurred during resolution, dialing, the proxy handshake, or TLS.

Clear the connection list in the client or note the test time, then open the target site once. If a reused connection makes the result hard to interpret, close that connection and try again. A policy group name is only an entry point; groups may be nested, so trace the route to the final outbound node.

Use Global Mode Only for a Brief Comparison

Temporarily switch to Global mode and explicitly select a node. If the same destination works in Global mode but fails in Rule mode, focus on rule order and policy group selection. If both modes fail, continue checking the node and network. Global mode won't fix a dead node or automatically capture traffic from apps that never reach the core.

Failed rule set downloads can also affect configuration loading or routing. Check the rule-providers update logs and local cache status. Don't delete all your rules just to get a website working temporarily; identify the specific matched rule, then adjust only the necessary order or policy. Restore Rule mode when troubleshooting is complete.

6. Node Availability: A Latency Reading Doesn't Guarantee Website Access

A latency test is a single probe to a specific test URL, at a specific time, over your current network. A latency reading doesn't mean other domains, video services, or UDP traffic will work. A node appearing in the list also doesn't mean its subscription address, port, or credentials are still valid.

• Try a different node on the same network: Keep the browser, destination URL, and proxy mode unchanged; switch only the node. If another node works immediately, check the original node or its server status first.
• Try a different network with the same node: Switch from Wi-Fi to a mobile hotspot and revisit the same destination. If the result changes, investigate the network's DNS, firewall, or routing conditions.
• Check when the subscription was last updated: Confirm the update succeeded and the client isn't still using an old cache. After updating, check whether client overrides are replacing node settings.
• Check protocol settings: For a manual configuration, verify the server address, port, authentication, TLS server name, and transport settings. Which fields are required depends on the protocol; don't copy settings from a different protocol.

connection refused commonly means the destination port isn't listening or the connection was actively rejected. i/o timeout means the request timed out; that line alone can't tell you whether the server failed or packets were dropped somewhere along the network path. For certificate errors, check the system clock, destination domain, and TLS settings. Don't hide handshake errors by permanently skipping certificate verification.

If only a login page or a particular site fails, check the HTTP status code returned by the site. 403, 429, or an account restriction isn't the same as a local proxy port that won't start. First confirm the response came from the destination service, then consider exit IP policies or restrictions imposed by the site.

7. Additional Checks for TUN, Per-App Proxying, and Browser Protocols

If an explicit HTTP proxy test works but access fails with TUN enabled, that distinction is useful. TUN depends on a virtual network interface, routing, and permissions. If tun.auto-route, interface detection, or DNS hijacking is enabled, check for conflicts with other VPNs, virtual machine networks, and security software.

Isolate the TUN Path on Desktop

1. Note the current TUN and system proxy settings, then temporarily disable TUN.
2. Use only the explicit proxy command above to test the same URL and confirm the local endpoint and node connection.
3. If the explicit proxy works, re-enable TUN and check the startup logs for permission issues, virtual interface creation, and route updates.
4. If direct access still fails after closing the client, check for leftover system proxy settings, other VPNs, and routing issues. Don't blindly delete system routes.

Check Whether Android Is Routing the App

Android usually allows only one regular app VPN service to be active at a time. Switching to another VPN, an ad-blocking VPN, or a network tool in a work profile may replace the original client. In per-app settings, “Only proxy selected apps” and “Bypass selected apps” mean opposite things; make sure the browser is in the intended list. If the problem starts only after the screen locks, check background restrictions and battery optimization before rewriting rules.

Check HTTP/3 Only If the Browser Is the Problem

HTTP/3 uses QUIC, which typically involves UDP 443. A successful explicit HTTP proxy command doesn't prove the browser's QUIC path is working. If the issue is clearly limited to the browser, temporarily disable HTTP/3 for comparison. If that changes the result, investigate UDP outbound traffic, node support, and TUN routing. Disabling the protocol isn't a universal fix for website access problems.

8. Restore Settings and Prepare a Minimal Issue Report

Once you've identified the failing layer, restore temporary changes one by one, including Global mode, DNS upstreams, and browser protocol settings. Keep only changes that actually solved the problem. Retest a site that connects directly, one that requires a proxy, and the original failing destination. Finally, check that the system connects as expected after closing the client.

If you still need to report the issue, the information below will make it easier to diagnose than a screenshot that just says “Connected.” Include only the log excerpts needed to reproduce the problem, and don't expose subscription credentials, node passwords, or control interface tokens.

• Operating system version, client version, actual Mihomo core version, and whether client overrides are in use.
• Whether the system proxy or TUN is enabled, local listening address and port, and per-app proxy settings.
• When the issue occurred, destination domain, network in use, and whether all destinations fail.
• Result of the explicit proxy command, matched rule, final policy group, and selected node.
• Which of the node change, network change, or TUN disable tests changed the result.