在VPS上搭一个能调用Claude API的私有聊天服务，这件事的难点不在“部署”这个动作本身，而在部署之前的那个判断：你打算让这台机器怎么连上Anthropic的API。如果VPS本身在国内，直连api.anthropic.com基本走不通，这不是配置问题，是链路层面的限制。所以“一键部署”之前，得先把网络路径想清楚，否则脚本跑完了，界面也打开了，一发消息就报错，那种挫败感比命令行报错还难受。

　　下面以Open WebUI作为前端方案来展开。它本身是一个自托管的Web聊天界面，支持通过Pipeline接入Anthropic的API，部署方式成熟，社区文档也够用。另一个选择是LibreChat，配置思路类似，但Open WebUI的Pipeline机制对Claude模型的支持更直接一些，包括动态模型列表和扩展思考模式。

　　先决条件：VPS上需要有什么

　　硬件层面不需要太苛刻。Open WebUI跑起来本身占不了多少内存，主要的开销在Python环境和向量数据库(如果启用RAG功能)。一台1核2G的VPS足够跑通基础聊天，但如果要同时开RAG做文档检索，2G会紧，4G更稳妥。操作系统用Debian 12或Ubuntu 22.04以上，Docker的安装最省事。

　　最关键的前置条件是：VPS必须能稳定访问Anthropic的API端点。如果你的VPS在香港或海外，这一步天然满足。如果VPS在国内，需要先解决出口问题，否则后面所有步骤都会卡在curl测试那一步。判断方法很简单，在VPS上执行：

curl -sS -o /dev/null -w "%{http_code}" https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{"model":"claude-3-haiku-20240307","max_tokens":10,"messages":[{"role":"user","content":"hi"}]}'

　　返回200说明链路通，返回403或超时，说明网络层还没解决，先别往下走。

　　另外需要准备一个Anthropic API Key。在platform.claude.com的settings/keys页面生成。这个Key只在服务端使用，不会暴露给聊天前端。

　　部署Open WebUI

　　官方推荐的Docker方式最不容易出错。先确认Docker和Docker Compose已经装好，然后拉取镜像并启动：

docker run -d \
  --name open-webui \
  --restart always \
  -p 3000:8080 \
  -v open-webui:/app/backend/data \
  -e ANTHROPIC_API_KEY="sk-ant-xxxxxxxx" \
  ghcr.io/open-webui/open-webui:main

　　-v open-webui:/app/backend/data把数据持久化到Docker volume里，容器重建不会丢聊天记录和配置。-e ANTHROPIC_API_KEY把Key注入环境变量，Open WebUI的Anthropic Pipeline会读取它。端口映射到宿主机的3000，稍后在浏览器访问http://你的VPS_IP:3000。

　　容器启动后，Open WebUI默认会加载内置的Pipeline。但Anthropic的支持在社区版里是以Pipeline文件形式存在的，需要确认它是否已经就位。检查方法：进入容器看/app/backend/open_webui/pipelines/目录下有没有anthropic.py。如果没有，需要手动放进去并重启容器。社区维护的Pipeline版本比内置的更完整，支持动态获取模型列表、prompt caching统计和扩展思考模式。

　　配置Anthropic Pipeline

　　Pipeline放好之后，还需要在Open WebUI的管理界面里启用它。用管理员账号登录(第一个注册的账号自动成为管理员)，进入Admin Panel → Settings → Pipelines，应该能看到Anthropic的条目。如果看不到，检查容器日志：

docker logs open-webui --tail 100 | grep -i pipeline

　　常见的报错是ModuleNotFoundError: No module named 'anthropic'，说明Pipeline依赖的Python包没装。进入容器手动安装：

docker exec -it open-webui pip install anthropic
docker restart open-webui

　　Pipeline加载成功后，在聊天界面的模型下拉列表里应该能看到Claude的模型。如果只看到默认的Ollama模型，说明Pipeline没有被正确识别。回到Pipelines页面，确认Anthropic条目旁边的开关是开启状态，并且ANTHROPIC_API_KEY那一栏填的是你的Key(如果环境变量没生效的话)。

　　一个容易忽略的细节：Open WebUI的Pipeline配置里有一个ANTHROPIC_BASE_URL选项，默认指向官方端点。如果你的VPS通过某种中转或网关访问API，在这里填入网关地址。但要注意，中转层如果对请求体做了任何解析和重组，Claude的Prompt Cache会全部失效，因为cache命中依赖messages数组的字节级哈希一致性。正确的透传方式是原样转发request.body，不在中间层做JSON解析。

　　反向代理与访问控制

　　直接暴露3000端口在公网上不是个好主意。Open WebUI本身有登录鉴权，但缺少传输层加密意味着密码在网络上明文传输。用Nginx或Caddy加一层HTTPS是必须的。

　　Caddy的配置最简洁，假设你已经把域名解析到VPS的IP：

chat.yourdomain.com {
    reverse_proxy localhost:3000
}

　　Caddy会自动申请Let‘s Encrypt证书并处理续期。Nginx的方案需要额外配置certbot，步骤多一些，但如果你已经熟悉Nginx的配置结构，也不复杂。

　　还有一个安全层面的建议：Open WebUI默认允许任何人注册账号，第一个注册的是管理员，后续注册的是普通用户。如果你的服务只给自己或小团队用，在Admin Panel → Settings → General里把Enable New Sign Ups关掉，然后手动创建需要的账号。公开注册的聊天界面加上你的API Key在后台跑，等于把账单控制权交给了第一个发现这个地址的人。

　　注意事项：那些部署完才会浮现的问题

　　API Key的额度与模型选择。 Claude API按token计费，不同模型的价格差距很大。Opus最贵，Haiku最便宜。在Open WebUI的模型设置里，可以把不常用的贵模型隐藏掉，只保留Sonnet或Haiku作为默认。如果只是个人日常问答，Haiku的性价比足够，响应速度也快。

　　对话历史与上下文长度。 Claude的上下文窗口很大，但每轮对话都会把历史消息重新发给API，意味着长对话的token消耗是累积的。Open WebUI默认会带上完整历史，在Settings → General里可以限制带入的对话轮数。对于成本敏感的场景，把历史限制在最近10到20轮是合理的折中。

　　VPS的出口IP稳定性。 如果你的VPS通过代理或网关访问Anthropic，那个出口IP如果被大量用户共享，可能会触发Anthropic的风控。表现是间歇性的403或429错误。自建服务的好处是出口相对干净，但如果用的是公共中转，这个问题无法完全避免。一个判断方法是看错误是否集中在特定时段出现，如果是，多半是上游IP池被标记了，而不是你的配置问题。

　　数据持久化。 Docker volume的方式已经能保住数据，但如果VPS本身出问题，volume也跟着丢。定期把/app/backend/data目录备份到其他地方(对象存储或另一台机器)是值得养成的习惯。聊天记录里可能有你不想丢的内容，而重建一个Open WebUI实例只需要一条docker run命令，数据没了就是没了。

　　这套方案的核心逻辑是把“模型调用”和“界面呈现”拆开：Open WebUI负责聊天体验，Anthropic API负责推理，VPS只做承载和转发。部署本身是机械性的，照着命令执行就能跑起来。真正需要你提前想清楚的是两件事：VPS到API的链路是否通畅，以及你打算为这个聊天服务花多少token钱。前者决定它能不能用，后者决定它值不值得一直用下去。把这两个问题解决了，剩下的步骤只是把命令敲对。