在被 Anthropic 封了 6 个 Claude Code 账号之后，我实在是受不了了，下决心避开所有中国大陆元素，整上全套美系装备：美国 VPS + 美国手机号 + 美区 Apple Pay，注册了一个新的 Claude Code 账号，目前这个号用了小半年，安全度过了这几次封禁潮。

这几天 Anthropic 又在作妖，Timeline 上一片哀嚎，新一波封号潮又杀过来了

同时，Reddit 有个爆贴，作者反编译 Claude Code 扒出一段检测代码，我顺手把整套方案整理清楚，应该算得上是最完善的防封策略了。

先说结论：一张清单

下面挨个来说。

第 1 步：Mac 和 iPhone 时区改中国台湾

时区伪装

反编译扒出来的检测逻辑，在你本机跑三层判断：

第一层：读时区。 如果是 Asia/Shanghai 或 Asia/Urumqi，触发额外针对中国大陆地区的处理逻辑，Anthropic 真的是贱啊，所以要避开。

第二层：查代理 URL。 拿系统代理 URL 去和一份 147 条的名单比对，里面有百度、阿里、蚂蚁、字节、Moonshot、MiniMax、Stepfun 等中国 AI 公司的域名。

第三层：AI Lab 关键词扫描。 在 hostname 里再扫一遍关键词。

时区是第一道门，命中就已经进风控队列，后面 IP、手机号、支付再怎么美国化都是白搭。这就是为什么把它作为第一步：成本最低（几个点击）、收益最高（切断整个信号链的源头）。

编码结果怎么送出去

最鸡贼的是结果怎么送出去。不发独立请求，而是把三层判断的组合编码进 system prompt 里两个肉眼看不见的细节：

日期从 2026-06-30 变成 2026/06/30
英文撇号 ‘ 被替换成三种视觉一样但 Unicode 码点不同的字符（U+2019 / U+02BC / U+02B9）之一

服务器一 parse 就知道你的完整画像：中国大陆 + 用了 proxy + proxy 指向哪个 AI Lab。

这个信号命中之后账号不会立刻封，而是进风控队列。所以有人用几个月才被封、有人几天就没了，打分累积到阈值触发。

解决办法：改系统时区到 Asia/Taipei

同样是东八区（UTC+8），显示时间跟北京一模一样，日历日程完全正常，但检测名单里没有 Taipei。

有人问能不能选新加坡。理论上可以，但我个人倾向避开，两个原因：

新加坡马甲太多。 大量做 Claude / OpenAI 二手账号生意的国内号都挂新加坡时区，加上新加坡本身就是华人 AI 从业者聚集地。Anthropic 后续要扩检测名单，Asia/Singapore 是明显的下一个候选。
中国台北在 Claude 官方支持范围内。 Claude 官方服务中国台湾，Asia/Taipei 是他们服务区域里的合法时区，被主动扩检测的概率相对最低。

Mac 上怎么改

系统设置 → 通用 → 日期与时间
关掉「自动设置时区」
点「设置……」，手动搜 Taipei 或「台北」
重要：再去「隐私与安全性 → 定位服务 → 系统服务」，关掉「设定时区」——否则 Apple 会根据你的 Wi-Fi 定位又把时区改回上海

改完在终端验证：

bash

$ readlink /etc/localtime
/var/db/timezone/zoneinfo/Asia/Taipei

$ node -e "console.log(Intl.DateTimeFormat().resolvedOptions().timeZone)"
Asia/Taipei

第二条那个 Node 命令就是 Claude Code 在内部读时区用的 API。返回 Asia/Taipei 说明这层伪装到位了。

iPhone 上怎么改

设置 → 通用 → 日期与时间
关掉「自动设置」
时区选「台北」
同样重要：设置 → 隐私与安全性 → 定位服务 → 系统服务，关掉「设定时区」

iPhone 这一步不是给 Claude Code 用的（Claude Code 目前只有桌面版），是防止哪天 iPhone 和 Mac 之间 iCloud 同步偏好设置时把 Mac 的时区又拉回上海。两端保持一致是最省心的做法。

第 2 步：美国 VPS

时区改完，下一步搞定第二层检测：IP 出口。出口 IP 是美国的，Claude Code 才连得上「这是个美国用户」这个画像。

我用的是 Hostinger，选美国机房节点。Hostinger 是老牌主机商，反查 hostname 是干干净净hostinger.com，跟那 147 条中国 AI 公司名单毫无关联。4GB 内存的机器就够用，8G也行，这台机器一台多用：

提供干净的美国 IP 出口
自建 Hysteria2 代理节点（让 OpenClaw 一句话装好）
顺便部署 OpenClaw

VPS 尽量避开腾讯云、阿里云

有些朋友图方便买了「阿里云国际」「腾讯云 Lighthouse 硅谷节点」「火山引擎海外」这类国内大厂的海外机房，看起来 IP 归属地在美国，觉得应该没问题。

我个人还是觉得不保险，即使只是把这些机器当 VPS 中转，只要「美国出口 + 阿里云/腾讯云域名」这个组合出现，Claude Code 服务端就能推断出这是一个中国大陆用户在用国内大厂的海外节点翻墙，这个画像的风控分有可能比直接从中国大陆访问还高。

正确选法：

首选独立域名的主机商：Hostinger、CloudCone、Vultr、Linode，反查 hostname 是 hostinger.com 这种独立域名，不在名单里
IP 类型是次要因素：住宅 IP 理论上比机房 IP 风控分更低，但只要域名不在 147 名单里、IP 归属地在美国，机房 IP 一样能用。想再稳一档可以在 VPS 上再套一层住宅 IP 代理。我个人经验，没必要追求很贵的住宅 IP，Hostinger VPS 这种其实够用了。
如果非要用大厂云，选 AWS / GCP / Azure 的美国区域，虽然是 datacenter IP 但至少域名不在名单里
绝对避开：任何名字里带 alibaba / aliyun / tencent / qcloud / huawei / volces / bytedance 的服务商，不管它标「海外版」还是「国际版」

配置代理（TUN 模式 + 清残留）

VPS 搞定了，这一步把 Mac 的流量正确地引过去，同时把历史 proxy 残留清干净。这是整个链路里最容易翻车的地方，很多人 VPS 买好了、时区改好了，最后倒在这一步。

先看看你是哪种情况

「我用 Clash 到底会不会被封？」分两种典型情况：

普通用户开 Clash / V2Ray / Surge 走系统代理 → Claude Code 读到的 proxy URL 是 127.0.0.1:7890，147 名单不命中，但时区 Layer 1 已经命中，账号照样进风控队列。绝大多数被封的个人开发者都在这个位置。
中转站用户设了 ANTHROPIC_BASE_URL → 严格说这不是 proxy 检测，但服务端一看 Host 头不对，就知道你在走中转。独立强信号。

共同点：只要 Claude Code 能读到 proxy 或 base URL 配置，就有东西可扫。解法两条腿：TUN 模式让 macOS 层面看不到 proxy；手动清干净残留让工具链里没有 base URL 泄漏。

Clash 怎么配置（Mac）

先讲清楚概念。代理客户端有两种工作模式：

系统代理模式（你以前大概率就是这个）：客户端把 macOS 网络偏好里的 HTTP/HTTPS proxy 改成 127.0.0.1:7890。scutil –proxy 一查就有，Claude Code 一眼看穿了。
TUN 模式（要的就是这个）：客户端在内核层创建虚拟网卡（utun0），劫持全系统的 IP 流量。macOS 系统代理配置保持是空的，scutil –proxy 全 0，Claude Code 感知不到任何 proxy 存在——它以为自己在直连美国互联网。

我们要的就是 TUN 模式，不要系统代理。

配完之后终端验证：

bash

$ scutil --proxy | grep -E "HTTPEnable|HTTPSEnable"
  HTTPEnable : 0
  HTTPSEnable : 0

$ curl -s ipinfo.io | grep -E '"ip"|"country"|"org"'
  "ip": "104.xxx.xxx.xxx",
  "country": "US",
  "org": "..."

系统代理全 0 + 出口 IP 是美国，到这个程度就算完美了。

手动清干净历史 proxy 残留

TUN 模式只解决「macOS 网络层看不到 proxy」这一层，环境变量和工具链里的残留 proxy 配置是独立问题，得单独清。

很多人当年为了 npm 装包能翻墙，在 ~/.zshrc 里写过 export HTTPS_PROXY=http://127.0.0.1:7890，或者装某个工具时它偷偷写进 ~/.npmrc、.gitconfig——早就忘了，但 Claude Code 一启动会全都读到。

按这套命令挨个查，一步一步来：

bash

# 1. 系统代理（应该全 0）
scutil --proxy | grep -E "HTTPEnable|HTTPSEnable|SOCKSEnable"

# 2. 当前 shell 环境变量
env | grep -iE "proxy"

# 3. shell 启动文件里有没有硬编码 proxy
grep -iE "proxy" ~/.zshrc ~/.bashrc ~/.profile ~/.zshenv 2>/dev/null

# 4. npm / yarn / pnpm 配置
npm config get proxy
npm config get https-proxy
cat ~/.npmrc 2>/dev/null | grep -i proxy

# 5. Git 配置
git config --global --get http.proxy
git config --global --get https.proxy

# 6. Claude Code 自己的 settings.json
cat ~/.claude/settings.json 2>/dev/null | grep -iE "proxy|base_url|anthropic_"

# 7. 所有 anthropic / claude 相关的环境变量（重点关注 ANTHROPIC_BASE_URL）
env | grep -iE "anthropic|claude"

# 8. Homebrew
brew config | grep -i proxy

任何一处不是空的、不是 0、不是 null，就手动清掉。

第 6、7 条尤其要看——ANTHROPIC_BASE_URL 是最容易被漏掉的一处。以前用过第三方中转站（各种镜像站）或者跑过 Claude Code Router，很可能留下了指向anthropic.co的 base URL，服务端一收请求看 Host 头就知道你在走中转。

清理完之后重启一下终端（让新 shell session 生效），再重新跑一遍第 2 条 env | grep -i proxy 确认。