VPS & Windows 网络底层故障排除手册 (Gemini & WARP 专题)

核心病理总结

当 VPS 正常且另一台设备能用时，本机失败通常是因为 “流量泄露”：Windows 系统优先使用了本地原生 IPv6 或存在残留路由，导致流量绕过了代理隧道，直接以“真实身份”撞向 Google。

第一阶段：服务端“隐身衣” (VPS 层)

目标： 确保 VPS 出站 IP 是干净的 Cloudflare 节点，而非被拉黑的机房 IP。

1. 部署 WARP 双栈： 运行 WARP 脚本，务必开启 IPv4 + IPv6 双栈接管。

• 逻辑： 无论客户端发来什么协议，出站统一伪装成 Cloudflare IP。

2. 验证： 在 VPS 终端看到 IPv4/v6 均显示为 Cloudflare 即可。

第二阶段：客户端“防侧漏” (Clash Verge 层)

目标： 强制接管本地所有协议流量，不给系统“裸奔”的机会。

1. 开启 TUN 模式： 必须使用虚拟网卡接管，而非单纯的系统代理。

2. 关键开关：

• Fake-IP： 拦截 DNS 解析，防止 Windows 拿到真实 IP 后走直连。

• 严格路由 (Strict Route)： 开启此项，强制删除系统默认路由，让 IPv6 无法绕过虚拟网卡。

• IPv6 全局开关： 确保客户端允许并能解析 IPv6。

第三阶段：系统底层“大清扫” (Windows 层)

目标： 解决多设备差异，重置混乱的协议栈，强制认领新配置。

1. 重置网络堆栈（管理员权限 CMD）：

• netsh winsock reset (重置接口)

• netsh int ip reset (重置 IPv4)

• netsh int ipv6 reset (重置 IPv6)

• 逻辑： 清理掉所有以往工具残留的“幽灵路由”和无效映射。

2. 清空 DNS 缓存： ipconfig /flushdns。

3. 重启系统： 必须重启，使底层驱动和路由表重新装载。

第四阶段：终极验证流程 (SOP)

每次怀疑环境失效时，按此顺序自检：

1. 访问探针： browserleaks.com/ip

2. 查三项指标：

• IPv4： 必须显示为 Cloudflare/节点 IP（不能是机房原生 IP）。

• IPv6： 必须有值，且为 Cloudflare 代理 IP。

• WebRTC： 必须显示 N/A 或代理 IP（绝不能显示长沙本地 IP）。

3. 测试 Gemini： 开启无痕窗口登录。

为了让你日后能更直观地复现这个排查路径，我为你准备了一个交互式故障排除导航。你可以点击不同的状态，它会给出最核心的针对性解决步骤。

这份文档和工具应该能帮你节省以后 90% 的折腾时间。祝你的 Deenta 平台开发顺利，环境从此稳如泰山！