Classify the failure before you touch YAML

Start by writing down three observable facts: what IP or geolocation the browser shows, whether Clash’s dashboard registers new connections when you open a new tab, and whether any other Chromium derivative on the same Windows user profile behaves differently. If Clash logs stay flat while Chrome loads a site, you are not debating rule quality—you are debating whether Chrome is even reaching the local forwarder. If logs spike but the page still shows the wrong country, you are in DNS, exit selection, or split-routing territory, and you should pivot to our YAML policy tutorial after you confirm the browser is actually attached to Clash.

Windows makes this confusing because “system proxy” is not one switch. Clash Meta–style GUIs typically flip the active WinINET profile for the interactive user, exposing HTTP and SOCKS listeners on 127.0.0.1. Chrome consults that dictionary, but only when no higher-priority override—command line, managed policy, or extension—is in play. Firefox users saw the same conceptual split in our companion article: the OS says one thing while the application stack insists on another. Chrome’s override mechanisms are simply more entangled with enterprise tooling and shortcut hygiene.

Sixty-second proof Open an Incognito window with all extensions disabled and load the same test URL. If Incognito suddenly follows Clash while normal windows do not, promote extensions and profile-specific PAC scripts to the top of your suspect list before enabling Clash TUN.

Step 1: Confirm Windows is really proxying the current user

Open Windows Settings → Network & Internet → Proxy (or the legacy “Internet Options” dialog if you still rely on it). Verify that “Use a proxy server” is on and that the address and port match what Clash publishes—commonly 127.0.0.1 with an HTTP port such as 7890 and a separate mixed or SOCKS port elsewhere. If you recently toggled Clash off and on, confirm you did not leave a stale manual configuration pointing at a dead listener.

Pay attention to scope. Many school and corporate images apply machine-level proxy defaults through Group Policy that differ from the interactive user’s WinINET keys. If you are on a shared PC, log out and test under a clean account. If you are on your own hardware but run elevated installers frequently, remember that services and scheduled tasks may execute under accounts that never inherited your per-user proxy toggle. Chrome almost always runs as you, so the relevant surface is the profile you used to launch Explorer or the Start menu shortcut—not an Administrator shell from years ago.

When Clash offers a “PAC” or automatic configuration URL, paste the same string into Windows’ “Use setup script” field only if you intend to maintain it. Mixed setups—manual proxy plus PAC—are a frequent source of “works for five minutes” reports. For home labs, prefer the straightforward manual proxy row that your GUI writes when you click System Proxy, then document the port numbers in a note so future you does not chase ghosts.

If you need to restore settings to a known-good baseline, disable the manual proxy in Windows, quit Clash completely, reboot once if drivers were touched, then re-enable system proxy from the GUI so it rewrites the keys atomically. That sequence is boring and effective; skip it only when you are deliberately bisecting a corporate policy conflict.

Step 2: Inspect Chrome’s own proxy page

Navigate to chrome://settings/system and click “Open your computer’s proxy settings.” Chrome is not being lazy—it is acknowledging that on Windows the authoritative configuration still lives in the OS dialog you verified in Step 1. If that button opens a blank or grayed-out panel, your organization may be locking the UI while still injecting settings elsewhere. Note the state, then continue to policy checks in Step 4.

For users who once experimented with Chrome’s deprecated built-in proxy UI, remember that modern Chrome expects the OS path first. If you previously installed a third-party “profile manager” that launches Chrome with wrappers, those wrappers may prepend flags you forgot about. Searching your Start menu for every Chrome shortcut and choosing Properties is tedious but cheaper than a weekend of packet captures.

While here, confirm you did not enable VPN-like features inside Chrome that tunnel DNS separately from Clash. Secure DNS settings can make it look like “the proxy failed” when in reality the resolver succeeded through a different path. Align Secure DNS with your threat model: either off for debugging or pointed at a resolver that matches your Clash fake-ip expectations, as described in our DNS mode comparison.

Step 3: Extensions, PAC scripts, and “smart” proxies

Return to the Incognito test from the classifier. Extensions with host permissions can reorder proxy logic for subsets of traffic. Some consumer VPN brands ship Chromium extensions that hard-code direct connections for “split tunnel” domains; others inject PAC files that conflict with Clash’s domestic-direct / foreign-proxy YAML story. Disable every extension that touches the network, then restart Chrome normally—not only Incognito—to see if behavior normalizes.

If you manage a developer machine, scrutinize ad blockers and privacy suites that ship their own filtering proxies. They often listen on localhost and forward to Clash, which sounds clever until port numbers drift after an update. When in doubt, remove the extension temporarily rather than toggling half its switches.

Document what you changed. The goal is not to run Chrome bare forever—it is to know which layer was lying so you can reintroduce tools deliberately. Users who skip this step and jump straight to Clash TUN sometimes “fix” Chrome while silently breaking an internal portal that depended on a PAC exception.

Step 4: Read chrome://policy like an IT admin

Open chrome://policy and scan for keys containing “Proxy”. ProxyMode, ProxyServer, ProxyPacUrl, and ProxyBypassList are the usual suspects. A managed browser will show “Source: Platform” or similar, meaning the operating system or domain controller pushed values Chrome must obey regardless of what WinINET appears to say in the Settings app.

On personally owned PCs, stray policies sometimes remain after uninstalling MDM agents or “school” Chrome builds. Clearing them may require deleting registry keys under HKLM\Software\Policies\Google\Chrome (and the WOW6432Node mirror) or running the official policy cleanup guidance from your organization—do not randomly edit the registry without a backup.

If you are on a legitimate enterprise device, do not fight IT with hacks. Instead, ask for an exception or use a profile that is not policy-bound for lab work. Clash TUN may still be disallowed by deeper network inspection; recognize that boundary early.

Step 5: Audit shortcuts for --proxy-server and friends

Right-click every Chrome shortcut you actually use—taskbar pins count—and inspect the Target field. Chromium accepts a family of networking flags that override WinINET:

  • --proxy-server=http://127.0.0.1:PORT forces an explicit forwarder. Useful when debugging, dangerous when the port is wrong.
  • --proxy-server=socks5://127.0.0.1:PORT mirrors the same idea for SOCKS-only workflows.
  • --no-proxy-server disables proxying entirely regardless of OS settings—classic after copying a shortcut from a forum post.
  • Less common but relevant: --winhttp-proxy-resolver changes how some builds consult WinHTTP; leave it alone unless you know why it was added.

Remove experimental flags, apply, fully exit Chrome (check the system tray), and relaunch. If Chrome was pinned while a flag was present, Windows may have cached the command line; unpin and repin after cleanup.

When you intentionally want Chrome isolated from flaky OS proxy state, a minimal --proxy-server pointing at Clash’s HTTP or mixed port is a valid crutch. Pair it with Clash’s “Allow LAN” guidance if you also need other devices—our LAN sharing tutorial covers the firewall side. Document the flag so future you remembers why Chrome behaves differently from Edge.

Step 6: Enable Clash TUN when the browser stack refuses to cooperate

Clash TUN creates a virtual adapter and steers eligible IP traffic through the Meta core before individual applications get to argue about WinINET. For Chrome specifically, TUN is the reliable answer when policy or extensions make the high-level proxy path untrustworthy, or when you need the same capture semantics as games and Electron apps that never respected system proxy.

Turn on TUN from your maintained GUI, accept the administrator prompt on Windows, and verify the adapter appears in ncpa.cpl. Then re-run your browser test while watching Clash logs: you should see session rows even if Chrome’s internal proxy page still reads ambiguously. If the entire machine loses connectivity, stop immediately and follow the rollback order in our desktop TUN guide—the failure is usually DNS hijack alignment or a second VPN fighting for the same routes.

Align TUN with your YAML: keep domestic CDNs and bank domains on DIRECT lanes, put foreign SaaS into named policy groups, and ensure MATCH is not accidentally sending everything to a dead node. TUN magnifies configuration mistakes because more traffic hits the stack. If you are new to ordering rules, spend ten minutes in the YAML article linked above before blaming the tunnel.

Remember that TUN does not replace thoughtful split routing—it exposes more of your traffic to whatever rules you already wrote. Pair TUN with the DNS mode that matches your LAN: corporate users may need redir-host realism, while home users on aggressive fake-ip profiles should verify local names still resolve. The intersection of TUN plus wrong DNS produces “Chrome loads Google but not the router page” mysteries that are tedious until you draw a simple table of which resolver owns which query.

Sidebar: localhost listeners and UWP-style isolation

Some Chrome-adjacent tooling (PWAs, helper apps) still bumps into Windows’ loopback rules. If only packaged apps fail while classic Chrome works, review our UWP loopback article before you assume Chromium itself is broken. The symptom family looks similar—proxy toggles yet traffic misroutes—but the fix starts with CheckNetIsolation, not a new subscription.

Multiple Chrome profiles, channels, and side-by-side installs

Power users often run Chrome Stable, Beta, and Canary together, or keep a legacy “work” profile beside a personal one. Each shortcut can point at a different user-data directory and therefore a different extension set, policy inheritance path, and remembered experiment flag. When someone says “Chrome ignores the system proxy,” the first clarification question should be: which executable and which profile badge in the title bar?

If Stable obeys Clash but Canary does not, compare their respective shortcuts rather than Windows proxy panels. Canary frequently inherits test flags from older sessions; wiping the Canary profile is acceptable when it is not your daily driver. Conversely, if only one Windows user account shows the bug, export the relevant portion of chrome://policy from both accounts and diff them—IT sometimes applies per-user GPO filters that are invisible from an admin console you cannot access.

Portable Chromium builds and third-party repacks deserve skepticism. They may ship a default master_preferences or an embedded policy template that pins direct mode for “performance.” Replace them with signed builds from Google when possible, or at least read their documentation before you spend hours tuning Clash YAML that never executes.

Finally, remember that signing into Chrome with a managed Google Workspace account can layer cloud policy on top of Windows policy. The UI will tell you when the browser is “managed.” In that situation, local WinINET tweaks still matter for other apps, but Chrome may follow Google Admin console rules first. Escalate to the workspace administrator instead of chasing registry keys you are not authorized to change.

Verification checklist you can print

After each step, record pass/fail so you do not circular-debug:

  1. Windows manual proxy matches Clash ports for the same user session.
  2. Incognito-without-extensions matches signed-in Chrome behavior—or explains the delta.
  3. chrome://policy shows no surprise Proxy* rows.
  4. No shortcut injects --no-proxy-server or a stale --proxy-server.
  5. With TUN on, Clash logs show new flows for the test domain and the public IP matches expectation.
  6. Rollback path documented: disable TUN, remove flags, restore Windows proxy defaults.

If you pass all six rows and still see odd routing, capture a HAR or net-export trace before editing rules. Guessing wastes time when the browser already told you which handler won.

Closing thoughts

Chrome on Windows is not allergic to Clash; it is allergic to contradictory instructions. Clean the WinINET layer, eliminate extension and policy overrides, audit shortcuts for launch flags, then promote Clash TUN when you need IP-layer certainty. That sequence preserves domestic-direct goals, respects enterprise boundaries, and keeps your subscription URL debugging separate from browser mythology.

Compared with ad-hoc proxy helpers, a maintained Meta-based client gives you one place to manage ports, TUN, and logs—less whack-a-mole when Chrome updates weekly. → Download Clash for free and experience the difference — import a fresh subscription, enable system proxy for quick validation, then add TUN only when you have proven the browser stack is not overriding you.

Keep our tech column bookmarked for YAML and DNS pairs; browser fixes mean little if MATCH sends the wrong exit.