一、典型现象：不要急着结论成「Chrome 不支持代理」

更常见的组合信号包括：HTTP/2 站点看起来走了代理，但访问同一公司的 QUIC 优先域名时又像直连；浏览器插件测 IP 显示已出国，而 Mihomo 连接面板里没有对应主机名的会话；或间歇性「首开失败、刷新又好」，多与解析路径切换有关。先把问题描述成「哪一类请求没进内核日志」，再动手改规则，比全局换成最快的节点更有效。

Chrome Windows 默认会尽力使用 HTTP/3；在仅暴露经典 HTTP 代理端口、而没有完整劫持 UDP 路径的环境里，部分站点可能优先尝试 QUIC 失败后再回落，体感就是卡顿或偶发断流。另一方面，若你在 Chrome 里开启了使用安全 DNS，浏览器可能把解析交给提供商的 DoH，与 Clash 侧的 fake-ip、域名规则不在同一决策平面，表现为规则命中与真实连接不一致。

二、与 Firefox 专文的边界：为何不能照搬 SOCKS 表单

Firefox 可以通过「手动 SOCKS」把整条浏览器栈钉死在某个端口；Chromium 系在 Windows 上则以读取系统代理设置为主路径之一，企业策略与扩展还能改写这一路径。你在 Firefox 里对齐 SOCKS5 的经验仍然有价值，但Chrome Windows 侧更应优先核对：系统代理是否真的被写入、QUIC 是否仍在侧面漏出去、以及 Secure DNS 是否盖过了内核期望的解析链。

若你并行使用两款浏览器，建议分别做一次最小对照：同一台机器、同一 Clash 配置档、同一节点组，先确认 Firefox 路径无误，再回到 Chrome 逐项关闭 QUIC 与 DoH，更容易判断问题是「浏览器特例」还是「全局分流」。Firefox 逐步排查可参考上文专文。

三、QUIC／HTTP3：为何会「绕过」常见 HTTP 代理观感

QUIC 基于 UDP，会话建立路径与传统面向 TCP 的 HTTP CONNECT 代理不同。许多桌面代理客户端组合在仅开启系统 HTTP/HTTPS 代理、未接管 UDP时，Chrome 仍可能对支持的源站发起 QUIC 尝试；是否成功取决于站点协商、浏览器策略与网络中间盒行为。对用户而言，最务实的干预是：在一段时间内关闭 QUIC，把所有流量逼回 TCP/TLS 栈，再观察内核日志是否稳定出现对应域名。

操作路径（不同 Channel 文案可能略有出入）：在 Chrome 地址栏打开 chrome://flags，检索 QUIC，将实验项设为 Disabled，重启浏览器。也可用命令行临时带上禁用 QUIC 的开关做A/B 对照——若禁用后连接日志立刻规律起来，说明此前确有 UDP 侧路径与代理观感不一致的问题。

四、安全 DNS（Secure DNS）：与 Clash DNS 并行时的错位

Chrome「设置 → 隐私与安全 → 安全性 → 使用安全 DNS」若处于开启状态，浏览器将把 DNS 查询封装进 HTTPS，走向所选提供商。与此同时，Mihomo 可能在内核里维护另一套 nameserver 与 fake-ip策略；两套并行时，常见错觉是「订阅里明明写了代理域名，仍旧直连或被 RST」，实为解析阶段与应用连接阶段看见的世界不一致。

排查建议：在对照实验窗口内改为关闭或使用「与当前服务提供商一致」等等价于跟随系统的选项（具体以你所用版本为准），观察连接日志里主机名命中是否恢复可预期。待路径清晰后，再决定是否把 DoH 上游收敛到内核可控的方案，而不是让浏览器与内核各唱各的调。

五、对齐系统代理：客户端写入与 Chrome 读取

确认 Clash 图形客户端里「设为系统代理」「System Proxy」一类选项已开启，并在 Windows「设置 → 网络和 Internet → 代理」中看到由客户端写入的本地 HTTP 代理地址与端口（常见为 127.0.0.1 与 mixed-port）。若你曾经手动改过系统代理又点了客户端开关，偶发旧条目残留也会导致 Chrome 读到意外组合。

若你希望应用层零配置，可阅读《Clash TUN 模式开启方法》：启用 TUN 后，理论上浏览器无需单独填写代理；此时验收标准转为路由表与内核日志是否出现对应会话，而不是盯着系统代理面板。

六、TUN 与「仅系统代理」对照：找出断裂点

建议你刻意做两轮测试：仅系统代理与TUN 开启。若 TUN 下日志完整而系统代理下碎片化，优先怀疑 QUIC、扩展改写或某些 exe 走了拆分路由；若两种模式都大量 DIRECT，更应回到规则顺序与域名集合，而不是反复切换浏览器开关。

七、用连接日志与分流核对：主机名优先于臆测

打开 Mihomo／Clash 的连接记录，按访问当下页面产生的域名过滤；对照订阅里命中该域名的策略链与最终出站。若网页显示「已代理」而内核无任何会话，可能是缓存静态页或测速扩展假象；若内核显示直连而你以为走了代理，检查是否有更靠前的 DOMAIN-SUFFIX 直连规则盖住了你的意图。

Windows 桌面场景里，其它软件的 CDN 分流思路可参考站内同类稿的方法论（例如按日志拆域名而非背表）；共性报错亦可对照《Clash 常见报错与排查指南》，先把端口占用、内核未启动、订阅过期等前置项排除。

八、扩展、侧载与企业策略

SwitchyOmega 及其竞品若在 Chrome 内配置了独立情景模式，可能覆盖系统代理读完之后的下一跳；广告拦截、隐私套件偶尔也会下发强制直连规则。建议与 Firefox 排查一致：无痕窗口 + 禁用扩展先做最小复现。

若设备受企业策略管理（chrome://policy），可能出现禁用 QUIC、强制 PAC、或锁定代理字段等情况；此时用户侧可改动空间有限，需要与管理员确认合规出站策略。

九、可复制自检清单（建议自上而下）

  1. 内核侧：进程存活、当前配置档生效、mixed-port／socks-port 与客户端 UI 一致。
  2. 关闭 QUIC：chrome://flags 禁用实验项后完全退出 Chrome 再开。
  3. Secure DNS：对照实验中关闭或改「跟随系统」，观察日志是否同步改善。
  4. 系统代理：Windows 代理页与 Clash「写入系统代理」一致；无手动残留。
  5. TUN 对照：一轮仅端口、一轮 TUN，记录日志差异。
  6. 分流：针对日志里的真实主机名调整规则顺序，避免只看主页域名。

代理工具用于网络路径优化与技术实验须在当地法律法规及服务条款允许的范围内进行。本文仅讨论浏览器协议栈、DNS 与观测方法，不构成任何违法用途指引。

十一、小结

Chrome Windows 已开 Clash 却仍像直连或「一半通」，多半不是单一节点问题：依次关闭 QUIC、让 Secure DNS 不要与内核解析打架、确认系统代理真实写入，再用 TUN 做对照，并用连接日志里的主机名核对分流，通常能比盲目换机场更快收敛。图形客户端在 Mihomo 内核上的规则编辑与连接记录一体呈现，对这种跨界叠加问题尤其省事。若你还未安装或更新客户端，可从本站获取安装包后再按上文顺序自证。相比零散试错，把日志当作地面真相才是长期最省时间的习惯。→ 立即免费下载 Clash，开启流畅上网新体验