受信主机部署：DSH Web 反向代理后部分设置接口 403，部分配置仍无法持久化保存

[roojay]

把 dsh web 放在 Cloudflare Tunnel 和 Access 后面，DSH 本身仍然只监听 127.0.0.1:3080：

浏览器
  → Cloudflare Tunnel + Access
    → 127.0.0.1:3080
      dsh web --port 3080 --trusted-host <公网域名>

公网入口有身份认证，源站端口不对外开放，--trusted-host 填的是浏览器实际访问的域名。配置完成后，host.describe、llm.providers、events.mux 等接口都能正常访问，但设置、凭据和 Agent 预设相关接口仍然返回 403：

transport failure for /api/settings.describe: HTTP 403

把这层 403 处理掉后，又遇到了第二个问题：语言、外观、Composer Enter 等设置当时可以修改，刷新页面或重启 dsh web 后就会恢复原状，$DSH_HOME/settings.yaml 里也没有对应配置。

--trusted-host 不会放行这组方法

在 @deepseek-ai/dsh-client-connection 0.1.0-rc.6 中，普通 /api 请求会用 trustedHosts 判断请求是否可信。源码另外把 15 个方法放进 PRIVILEGED_METHODS，再次检查时传入空的信任列表，所以它们始终只接受回环 Host。

[官方中文文档](https://github.com/deepseek-ai/deepseek-harness/blob/master/packages/client/connection/README.zh.md) 对这组方法有更具体的分类：

• settings.*、credentials.* 和 llm.discoverModels 属于设置与凭据的配置面；
• host.pickDirectory 和 host.openPath 会操作 Host 桌面；
• agentPreset.read、copy、openDocument、remove 属于 Agent 预设创作面。

即使请求的 Host 已经列在 --trusted-host 中，这些配置和 Host 操作仍然无法通过第二次检查。

这个默认值有安全上的理由。trustedHosts 是 /api 浏览器信任栅栏的一部分，主要防御 DNS rebinding，不负责验证用户身份。设置、凭据、目录操作和模型发现都涉及本机配置或本机能力，在没有远程认证时只允许回环访问是合理的。现在缺少的是一个明确的 opt-in，供已经部署认证层或网络隔离的用户自行开放这些方法。

[Discussion #1054](#1054) 向上游反馈了这个问题。另一个相关讨论是 [#397](#397) ，不过它还涉及开放 --host 0.0.0.0。为了安全部署不需要修改监听地址，也不建议把开放监听作为解决 403 的条件。

接口恢复后，浏览器仍然不保存设置

写了个插件允许服务端放行这些请求后，非回环页面上的设置仍然使用 persistence: "memory"。这是官方 SettingsScopeController 的默认行为：设置只保留在当前页面，不向 Host 读写。

页面刷新后，语言和外观等选项会重新读取默认值。

给上游的建议

默认行为可以继续保持不变：设置与凭据配置面、Host 原生操作和 Agent 预设创作面仍然只允许回环访问，CLI 也继续拒绝 --host 0.0.0.0。[Discussion #130](#130) 已经说明，HTTP 客户端可以伪造 Host: 127.0.0.1，所以回环 Host 并不能证明请求真的来自回环网络。

在此基础上，可以给 connection 增加一个显式配置，例如：

privilegedAuthority: trusted-host

不开启时沿用现在的空信任列表；开启后，这组只限回环的方法使用与 --trusted-host 相同的列表做第二次检查。#1054 中提到的 --allow-remote-settings 也能表达基本意图，不过实际开放范围还包括凭据、Host 原生操作、Agent 预设和模型发现，privilegedAuthority 与实际范围更一致。

同一个配置还需要传到浏览器端。当前 Host 受信并且 opt-in 已启用时，语言、外观等用户设置应使用 host 持久化，写入 $DSH_HOME/settings.yaml。会话草稿和临时界面状态仍然可以留在浏览器内存中。

文档也需要明确说明，这个开关和 --trusted-host 都不是身份认证。启用前，入口必须已经有 Access、其他认证层或等效的网络隔离。

临时解决方案

在上游提供开关之前，做了一个临时插件，同时处理配置接口 403 和设置无法持久化：

• npm：[dsh-trusted-host-proxy-403-fix@0.2.0](https://www.npmjs.com/package/dsh-trusted-host-proxy-403-fix)
• 源码：[roojay/dsh-trusted-host-proxy-403-fix](https://github.com/roojay/dsh-trusted-host-proxy-403-fix)

安装后仍按原来的方式启动 DSH：

dsh plugin --profile web add dsh-trusted-host-proxy-403-fix@0.2.0
dsh web --port 3080 --trusted-host <你的域名>

服务端会为这 15 个只限回环的方法注册精确匹配的 /api/<method> 路由，并使用 ctx.webRuntime.trustedHosts 检查 Host、Origin 和 Fetch Metadata。错误的 Origin 或 sec-fetch-site: cross-site 仍然会返回 403。

浏览器端会移除 SettingsScopeController.enqueue 在 memory 模式下跳过读写的逻辑，并把可以直接访问的语言和主题控制器改为 host 模式。语言、外观和 Composer Enter 等设置可以写入 settings.yaml，刷新页面或重启 Web 进程后仍然保留。

插件不修改 DSH 源码，不要求监听 0.0.0.0，也不提供身份认证。它严格对应 @deepseek-ai/dsh@0.1.0-rc.6 的实现，升级 DSH 后需要重新核对 SettingsScopeController 和官方方法列表。

如果入口没有认证或等效的网络隔离，请不要安装这个插件。上游提供同类 opt-in 并处理浏览器端持久化后，插件就可以移除。

[Electricitysheep]

受信主机部署（Cloudflare Tunnel）下特权 API 403 + 设置不持久化——远程部署的组合问题，和 #755/#764 的 origin 白名单同源。

opt-in 建议合理（默认锁死 + 显式信任）。远程部署的边界第 12 章有记录：https://github.com/Electricitysheep/dsh-handbook/blob/main/docs/12-limitations.md

[JUANWANG-BUAA]

我做了个远程控制的方案https://github.com/JUANWANG-BUAA/dsh-full-remote ，实测是可以解决 403 与设置无法持久化保存