Why “No Internet” Appears After Clash Exits

Clash is not only a YAML engine—it is an orchestration layer that often asks the operating system to cooperate. When you enable system proxy, the OS stores HTTP, HTTPS, and SOCKS endpoints that many applications query through WinINet on Windows or CFNetwork on macOS. When you enable TUN mode, the client installs a virtual interface, adjusts routes, and sometimes registers filters so traffic can be steered before it hits your normal default gateway. If the client shuts down gracefully, well-behaved builds clear those hooks. If the process crashes, is force-killed during an upgrade, or an auto-update swaps binaries mid-flight, the teardown routine may never run.

The user-visible symptom is maddeningly uniform: web pages time out, app stores spin, and chat clients report offline, yet the Wi‑Fi or Ethernet indicator still shows connected because Layer 2 is fine—it is Layer 7 that is pointed at 127.0.0.1:7890 (or another local mixed port) where nothing listens anymore. Corporate laptops add another twist: MDM profiles can reapply proxy entries you thought you deleted, so the fix appears to “revert” until you find the policy owner. This guide stays on consumer-controlled machines; if a device is managed, escalate to IT after you collect screenshots of the stuck proxy fields.

Mentally separate three failure buckets. First, system proxy residue—the OS still forwards cooperative apps to a dead loopback service. Second, routing and TUN residue—a virtual interface or custom route sends packets into a black hole. Third, DNS or secure DNS overrides—browsers resolve names through a path that depended on Clash’s DNS stack and now returns nonsense. You can chase them in that order because proxy checks are fast and non-destructive, while adapter surgery should be last.

Scope note: This article complements the TUN deep dive and macOS extension approval guidance, which focus on making tunnels work while Clash runs. Here we assume Clash is not running and you need the OS defaults back.

Two-Minute Triage: Proxy, Routes, or DNS?

Start with a terminal that inherits your interactive profile. On Windows, open Windows Terminal or cmd.exe; on macOS, open Terminal.app. Run a trivial DNS lookup such as nslookup example.com or dig example.com +short. If name resolution fails instantly, suspect DNS before you uninstall adapters. If names resolve but HTTPS fails, try curl -I https://example.com (Git for Windows ships curl; macOS includes it). When curl reports connection refused to a loopback address, you have strong evidence of a stale proxy or a redistributed local forwarder.

Compare against a browser that uses its own secure DNS. Chrome’s “Use secure DNS” can bypass ISP resolvers while still honoring OS proxy toggles—mixed symptoms are normal. For a cleaner experiment, temporarily launch the browser with extensions disabled and secure DNS set to “with your current service provider” while you clean the OS layer. Document what you change; the worst debugging sessions are the ones where three panels disagree and you forget which toggle was original.

If you recently followed a Windows 11 + TUN setup walkthrough, assume both system proxy and TUN might be enabled together. That combination is powerful for coverage but increases the surface area for partial teardown—exactly the scenario this article addresses.

Windows 11: Settings Proxy and Manual PAC Cleanup

Open Settings → Network & internet → Proxy. Turn Use a proxy server off unless you intentionally rely on an corporate forwarder. If the switch keeps returning on, note the address: Clash derivatives often populate 127.0.0.1 with ports like 7890, 7897, or 9090. Clear the fields entirely after disabling. Scroll up and inspect Automatically detect settings and Use setup script; a leftover PAC URL pointing at a local file or http://127.0.0.1/... can outlive the app that served it. Remove suspicious script URLs and apply changes, then reopen the page to confirm nothing rehydrated from another policy source.

Repeat the check for each physical interface if you frequently switch between Wi‑Fi and Ethernet; Windows can store per-network profiles, and one interface may still carry a manual proxy while the other is clean. After edits, restart the browser completely (not only close tabs) because Chromium caches proxy decisions for running processes.

Windows: Legacy Internet Options and Per-User Surprises

The modern Settings UI does not always mirror every WinINet knob. Launch inetcpl.cpl from Win+R, open the Connections tab, click LAN settings, and verify that automatic configuration and manual proxy are both cleared unless required. Some Clash GUIs write here for compatibility with older enterprise apps. If you see a grayed-out checkbox, another user profile or policy may own the value—log out of secondary accounts or inspect with an administrator session.

Edge and Internet Explorer historically shared this stack; even if you never open IE, components of the OS still consult these fields. Treat this step as mandatory, not nostalgic.

WinHTTP Proxy: When Services Ignore the Settings App

Windows services and parts of the update stack consult WinHTTP proxy, which is independent from the per-user WinINet dialog. Open an elevated terminal and run netsh winhttp show proxy. If you see a direct access message, you are clean. If you see a proxy pointing at loopback, reset it with netsh winhttp reset proxy after you confirm no legitimate enterprise tool requires a WinHTTP forwarder. Some Clash installers import WinHTTP settings to help background updaters; a crash between import and cleanup leaves services talking to nowhere, which surfaces as “Windows Update works oddly” while the browser—using a different path—also fails.

After resetting, reboot once if Windows Update or Store still misbehave; the Background Intelligent Transfer Service caches handles aggressively. This is normal operational friction, not a sign you need to reinstall Windows.

Elevated commands (illustrative)
netsh winhttp show proxy
netsh winhttp reset proxy

Environment Variables, Dev Tools, and Scheduled Tasks on Windows

Developer shells frequently export HTTP_PROXY, HTTPS_PROXY, and ALL_PROXY. If your Clash client or a helper script appended those variables system-wide, every tool that respects them—including git, npm, pip, and winget—will continue to route through a dead port after Clash exits. Open Settings → System → About → Advanced system settings → Environment Variables and remove stray entries from both user and system lists. Then close all terminals and reopen so child processes inherit a clean environment.

Inspect scheduled tasks that might reapply proxies at logon. Some tuning scripts write a scheduled action to re-run netsh or import registry keys. Task Scheduler is tedious but authoritative—search for tasks mentioning “proxy” or your client name. If you find one, disable it until you understand why it exists.

TUN on Windows: Adapters, WFP, and Driver Leftovers

After clearing proxies, if pings to well-known IPs succeed but TCP to port 443 on arbitrary hosts fails, return to routing. Open ipconfig /all and look for adapters named after Wintun, TAP, Meta, or your GUI vendor. If an adapter remains with an odd gateway or a small RFC1918 subnet pointing nowhere, disable the adapter from Control Panel → Network Connections or the modern adapter list, then reboot. Only uninstall drivers if you know the package; prefer the client’s own “Remove TUN” or repair option first.

Windows Filtering Platform (WFP) diagnostics are advanced; if you suspect a half-removed filter, rebooting after a clean uninstall usually restores order faster than manual WFP edits. Keep third-party “internet accelerators” uninstalled while testing—they often register competing filters that resemble Clash failures.

macOS: System Settings Proxies and Hidden Profiles

Open System Settings → Network, select the active service (Wi‑Fi or Ethernet), open Details… → Proxies, and uncheck Web Proxy (HTTP), Secure Web Proxy (HTTPS), SOCKS Proxy, and Automatic Proxy Configuration unless your organization requires them. Clear any URL fields that reference 127.0.0.1 or a local PAC. Apply the changes, then toggle Wi‑Fi off and on to force CFNetwork-capable apps to reload settings.

If fields repopulate immediately, open System Settings → Privacy & Security → Profiles (if present) and look for configuration profiles that enforce proxy or PAC. MDM-managed Macs may require administrator removal. For advanced inspection, scutil --proxy in Terminal prints the live dictionary the system is using—useful screenshots for support tickets.

macOS: TUN, utun, and Network Extension Cleanup

macOS exposes tunnel interfaces as utun* entries. After quitting Clash, run ifconfig and note interfaces that persist with no corresponding VPN app. If your GUI crashed, use the client’s own disconnect routine after relaunching it once in a controlled way; if that is impossible, rebooting macOS clears most user-space tunnel states tied to Network Extensions. Avoid deleting kernel extension remnants manually on Apple Silicon—use vendor uninstallers.

If you recently approved a Network Extension for Clash, revisit the macOS TUN approval article for the permission flow; this section assumes permissions were once valid but shutdown order went wrong. After a reboot, re-open your client and disable TUN before uninstalling if you intend to remove the app entirely.

Browsers, Secure DNS, and Extensions That Mimic VPNs

Chromium-based browsers can pin DNS-over-HTTPS providers and ship extensions that start mini VPNs. After cleaning the OS, test with a fresh user profile or incognito window with extensions disabled. Safari’s Private Relay and third-party “security” suites can also change egress independently of Clash; pause them temporarily to avoid false negatives while you validate OS defaults.

For policy questions that span DNS modes and fake-ip, the FAQ remains the quickest cross-link when Clash is running again; during offline recovery, prioritize turning secure DNS features back to system default so resolvers match what scutil --dns reports.

Verification: curl, ping, and DNS Sanity Checks

After each cleanup phase, run the same three probes: ICMP or TCP reachability to a well-known host, HTTPS HEAD via curl, and DNS resolution against both system resolver and a public resolver for comparison. Mismatches between the last two implicate split DNS or browser overrides rather than proxy residue. Keep notes; if you escalate to forums, “proxy fields empty, WinHTTP direct, curl works, Chrome fails” is a precise story that invites accurate answers.

When Clash is running again, timeout and TLS log patterns help confirm upstream health—distinct from the local-loop failures discussed here.

  1. Confirm Clash is fully quit (check Task Manager / Activity Monitor).
  2. Clear Windows Settings proxy + LAN dialog + WinHTTP as needed.
  3. Remove user/system proxy environment variables; restart shells.
  4. On macOS, clear Network service proxies and check profiles.
  5. Reboot if virtual adapters or extensions look half-attached.
  6. Verify with curl and DNS tools before blaming ISP outages.

Preventing Sticky Proxies Inside Your Clash Client

Modern GUIs expose toggles such as Set system proxy and TUN mode. Prefer clients that restore previous OS proxy values on exit instead of blindly overwriting with blanks. If your workflow allows, use either TUN or system proxy for daily driving—not both—so teardown has fewer moving parts. When upgrading, close the old build completely before launching the new binary, and temporarily disable auto-start entries that might launch a half-configured instance at boot.

Choosing a maintained distribution matters; see how to choose a Clash client for features like graceful shutdown hooks and visible adapter state. Open-source transparency for troubleshooting is separate from downloading installers—refer to project repositories for issue trackers when you need to file a bug about cleanup regressions, but keep installer acquisition on this site’s download page for consistency.

Policy: Do not use these steps to bypass workplace or school network controls. Running or removing tunnel software may violate acceptable-use policies; obtain permission before changing managed devices.

Wrap-Up: Restore the Default Path, Then Re-launch Cleanly

No internet after Clash exits is rarely a mystery ISP outage—it is usually system proxy residue, WinHTTP drift, or a TUN adapter that survived a crash. Clear Windows 11’s Settings and legacy dialogs, reset WinHTTP when services behave oddly, scrub environment variables dev tools inherit, then mirror the same discipline on macOS with Network service proxies and extension-aware reboots. Verify with curl and DNS before you reinstall drivers or chase unrelated Wi‑Fi gremlins.

Compared with opaque one-click “VPN” utilities, explicit Clash setups reward you with inspectable knobs—but that visibility implies responsibility for putting interfaces back to defaults when the core stops. Keeping cleanup steps repeatable saves time the next time an update interrupts the graceful shutdown path.

Download Clash for free and experience the difference—pick a client that surfaces proxy and TUN state clearly, then recover faster when something interrupts a clean exit.