Claude 订阅转 API 部署指南（住宅代理 + Fail-Safe 隔离方案）

这篇文档整理一套围绕 VPS、住宅代理、Systemd 隔离、Fail-Safe 验证、Claude Code 接入 的部署流程，目标是把账号授权、网络出口与服务常驻拆开管理，形成可长期维护的 AI 系统运维 SOP。

两种方案怎么选

如果你两台条件都具备，优先选 ISP 住宅 IP 方案，链路更短、更好排查。本文针对的是只能靠代理补出口的场景。

背景

很多 AI 工具接入场景都需要一个稳定、可控、可复用的接口层。单纯把服务跑起来并不够，真正影响长期可用性的，通常是以下几个问题：

• 网络出口是否稳定
• 代理失效时是否会泄露原生机房 IP
• 授权链路是否与目标环境保持一致
• SSH 断开或系统重启后服务是否还能自动恢复
• 客户端配置是否统一且易于维护

这篇文章的重点不是“临时跑通一次”，而是整理出一套能用于长期维护的 AI 系统运维流程。

核心架构

适用场景

• 需要把 Claude 使用能力封装成统一 API 接口
• 需要在 VPS 上长期常驻服务
• 需要让特定进程走住宅代理，而不是整机全局代理
• 需要为 Claude Code 等客户端提供稳定入口
• 需要一套可以复用、验证、排障的运维文档

准备工作

在开始前，至少准备好以下资源：

1. VPS：建议 Ubuntu 22.04+
2. 住宅代理：支持 SOCKS5 的静态住宅 IP
3. Claude 账号：具备对应使用权限
4. 本地浏览器环境：用于最终授权接力

整体部署流程

第一阶段：系统加固与常驻

目标是让服务具备“掉线不掉进程、重启可恢复”的基础条件。

1. 开启用户进程常驻

loginctl enable-linger root

2. 预检当前机房 IP

curl ip.sb

记录当前 VPS 的原生机房 IP，后面做代理验证时要拿它做对照。

第二阶段：安装与 Systemd 隔离配置

这一阶段的关键，不是“把程序安装上去”，而是“让程序的网络出口可控”。

1. 一键安装 CLIProxyAPI

curl -fsSL https://raw.githubusercontent.com/brokechubb/cliproxyapi-installer/refs/heads/master/cliproxyapi-installer | bash

2. 编辑 Systemd User Service

nano /root/.config/systemd/user/cliproxyapi.service

建议写成如下结构：

[Unit]
Description=CLIProxyAPI Service
After=network.target
 
[Service]
Type=simple
WorkingDirectory=/root/cliproxyapi
ExecStart=/root/cliproxyapi/cli-proxy-api
Restart=always
RestartSec=10
Environment=HOME=/root
# 代理格式示例：socks5h://用户名:密码@IP:端口
Environment="HTTP_PROXY=socks5h://<USER>:<PASS>@<PROXY_IP>:<PORT>"
Environment="HTTPS_PROXY=socks5h://<USER>:<PASS>@<PROXY_IP>:<PORT>"
Environment="ALL_PROXY=socks5h://<USER>:<PASS>@<PROXY_IP>:<PORT>"
 
[Install]
WantedBy=default.target

3. 为什么要这样配

这样做的价值在于：

• 代理只注入目标服务进程
• 系统其他操作不必强制走代理
• 问题定位更清楚
• 出口策略更容易验证

第三阶段：零风险 Fail-Safe 物理验证

这是整篇文章里最重要的一段。不要跳过。

验证目标

你要确认两件事：

1. 服务正常运行时，出口确实是住宅 IP
2. 代理异常时，服务会失败退出，而不是偷偷回落到机房 IP

1. 临时把 ExecStart 改成探测器

ExecStart=/usr/bin/bash -c "curl -s http://ip.sb"

2. 执行验证三步

systemctl --user daemon-reload
systemctl --user restart cliproxyapi.service
journalctl --user -u cliproxyapi.service -n 10

3. 结果判定

• 成功：日志输出的是你的住宅 IP
• Fail-Safe 成功：如果故意填错代理信息，日志应显示连接失败，例如 status=7/NOTRUN
• 需要排查：如果日志出现的是 VPS 原生机房 IP，说明隔离策略没有真正生效

4. 验证完成后还原服务启动命令

把 ExecStart 改回原来的程序路径，然后重新执行：

systemctl --user daemon-reload

第四阶段：最高安全等级授权

这一阶段的目标，是让本地浏览器与 VPS 端的授权动作尽量保持同一网络策略下完成。

对应命令如下：

cd /root/cliproxyapi
ALL_PROXY=socks5h://<USER>:<PASS>@<PROXY_IP>:<PORT> ./cli-proxy-api --claude-login --no-browser

成功标志通常是：

• 终端显示 Login Successful
• 服务能够继续进入后续正式运行阶段

第五阶段：正式投产

当隔离、验证、授权都完成后，再进入正式启用阶段。

启动服务

systemctl --user enable cliproxyapi.service
systemctl --user restart cliproxyapi.service

查看管理后台

http://<VPS_IP>:8317/management.html

这里可以用于做基础状态观察与运行监控。

第六阶段：客户端配置

如果要接入 Claude Code，可在本地配置中写入统一接口信息。

{
  "env": {
    "ANTHROPIC_AUTH_TOKEN": "<你在 config.yaml 中自定义的 Key>",
    "ANTHROPIC_BASE_URL": "http://<VPS_IP>:8317/v1",
    "ANTHROPIC_MODEL": "claude-sonnet-4-5-20250929"
  }
}

运维检查清单

上线前建议逐项确认：

• 已开启 linger，服务支持常驻
• 已记录 VPS 原生机房 IP
• Systemd 环境变量已写入正确代理信息
• 已验证正常情况下输出住宅 IP
• 已验证错误代理情况下不会回落到机房 IP
• 已完成授权接力并确认登录成功
• 已能通过管理后台观察服务状态
• 已完成 Claude Code 或其他客户端接入

深度运维 FAQ

为什么不用 Docker？

在这个场景下，Systemd 对进程级环境变量的控制更直接，验证路径也更清晰，尤其适合配合 curl 做出口探测。

住宅代理失效了怎么办？

如果 Fail-Safe 配置正确，服务会直接停止工作，而不是继续走原生机房 IP。此时更换新代理并重启服务即可。

如何确认运行中的进程真的加载了代理变量？

cat /proc/$(pgrep cli-proxy-api)/environ | tr '\0' '\n' | grep _PROXY

哪些地方最容易出问题？

最常见的是：

• 代理地址填错
• 只配置了某一个 _PROXY 变量
• 修改了 service 文件但没有 daemon-reload
• 授权阶段本地浏览器与 VPS 端网络策略不一致
• 只做了正向验证，没有做反向失效测试

后续优化方向

后续根据反馈继续补充：

• 多代理供应商对比
• 多客户端接入模板
• 管理后台监控指标说明
• 常见报错排查手册
• VPS 安全加固补充清单