Claude 桌面端登录一直弹 hCaptcha 过不去？TUN 路由、IPv6 泄漏与节点风控排查实录（Windows）

结论先行

Claude 桌面端登录卡在 hCaptcha，表面看是「验证码太难」，实际是三个互相独立的问题叠在一起：

1. TUN 网卡建好了，但没写路由——不读系统代理的请求从物理网卡 IPv4 直连；
2. IPv6 在裸奔——TUN 只接管了 IPv4，IPv6 照样直连 Anthropic；
3. 节点本身是机房 IP——数据中心段被风控标记，弹验证码的目的不是让人通过。

处理顺序比原因更值得先记：先换节点，再查网络。换节点成本最低，验证码过不去时第一件事是换节点；换到三四个还不行，再回头查网络，这时候继续换只是在浪费订阅流量。两层互不替代：网络没修干净，换节点是白换；节点被标记，修网络是白修。

症状：浏览器能登录，App 卡死在验证码

浏览器里一切正常：magic link 点完，页面显示已登录。回到 App，内嵌的 claude.ai/login 弹出 hCaptcha，点多少次都过不去，最后停在「无法完成登录，您可以尝试使用其他浏览器登录」。换浏览器没有用——问题不在浏览器。

翻 App 日志，真正失败的是主进程自己发起的那个请求：

21:20:10  second-instance: suppressing duplicate argv
21:20:13  Loaded https://claude.ai
21:20:18  [account] IPC did not provide accountUuid,
          falling back to bootstrap API
21:20:42  hCaptcha challenge 加载（topFrameUrl: claude.ai/login）

浏览器把凭证交给了 App，App 主进程自己拿账号去校验，这一步被拦下，界面才开始弹验证码。

为什么「进程都走代理」还是被拦

第一步查 App 走不走代理。按进程 PID 过滤 netstat，claude.exe 的对外连接全部是 127.0.0.1:xxxxx → 127.0.0.1:代理端口，没有一条直连外网。这一层没问题。

但「走代理」这件事，只对读系统代理设置的程序成立。Electron 里有两套网络栈：内嵌页面跑的是 Chromium，读系统代理；主进程的 Node 原生 fetch 不读，HTTP_PROXY 环境变量对它也无效。刚才失败的那一步，恰好是主进程发的。

用 curl 模拟主进程、绕开本地代理直连一次：

curl --noproxy "*" -sI https://claude.ai/
HTTP/1.1 302 Found
Location: https://claude.com/app-unavailable-in-region

有响应，说明这台机器不经过代理也能连上 claude.ai，走的是 IPv6（2607:xxxx::xx）。能连上，只是被判定为区域外。

第一条线索成立：同一次登录里，有的请求走美国节点，有的请求走国内校园网直连，风控看到的是两个 IP 在操作同一个账号。

第一层：TUN 网卡建好了，路由没写

v2rayN 开了 TUN 模式，netsh interface show interface 能看到 singbox_tun，状态是已连接。但 route print -4 的路由表里没有任何指向 singbox_tun 的条目——没有默认路由，也没有 0.0.0.0/1 那种特征路由。

翻 v2rayN 生成的 sing-box 配置 binConfigs\configPre.json：

"interface_name": "singbox_tun",
"auto_route": false,
"strict_route": false,
"stack": "gvisor"

auto_route 是 false。sing-box 只负责建网卡，不负责写路由。网卡挂在那里，一条流量都不经过，不读系统代理的请求就从物理网卡直接出去了。

修复：在 v2rayN 的「Tun 模式设置」里勾上自动路由，再用管理员身份重启核心。重启后路由表出现默认路由指向 singbox_tun，直连测试的出口 IP 变成美国。

第二层：IPv6 还在裸奔

路由修好之后，curl -6 单独测一次，还是 302 到 region 页面。TUN 只接管了 IPv4 的默认路由，网卡上的 IPv6 地址照样能直连 Anthropic。系统代理和 TUN 走的都是 IPv4 那一套，IPv6 是另外一条路，没有东西管它。这台机器在校园网里，IPv4 和 IPv6 都能出网。

关掉它，管理员 PowerShell 一行，可逆：

Disable-NetAdapterBinding -Name "WLAN 2" -ComponentID ms_tcpip6

复测，IPv6 直连直接失败，所有出网路径汇聚到同一个美国出口。

这一层的麻烦在于没有任何报错：连接成功、TLS 成功、请求有响应，只有那句区域判定。如果不是专门用 -6 单测一次，很容易以为网络已经干净了。

第三层：这个 IP 本来就是高风险

网络到这一步被证明是干净的：用每秒采样的脚本盯住 claude.exe 的全部连接，整个过程直连泄漏 0 条。强杀所有 claude.exe，把会话状态目录改名隔离（加 .bak-1 后缀留了备份），重新登录——还是弹验证码，还是过不去。

换一个节点，立刻登上。

原因在 IP：原来的出口属于 ColocationAmerica 的机房段。登录风控对数据中心 IP 的评分很高，这类 IP 弹验证码的目的不是让人完成验证，是它默认不信。

两个白耗时间的坑

商店版（MSIX）的数据目录不在 %AppData%\Claude。 那个目录根本不存在。真实路径是：

C:\Users\<你>\AppData\Local\Packages\Claude_xxxxxxx\LocalCache\Roaming\Claude

网上「删掉 %AppData%\Claude 清登录状态」的教程对商店版完全无效——删了一个不存在的目录，还会以为自己已经做过了。

点窗口的 × 只是隐藏到托盘，不是退出。 旧进程带着旧状态一直活着，你以为重启过，其实还是同一个进程在跑。要真的退出，从托盘图标右键退出，或者：

taskkill /F /IM claude.exe

30 秒自检：四条命令看出网络干不干净

curl --noproxy "*" -sI https://claude.ai/              # 出现 region 302 就是有泄漏
curl --noproxy "*" -6 -sI https://claude.ai/           # 单测 IPv6
curl --noproxy "*" -s https://api.ipify.org            # TUN 出口 IP
curl -x socks5h://127.0.0.1:端口 -s https://api.ipify.org   # 代理出口 IP

第三条和第四条结果不一样，说明有流量没走代理；第一条出现 302，说明存在直连路径被区域判定命中；第二条单独测 IPv6，是修完路由后最容易被漏掉的一步。

稳态配置

这套配置从修复当晚保持至今没有问题：

• v2rayN TUN 开自动路由（接管 IPv4 默认路由），核心以管理员运行；
• 网卡 IPv6 绑定关闭（Disable-NetAdapterBinding，可逆）；
• 节点选非机房段出口，TUN 路径和代理路径出口 IP 完全一致。

同样是本地代理引发的桌面端故障，Codex Desktop 的反复 Reconnecting 走的是另一条排查线：Codex 桌面端新会话 5 次 Reconnecting 怎么办？HTTP/SSE 修复方案。

使用边界：代理客户端与内核版本不同时配置项名称可能变化；登录风控由服务端策略决定，本文方法不保证对所有账号与节点生效；关闭网卡 IPv6 前请确认没有依赖 IPv6 的其他业务