dsh web behind Nginx: HTTPS, WebSocket and DSH plugin

Configuring a reverse proxy for DeepSeek Harness dsh web is not hard; forwarding three things correctly is: the WebSocket upgrade, unbuffered streaming, and long timeouts. Miss one and the page loads but nothing works — the channel fails, data never refreshes, or output stops halfway, with errors hiding in the browser console and proxy logs. Nginx and Caddy both satisfy the requirements, and a tunnel avoids opening ports at all.

Three hard requirements for proxying DeepSeek Harness dsh web

Bottom line: forward the upgrade headers, disable response buffering, and use long timeouts. Any one missing produces a page that loads but does not work.

1. WebSocket upgrade: forward Upgrade and Connection, and set the proxy HTTP version to 1.1. Otherwise the persistent connection fails.
2. No response buffering: disable it (or minimize it) so server chunks reach the browser immediately instead of looking stuck.
3. Long timeouts: raise read and write timeouts so idle sessions survive and long tasks are not cut off.
4. Forward the original source too: pass X-Forwarded-* headers so logs and source restrictions see real clients.

Option A: Nginx configuration for DeepSeek Harness dsh web

Bottom line: the key is two upgrade headers, one buffering switch and three timeouts. Everything else is a normal site configuration.

server {
  listen 443 ssl;
  server_name dsh.example.com;

  ssl_certificate     /etc/ssl/dsh/fullchain.pem;
  ssl_certificate_key /etc/ssl/dsh/privkey.pem;

  location / {
    proxy_pass http://127.0.0.1:3080;      # the actual dsh web port
    proxy_http_version 1.1;                # requirement 1: persistent connections need 1.1
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;

    proxy_buffering off;                   # requirement 2: do not buffer streaming output
    proxy_read_timeout 3600s;              # requirement 3: long timeouts
    proxy_send_timeout 3600s;
  }
}

1. Point proxy_pass at your real port (confirm flag names with dsh web --help).
2. Verify the upgrade by checking the browser connection panel and looking for 101 Switching Protocols in the access log.
3. Force HTTPS with a separate port-80 redirect to 443.
4. Keep a rollback point by leaving the previous configuration commented in place.

Option B: Caddy configuration for DeepSeek Harness dsh web

Bottom line: Caddy buys a short configuration and automatic certificates. Set the hostname and let defaults handle the rest.

dsh.example.com {
  reverse_proxy 127.0.0.1:3080
}

1. Defaults cover the hard requirements: Caddy reverse_proxy handles connection upgrades and streaming without extra headers.
2. Automatic certificate issuance and renewal once the hostname resolves.
3. Add directives only when needed — timeouts, source restrictions, compression policy.
4. Trade-off: defaults do a lot for you, which means debugging requires understanding them. Note the important defaults in comments.

Option C: tunnel for DeepSeek Harness without open ports

Bottom line: keep the service on loopback and let a tunnel client connect outward. You avoid a listening port at the cost of latency and third-party traffic.

1. Self-hosted relay: more controllable, appropriate when sessions are sensitive; you maintain relay certificates and access control.
2. Commercial tunnel: faster to stand up; traffic passes through a third party, so evaluate whether that is acceptable.
3. Add access control either way — a tunnel provides reachability, not authorization.
4. Common strong pattern: a tunnel entry in front of a reverse proxy that enforces authentication and source restrictions.

Subpath hosting pitfalls for DeepSeek Harness dsh web

Bottom line: prefer a subdomain. If a subpath is unavoidable, plan for three rewrites: assets, API prefixes and redirects.

1. Static assets loaded from the root return 404 under /dsh/ and the page goes blank.
2. API and realtime prefixes must follow the subpath or they fall outside it.
3. Redirect and callback links built from absolute paths leave the subpath.
4. Recommendation: use a subdomain such as dsh.example.com — clear semantics, zero rewriting. Reserve subpath hosting for cases where a subdomain is unavailable, and budget debugging time.

Authentication and exposure for DeepSeek Harness dsh web

Bottom line: do not rely on one layer. Combine source restriction, access authentication and enforced HTTPS.

1. Source restriction: allow only specific ranges, or require VPN before access.
2. Access authentication: basic auth at the proxy or an identity gateway. Local convenience is not internet security.
3. Enforce HTTPS: redirect plaintext so session content never travels unencrypted.
4. Shrink the exposure surface: turn the proxy off when remote access is not needed. Many incidents start as a temporary proxy that was never removed.

DSH plugin troubleshooting through a reverse proxy

Bottom line: separate "cannot connect" from "connects but misbehaves." The first is headers and protocol version; the second is buffering and timeouts.

1. Cannot connect — check Upgrade and Connection headers, HTTP/1.1, and whether the log shows 101.
2. Connects but output stalls — check that buffering is off.
3. Long tasks cut off — check read and write timeouts.
4. Blank page or 404 assets — suspect subpath hosting, which is why a subdomain is recommended.
5. Plugin market will not load — open the DSH Plugin Hub page through the proxy as a quick end-to-end check.
6. Repair status, stated honestly: these Nginx and Caddy configurations follow each project's official documentation for WebSocket proxying and reverse proxying; they are not endorsed for any specific DeepSeek Harness version. Confirm dsh web port and bind flags with dsh web --help, and validate locally before deploying.

Sources: apps/cli/README.md, nginx Docs · WebSocket proxying, Caddy Docs · reverse_proxy.