YOURSJEYO/claude-switcher · 上手攻略

  • 仓库：YOURSJEYO/claude-switcher
  • 链接：https://github.com/YOURSJEYO/claude-switcher
  • 分类：engineering（账号环境防护 / 网络隔离工具）
  • 作者：spark
  • 更新：2026-10-21

一、它是什么

claude-switcher 是一个 Fail-Closed（失败即阻断）理念的多账号环境管理器，用 Shell + SwiftUI 写成，MIT 许可，553 star，最近提交 2026-10-20。

作者的出发点写得很直白：AI 平台的风控已经从"只看 IP"进化到"看全维度环境画像"——时区、Locale、DNS 出口、WebRTC 候选地址、设备指纹、行为时序。绝大多数封号不是因为用户做错了什么，而是"某个没意识到的场景里，真实出口 IP 悄悄溜出去了一次，哪怕只是一个 TCP SYN 握手包"。

所以它的立场不是"提醒你注意"，而是"在物理上不让你发出直连请求"。这是我在这类工具里第一次看到把口号落到硬约束上的：

哪怕代理暴毙、哪怕软件静默升级、哪怕随手乱点，也绝对发不出一次直连请求。

二、它解决什么问题

核心场景是多账号 + 代理 + 反关联。典型用户画像：手上有几个 Claude 账号，绑不同的代理节点，想让每个账号在服务端看起来像一台恒定的设备，而不是一个频繁乱跳 IP 的可疑用户。

它提供五层防护：

第 1 层：启动前 14 项环境指纹审计

每次启动前强制执行审计，任一项不达标应用物理上不会被拉起（Block-on-Fail）：

# 检查项 防什么
01 代理内核 代理根本没在跑就启动
02 TUN 网卡 系统代理开着但流量没被接管
03 出口 IP 出口国家/地区异常
04 IP 一致性 出口 IP 突变（跳节点是风控信号）
05 时区 系统时区与 IP Geo-location 冲突
06 地区 Locale 系统区域设置不符
07 IPv6 双栈旁路直连（最隐蔽的泄漏通道之一）
08 DNS 隧道 Fake-IP 校验，杜绝明文 DNS 泄漏
09 WebRTC 多节点 STUN 交叉探测
10 保镖守护进程 Kill-Switch 是否在线
11 置顶路由规则 生态域名是否被强制走代理
12 客户端语言 防止 JS 层 navigator.language / Intl 读出系统中文
13 ASN 属性 住宅宽带 vs 机房 IP
14 生态可达性 claude.ai / api.anthropic.com 连通性验证

第 04 项有个额外机制：审计引擎维护 48 小时出口 IP 历史，48 小时内出口 IP 变化 ≥3 次亮黄色警告（不阻断启动）。

第 2 层：手写 STUN 协议栈的 WebRTC 泄漏探针

不依赖浏览器内核（作者说 headless Chrome 的 ICE 子系统在无人值守场景下根本不工作，"我们踩过这个坑"），直接用 socket + struct 手工构造 RFC 5389 Binding Request，解析 XOR-MAPPED-ADDRESS。

它的创新点是交叉验证拓扑：探测列表同时包含全球节点（Google/Cloudflare）与国内骨干节点——走隧道时应回传代理出口 IP，裸连时国内节点必然秒回并当场抓获真实 IP。两种状态可区分、零误报、不依赖"恰好不通"。

第 3 层：Kill-Switch 断网急停

常驻守护进程以 10s 周期巡检隧道健康度（内核进程 × 虚拟网卡双因子），隧道中断即刻终止受保护进程。

作者明确对比了客户端自带的 Fail-Open 容错重试：那种机制会把含真实 IP 的握手包送到对方网关日志里，哪怕最终"超时失败"。这是个很多人忽略的细节——泄漏发生在包发出去那一刻，不在握手是否成功。

第 4 层：多账号快照隔离

不是"登出再登入"（那会产生大量认证事件与指纹抖动），而是物理交换数据卷：每个账号持有独立的 Device Fingerprint、OAuth Credential 与本地状态，切换时原子化封存/载入。对服务端而言每个账号看到的都是一台恒定不变的设备。

第 5 层：配置漂移自愈

作者给的实战数据很有说服力：

我们的生产环境里，TUN 开关被代理客户端更新重置了 4 次，系统时区被改回 8 次。

Watchdog 周期巡检 + 基线回滚 + 全程留痕，把配置漂移从"事故"降级为"日志里的一行记录"。真实拦截日志长这样：

2026-10-07 00:31:12 代理离线(内核或TUN丢失),已自动关闭 Claude ← Kill-Switch 真实拦截
2026-10-04 12:55:26 时区异常: [Asia/Shanghai] 已自动恢复 ← Watchdog 第 8 次拦截漂移

还有第 6 项：目标服务全家族域名（Turnstile 人机验证 / Telemetry / Payment / Support）置顶锁定代理路由，优先级高于任何第三方分流规则集——不信任、不验证、直接免疫规则库误判。

三、快速安装

系统要求：macOS · Clash Verge / Shadowrocket / sing-box / ClashX / Surge 任一（TUN 可用）· Claude 桌面版 · python3

Windows 用户有 windows/ 目录（PowerShell + WPF，Beta）；Linux 用户有 linux/ 目录（bash + systemd，Beta，因无官方桌面版改为切换浏览器登录态）。

git clone https://github.com/YOURSJEYO/claude-switcher.git

然后双击 installer/安装.command，会自动识别代理客户端、代理组名与地区目标。

注意它的地区锁定逻辑：安装程序按当前出口 IP 的国家自动锁定目标国家 + 时区 + 地区格式三件套，出口是 CN 会直接拒装（逼你先挂好代理）。

四、核心用法

4.1 日常流程

  1. 双击桌面「Claude切换器」→ 等 14 项检查
  2. 全绿 → 选账号启动；有红项 → 点「一键修复」自动处理
  3. B 账号首次使用登录一次，以后 A/B 随切随用、互不干扰

4.2 换国家节点后重新适配

换节点不用重装：

~/.local/bin/claude-switch.sh set-region
# 自动探测出口国家 → 改写自身配置 → 设地区格式 → 弹一次授权锁时区 → 同步看门狗
# 输出: OK:region=JP tz=Asia/Tokyo locale=ja_JP

14 项检查里的「出口 IP / 时区 / 地区」会全部按新目标判定，界面无需改动。

4.3 交给 Agent 自动配置

仓库根目录的 AGENTS.md 是一份完整的 Agent 交接提示词——直接粘给本地模型（Kimi Code / Cursor / Claude Code 等），它会按文档自动完成环境检查、安装、配置与验收，里面还附了实战踩坑的排障手册。

4.4 改代码

├── app/main.swift            # SwiftUI 界面（单文件）
├── core/
│   ├── claude-switch.sh      # 核心逻辑：审计/切换/修复
│   └── stun-probe.py         # STUN 探针（手工协议实现）
├── windows/                  # Windows 版（PowerShell 核心 + WPF 界面，Beta）
├── linux/                    # Linux 版（bash 核心 + systemd 保镖 + 终端菜单，Beta）
├── daemons/                  # Kill-Switch / Watchdog 模板
├── installer/                # 双击安装/卸载
└── assets/                   # 程序生成图标

原生 SwiftUI 单文件应用，无 Xcode 工程、无第三方依赖，swiftc 一条命令出可执行文件。整个仓库不含一张设计素材——图标由 Swift 代码程序生成。

  • 改界面：编辑 app/main.swift，swiftc -O -parse-as-library 重编译
  • 加检查项：core/claude-switch.sh 的 checkdetail() + UI 的 keyMap 各加一行
  • 改防护策略：daemons/ 里的模板即全部守护逻辑

4.5 更新与自动化

应用内自动更新：launchd 每 12 小时自动检查更新，自检失败自动回滚，也可手动 claude-switch.sh update 保底。

五、典型适用场景

  1. 持有多账号、需要严格隔离的老用户。核心场景，不解释。
  2. 发现过 WebRTC / IPv6 / DNS 泄漏之后。它的 14 项里有一半是针对各种隐蔽旁路通道的。
  3. 用 Windows / Linux 的 Claude 用户。两个 Beta 版覆盖，但成熟度低于 macOS。
  4. 想给 Agent 自动配环境的人。AGENTS.md 这条路对本地模型用户很友好。

六、坑与注意

  1. 工具兜不住主动作死。作者自己列了四条教训，这是最需要记住的一节：先退出 Claude 再断/换代理（断线重连那几秒是全年最高危时刻）；不要把订阅账号接入任何第三方工具/中转站/拼车服务（作者称这是 2026 年头号封号诱因）；支付卡段和账单地址尽量与出口国家一致；新账号前几天别拉满高档位用量（注册即跑满额度本身就是批量养号工作室的指纹）。
  2. 这是一个规避风控的工具，伦理与合规风险由使用者自担。它的技术手法（多账号、指纹隔离、IP 轮换）与各大平台 ToS 中"禁止规避检测"的条款直接相关。请自行判断使用场景是否合规——我这里只做技术事实描述，不做使用推荐。
  3. Beta 版质量不齐。Windows 和 Linux 版都标注 Beta，Linux 版因为没有官方桌面版只能切浏览器登录态，防护面天然弱于 macOS 版。
  4. 强依赖 TUN 模式。你的代理客户端必须支持并开启 TUN，只开"系统代理"是不够的——检查项 02 就是专门抓这个的。
  5. 它在跟平台风控赛跑。README 自己写着"防护项随目标平台风控演进不断增加"。这意味着今天安全的配置明天可能已经失效，工具作者自己也追不上。
  6. 版本号会漂。⭐553，仓库仍在活跃迭代（路线图上还排着 Web 版检测页、更多指纹维度如字体地区特征和 Canvas/WebGL 渲染特征）。本文描述的 14 项检查对应的是抓取时状态（2026-10-20 main 分支），具体项数可能已变。
  7. 被封号的申诉经验仅供参考。作者提到"用被封账号登录 claude.ai/restricted 提交申诉，社区历史成功率约十分之一"，并警告不要立刻用同一台机器、同一张卡、同一邮箱再注册新号——绕过封禁本身违反条款。这个成功率是社区统计，非官方数据。

七、与同类对比

维度 claude-switcher 普通代理客户端 浏览器 Profile 隔离
防护层数 6 层（审计/STUN/Kill-Switch/快照/漂移自愈/路由置顶） 1-2 层（代理 + TUN） 1 层（cookie 隔离）
失败模式 Fail-Closed，不过审就不启动 Fail-Open，断了就裸连 无网络层防护
多账号隔离 物理快照交换（设备指纹 + 凭证 + 状态） 无 仅登录态
WebRTC 泄漏防护 手写 STUN 交叉验证 部分客户端有 无
配置漂移自愈 ✅ Watchdog + 基线回滚 ❌ ❌
平台 macOS 稳定 / Windows·Linux Beta 全平台 全平台
认知负担 中（要理解 14 项检查的含义） 低 低

和普通代理客户端的根本区别在失败模式：大多数代理客户端断线后的行为是把流量直连出去（Fail-Open），因为"不断网"是用户期望；claude-switcher 宁可把应用杀掉也不发包。两种设计都合理，取决于你在防什么。

八、一句话推荐结论

从工程角度看，这是一个设计相当认真、把"泄漏发生在包发出那一刻"这件事想透了的防护工具，14 项审计 + 手写 STUN 交叉探测 + 双因子 Kill-Switch 这几层的思路值得任何做网络隔离的人都读一遍；但请注意——它服务于多账号反关联这一本身游走在平台 ToS 灰区上的用途，macOS 版成熟、Windows/Linux 还在 Beta，且它追的是平台风控的风控，这个赛跑它注定跑不赢，所以别把它当安全产品用，只当一个尽力而为的护栏。

本文信息源：GitHub README（2026-10-20 main 分支，MIT）、organized/repo_cards/4509-yoursjeyo-claude-switcher.md。未运行代码，仅读公开文档。