SSF0SSF0
首页
前端
  • Node
  • Go
  • Python
  • MySql
  • Bash
  • Git
  • Docker
  • VuePress
  • CI/CD
  • 服务器
  • 网站
  • 学习资料
  • 软件
  • 开源项目
Timeline
Github
标签
分类
首页
前端
  • Node
  • Go
  • Python
  • MySql
  • Bash
  • Git
  • Docker
  • VuePress
  • CI/CD
  • 服务器
  • 网站
  • 学习资料
  • 软件
  • 开源项目
Timeline
Github
标签
分类
  • Bash

    • Bash 获取路径在不同类型电脑的区别
  • Git

    • Git 使用 ssh 与 https 的区别
    • Git 回滚、重置与变基
    • 文件名大小写发生变化的坑
    • Git 提交信息规范解读与实践指南
    • Git 历史邮箱统一
    • Git 拉取 GitHub 失败、配置代理及 DNS 问题排查总结
    • Git 实战教程:如何使用 Cherry-pick 或直接覆盖让两个分支同步公共功能
  • Docker

    • Docker 命令大全
    • nginx 镜像部署静态文件
    • Docker 运行命令说明
    • 使用 node 镜像运行本地项目
    • 挂载和卷的区别
    • Docker 打包多平台镜像
    • Docker 使用 mysql
    • Docker 容器网络访问问题总结
    • Docker 容器绑定ip问题
  • VuePress

    • 使用 VuePress 搭建个人博客概括
  • CI/CD

    • blog 使用 Github-Actions 部署 docker 服务器
    • GitHub Actions项目部署国内服务器文件传输时间优化
  • 服务器

    • 腾讯云使用 ssh 连接服务器(Linux 实例)
    • ssl 证书安装到 docker 服务器
    • 操作系统与架构
    • ssh 连接时长问题
    • Oracle 服务器基础知识
    • OCI 专属网络拓扑图
    • 甲骨文-宝塔面板无法访问问题
    • 甲骨文服务器防火墙问题排查记录
    • 甲骨文重启后宝塔面板无法访问
  • hosts 文件指南
  • Cloudflare DNS与代理
  • 跨平台定时任务设置指南
  • Edge 浏览器连不上代理?一场由插件引发的“夺权”与 v2rayN 的深度探索
  • 二级域名访问异常排查记录
  • 软件走代理时如何抓包
  • JetBrains AI 使用
  • Clash 代理工作原理详解

【排查实录】Edge 浏览器连不上代理?一场由插件引发的“夺权”与 v2rayN 的深度探索

前言:诡异的“双标”现场

最近在使用 v2rayN 时发现了一个非常令人困惑的现象:

  • Google Chrome:在普通系统代理模式下,访问畅通无阻。

  • Microsoft Edge:同样的设置,死活连不上外网。只有开启 v2rayN 的 TUN 模式(虚拟网卡全局接管)才能正常访问。

这就引出了一个问题:难道 Edge 浏览器因为“关联到电脑系统”,权限受限,必须用 TUN 模式这种“重武器”才能上网吗?

带着这个问题,我开始了一场排查之旅,不仅找到了真凶,还顺带深入理解了 Windows 网络权限和代理优先级的底层逻辑。


第一阶段:误入歧途 —— UWP 回环限制

起初,我和 AI 助手都认为这是经典的 Windows UWP 应用回环限制 (Loopback Restriction) 问题。

什么是回环限制?

Windows 为了安全,默认禁止 UWP 应用(如 Windows 商店应用、旧版 Edge)访问本机回环地址(127.0.0.1)。而 v2rayN 的普通模式正是监听在 127.0.0.1:57225。这就像是你开了一扇门,但系统禁止 Edge 走进这扇门。

v2rayN 的“手术刀”功能

v2rayN 自带了一个神器:“解除 Windows 10 UWP 应用回环限制”。

  • 这就像给特定应用发“通行证”,允许它们访问本机代理,而不需要开启沉重的 TUN 模式。

  • 我尝试勾选了 Microsoft Edge 甚至点击了 Exempt All(豁免所有),并重启了浏览器。

结果:Edge 依然无法上网。这说明“回环限制”虽然存在,但并不是导致这次断网的核心原因。


第二阶段:真相大白 —— 插件的“夺嫡之战”

在排除了系统层面的限制后,我将目光转向了 Edge 内部。经过排查,终于揪出了罪魁祸首 —— 一个名为 Ghelper 的浏览器插件。

为什么 Chrome 没事?

因为我的 Chrome 浏览器里也安装这个插件,但是插件处于关闭状态,没有登录账户。它老老实实地读取了 v2rayN 设置的系统代理,所以能上网。 Chrome 浏览器去测试的时候,登录账户还是可以访问代理的连接,可见登录账户开启 Ghelper 插件不是及时响应的(开启或关闭,重启浏览器立即见效),所以测试的时候需要注意,登录账户后也算会和 Edge 一样普通代理无法代理的问题。

为什么 Edge 挂了?

Edge 里开启了 Ghelper 插件。这里涉及到一个关键的浏览器代理优先级原则:

浏览器插件 (Extensions) > 系统代理 (System Proxy) > 直接连接

  1. Ghelper 接管权限:只要这个插件开着,它就会告诉 Edge:“别听系统的,听我的!”

  2. 架空 v2rayN:插件试图接管流量,但可能配置有误或未连接,导致流量在这个环节就断了。

  3. 无视系统设置:此时 v2rayN 在系统里设置好的 127.0.0.1 代理完全被 Edge 忽略了。

解决方法:直接关闭或卸载该插件,Edge 瞬间恢复正常,不再需要开启 TUN 模式。


第三阶段:深度思考 —— 既然插件接管了,为什么 TUN 模式能用?

在排查中我发现了一个有趣的细节:即使 Ghelper 插件开着(接管了代理),只要我开启 v2rayN 的 TUN 模式,Edge 依然能上网。

这是为什么?难道 TUN 的权限比插件还大?

“地图”与“道路”的区别

这涉及到了网络模型的层级压制:

  1. 插件层(应用层 - Layer 7):

    • 插件修改的是“导航策略”。它告诉浏览器:“我不走代理,我要直连去谷歌”。

    • 浏览器听信了,发起了一个“直连”请求。

  2. TUN 模式(网络层 - Layer 3):

    • TUN 模式修改的是“物理道路”。它在系统底层建立了一个虚拟网卡,并修改路由表,让所有出口流量强制经过它。

    • 当浏览器发出“直连”请求时,数据包刚出门就被操作系统抓住了:“不好意思,现在唯一的路就是 v2rayN 的虚拟网卡”。

    • 于是,“直连”请求被强行塞进了代理通道。

结论:TUN 模式属于降维打击。插件再怎么折腾应用层逻辑,也逃不出底层网络路由的物理定律。


收获与总结:v2rayN 的强大之处

通过这次事件,我对 v2rayN 这个工具有了全新的认识。它不仅仅是一个开关,更像是一个精密的多功能网络控制台。

1. “手术刀” vs “推土机”

  • TUN 模式(推土机):强力、万能,能解决所有顽固不化的网络问题(包括插件冲突),但开销大,可能影响其他局域网应用。

  • 回环豁免 + 系统代理(手术刀):轻量级,不侵入底层网络。

2. 实测 Microsoft Store 提速

之前我的 Microsoft Store (微软应用商店) 打开极慢,图片加载不出来。 这次我利用 v2rayN 的 “解除 UWP 回环限制” 工具,在不开启 TUN 模式的情况下,专门勾选了 Microsoft Store。 效果:商店秒开,下载速度飞快。这证明了该功能对于处理 UWP 应用的网络隔离问题极其有效。

3. 排查思路总结 (避坑指南)

以后遇到浏览器连不上代理,请按此顺序排查:

  1. 查插件:是否有 Ghelper、SwitchyOmega 等接管了代理?(先全关掉!)

  2. 查 DNS:浏览器是否开启了“安全 DNS”?(建议关闭)

  3. 查回环:如果是 Win10/11 的 UWP 应用(邮件、商店),记得去 v2rayN 里勾选豁免。

最后更新时间:
贡献者: 何风顺
上一页
跨平台定时任务设置指南
下一页
二级域名访问异常排查记录