之前我把 IPRoyal 的 ISP 配好，给 AI 流量单独分流。本来挺顺。结果这两天 Claude 的桌面客户端开始抽风：开系统代理死活连不上，一开 TUN 就好了。

报错长这样：

Couldn't connect to Claude
Your network redirected this request to www.anthropic.com.
Contact your IT administrator.

这句 redirected this request to www.anthropic.com 基本就是在说：有请求直连出去了。Anthropic 看到不支持地区的出口，就把请求带到地区不可用页面。

所以问题不是 Claude 坏了，也不是账号坏了，而是：Claude 桌面端有一部分请求没有走代理。

但我当时系统代理明明开着。这个就很迷惑。

我一开始想歪了三次

第一反应是机场客户端把规则改坏了。

我最近装过几个机场的客户端，装完 Claude 就开始报错，所以我怀疑它们把 claude.ai、anthropic.com 之类的规则改成 direct。查了一圈，规则没动，还是指向 AI 分流组。

第二个怀疑是 IPRoyal 的 IP 被 Cloudflare 拉黑。

因为我用 curl 测 claude.ai，返回了：

HTTP/1.1 403 Forbidden
server: cloudflare

这个很容易让人误判成 IP 被封。但浏览器打开 web 版 Claude 又一切正常，没有 403，也没有 JS 质询。

但其实：curl 没有浏览器那套指纹和状态，很容易自己先被风控挡掉。

第三个怀疑是 DNS。

我发现网卡主 DNS 被我写成了 235.5.5.5。235.x 是多播保留段，根本不是 DNS。看起来很可疑，对吧。

结果也不是它。那是我自己手抖，想写 223.5.5.5，写成了 235。虽然确实该改，但跟这次 Claude 桌面端连不上没关系。

绕了一圈，三个方向都不对。

真凶：系统代理是假开

不猜了，直接看 Claude 到底往哪连。

用 PowerShell 抓 Claude.exe 的出站连接：

$pids = (Get-Process Claude*).Id
Get-NetTCPConnection | Where-Object { $pids -contains $_.OwningProcess } |
  Select-Object @{n='Remote';e={"$($_.RemoteAddress):$($_.RemotePort)"}}, State

结果很明显：

• 49 条走 127.0.0.1:7890
• 3 条直连 160.79.104.10:443

再查一下，160.79.104.10 就是当时 claude.ai 解析出来的真实 IP。

也就是说，Claude 大部分连接走了代理，但有几条绕过代理直连了 claude.ai。撞墙的就是这几条。

然后我去看 Windows 系统代理的注册表：

ProxyEnable = 0

这下真相就出来了。

Clash Verge 里“系统代理”开关显示是 ON，配置里也有 enable_system_proxy: true，但 Windows 这边实际没有开，ProxyEnable 一直是 0。

也就是：Clash Verge 以为自己开了系统代理，但根本没真正写进 Windows。

怎么修

修法其实很简单，把系统代理真正写进去：

$reg = "HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings"
Set-ItemProperty -Path $reg -Name ProxyServer  -Value "127.0.0.1:7890"
Set-ItemProperty -Path $reg -Name ProxyEnable   -Value 1
Set-ItemProperty -Path $reg -Name ProxyOverride -Value "localhost;127.*;10.*;192.168.*;<local>"

改完以后，最好把 Claude 从托盘完全退出，不是只关窗口，然后重新打开。

我再抓一次连接：

走代理(127.0.0.1:7890): 49 条
直连公网:            0 条

那 3 条直连没了，Claude 桌面端也就正常了。

所以这次不是机场客户端的问题，不是 IPRoyal 的问题，也不是 DNS 投毒。至少这次证据链里，真凶就是 Clash Verge 的系统代理假开。

为什么 TUN 一开就好

这次顺手把 TUN / 系统代理 / DNS 的关系捋了一下。

简单说：

• 系统代理：是在 Windows 里告诉应用“这里有个代理可以用”。但应用要不要读、不同进程怎么读、不同协议怎么走，都有变量。
• TUN：在更底层接管流量。应用自己认不认代理，影响小很多。

Claude 桌面端这种 Electron 应用，里面不一定只有一条网络路径。有些请求可能走 Chromium 网络栈，有些可能走别的路径。系统代理没真生效的时候，就容易出现“多数连接走代理，少数连接漏出去”的情况。

再加上 HTTP/3 / QUIC 这类 UDP 路径，系统代理模式更容易让人疑神疑鬼。

所以我的结论很简单：Claude 桌面端就用 TUN，省心。

系统代理不是不能用，但你得确认它真的写进 Windows，而且最好能抓连接验证。否则 UI 上显示 ON，不代表系统里真的 ON。

DNS 这块也顺手记一下

我之前还误会过 Clash Verge 的“DNS 覆写”。

这个开关在我这套配置里，更像是“用 Verge 自己的 DNS 配置，还是用订阅自带的 DNS 配置”，不是“mihomo 要不要做 DNS”。

我订阅里的 dns 段本来就写着 enable: true + fake-ip。所以就算没开 DNS 覆写，mihomo 的 DNS 也在跑。

证据是 TUN 模式下解析 claude.ai，结果是 198.18.0.x 这种 fake-ip 段。这就是 mihomo 回的，不是我网卡那个阿里/腾讯 DNS 回的。

所以系统 DNS 在我这套用法里，主要影响的是漏出去的直连流量。也正因为这样，网卡 DNS 乱写反而容易坑自己。

反正我后面直接设回自动获取了。至少不会再手抖写个 235.5.5.5。

下次怎么排

以后再碰到这种“浏览器能用，某个 App 连不上”“开 TUN 好，开系统代理坏”的情况，我会先做三件事：

1. 抓这个 App 的连接，看它到底有没有直连公网 IP。
2. 看 Windows 系统代理的 ProxyEnable / ProxyServer 是不是真的生效。
3. TUN 下看 DNS 是否已经变成 198.18.x fake-ip。

先别急着怀疑 IP 被封，也别急着赖机场客户端。

这次我就是绕远了。最后发现问题很土：开关显示开了，但系统里没开。

先这样，Claude 桌面端我现在直接固定 TUN 了。懒得再跟系统代理斗智斗勇。