Get the symptom right first. This is not one site failing, it is everything going quiet at once — browser, chat apps, system updates. That pattern almost always lives on your own machine and has very little to do with the quality of your nodes.

Proxy problem or network problem

  1. Turn off the system proxy switch in the client, but leave the client running.
  2. Open a page you know works and force-reload it.
  3. The page comes back: the fault is somewhere in the proxy chain, carry on below.
  4. The page still fails: fix the local network first. Flush DNS with ipconfig /flushdns, check the cable and Wi-Fi, and leave the proxy side alone for now.
If flipping the switch off restores everything, then every step from here on is about the proxy path only. Do not reset the adapter, do not reach for netsh winsock reset, and definitely do not reinstall the OS. Those turn a five-minute problem into an afternoon.
SponsoredWhere does the subscription link come from?Our partner provider gives you 1 GB of high-speed Hong Kong data at signup — import it in one click.Get high-speed nodes

Is the client actually listening on that port

netstat -ano | findstr 7890
lsof -i :7890
ss -tlnp | grep 7890

One line each for Windows, macOS and Linux; swap in whatever your mixed-port is. No output at all means nobody is listening and the core never came up. Output naming a process that is neither mihomo nor your client means something else grabbed the port — and clients usually fail silently here, with a UI that looks perfectly healthy. Move mixed-port to something unloved like 7891 and restart the core.

Does the system proxy point at the right port

Windows keeps this under Settings, Network and Internet, Proxy; macOS under System Settings, Network, Proxies. Check that the manual entry reads 127.0.0.1 plus the port the client is really using. Changing mixed-port and forgetting the system proxy is a classic: the client reports connected while the OS pushes traffic at a port with nothing behind it.

curl -x http://127.0.0.1:7890 -I https://www.cloudflare.com
curl -x socks5://127.0.0.1:7890 -I https://www.cloudflare.com

Both bypass the system proxy setting and hand the request straight to the client's port. A returned HTTP status line means the client and the node are fine and the fault is purely on the system-proxy side. A connection refused means nothing is answering on that port, so go back a section.

The port answers and pages still will not load

  • The group is empty. A failed subscription fetch, or a filter that matched nothing, leaves a group with zero nodes and traffic with nowhere to go.
  • No node is selected. A manual group may be sitting on its first entry, and that entry can be REJECT or another empty group.
  • The final MATCH rule points at a group that does not work. Everything the earlier rules did not catch exits through it.
  • Search the log for timeout, EOF, context deadline exceeded. A steady stream of those means requests are leaving but the node is not answering; try a different one.

You closed the client and now nothing works at all

This is the common one, and the most confusing. When a client crashes or gets killed from Task Manager, it never gets to put the system proxy setting back. The OS keeps aiming traffic at a port that no longer exists, so the whole machine is offline, and relaunching the client does not always clear it. Open the proxy settings and switch off the manual proxy by hand; on macOS, untick the boxes on the proxy tab. Next time, quit from the tray icon.