摘要：本文记录了一次在复杂校园网环境（PPPoE + 行为管理）下的网络代理故障排查过程。故障表现为“Chrome 命令行可用，但系统代理（Edge）失效”。排查过程经历了从误判为“网关封锁”而进行复杂的路由表（Route Table）操作，到最终通过“对照实验”定位为 Windows 网络栈与代理软件在本地回环（Loopback）上的协议错位。本文将解构 Windows WinINET 库与代理软件的 IPv4/IPv6 通信博弈。

一、 问题背景：幽灵般的“连接关闭”

在校园网环境下，为了解决内网资源访问与外网学术搜索的需求，我试图配置 Clash Verge 进行代理。然而，我遭遇了一个极具迷惑性的网络死锁：

1. 环境：Windows 11 + 校园网（PPPoE 认证）+ Clash Verge（Mihomo 内核）。

2. 现象：

   • Clash 显示运行正常，端口监听开启。

   • 开启“系统代理”后，Edge 浏览器无法打开任何网页，报错 ERR_CONNECTION_CLOSED 或 ERR_TIMED_OUT。

   • PowerShell 使用 Invoke-WebRequest 测试，报错“基础连接已经关闭”。

二、 误入歧途：路由表的陷阱

起初，我基于“校园网防火墙极其严格”的刻板印象，做出了错误的归因假设：

• 假设：学校网关通过 DPI（深度包检测）识别并阻断了代理流量，或者通过推送默认路由劫持了所有出口。

• 错误尝试：我试图实施“双网卡策略路由”——同时连接手机热点和校园网，试图通过 route add 命令和修改接口跃点数（Metric），强行让外网流量走热点，内网流量走校园网。

结果陷入了 endless loop：复杂的路由表配置不仅没有解决问题，反而导致内网外网全部断连。

三、 转折点：一次关键的“对照实验”

在重置网络并冷静下来后，我决定摒弃复杂的路由理论，回到应用层进行一次最基础的对照实验（Control Experiment）。正是这次实验，彻底推翻了“网关封锁论”。

实验设计

我设置了两个对照组，测试目标均为 YouTube：

• 实验组 A（标准链路）：

  • 操作：开启 Clash 系统代理，使用 Edge 浏览器正常访问。

  • 结果：失败。Edge 提示无法连接代理服务器。

  • 路径分析：Edge -> Windows 系统代理设置 (注册表) -> 本地端口 -> Clash -> 校园网。

• 实验组 B（旁路链路）：

  • 操作：关闭所有浏览器，打开 PowerShell，使用 Chrome 的调试参数强制指定代理： Start-Process chrome --proxy-server="http://127.0.0.1:7897"

  • 结果：成功！秒开 4K 视频。

  • 路径分析：Chrome (强制参数) -> 本地端口 -> Clash -> 校园网。

破案推理（The Deduction）

这次实验的结果带来了巨大的信息量：

1. 物理链路是通的：既然 Chrome 能通过同一个网口、同一个 Clash 节点访问外网，说明校园网网关根本没有拦截代理流量。所有的“防火墙阻断论”全部证伪。

2. 锁定故障点：问题出在 Edge/Windows 系统组件 与 Clash 之间的**“最后一厘米”**通信上。

3. 协议栈博弈：

   • Edge 严格遵循 Windows 的系统代理设置（Internet Settings），默认指向 127.0.0.1（IPv4）。

   • Clash Verge 在 Windows 上的监听行为倾向于 IPv6（::1）。

   • 虽然理论上 Windows 支持双栈映射，但在 WinINET 网络库中，Edge 试图用 IPv4 去“敲门”，而 Clash 却在 IPv6 的“房间”里等待。语言不通，握手失败。

结论：这不是**“被墙了”，而是“拨错号了”**。

四、 解决方案：强制 IPv6 本地回环

既然 Clash 优先监听 IPv6，且 Windows 完美支持双栈，最优雅的解法不是修改路由表，而是修改系统代理的指向。

我们只需要将系统代理地址从 IPv4 的 127.0.0.1 修改为 IPv6 的 [::1]。

一键修复脚本（PowerShell）

以管理员身份运行以下命令：

# 1. 清除旧的 IPv4 代理残留
Set-ItemProperty -Path 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings' -Name ProxyEnable -Value 0

# 2. 强制写入 IPv6 格式的代理地址 ([::1])
# 注意：7897 是 Clash Verge 的混合端口，请根据实际情况修改
Set-ItemProperty -Path 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings' -Name ProxyServer -Value "[::1]:7897"

# 3. 启用代理
Set-ItemProperty -Path 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings' -Name ProxyEnable -Value 1

# 4. 刷新系统状态
Write-Host "系统代理已修正为 IPv6 模式，请重启 Edge 验证。" -ForegroundColor Green

五、 技术总结与反思

1. 为什么 Chrome 能行？

Chrome 的 --proxy-server 参数属于应用层强制覆写。当我们在命令行中显式指定 IP 时，Chrome 的网络栈（Netstack）直接向目标发起了 Socket 连接，绕过了 Windows 系统层面的代理自动发现和协议协商机制，从而“侥幸”连通。

2. 为什么校园网“拦不住”？

这涉及到一个逆向安全视角：隧道效应（Tunneling）。 当本地连接打通后，Clash 将 HTTP 请求封装成了加密的 TCP/UDP 数据流。在校园网网关看来，这只是一堆指向未知 IP 的加密数据。如果没有针对特定协议特征（如 VMess/Trojan）的 DPI 阻断策略，防火墙通常会选择放行。

3. 避坑指南

• 现象：能 Ping 通，Chrome 命令行能用，但 Edge/系统更新 无法联网。

• 诊断：检查系统代理设置是否为 127.0.0.1。

• 对策：不要去动路由表！不要去动路由表！直接改用 [::1] 即可。

The Lesson：在网络排错中，OSI 模型下层（网络层/路由）的“通畅”并不代表上层（应用层/会话）的“握手成功”。有时候，问题仅仅出在本地的那一行配置代码上。