Clash Verge 开了系统代理浏览器不走代理：按日志和端口排查

更新于 2026-10-27 · netcli.net

简答：Clash Verge 开启系统代理后浏览器不走代理，先看连接面板：无浏览器日志，查浏览器代理、系统代理和端口；有日志，查 DIRECT 规则、代理组、节点、DNS 与安全软件。

定义：Clash Verge 的系统代理模式，是把操作系统或浏览器的 HTTP/HTTPS 代理指向客户端当前监听地址；它不同于通过虚拟网卡接管系统流量的 TUN 模式。

先看连接面板：30 秒判断浏览器是否进入 Clash Verge

先不要重装客户端，也不要立即修改 DNS。打开 Clash Verge Rev 的“连接”或“日志”面板，保持面板可见，再用同一个浏览器访问一个平时可测试的网页。

现象	初步判断	下一步
完全没有浏览器请求，流量统计也没有对应变化	浏览器没有使用系统代理，或系统代理指向了错误端口	检查浏览器代理模式、Windows 代理地址和监听端口
出现请求并显示 DIRECT	浏览器已经进入客户端，但当前规则选择了直连	检查规则模式、规则顺序和代理组选择
出现请求但提示 connection refused	本地代理端口没有监听，或端口填写错误	用 `netstat -ano` 检查监听进程并重新对齐端口
出现请求但 timeout 或网页打不开	代理入口已生效，问题转向节点、DNS、规则或安全软件	查看该请求详情和内核日志，再更换一个已配置节点对照
系统代理不工作但 TUN 正常	更像是浏览器代理、系统代理写入、端口或 PAC 问题	按本文的端口、浏览器和环境变量顺序排查

Clash Verge Rev 的设置文本把 System Proxy 定义为修改操作系统代理设置，并说明 TUN 模式会接管系统流量，启用 TUN 后通常不需要同时开启系统代理。可参考 Clash Verge Rev 设置说明。

第一步：核对 7890、7897 与当前实际监听端口

不要把某个端口当成永久固定值。mihomo 官方端口文档示例使用 7890 作为 HTTP 端口、7892 作为 Mixed Port；Clash Verge Rev 当前设置文本则包含 Mixed Port 的回退机制，运行时还可能因端口占用临时改用其他端口。因此，旧客户端或旧配置曾写入 7890，并不代表当前 Clash Verge Rev 仍监听它；设置文件或旧教程中出现的 7897 也不应直接当成固定值。参考 mihomo Proxy Ports 文档和 Clash Verge Rev 当前设置文本。

在 Clash Verge Rev 的端口设置中读取当前 Mixed Port，记录主机地址和端口，不要只凭记忆填写 7890 或 7897。
打开 Windows“设置”中的网络和 Internet、代理，确认手动代理服务器通常应为 127.0.0.1，端口与客户端当前 Mixed Port 完全一致。
如果启用了 PAC 模式，先记录 PAC 地址，再暂时切换为普通手动代理做对照；避免系统代理开关显示开启，但浏览器实际执行的是另一份 PAC 规则。
在命令提示符中执行：netstat -ano | findstr :7897。如果客户端显示的是其他端口，将命令中的数字替换为实际端口。
发现端口被占用后，执行 tasklist /fi "PID eq 进程号"，确认占用者是否为旧客户端、旧内核或其他网络程序；关闭冲突进程后重新启动 Clash Verge Rev。

Microsoft 的 netstat 文档说明，-o 参数可以显示连接对应的进程 ID。验证时要同时看“客户端当前端口”“Windows 代理端口”和“实际监听 PID”，三者一致才算完成。

第二步：排查 Chrome、Edge 和 Firefox 的独立代理设置

Chrome、Edge：停用扩展并检查启动参数

先暂时停用代理切换扩展、PAC 扩展或其他会修改代理的扩展，完全退出浏览器后重新打开。Chrome 和 Edge 还可能通过启动参数覆盖系统代理，可分别打开 chrome://version 和 edge://version，检查命令行中是否存在旧的 --proxy-server 或 --proxy-bypass-list。

Chromium 官方文档说明，代理可以来自系统设置、PAC、扩展、策略或命令行参数；如果命令行仍指定旧端口，Windows 系统代理开关变化不一定能改变浏览器实际路径。参考 Chromium Proxy support 文档。

Firefox：确认使用系统代理

Firefox 有独立的连接设置。打开设置中的网络设置，在代理选项中选择“使用系统代理设置”，不要误选“无代理”或填写已经失效的手动端口。Mozilla 官方帮助页明确列出了“Use system proxy settings”选项，参考 Firefox Connection settings。

用无痕窗口做一次干净复测

停用扩展后，使用无痕或隐私窗口访问同一个测试页面，并观察连接面板。无日志时继续查系统代理和端口；有日志时不要再反复修改浏览器，而应转向规则、节点和 DNS。

第三步：检查 HTTP_PROXY、HTTPS_PROXY 是否影响实际请求

HTTP_PROXY、HTTPS_PROXY、ALL_PROXY 和 NO_PROXY 不是 Windows 浏览器系统代理的统一替代品，但部分 PowerShell、.NET、Node.js 或其他命令行程序会读取它们。它们可能造成“浏览器和终端走的不是同一条路径”，也可能让终端继续使用旧的 7890 端口。

在 PowerShell 中查看当前会话变量：

Get-ChildItem Env:HTTP_PROXY,HTTPS_PROXY,ALL_PROXY,NO_PROXY,http_proxy,https_proxy,all_proxy,no_proxy

在命令提示符中查看持久化环境变量：

set HTTP_PROXY
set HTTPS_PROXY
set ALL_PROXY
set NO_PROXY

如果发现变量指向旧端口，先记录原值，再只在当前 PowerShell 会话中清除并重新测试：

$env:HTTP_PROXY = $null
$env:HTTPS_PROXY = $null
$env:ALL_PROXY = $null
$env:NO_PROXY = $null

关闭并重新打开需要测试的终端或应用，因为部分程序只在启动时读取环境变量。Microsoft 文档说明，PowerShell 7 和 .NET 的默认代理可能读取这些变量；因此它们主要用于解释命令行或开发工具与浏览器表现不同的情况，不应直接推断浏览器一定受其控制。参考 Invoke-WebRequest 代理说明和 .NET HttpClient 代理说明。

第四步：用 Secure DNS 做对照，不要把 DNS 现象当成代理未生效

如果连接面板已经出现浏览器请求，但网页仍提示无法解析域名或打开失败，先区分“请求没有进客户端”和“请求进了客户端但解析失败”。Chrome 的 Secure DNS 可以使用当前服务商或自定义服务商；Google 官方说明，遇到解析错误时可以检查服务商设置或暂时关闭 Secure DNS 做对照。参考 Google Chrome Secure DNS 帮助。

记下当前浏览器、客户端配置和测试域名，避免修改多个变量。
在 Chrome 的设置、隐私和安全、安全性中找到“使用安全 DNS”，暂时关闭，重新访问同一域名。
观察 Clash Verge 连接面板：如果仍有请求但结果变化，说明 DNS 路径可能参与了故障；如果始终无请求，回到浏览器代理和端口层排查。
测试结束后，根据你的网络环境和隐私需求决定是否恢复 Secure DNS，不要把临时关闭当成永久修复。

Edge 也提供 Secure DNS 设置，微软说明可在隐私、搜索和服务中的安全选项里配置。参考 Microsoft Edge 安全 DNS 说明。

第五步：按错误提示分流规则、节点和安全软件

提示或现象	检查重点	建议动作
无连接日志	浏览器代理模式、扩展、PAC、系统代理端口	统一读取当前 Mixed Port，停用扩展并重启浏览器
显示 DIRECT	规则模式、规则顺序、代理组选择	临时切换到明确的代理模式做对照，再恢复原配置
connection refused	本地端口未监听、7890/7897 端口错位、旧进程占用	执行 `netstat -ano`，确认监听 PID 和端口
timeout	节点、上游网络、DNS、连接策略	换一个已配置节点，查看内核日志中的具体失败阶段
仅命令行程序异常	HTTP_PROXY、HTTPS_PROXY、ALL_PROXY、NO_PROXY	查看并清除当前会话中的旧变量，重启终端后复测
更新后内核或配置文件找不到	文件是否被隔离、服务模式是否正常、配置目录是否损坏	先检查安全软件隔离记录和应用日志，再备份配置后修复

安全软件拦截只是排查方向，不是默认结论。优先检查隔离记录、阻止记录和应用日志；确认文件来源可信且问题可复现后，再考虑添加例外，不要为了测试长期关闭系统防护。

第六步：系统代理仍不稳定时，用 TUN 模式做对照

如果系统代理无浏览器日志，而 TUN 模式可以产生请求，这只能说明两种流量接管路径的结果不同，不能单独证明节点一定正常，也不能证明系统代理一定被 Windows 拦截。

关闭系统代理，避免系统代理与 TUN 同时修改网络设置。
确认 Clash Verge Rev 已运行所需的服务模式或管理员权限；其设置说明标注 TUN 需要服务模式或管理员模式。
开启 TUN，根据系统提示授权虚拟网卡，然后访问同一个测试页面。
如果 TUN 有请求、系统代理无请求，重点回到浏览器代理、端口、PAC 和 HTTP_PROXY。
如果 TUN 也失败，再检查节点、规则、DNS、权限和防火墙，不要继续只改浏览器选项。

mihomo 官方文档将 TUN 描述为可接管系统流量、自动路由和 DNS 劫持的入口；HTTP、SOCKS 和 Mixed 入站则是不同的代理端口入口。参考 mihomo Inbound Configuration 文档。

验证标准：怎样确认浏览器真的走了代理

连接面板出现了刚刚由目标浏览器发起的新请求。
请求详情显示的规则、代理组和出站结果符合当前测试模式；显示 DIRECT 代表请求进入客户端后被规则选择直连。
将系统代理关闭后重新访问同一页面，面板中的新请求应停止或表现发生可解释变化；这只是辅助证据，不能单独证明浏览器一定使用了代理。
停用代理扩展、关闭 Secure DNS 或清除环境变量时，一次只改一个变量，并使用同一个浏览器和同一个测试域名。
最后再恢复原设置，确认恢复后结果与排查结论一致。

“网页能打开”不是充分验证标准，因为网页可能命中直连规则、缓存或本地网络。连接日志、当前监听端口和请求详情应作为主要证据。

安全提醒

不要把 Clash Verge 或 mihomo 的 HTTP、SOCKS、Mixed 入站绑定到公网地址，也不要直接复制不理解的第三方配置。mihomo 官方文档明确提醒，未加密的 HTTP、SOCKS 和 Mixed 入站不应直接暴露到互联网，参考 mihomo Inbound Configuration 文档。

修改代理、环境变量或 TUN 前，先记录当前端口、PAC、绕过列表和环境变量。遇到系统代理无法写入时，优先检查权限、服务模式、端口占用和安全软件记录，不要反复执行无法解释的网络重置命令。

常见问题

Clash Verge 开了系统代理，为什么连接面板没有浏览器记录？

优先检查浏览器是否使用系统代理、是否被扩展或启动参数改成直连，以及 Windows 代理是否仍指向旧端口。Firefox 还要单独确认“使用系统代理设置”。

Clash Verge 的端口一定是 7897 吗？

不一定。7897 可能出现在 Clash Verge Rev 的设置或运行配置中，但实际端口会受当前配置、端口占用和自动回退影响，应以当前客户端显示并由 netstat 验证的端口为准。

旧客户端写的是 7890，换到 Clash Verge 后要怎么改？

不要直接假定新端口。先读取 Clash Verge 当前 Mixed Port，再同步修改 Windows 代理、浏览器扩展、PAC 或命令行参数；最后用 netstat 确认该端口确实由目标内核监听。

HTTP_PROXY 会让 Chrome 浏览器不走 Clash Verge 吗？

它更常影响 PowerShell、.NET、Node.js 等会读取环境变量的程序，不能直接推断 Chrome 一定受影响。遇到终端和浏览器路径不同，查看 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY、NO_PROXY 并重启对应应用。

浏览器有连接记录但网页打不开，还是系统代理问题吗？

不一定。出现记录说明请求已进入客户端，下一步应看是否命中 DIRECT、代理组是否有可用出站、节点是否超时，以及 DNS 或安全软件是否影响连接。

关闭 Chrome Secure DNS 后恢复，说明什么？

这说明 DNS 解析路径可能参与了故障，但不能单独证明代理没有生效。应使用同一个域名、同一个节点做开关前后对照，再决定是否恢复 Secure DNS。

Firefox 为什么和 Chrome 的系统代理表现不一样？

Firefox 提供独立的连接设置，可以选择无代理、自动检测或使用系统代理；如果没有选择使用系统代理，就不会按 Windows 系统代理开关工作。

TUN 模式正常，是否说明节点一定没有问题？

不能完全说明。TUN 与系统代理的接管路径不同；TUN 正常只能说明当前测试流量可通过 TUN 路径，系统代理仍可能存在端口、浏览器或 PAC 问题。

关闭 Clash Verge 后浏览器报代理连接失败，能证明它之前走了代理吗？

只能作为辅助现象，不能单独确认。更可靠的证据是客户端连接面板出现浏览器请求、请求详情显示预期出站，并且端口和进程监听关系一致。