dsh-remote-access-proxy
从手机或另一台电脑访问 DSH Web GUI：通过秘密路径反向代理，以及可选的密码和客户端允许列表，转接 DSH 每次启动时生成的启动令牌；可在 Plugins 面板中该插件自己的页面进行配置。
插件会安装到这里；不确定时保持 web。
npx -y @deepseek-ai/dsh plugin --profile web add github:citydirector/dsh-remote-access-proxy#98ec1586a6fafea4de4182316be6343eaf3bdbc0Remote Access Proxy 以 dsh-remote-access-proxy 发布，当前版本为 1.4.1。Plugin Hub 会校验它的 manifest，并保存精确安装来源，便于复现安装结果。
Use DSH (DeepSeek Harness) from your phone, tablet, or another computer's browser.
The plugin runs a small reverse proxy inside DSH. A remote device opens one address with a random path and gets the full Web GUI, without ever needing the launch token DSH changes on every start. Anything can sit in front: a LAN IP, easytier, ZeroTier, Tailscale, nginx, Caddy, Cloudflare Tunnel.
Requires DSH 0.1.7-rc.1 or newer (tested on 0.2.0-rc.2 and 0.2.1-alpha.3).
https://github.com/citydirector/dsh-remote-access-proxy
http://192.168.1.20:13337/k3x9q2m7p1zt/. Bookmark it or add it to the home screen.Nothing needs configuring: port 13337 on every interface, with the random path generated and saved on first start. Add a password or limit who may connect whenever you like.
Set your API key on this machine first. Some DSH settings can only be changed from a page on the host (DSH's own rule, not this plugin's; on 0.2.0 remote pages cannot change settings at all), so set the API key in DSH on the host. Remote pages can create sessions, chat, and pick workspaces normally.
From the command line:
dsh plugin --profile web add github:citydirector/dsh-remote-access-proxy
A git dependency is pinned to a commit by the profile's pnpm-lock.yaml; prefer a tag-pinned spec (github:citydirector/dsh-remote-access-proxy#v1.4.0). While DSH runs, update from the configuration page or the Plugins page; with DSH stopped you can also pnpm add the new tag in the profile directory.
192.168.1.0/24, 100.64.0.0/10. LAN and VPN only fills in every private range in one click; empty means anyone. Connections from elsewhere are dropped before a byte is exchanged, and the page tells you the last address it turned away, so you can add your own device if you locked it out. This machine itself is always allowed.<entry>/__rap/logout signs a device out.On DSH 0.2.0 the page appears on the host only; from 0.2.1 remote pages can open it too, but one-click updates are offered on the host only.
No. DSH 0.2 works over plain http.
TLS needs a .pfx certificate. A self-signed one on Windows (PowerShell):
$cert = New-SelfSignedCertificate -DnsName "dsh.local" -CertStoreLocation Cert:\CurrentUser\My -NotAfter (Get-Date).AddYears(5)
Export-PfxCertificate -Cert $cert -FilePath .\data\certs\dsh-proxy.pfx -Password (ConvertTo-SecureString "your-passphrase" -AsPlainText -Force)
On macOS / Linux (openssl):
openssl req -x509 -newkey rsa:2048 -nodes -days 1825 -subj "/CN=dsh.local" -keyout key.pem -out cert.pem
openssl pkcs12 -export -inkey key.pem -in cert.pem -out dsh-proxy.pfx -passout pass:your-passphrase
Then switch on "Enable TLS" in the page, fill in the path and passphrase, and save. Browsers ask you to accept the certificate once. With TLS the gate cookie also gets the Secure flag.
| The page says | Do this |
|---|---|
| Port … is already in use | Pick another port, or close what holds it. Two DSH apps sharing one data directory (portable + desktop) do this too — see below |
| These client addresses aren't valid | Write an IP (10.0.0.5), a CIDR block (10.0.0.0/24) or a range (10.0.0.5-10.0.0.9) |
| The certificate could not be loaded | Check the path (relative to DSH's working directory) and the passphrase |
| Can't read the proxy status | The plugin isn't running: check both the plugin's and the component's switches |
forbidden on the remote device: the path is wrong. Open the full entry address again.bad gateway: the proxy could not reach the upstream DSH. The status card's Upstream line shows the address it is using, and access.log records the reason (usually ECONNREFUSED). Leave upstreamHost / upstreamPort at empty / 0 so the address follows the running instance. Before 1.4.1 the desktop app was unusable this way: it starts its host with --port 0, the plugin read the requested 0 from webStartup instead of the port the OS bound on webServer, and fell back to 3080.$DSH_HOME read the same profile and fight over one port. Switch "Enabled" off in one of them, or give each its own port.Access control is entirely the proxy's gate:
allowFrom is dropped at the TCP level (before TLS), like a firewall rule. Loopback is always allowed, so a local HTTPS reverse proxy keeps working;<address>:<port>/<secretPath>/, generated from the OS CSPRNG;dsh_et_gate, a signed value that expires after 30 days (Path=/; Max-Age=2592000; HttpOnly; SameSite=Strict, plus Secure with TLS). It is signed with a server secret over the path and the password, so changing either — or regenerating the path — revokes every device. Nobody ever edits it by hand.The proxy forwards to DSH as loopback (Host rewritten to 127.0.0.1:<port>, Origin stripped) and performs the launch-token exchange itself, holding the dsh-auth-* cookie, so remote users never see the per-start token. On an upstream 401 it drops that cookie and exchanges again.
The path is the key: treat the entry address like a password. The access.log startup line records it too.
Every field is a .volatile() field of the plugin's Cordis Config, stored in the active profile's cordis.patch.yml. Edit them in the page, or by hand from config/cordis.patch.example.yml.
| Field | Description |
|---|---|
enabled | Stop listening when off |
listenPort | Port (default 13337); the proxy listens on every interface, IPv4 and IPv6 |
allowFrom | Client addresses allowed to connect: IPs, CIDR blocks, a-b ranges, separated by commas or spaces. Empty = anyone; loopback always |
secretPath | Gate path (4–32 letters, digits, -, _; generated when empty) |
password | Optional access password (empty = none) |
cookieValue | Server secret that signs remembered devices (generated; not shown on the page) |
upstreamHost / upstreamPort | Upstream DSH. Empty / 0 follows the running instance: the bound port from its webServer service, then webStartup (3080 under dsh web; a desktop launch passes --port 0, so its real port exists only on webServer) |
tlsEnabled / tlsPfxPath / tlsPassphrase | TLS (pfx certificate) |
logMaxBytes / logKeep | access.log rotation: rotate past the cap (default 1 MiB), keep this many old files (default 3); 0 turns rotation / history off |
updateCheck | Check for updates (default on): read the release tags on GitHub a few seconds after start and every 12 hours; it only tells you, never installs |
A few seconds after start, and every 12 hours after that, the plugin reads this repository's tags on GitHub, takes the highest vX.Y.Z (pre-releases and other tags are ignored) and compares it with the running version. The Version line of the status card says Up to date, vX is available, or Couldn't check for updates (with the time and the reason). Offline or rate-limited checks just show as failed; the proxy is not affected. Check now checks again at once; turn Check for updates off under Advanced if you don't want it to go online.
When a release is available, click Update to vX. The page asks DSH's own plugin manager (the same call the Plugins page installs with) to install github:citydirector/dsh-remote-access-proxy#vX; DSH installs it over the running version and hot-swaps it, no restart needed:
The update button is only offered on a page opened on this computer; remote pages only say a release is available. The plugin never updates itself.
To update or roll back by hand: Plugins → Add plugin, and give it a tag-pinned spec such as github:citydirector/dsh-remote-access-proxy#v1.4.0. A spec without a tag, or exactly the spec already installed, is refused as already installed.
Nothing to do beyond the update itself: 1.4.1 only fixed upstream auto-detection. If the status card showed an Upstream of 127.0.0.1:3080 while DSH itself was reachable, that was the bug — the address now follows the port DSH actually bound. Entry paths, passwords, allow lists and signed-in devices are untouched.
1.3 has no update button, so install 1.4.0 once by hand: Plugins → Add plugin, and give it
github:citydirector/dsh-remote-access-proxy#v1.4.0
From DSH 0.2.1 it installs over 1.3 and hot-swaps (tested from 1.3.0: entry path, password and allow list kept). Later releases update from the configuration page. DSH 0.2.0 and older have no hot reload: pnpm add that spec in the profile directory, then restart DSH.
listenHost is gone: the proxy now always listens on every interface, and who may connect is allowFrom. An old listenHost value is ignored.Nothing to do:
file:///… path.DSH 0.1.7 removed settings.yaml. Update DSH first, then the plugin, and switch it off and on. On first start DSH imports the remote-access-proxy: section of data/settings.yaml into the profile and renames the file to settings.yaml.imported.
dsh-remote-access-proxy/
├── package.json # bundle manifest + dsh.client; "." = proxy, "./client" = page
├── cordis.patch.yml # the one row this bundle inserts (by package name)
├── plugin/dsh-remote-access-proxy.mjs # host: gate + forwarding + status route
├── client/index.js # browser: the configuration page
├── config/cordis.patch.example.yml # hand-configuration template
├── locale/{en,zh}.json # Plugins-page title and description
└── test-remote-access-proxy.mjs # end-to-end tests against a mock DSH
pnpm install
node test-remote-access-proxy.mjs # Expected: 86 passed, 0 failed
The tests mock a DSH upstream (launch-token exchange + dsh-auth cookie gate) and the host contract the plugin relies on, and cover the gate, cookie injection, token stripping, 303 rewrite, 401 self-heal, WS upgrade, log rotation, secret generation and write-back, the status route, failure reasons (invalid path, busy port, bad allow-list entry), the password sign-in (deep links, lockout, logout, revocation), the allow list (drop, loopback, reporting), the 1.1 → 1.2 migration, upstream auto-detect, the update check (tag filtering, version comparison, failures and rate limits, the switch, check now), closing every connection on a hot swap and rebinding the port at once, and the package layout.
The tests check for updates against a mock GitHub only. To rehearse a release in a real DSH, start DSH with DSH_RAP_UPDATE_SOURCE pointing elsewhere: owner/repo (another GitHub repository) or any git URL (for example a local bare repository with tags, git+file:///path/to/repo.git). The update button then installs <source>#<tag>.
version in package.json, e.g. 1.4.1.main.v1.4.1 (exactly v + three numbers) and push the tag: git tag v1.4.1 && git push origin v1.4.1.Only vX.Y.Z tags count as releases; a pre-release such as v1.5.0-rc.1 is never offered. Each release installs from its own tag, which is what lets DSH install it over the previous one — so every release needs its tag.