EN 中文
← Blog

Monthly Update: Running Claude Code Behind the GFW

A callback to my February update — here’s what March looked like.

Most of March was spent on one thing: building a self-healing network so Claude Code could actually stay online from China.

Development Hell

Most Claude Code tutorials assume you have a clean, fast, unmonitored internet connection. I don’t. I’m in Shenzhen, where the GFW actively detects and kills proxy protocols, WebSocket connections get terminated every 90 seconds, ISPs throttle proxy traffic at night, Anthropic’s API returns 403 for Chinese IPs, and company WiFi stacks another layer of DPI on top. Claude Code would connect, work for 60 seconds, and die. Every single time.

The core problem is simple: Anthropic bans API requests from proxy exit IPs that look like shared datacenter or airport nodes. Consumer VPNs and most proxy subscriptions route through exactly those kinds of nodes. So Claude Code would connect, work for a minute, and get cut off. Every time.

What actually saved me was an old MacBook Pro (2020, T2 chip) sitting at home. I wiped it, installed Ubuntu Server, and set up mihomo (a Clash.Meta fork) on it, connected via Tailscale. It was using the same airport proxy nodes that kept getting banned from my main setup — but from this machine they weren’t getting banned by Anthropic. My guess is the traffic pattern was clean enough: low concurrency, no bursts, the exit IPs hadn’t been flagged yet. I still don’t fully understand why, but it solved the ban problem.

The real fix, though, is a stable residential IP — what you actually need to never get flagged. I’m currently testing EqualDCDN, which provides exactly that. Still early, but if it holds up, the Old Mac workaround becomes unnecessary.

Not getting banned doesn’t mean not getting disconnected. Airport nodes themselves go down, ISPs throttle at night, company WiFi blocks certain ports. So I wrote a 3,500-line vpn CLI that automatically scans for a working path and reconnects when the connection drops. It maintains multiple routes, detects which network environment I’m in (home WiFi, hotspot, office), and picks the right failover order for that scenario. When Claude Code hits a network error, a PostToolUse hook triggers the CLI to find a new path automatically.

Six failover levels total. Roughly 95% of network failures self-heal without me noticing. When absolutely everything is down, I fall back to OpenCode + OpenRouter — inferior experience, but it keeps me productive.

I spent more time on networking in March than on actual coding. But by month’s end it mostly just ran — occasional drops that fixed themselves. When you’re running AI agents from behind the GFW, your network is the single most important piece of infrastructure you have.

月度更新:在防火墙后面跑 Claude Code

接着二月更新,聊聊三月的变化。

三月主要就做了一件事:搭了一套自愈的网络系统,让 Claude Code 能在中国稳定上线。

开发地狱

大部分 Claude Code 的教程都有一个隐含假设:你有一条干净的网络。我没有。我在深圳,GFW 主动检测并杀死代理协议,WebSocket 连接每 90 秒被掐断,深夜 ISP 限速,Anthropic API 对中国 IP 直接 403,公司 WiFi 再叠一层 DPI。Claude Code 连上,干 60 秒活,死掉。每次都是。

核心问题很简单:Anthropic 会 ban 掉从机场代理节点出去的 API 请求。消费级 VPN 和大部分代理订阅走的全是这种节点。所以 Claude Code 连上,干一分钟活,就被掐掉。每次都是。

真正救命的是家里一台旧 MacBook Pro(2020,T2 芯片)。刷了 Ubuntu Server,装上 mihomo(Clash.Meta fork),通过 Tailscale 接入。用的还是同一批机场节点 — 在主力机上被 ban 的那些 — 但从这台机器出去就是没被 Anthropic ban。我猜是流量行为比较干净,低并发、没有突发请求,出口 IP 没被标记。到现在也不完全理解原因,但它解决了被 ban 的问题。

但真正需要的是一个稳定的住宅 IP — 这才是从根本上不被标记的办法。我目前在测试 EqualDCDN,提供的就是这个。还在早期,但如果稳住了,旧 MacBook 那套 workaround 就可以退役了。

不被 ban 不等于不会断。机场节点本身会挂,ISP 深夜限速,公司 WiFi 封特定端口。所以我写了一个 3500 行的 vpn CLI,它自动扫描所有可用通路,找到能用的那条,断了自动重连。它能识别我当前在什么网络环境 — 家里 WiFi、手机热点、还是公司 — 然后选对应的 failover 顺序。Claude Code 遇到网络错误的时候,一个 PostToolUse hook 会自动触发这个 CLI 去找新的通路。

一共 6 层 failover,大概 95% 的网络故障能自动恢复。实在全断了就用 OpenCode + OpenRouter 应急 — 体验差很多,但至少能干活。

三月我在网络上花的时间比写代码还多。但到月底基本不用管了,偶尔断一下自己就恢复了。在墙里面跑 AI agent,网络就是你最重要的基建,没有之一。