典型现象：系统代理有，Chrome 像没有
在 Windows 10/11 上，Chromium/Chrome 通常通过系统提供的 WinINET/系统代理表读取与系统设置一致的出网路径。但你若遇到同机多浏览器、多用户、域策略、一键优化脚本或曾手动改过「Internet 选项」里为 LAN 使用代理服务器的勾选，就会出现极难直觉定位的分叉：Clash 状态栏里显示已开系统代理、任务管理器里别的进程经代理正常，Google Chrome 却因本进程带着错误的与系统代理关系而直连到被墙目标。
另一大类是「并非没代理，而是被更高优先级参数否决」：快捷方式目标行末尾的 --no-proxy-server、--proxy-pac-url= 指向空 PAC、或 --host-resolver-rules 与 DNS/ Fake-IP 行为打架。此时你在与系统设置里看到一切正常，chrome://net-internals/#proxy 却显示 Effective proxy settings 为 direct 或与你预期不同的 PAC。结论：先以本机为当前用户有效的那一份系统代理与 LAN 为准，再查本 Chrome 可执行体上挂着的命令行，而不是只看「系统里有个开关开了」这一层皮。
下述步骤都假设你至少能在一个非 Chrome 的通道上验证 Clash 出口与订阅可更新。若连订阅都拉不动，请先到本站的 下载页核对安装包、权限与 免费订阅链接 导入方式，再回来看浏览器专层。
先定两条路：只修系统表，还是上 TUN / 显式 --proxy-server
可把它理解成与系统设置同步的两类手段：（A）让 Chrome 只读系统代理，像 Edge 一样跟随；（B）在路由或进程级强制——Clash TUN 接管默认路由，或给 Chrome 单独建一个带 --proxy-server=127.0.0.1:port 的快捷方式。路径 B 不否定 Clash 本身，只解决「Chromium 这条读表路径异常、但你又赶时间要上网」的救急。长期仍建议让与系统设置、LAN、仅当前用户 配置三者对齐，并保留还原能力，避免将来卸载 Clash 后残留不可理解的代理壳。
| 策略 | 适合谁 | 注意点 |
|---|---|---|
| 只修系统代理 + LAN | 能改设置、无强制域策略、希望与全机一致 | 在「网络与 Internet」与「Internet 属性」中成对核对，必要时与系统设置里点代理的关闭再打开，让 Clash 重写一次 |
| Clash TUN | 希望终端、UWP 与浏览器同策略；已满足管理员/驱动/冲突前提 | 见TUN 专文的 DNS 与断网；与「系统代理也开」的叠床架屋要心里有数，通常可保留其一为主 |
--proxy-server= 与可选 bypass |
怀疑策略/旧快捷方式、或需 A/B 对比某一实例 | 与系统代理二选一，避免同 URL 上双进双出；--proxy-bypass-list 要写得比直觉短，还原时删除整条目标行即可 |
第 1 步：本机/当前用户、LAN 与「还原」的边界
在 Windows 设置 → 网络和 Internet → 代理，确认是使用设置脚本 还是 使用代理服务器，并记下地址与端口。然后打开 控制面板（仍可通过搜索进入）中Internet 选项 → 连接 → 局域网设置，核对为 LAN 使用代理服务器是否与上一屏一致。历史上很多人只改新 UI、不动旧「LAN」或反过来，Chromium/Chrome 在部分版本与场景下会读到看似矛盾的那一侧。若你曾点过还原网络设置类入口，要预期与系统设置会回到无代理，再让 Clash 的「系统代理」重新写入，而不是假定 Clash 会永久占有注册表/策略。
多账户机器上，确认你是仅当前用户那套在登录。另有一类坑：用以管理员身份运行 启动的某优化工具在 HKLM 写死了直连，而 Clash 只改了 HKCU。第 1 步的目标，是把「系统认为有效的代理行」在设置页、Internet 属性和 netsh（可选） 三条目里对得上号。对不上时，先还原、再开 Clash，比只在各窗口间盲目切换更有效。
第 2 步：在 Clash 里记清 mixed/HTTP 端口并确认已写入
打开 Clash 系客户端的连接/端口/入站页，抄下本机 mixed 或 HTTP/HTTPS 代理 端口（如常见 7890、7892 等）。点一次系统代理开关的关闭再打开，或重载一次配置，让客户端重新应用 WinINET/设置应用中的项目。此步不讨论高级 YAML，只保证你接下来要对比 chrome 的「有效代理表」时，本机 127.0.0.1 上真有一个在听的口。若 SOCKS 与 HTTP 拆开，--proxy-server 通常填能承载 HTTPS CONNECT 的那一格，即 HTTP 入站，除非你知道自己在做 SOCKS5 到下游的特化；多数 Clash 用户用 HTTP 代理 127.0.0.1:混合口 即可与 Windows 代理页里为环回写下的地址、端口一致。
第 3 步：chrome://net-internals/#proxy 与「打开计算机的代理设置」
在 Chrome 地址栏进入 chrome://net-internals/#proxy，看 Re-fetch proxy settings / Effective proxy settings 是否与你在第 1、2 步里预期的一致。若这里已是 direct，而系统里明明有代理，几乎可断定是策略、命令行或某 profile 的异常，而不是 Clash 没开。再打开 Chrome 设置 → 系统，点「打开计算机的代理设置」直接跳到 Windows 与系统设置 中的同一页，避免你在浏览器子页面里改到一半。若 net-internals 里能显示 HTTP 或 PAC，而页面仍打不开的，别急着加启动参数，先与《Fake-IP 与 Redir-Host》 对照 DNS/ Fake-IP 与解析环。
第 4 步：快捷方式、企业策略、扩展——谁在覆盖 与系统代理
用资源管理器 找到你真正启动的 chrome.exe 快捷方式（开始菜单、任务栏、桌面可能不是同一个）。右键 → 属性，看目标 末尾是否带 --no-proxy-server、--proxy-server= 指向奇怪的主机、或 --user-data-dir= 指向了另一份仍含老策略的 profile。若用组策略/Intune 管理，在浏览器地址栏开 chrome://policy 搜 Proxy 相关项；若显示有来源 且为禁止代理或 fixed proxy，本地在设置里改往往会被回滚，须从企业或域管理端 调整，而非只改本机一次。
扩展方面，VPN/广告拦截/安全壳 类会注入独立 PAC 或本地 HTTP 连接。可临时在 chrome://extensions 用无痕窗口 且禁用扩展的对比，或建新用户 profile 验证「干净 Chrome 是否只跟系统」。若新 profile 即正常，就回头删除问题扩展、或清理旧 profile 中的策略残留，而不是在 Clash 里无限加规则。
与 UWP 的回环问题不同，Chrome 桌面 少踩 CheckNetIsolation，但若你曾按《Windows 11 UWP 与 Clash》 动过全机过滤，可顺带确认：过滤类驱动或安全软件没有把到 127.0.0.1 的环回连接搅乱。
第 5 步：开 Clash TUN 并核对进内核、DNS 与一条日志
在客户端里启用 TUN 模式，按你发行版要求授予管理员 或装Wintun/虚拟网卡 驱动。TUN 开启后，理论上操作系统 默认路由上未特殊排除的 TCP/UDP 会经 Clash 规则；此时 Chrome 即使不读好系统代理，只要不 被前面步骤里的 direct 或扩展 PAC 强扭，也有概率 随路由进内核。若 TUN 后反而全机断网，请按 TUN 专文 做 DNS/栈/排除名单；这属于 TUN 自身排错，不重复展开。
在有连接/日志 的视图中，对你测试的那条域名看是否命中 预期策略组。TUN 与系统代理 同时开时，注意你使用的 Clash 客户端对二者并存的说明；许多用户为简化，会只留 TUN、关闭对系统代理的自动写入，以本机是否断网、日志是否干净为准。若 TUN 已能稳定出网，一般不必再为 Chrome 加 --proxy-server，避免双重转发。
第 6 步：用 --proxy-server 显式指向环回，并会还原为干净快捷方式
当第 1～3 步仍对不上、或你暂时无法上 TUN、又必须让某一实例先通网时，给 Chrome 做独立快捷方式 最省事：在可执行体路径后空一格，追加例如 --proxy-server=127.0.0.1:7890（把数字换成第 2 步抄下的 mixed/HTTP 入站）。为减少公司内网与本地回环被误送代理，可再追加 --proxy-bypass-list=<local>;127.0.0.1;localhost 一类表项；是否还要把 10.x、192.168.x 等段写进表内，以你机房的内网规划为准。bypass 写得太长时，事后很难从现象反推「哪条该直连、哪条仍经 127.0.0.1:端口」。
用该快捷方式启动后，立刻回到 chrome://net-internals/#proxy，确认 Effective proxy settings 里出现 127.0.0.1:端口 而非 direct。若这里终于对了、页面能开，就记住：这些启动参数只作用于「经该快捷方式拉起的进程」，与任务栏、开始菜单里另一个未带参的入口可能不是同一条命。准备还原为「不依赖额外线、只信系统或 TUN」时，应删去测试用快捷方式上的整段尾缀，在 Windows 设置里对代理做「关—开」、再让 Clash 重写，并检查默认 Chrome 快捷方式的目标 行里是否还残留 --no-proxy-server 或错端口。
长期仍建议把需求收敛到 《YAML 规则分流》 的同一套策略，让浏览器、终端、游戏共享同一选路方式；相比在论坛里零星搜 --proxy-server= 拼写，能导入免费订阅链接 并在客户端里可验证、可回滚的栈，更省心。
常见问题（与结构化数据一致）
为什么同机 Edge 能走代理，Google Chrome 却像完全没开系统代理？
两浏览器安装入口、组策略、快捷方式、用户数据目录可不同。若 Chrome 的快捷方式或 chrome://policy 里出现 --no-proxy-server 或固定代理策略，会压过你在系统设置里配好的项。应对照 net-internals 的 Effective 行与策略来源，而不只看 Clash 是否显示已开系统代理。
「仅对当前用户」或还原网络/代理，会影响 Clash 写入的系统代理吗？
会。Clash 多数在当前登录用户 下写入 WinINET 与现代「代理」页。若多账户、域管策略或你刚做过系统「还原网络」，可能回到无代理。应让 Clash 对系统代理再关开一次、或重载，而不是假定 127.0.0.1:端口 永远与界面一致。
已经开了 Clash TUN，还要不要再给 Chrome 加 --proxy-server？
TUN 走路由层，理想下进程无需额外代理参数。若 TUN 已稳、日志正常，可不必加。显式 --proxy-server= 多用于暂时无法上 TUN、或要单独验证某实例是否经 127.0.0.1 入站。二者不要无目的地叠成双重转发。
--proxy-server= 后面应填 7890 还是 7891？
以 Clash 客户端里标明的本机 mixed/HTTP 代理 入站为准；--proxy-server= 通常对 HTTP/HTTPS 代理行有效。若你拆分了 HTTP 与 SOCKS，就填能承载 CONNECT 的那格，并对照一条连接日志，而不是背默认口。
小结：先分清「表上写的」和「本进程真用的」
在 Windows 上，Chrome/ Chromium 是否与系统代理 一致，不只看系统里的开关，而要看 net-internals 的 Effective 行，并核对组策略、扩展、快捷方式是否另改写了出网。你已经为 Clash TUN 和可在「设置」里逐页核对的那套系统代理项付过学习成本，就不值得用随手抄的端口号、未经核对的 --proxy-server= 把现象搅浑。把本文六步与站内 《Firefox+TUN》 一起读，会更容易看清「表上有、进程里没有」的两种栈。
相比在论坛里按零散关键词东拼西凑，在 Clash 生态里统一维护规则与客户端、用免费订阅链接 在本站下载中心 获取安装与更新，长期更稳。需要把多应用出网与分流一次理顺，可继续用 《YAML 规则》 收敛策略。
更多排查与分流见技术专栏。