拆解中转站 Claude Code 接入远程托管账号#

这几天又被 Anthropic 封了一个 Claude 账号，被迫开始用中转站。挑了半天最后找到一家自称直接独占他们托管的真实 Claude 订阅账号。

他们还提供了自己修改过的 Claude 和 Codex 客户端以及 CLI。我就很好奇：原版工具的登录、模型请求和本地执行，是怎么接进这套服务的？于是让 GPT 6 Astra 扒了一下它的客户端实现。

这篇不打算给他们引流，只用了他们的 Claude CLI 链路，下面统一用 mClaude 代称。

使用时能看到，登录发生在第三方网站，打开的却仍然是熟悉的 Claude Code。它能读取当前项目、修改文件、执行本机命令，模型响应又经过第三方接入。要解释这些现象，需要把本地 CLI、负责身份与转发的中间层，以及最终提供推理的上游服务分开看。

从已检查的客户端实现看，mClaude 的主要结构是：本地启动官方 Claude Code，用独立登录状态和本地 HTTPS 代理接入远端应用网关。 本地 CLI 保留交互与工具执行能力，网关成为它访问模型服务的中间层。

这能够解释为什么客户端体验与原版接近，也能解释为什么“命令在本地执行”和“请求经过远端网关”可以同时成立。至于网关内部是否另有 Claude Code 实例、如何选择上游账号，客户端证据还不足以下定论。

分析范围：本次检查的 mClaude 客户端版本，采用静态分析与有限的本地行为检查。未取得服务端源码，也未通过完整推理请求验证其上游身份、账号调度或数据保留策略。下文把直接观察与架构推断分别说明。

整体架构#

把已观察到的客户端链路画出来，可以得到下面的结构。虚线部分表示服务端内部仍待核实的环节。

flowchart LR
    U["用户任务"] --> C["本地官方 Claude Code"]
    C --> T["本机终端与文件工具"]
    T --> C
    C --> P["mClaude 本地 HTTPS 代理"]
    P --> G["mClaude 远端网关"]
    G -. "上游鉴权与转发：具体实现未核实" .-> M["上游模型服务"]

mClaude 在这条链路中承担了几项工作：完成自己的网页登录和设备绑定，准备原版 CLI 能加载的登录状态，设置运行环境，启动本地代理，再把请求送到自己的网关。

被检查的 Claude Code 可执行文件与官方发行版本一致，客户端启动路径也显示它在本机执行。因此，至少在这份样本中，mClaude 可以通过外围启动器和代理接入原版 CLI，无须重写一套编辑器、终端工具或交互界面。

先记住三个结论，后面的细节就容易理解了：

• 官方客户端与第三方接入可以同时存在。 可执行文件来自官方，认证和请求链路则可以由第三方提供。

• 模型推理与工具执行可以分处两端。 模型决定调用什么工具，终端命令仍可由本地 CLI 执行。

• 网关能转发请求，尚不了解内部实现。 账号替换、账号池，以及远端是否运行 Claude Code，都需要额外证据。

CLI 启动包装#

把上面的机制落到启动过程，可以用下面这段 Shell 来理解：先选中独立的登录配置，再传入本地代理和 CA，最后启动原版 claude。

前提是第三方登录已经完成，本地后台代理也已运行。 这段脚本只示意启动包装，不负责网页登录、创建凭据或启动代理。为隐去服务名称，状态目录和目录布局做了示意化处理；/path/to/mclaude-state 不是实际路径，需要按真实配置调整，读取 JSON 的部分依赖 jq。

(
  set -e

  # Illustrative layout only; replace with the actual wrapper state directory.
  wrapper_dir="/path/to/mclaude-state"
  account_id="$(cat "$wrapper_dir/claude/current")"

  export CLAUDE_CONFIG_DIR="$wrapper_dir/claude/accounts/$account_id/config"

  proxy_url="$(jq -er \
    '.env.HTTPS_PROXY | select(type == "string" and length > 0)' \
    "$CLAUDE_CONFIG_DIR/settings.json")"

  export HTTPS_PROXY="$proxy_url"
  export HTTP_PROXY="$proxy_url"
  export https_proxy="$proxy_url"
  export http_proxy="$proxy_url"
  export NODE_EXTRA_CA_CERTS="$wrapper_dir/ca.pem"
  export NO_PROXY="localhost,127.0.0.1,::1"
  export no_proxy="$NO_PROXY"

  # Clear inherited provider and proxy overrides.
  unset ALL_PROXY all_proxy
  unset ANTHROPIC_API_KEY ANTHROPIC_AUTH_TOKEN
  unset CLAUDE_CODE_OAUTH_TOKEN ANTHROPIC_BASE_URL

  claude
)

外层括号创建一个子 Shell，环境改动只影响这次启动及其子进程。独立的 CLAUDE_CONFIG_DIR 让原版 CLI 读取对应配置和登录状态；代理变量决定请求先到哪里，NODE_EXTRA_CA_CERTS 则让这个进程信任本地代理使用的 CA。

这里同时设置了大写和小写代理变量，因为原版 CLI 会优先读取部分小写变量。清理已有的 API Key、认证令牌和服务地址覆盖项，是为了减少旧环境把请求带到另一条链路的干扰。这是简化示意，并没有复现完整客户端的时区处理、环境清理和生命周期管理。

此前的本地检查中，绕开第三方启动器，直接给官方 claude auth status 传入相同的配置与代理环境，确实能加载出 loggedIn: true。这只验证登录状态能被读取，并不等于已经验证模型请求成功，或所有第三方工具都兼容。

如果另一个工具会调用 claude，也可以把最后一行换成那个工具的启动命令，前提是它会把这些环境变量传给 Claude 子进程。从 Dock 打开的 GUI 应用通常不会自动继承这段 Shell 的环境，需要在应用支持的启动配置中另行设置。

登录状态：原版 CLI 为什么能识别第三方登录#

mClaude 的登录入口属于它自己的服务。客户端发起浏览器授权，等待授权完成，并注册设备公钥和相关设备信息。随后，它取得第三方服务签发的访问凭据。

接下来，它把凭据写成原版 Claude Code 能识别的登录状态，并让 CLI 使用独立的配置目录。在已检查的登录记录中，第三方凭据进入了 OAuth 样式的访问令牌字段。

可以把这里理解为一层兼容处理：原版 CLI 读到的是它认识的记录结构，而记录中的凭据需要由 mClaude 的服务体系解释。

因此，看到本地状态显示“已登录”，只能证明 CLI 成功加载了这份状态。它不能单独证明这是一枚 Anthropic 直接签发的用户令牌，也不能证明某项订阅权益已经在真实上游兑现。

登录记录里显示的套餐、额度标签或较长的有效期，也应与上游授权分开看。最终能请求哪个模型、由哪个账号承担用量，取决于请求到达服务端后的处理；仅凭本地字段无法确认。

本地 HTTPS 代理：请求怎样被接管#

启动官方 CLI 前，mClaude 会准备代理环境变量和 CA 配置，使 CLI 的网络请求进入本地代理，并能信任代理提供的证书。Claude Code 官方文档支持 HTTP(S) 代理和额外 CA 配置，这为外围接入提供了现成机制。官方网络配置说明

普通 HTTPS 隧道代理通常只转发加密字节：TLS 仍在客户端与目标服务之间建立，代理不能因此直接读取 HTTP 正文。

已分析的 mClaude 路径多了一步。它在本地终止 CLI 的 TLS 连接，取得 HTTP 层的 URL、方法、请求头和正文，再把这些内容封装后发给远端网关。因此，它能够按应用层协议处理请求，而不只是更换网络出口。

这里的 CA 配置属于理解信任边界的关键细节：允许代理解密之后，代理就进入了能够读取请求内容的范围。仅凭进程使用了额外 CA，仍不能推断它一定修改了操作系统的全局证书信任库。

网关协议：转发的是 HTTP 请求和响应#

客户端发送到网关的内容，不只是一个提示词字符串。它把原始 HTTP 请求拆成元数据和正文，再装进一个有明确边界的封包。

其基本布局如下：

请求封包
├── 4 字节：元数据长度
├── JSON：URL、方法、请求头等元数据
└── 原始请求正文

客户端把封包发送到网关的 /proxy 接口。返回方向也有对应结构：先读取长度和响应元数据，再把后续字节作为响应正文交给本地 CLI。

响应元数据包含状态码、响应头等字段。客户端据此重建 HTTP 响应，让原版 CLI 继续按它已有的网络逻辑工作；模型的流式输出也可以沿这条响应通道返回。

这套结构支持“应用层 HTTP 网关”的判断。它解释了网关怎样插入现有客户端的请求链路，但没有直接揭示网关后面采用了什么服务框架、如何维护上游连接，或者是否调用了其他内部服务。

设备签名：第三方服务怎样识别请求来源#

mClaude 的请求还带有设备身份。客户端使用 Ed25519 签名，并把时间戳、随机数和请求体摘要纳入签名材料，再与第三方访问凭据一起发送。

这些信息承担不同职责：

不过，客户端生成了这些材料，并不能证明服务端一定正确执行了验签、时间窗口或随机数去重。判断它们的实际安全效果，需要进一步检查服务端或开展专门验证。

这也说明，mClaude 登录所建立的身份，首先是它自己的服务身份。该身份怎样映射到模型服务的上游授权，是另一层问题。

模型在远端，命令为什么还能在本地执行#

以“运行测试并修复失败”为例，本地 Claude Code 可以先把任务、上下文和可用工具定义发给模型。模型返回的工具调用是一条结构化请求，例如“执行测试命令”，而不是已经运行完毕的终端进程。

本地 CLI 收到请求后，根据权限设置执行命令，收集输出，再把结果发回模型。模型据此决定继续读文件、修改代码，还是给出最终回答。官方工具协议用 tool_use 和 tool_result 表达这类往返。官方工具调用说明

把网关放进这个标准过程，就得到下面的交互。这里展示的是与客户端结构相符的工具调用机制，不是一次已捕获的完整 mClaude 推理会话。

sequenceDiagram
    participant C as 本地 Claude Code
    participant G as mClaude 网关
    participant M as 上游模型
    C->>G: 任务、上下文、工具定义
    G->>M: 转发模型请求
    M-->>G: tool_use：请求执行工具
    G-->>C: 返回工具调用
    C->>C: 根据权限执行本地工具
    C->>G: tool_result：返回执行结果
    G->>M: 继续模型推理
    M-->>G: 后续工具调用或回答
    G-->>C: 返回响应

因此，要实现这种体验，远端并不必然需要运行另一套 Claude Code。一个能够正确转发模型请求和响应的网关，就可以与本地 CLI 的工具循环配合。

但“不需要”也不等于“没有”。服务端仍可能运行 Claude Code 实例，用于账号初始化、凭据刷新，甚至承担其他内部流程；目前的客户端证据无法确认或排除这些安排。服务端工具或远程 MCP 也另有执行位置，不能把所有工具一概归为本地执行。

环境处理：时区和语言#

已检查的启动路径还会处理 CLI 继承的运行环境。它读取账号关联的时区设置，准备语言环境，并清理部分 SSH 连接信息、遥测配置、云开发环境标记和身份覆盖项。

请求处理代码也会规范化部分头信息。例如，对已经存在的 Accept-Language 做统一处理；这不意味着每个请求都会被无条件插入该字段。

这些处理可以减少本机环境差异向受管 CLI 传递，也能避免继承的配置意外改变它的行为。但仅凭这些代码，无法证明它消除了全部地区线索。

在已检查的主要转发路径中，请求正文仍作为字节流传递。没有建立“所有提示词、代码和工具输出都会经过完整位置脱敏”的证据。如果日志本身包含时区，或者文件内容包含地址，单纯修改环境变量不会自动删除它们。

从客户端能看清什么，仍看不清什么#

这次分析最明确的部分，是客户端如何连接原版 CLI 与第三方服务：独立登录状态、本地进程启动、HTTPS 解密代理、请求封包，以及响应还原。

服务端仍有几项关键未知：

• 第三方身份如何对应到上游凭据，是否存在账号池或动态调度。

• 最终请求的模型和上游账号，是否与客户端显示一致。

• 是否另有远端 Claude Code 实例，以及它承担什么职责。

• 网关是否修改正文、保存日志，以及实际的数据保留策略。

本地工具执行也不意味着数据只留在本地。凡是被纳入模型上下文的代码、提示词和工具输出，都可能进入这条代理与网关链路。客户端的实现已经说明中间层具备读取转发内容的能力；它是否实际记录或长期保存，需要另一类证据。

理解 mClaude 的关键，是看清这条连接关系：原版 Claude Code 提供本地交互和工具能力，mClaude 在外层接入自己的身份、环境和网关体系。体验可以沿用原版，数据与身份经过的边界则已经发生了变化。