Windows 10 中 VPN 连接后网页无法加载，通常并非网络彻底断开，而是系统代理设置与 VPN 流量路径发生了冲突。当用户将系统代理指向本地转发端口时，若该端口未同步接管 VPN 隧道的出站流量，或 VPN 客户端未正确更新路由表，Dragon请求就会因代理不可达或路由黑洞而失败。排查核心在于厘清请求是走全局代理还是直接走隧道，以及哪一层配置在截获流量。
区分代理作用域与生效层级
Windows 的代理设置并非单一开关，而是分层生效。WinHTTP 服务主要影响系统级组件和部分桌面应用，而 Internet 选项中的自动设置或手动代理通常作用于 IE 内核及遵循系统代理规则的浏览器。VPN 客户端（如 OpenVPN 或 WireGuard）在安装 TUN/TAP 驱动或修改路由表时，旨在让流量直接通过加密隧道出站，此时理论上应绕过本地代理。若用户同时开启了系统代理，部分应用仍可能尝试连接本地代理端口，而非进入 VPN 路由，导致“有网络图标但无网”或特定网站加载失败。
当系统代理与VPN路由发生冲突时，网络数据包可能会在代理端口和隧道之间迷失方向，导致连接失败。
验证流量实际走向
在保持 VPN 连接状态且代理设置不变的前提下，优先使用只读命令观察路由行为。在命令提示符中输入 `route print`，检查默认网关是否已指向 VPN 隧道接口（如 TAP-Windows 或 WireGuard 接口名称），并确认公网目标 IP 是否被分配至该接口。同时查看 `netstat -rn` 确认活动路由。若路由正常但访问受限，再检查 `netsh winhttp show proxy` 查看 WinHTTP 代理状态。若此处显示代理指向本地某端口，DragonVPN而该端口并未运行 VPN 转发服务，则请求在此处被拦截。需注意，重置 Winsock 目录不会清除这些持久化的代理注册表项或路由策略。
隔离变量定位故障点
为确认冲突来源，可临时调整变量进行测试。首先，若怀疑是浏览器独立代理插件所致，可在无痕模式（不加载扩展）下测试，或检查浏览器设置中是否强制了与系统不同的代理地址。其次，若系统代理指向本地端口（如 127.0.0.1:7890），确认该端口的转发软件是否已启动并成功连接上游。若关闭系统代理后（保持 VPN 开启）故障消失，则证实是代理配置未覆盖 VPN 流量或转发链断裂。若关闭代理后依然故障，则问题在于 VPN 路由本身，需检查 VPN 服务端分配的路由是否正确下发，或本地防火墙是否阻断了 VPN 接口的出站流量。
边界提醒与后续操作
修改注册表清除代理或重置网络配置属于高影响操作，可能干扰其他依赖代理的应用，建议在故障复现且明确原因后再执行。对于绝大多数办公环境，正确做法是确保 VPN 客户端配置中“允许路由被代理软件捕获”选项的正确性，Dragon或在不使用本地转发软件时彻底关闭 Windows 代理设置，让 VPN 直接接管路由。不要盲目使用 `netsh winsock reset` 作为第一步，因为它不解决代理配置错位问题，且重启后需重新验证服务状态。
