报错长这样：
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 了。懒得再跟系统代理斗智斗勇。
5/5 - (1 vote)