Nginx on BINGBlog

把 dsh 挂上公网：两道闸与自动登录

Thu, 17 Sep 2026 17:00:00 +0800

dsh（DeepSeek Harness）是 DeepSeek 开源的 agent harness，有 CLI 也有 Web UI，默认只监听 127.0.0.1:3080，CLI 明确拒绝 --host 0.0.0.0。它自带启动 token 与签名 cookie 两道鉴权，但没有 TLS、没有账号体系，官方也把「网络部署」列为不支持。想在服务器上用，就得自己在前面架一层。下面是完整过程，机器是 Azure 上那台 892MB 的小 VPS。

一、为什么不能直接开出去

dsh 的 Web 宿主在 /api 前缀上有一道「浏览器信任栅栏」，代码注释写得很直白：它挡的是 DNS rebinding 和跨站请求，不是身份认证。

检查	规则
Host	必须是回环地址，或与 `--trusted-host` 声明的 authority 匹配
Origin（带了才查）	必须与 Host 完全一致
`sec-fetch-site`	`cross-site` 一律拒
POST 媒体类型	必须是 `application/json`，否则 415

认证是另一层：每个进程随机生成一个启动 token，只有 GET /?token=... 能把它换成签名 cookie（HttpOnly、SameSite=Strict、绑定 host:port、默认 30 天）。token 不落盘、每次启动都变；签名密钥存在 $DSH_HOME/.credentials.yaml，所以 cookie 能跨重启继续用。

两条结论直接决定反代怎么写：

Host 必须原样转发。写成 $host:443 会当场 403 —— 浏览器发来的 Origin 是 https://域名，归一化后不带端口，和 host:443 对不上。
必须传 --trusted-host <域名>，否则 /api 全部被 Host 栅栏拒掉。

二、安装与首启

sudo useradd -m -s /bin/bash dsh # 独立账号，不进 sudo 组
sudo npm i -g @deepseek-ai/dsh # 本次装到 0.1.5-rc.1

首次启动会从内置模板生成 profile（$DSH_HOME/profiles，要装一批插件依赖），所以第一遍慢一些：

sudo -u dsh env HOME=/home/dsh DSH_HOME=/home/dsh/.dsh \
 dsh web --port 3080 --no-open --trusted-host dsh-xxxx.你的域名

# dsh web: http://127.0.0.1:3080/?token=...

--no-open 不弹浏览器，--trusted-host 只扩信任栅栏，不给身份。

三、systemd 托管

机器只有 892MB 内存，必须给上限；再按 RCE 服务的标准一并做隔离：

# /etc/systemd/system/dsh-web.service
[Unit]
Description=DeepSeek Harness (dsh) Web UI
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=dsh
Group=dsh
WorkingDirectory=/home/dsh/workspace # 工作区就是启动目录
Environment=HOME=/home/dsh
Environment=DSH_HOME=/home/dsh/.dsh
EnvironmentFile=/etc/dsh/dsh.env # DEEPSEEK_API_KEY，600 root
ExecStart=/usr/bin/dsh web --port 3080 --no-open --trusted-host dsh-xxxx.你的域名
Restart=always
RestartSec=5

MemoryMax=800M
TasksMax=512

NoNewPrivileges=true
PrivateTmp=true
PrivateDevices=true
ProtectSystem=strict
ProtectHome=read-only
ReadWritePaths=/home/dsh
ProtectKernelTunables=true
ProtectKernelModules=true
ProtectControlGroups=true
RestrictSUIDSGID=true
LockPersonality=true
CapabilityBoundingSet=
AmbientCapabilities=
RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6 AF_NETLINK
UMask=0077

[Install]
WantedBy=multi-user.target

ProtectSystem=strict 把整个根文件系统挂成只读，唯一能写的是 ReadWritePaths 指定的 /home/dsh。systemd-analyze security dsh-web 实测 4.1 OK。

四、Key 走环境变量

内置的 llm-deepseek 适配器默认凭据引用就是 DEEPSEEK_API_KEY，用 systemd EnvironmentFile 注入：

# /etc/dsh/dsh.env（600 root:root）
DEEPSEEK_API_KEY=sk-xxxxxxxx

由环境变量供值的引用在 Web 设置里是只读的（writable: false），key 不进应用可写状态，轮换只要改这个文件加一次 restart。

五、公网入口

为什么用子域名

dsh 前端是标准 SPA，静态资源与 /api 都走绝对路径，用路径前缀反代要动一堆地方，cookie 的 authority 绑定也更绕。子域名最省事；没有域名就用 sslip.io：dsh-xxxx.<IP>.sslip.io 会解析到那个 IP，Let’s Encrypt 照签。

随机子域名本身当第一层"隐藏"：串不可猜。证书用 webroot 签，80 端口的 server 块只放行 ACME 校验：

location ^~ /.well-known/acme-challenge/ { root /var/www/html; auth_basic off; }

sudo certbot certonly --webroot -w /var/www/html -d dsh-xxxx.你的域名

# Basic Auth 账号，密码用 openssl 生成 apr1 哈希（服务器上没装 htpasswd 也能用）
printf 'dsh:%s\n' "$(openssl passwd -apr1 "$PASS")" \
 | sudo install -m 640 -o root -g www-data /dev/stdin /etc/nginx/.htpasswd-dsh

反代与限速

server {
 listen 443 ssl;
 server_name dsh-xxxx.你的域名; # 只有这个名字能进

 auth_basic "DeepSeek Harness"; # 第一道闸
 auth_basic_user_file /etc/nginx/.htpasswd-dsh;
 limit_req zone=dsh_zone burst=120 nodelay;
 client_max_body_size 100m;

 location / {
 proxy_pass http://127.0.0.1:3080;
 proxy_http_version 1.1;
 proxy_set_header Host $host; # 不带端口，理由见第一节
 proxy_set_header Upgrade $http_upgrade;
 proxy_set_header Connection $connection_upgrade;
 proxy_buffering off; # SSE / 流式必需
 proxy_read_timeout 3600s; # 长任务别被 60s 掐断
 proxy_request_buffering off;
 }
}

六、第二道闸的坑

只过 Basic Auth 会被 dsh 自己挡住：

dsh web authentication required; reopen the URL printed by dsh web.

这是启动 token 那道闸。手动过的话，从服务日志里捞当前进程的 URL：

journalctl -u dsh-web -o cat | grep -o 'token=[A-Za-z0-9_-]*' | tail -1

两个容易踩的点：

上游返回的 401 不会触发 error_page：nginx 默认 proxy_intercept_errors off，只拦自己产生的错误码，要在这个 location 里显式打开
map $http_upgrade $connection_upgrade 得定义在 http 块；漏了 WebSocket 升级会失败，页面上表现为一直转圈

七、让闸门无感

token 每进程都在 journal 里，可以让 nginx 自己拿它换 cookie：首页拿到 401 时内部重试一次带 token 的请求，把 303 + Set-Cookie 原样透给浏览器。浏览器地址栏全程不带 token，比手动粘贴 URL 更干净。

location = / {
 error_page 401 = @dsh_login;
 proxy_intercept_errors on; # 关键：否则不触发 error_page
 proxy_pass http://127.0.0.1:3080;
}

location @dsh_login {
 proxy_pass http://127.0.0.1:3080/?token=$dsh_launch_token;
}

$dsh_launch_token 由一个小脚本同步：从 journal 取当前进程 token，写进 /etc/nginx/conf.d/dsh-token.conf 里的 map，再 reload nginx。挂到服务启动钩子上，重启后 token 自动跟上：

# /etc/systemd/system/dsh-web.service.d/token-sync.conf
[Service]
ExecStartPost=+/usr/local/bin/dsh-token-sync # + 前缀 = 以 root 跑，才能读 journal、reload nginx

代价要说清楚：这样一来对外实际只剩 Basic Auth 一道闸，加上它前面的随机子域名。想恢复两道闸，屏蔽掉内部重试即可：

sudo touch /etc/dsh/auto-login.off && sudo dsh-token-sync --now # 关
sudo rm /etc/dsh/auto-login.off && sudo dsh-token-sync --now # 开

八、验证

鉴权矩阵，全部从公网入口测：

请求	结果
无 Basic Auth	401
密码错误	401
Basic Auth、无 cookie	303 + Set-Cookie（自动登录）
Basic Auth、带 cookie	200
直连 `127.0.0.1:3080` 并伪造 `Host: localhost`	401（信任栅栏与 cookie 双查）

最后用无头浏览器跑一轮真实任务，确认 /api、工具调用、模型都通：

九、隔离与限制

同机隔离：dsh 能执行任意命令，这台机器上还跑着网关和博客，它的进程不该读到后者的凭据。除 ProtectHome=read-only 外再补一条 ACL，把整个家目录对它关掉：

sudo setfacl -m u:dsh:--- /home/你的用户 # 撤销：sudo setfacl -x u:dsh /home/你的用户

同机其他服务的家目录里若有 world-readable 的凭据文件（~/.cli-proxy-api/config.yaml、~/.pi、~/.codex），一并收成 700。

设置页在非回环访问下不可用：客户端会判断页面自身是不是 loopback，不是就把设置持久化降级成内存（源码里是 isLoopback ? 'host' : 'memory'），于是「设置 → 模型」直接报 settings are unavailable in this browser。模型与凭据都改服务端文件：

# /home/dsh/.dsh/settings.yaml，改完下一次请求生效，不用重启
llm-deepseek:
 reasoningEffort: high

公网暴露 RCE 的现实：过了 Basic Auth 就是一个能跑命令的 agent。密码用 24 位随机串、限定单域名、开限速，能做的都做了；要更稳就关掉自动登录，只用一次性 token URL 进。

小结

dsh 默认只回环，反代要原样转发 Host 并传 --trusted-host，否则 /api 被信任栅栏拒掉
上游 401 不触发 error_page，proxy_intercept_errors on 是自动换 cookie 的前提
token 每进程轮换、cookie 签名密钥持久化；用 ExecStartPost=+脚本 把 token 同步给 nginx，重启后进入无感
按 RCE 服务对待：独立用户、只读根、只写自己 home、清空 capability，再用 ACL 挡住同机其他家目录
非回环页面的设置页是禁用的，模型与凭据统一走 settings.yaml 和环境变量

用 CLIProxyAPI 在服务器搭多上游统一网关

Thu, 17 Sep 2026 01:30:00 +0800

同时用几个 AI 上游很麻烦：每个都要单独配 key、单独改客户端，额度也各管各的。用 CLIProxyAPI 在服务器上把它们聚合成一个端点，对外只给一把 key，客户端改个 base_url 就能用，/model 随时切模型。下面是完整部署流程，新服务器按顺序执行即可。

适用场景

多上游自用：官方 OAuth 与第三方 API 共用一个 base_url，/model 切模型不用改配置；服务器在境外且国内可直连（本文是日本节点）时，客户端也不必自己再挂代理
对外分发：账号额度用不完（比如 GPT Pro 20x），装到服务器上就能公网分发——本机版只能服务自己或局域网，一把 key 给团队 / 朋友，不用再搭 VPN
多客户端复用：Codex、Claude Code、Gemini CLI、Cursor 等共用同一把 key，新增或替换上游时客户端不动

一、准备

项	说明
服务器	能跑 nginx 的 Linux（本文 Ubuntu 24.04），CPA 常驻内存约 57MB
域名 + 证书	反代必须有 HTTPS；没有就用 `certbot --nginx -d 你的域名` 申请
nginx	反代与鉴权都在这一层
上游账号（可选）	ChatGPT / Claude / xAI / Kimi 等任一，用于 OAuth 登录
第三方 Key（可选）	DeepSeek 等 OpenAI 兼容服务，官方额度用完后接管

版本：CPA v7.3.4、codex-cli 0.154.0。

二、安装 CPA

cd /tmp
curl -fsSL -o cpa.tar.gz \
 https://github.com/router-for-me/CLIProxyAPI/releases/download/v7.3.4/CLIProxyAPI_7.3.4_linux_amd64.tar.gz
tar xzf cpa.tar.gz
mkdir -p ~/cliproxyapi
install -m 0755 cli-proxy-api ~/cliproxyapi/cli-proxy-api

单文件 Go 程序，约 64MB。用 systemd 托管：

# /etc/systemd/system/cli-proxy-api.service
[Unit]
Description=CLIProxyAPI - unified upstream gateway
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=azureuser # 改成你的运行用户
WorkingDirectory=/home/azureuser/cliproxyapi
ExecStart=/home/azureuser/cliproxyapi/cli-proxy-api -config /home/azureuser/.cli-proxy-api/config.yaml
Restart=on-failure
RestartSec=3
MemoryMax=384M

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now cli-proxy-api

三、写配置

~/.cli-proxy-api/config.yaml：

# 只监听本机：公网必须先过 nginx
host: "127.0.0.1"
port: 8317

remote-management:
 allow-remote: true # 反代场景建议 true
 secret-key: "管理密钥" # 明文填，启动时自动 bcrypt 加密回写

auth-dir: "/home/azureuser/.cli-proxy-api" # OAuth 凭证目录

api-keys: # 客户端访问 CPA 用的密钥
 - "sk-cpa-xxxxxxxx"

debug: false

三个关键点：

host 绑 127.0.0.1，公网只能从 nginx 进
secret-key 管管理接口，api-keys 管客户端调用，两者别混
上游 provider 全部在管理面板里配，配置文件保持干净

四、登录上游账号

CPA 内置多种 OAuth 登录，按需挑：

上游	命令
ChatGPT / Codex	`-codex-device-login`（服务器）、`-codex-login`（本机浏览器）
Claude	`-claude-login`
xAI	`-xai-login`
Kimi	`-kimi-login`
Meta	`-meta-login`
Devin	`-devin-login`
Antigravity	`-antigravity-login`
Google Vertex	`-vertex-import 服务账号.json`

以无浏览器的服务器为例，用设备码登录 Codex：

./cli-proxy-api -config ~/.cli-proxy-api/config.yaml -codex-device-login
# Codex device URL: https://auth.openai.com/codex/device
# Codex device code: XXXX-XXXX

打开网址输码授权，凭证落到 auth-dir。

当然也可以直接在 Web 面板里点「认证文件 → 对应上游 → 发起登录」。OAuth 回调端口被占用时用 -oauth-callback-port 指定，无浏览器加 -no-browser。

⚠️ 不要照搬教程里的 forced_login_method = "api" / preferred_auth_method = "apikey"：已有 ChatGPT 登录态时，Codex 会判定「要用 API key 登录」，登出并删掉 auth.json。加 provider 只靠 env_key。

五、nginx 反代分发（核心）

CPA 只监听本机，对外必须经 nginx。策略：隐藏路径 + Basic Auth + 限速，三条路径分开管面板页、管理 API、客户端 API。

1. 建账号密码

sudo htpasswd -c /etc/nginx/.htpasswd-cpa cpadmin # 没有 htpasswd 就先装 apache2-utils

2. 写反代片段

# /etc/nginx/snippets/cpa.conf（用 include 引入 server 块）

# 限速区（放 http 块；已定义过就跳过）
limit_req_zone $binary_remote_addr zone=admin_zone:10m rate=10r/m;

location = /cpa-adm-XXXXXXXX { return 301 /cpa-adm-XXXXXXXX/management.html; }
location = /cpa-adm-XXXXXXXX/ { return 301 /cpa-adm-XXXXXXXX/management.html; }

# ① 面板静态页：Basic Auth + 限速
location ^~ /cpa-adm-XXXXXXXX/ {
 auth_basic "CPA Admin";
 auth_basic_user_file /etc/nginx/.htpasswd-cpa;
 limit_req zone=admin_zone burst=60 nodelay;
 proxy_pass http://127.0.0.1:8317/;
 proxy_http_version 1.1;
 proxy_set_header Host $host;
 proxy_set_header X-Real-IP $remote_addr;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_set_header X-Forwarded-Proto $scheme;
 proxy_buffering off; # SSE / 流式必需
 proxy_read_timeout 3600s; # 长任务别被 60s 掐断
 client_max_body_size 200m;
}

# ② 管理 API：面板默认就调这里，鉴权交给 CPA
location ^~ /v0/ {
 proxy_pass http://127.0.0.1:8317/v0/;
 proxy_set_header Host $host;
 proxy_set_header X-Real-IP $remote_addr;
 proxy_buffering off;
}

# ③ 客户端 API：隐藏路径 + api-key
location ^~ /cpa-api-XXXXXXXX/ {
 proxy_pass http://127.0.0.1:8317/;
 proxy_set_header Host $host;
 proxy_set_header X-Real-IP $remote_addr;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_buffering off;
 proxy_read_timeout 3600s;
 client_max_body_size 200m;
}

XXXXXXXX 换成自己的随机串（路径本身就是一层防护）。没有现成 server 块的话，最小骨架：

server {
 listen 443 ssl;
 server_name 你的域名;
 ssl_certificate /etc/letsencrypt/live/你的域名/fullchain.pem;
 ssl_certificate_key /etc/letsencrypt/live/你的域名/privkey.pem;
 include /etc/nginx/snippets/cpa.conf;
}

3. 为什么要拆路径

nginx 的 auth_basic 用 Authorization: Basic ... 认证，而 CPA 面板用 Authorization: Bearer <管理密钥> 调 API（management.html 里写死了 Bearer ${managementKey}）。两者共用同一个头：Bearer 会顶掉 Basic，auth_basic 直接 401；用变量喂空值也不会关闭认证（实测返回 realm="" 的 401）。

所以面板页归 Basic Auth，管理 API 走一条不带 auth_basic 的路径，由 CPA 自己校验密钥；客户端 API 再走一条隐藏路径：

路径	用途	鉴权
`/cpa-adm-XXXXXXXX/`	面板静态页	Basic Auth
`/v0/`	管理 API（面板默认调用）	CPA 管理密钥（Bearer）
`/cpa-api-XXXXXXXX/v1/`	客户端 API	CPA api-key（Bearer）

4. 面板默认服务地址不带路径

面板取的是 window.location 里不带路径的协议 + 域名 + 端口：

$f = () => {
 const { protocol, hostname, port } = window.location;
 return Zf(`${protocol}//${hostname}${port ? `:${port}` : ""}`);
};

所以请求会打到 https://域名/v0/management/...（根路径），而不是 /cpa-mgmt-.../ 下的那条。这样配会 404，nginx 日志里能看到 /v0/management/config 没有路由。

两个解法：面板里手动把服务地址填全，或在 nginx 补一条根路径 /v0/ 路由。上面片段用的是后者。

改完检查并重载：

sudo nginx -t && sudo systemctl reload nginx

六、接入第三方 API（以 DeepSeek 为例）

登录面板（https://域名/cpa-adm-XXXXXXXX/management.html）后，在「提供商」里加一条 OpenAI 兼容：

字段	值
名称	`deepseek`
base-url	`https://api.deepseek.com`
api-key	DeepSeek 的 `sk-...`
模型	`deepseek-flash`（要更大就再加 `deepseek-v4-pro`）

base-url 带不带 /v1 都行；alias 留空会用 name 当模型名。

任何 OpenAI 兼容服务同理：填 base-url + api-key 即可，官方 OAuth 与这些第三方模型会一起出现在 /v1/models 里。保存后面板会把配置写回 config.yaml 并热重载，无需重启。

七、验证

三种协议各测一遍（走公网入口）：

BASE=https://域名/cpa-api-XXXXXXXX/v1
KEY=sk-cpa-xxxxxxxx

# 1) 模型列表（官方 OAuth 与第三方模型的合集）
curl -s "$BASE/models" -H "Authorization: Bearer $KEY"

# 2) OpenAI 协议
curl -s "$BASE/chat/completions" -H "Authorization: Bearer $KEY" \
 -H "Content-Type: application/json" \
 -d '{"model":"deepseek-flash","messages":[{"role":"user","content":"回复：A-OK"}]}'
# → A-OK

# 3) Responses 协议（Codex 用的就是它）
curl -s "$BASE/responses" -H "Authorization: Bearer $KEY" \
 -H "Content-Type: application/json" \
 -d '{"model":"deepseek-flash","input":"回复：R-OK"}'

鉴权矩阵（都应满足）：

面板页 无认证 → 401
面板页 Basic → 200
管理API 正确 Bearer → 200
管理API 错误/无 密钥 → 401
分发API 正确 key → 200
分发API 无 key → 401

八、客户端接入

Codex 指向 CPA（~/.codex/config.toml）：

model_provider = "cpa"
model = "gpt-5.6-sol"

[model_providers.cpa]
name = "CPA"
base_url = "http://127.0.0.1:8317/v1"
experimental_bearer_token = "sk-cpa-xxxxxxxx"
wire_api = "responses"
supports_websockets = true

/model 里会同时出现官方 OAuth 的模型和第三方模型，额度用光时切过去，会话不断。

分发给其他客户端（同一把 key）：

# OpenAI 兼容
OPENAI_BASE_URL = https://域名/cpa-api-XXXXXXXX/v1
OPENAI_API_KEY = sk-cpa-xxxxxxxx

# Claude Code
export ANTHROPIC_BASE_URL="https://域名/cpa-api-XXXXXXXX"
export ANTHROPIC_AUTH_TOKEN="sk-cpa-xxxxxxxx"

九、安全与分发建议

CPA 只绑 127.0.0.1，公网必须过 nginx（HTTPS）
面板页 Basic Auth + 管理密钥双因素；管理 API 连续 5 次失败封禁约 30 分钟
客户端 API 只靠 api-key，可随时增删（泄露一个删一个）
隐藏路径 + 限速，降低被扫概率

风险：分发出去的官方模型请求烧的是自己账号的额度，给的人越多越可能封号。分发给不熟的人，建议只发第三方付费模型（按量计费）或加 IP 白名单。

附录：为什么需要这层网关

/model 弹出的是当前 provider 的模型目录，切的是模型 slug，不是 provider。翻 Codex 源码可确认：ModelPreset 没有 provider 字段。

pub struct ModelPreset {
 pub id: String,
 pub model: String, // 只有模型 slug
 pub display_name: String,
 // ... 没有 provider
}

会话里 provider 固定，想在多个上游之间切只有两条路：退出后用不同 --profile 重开，或把上游合成一个 provider——后者就是第 2–6 节做的事。

小结

部署顺序：装 CPA → 写配置 → 登录上游 → nginx 反代 → 加第三方 API → 验证
登录方式按上游选：Codex 用设备码，Claude/xAI/Kimi 等用对应 -xxx-login，Vertex 导入服务账号
反代必须拆路径：面板页走 Basic Auth，管理/客户端 API 走 Bearer
面板默认服务地址不带路径，记得补 /v0/ 路由
网关让客户端只配一个 base_url 就能跨上游切换；对外分发的额度风险要提前评估