Access dsh web on your LAN: binding, firewall and TLS

Sharing DeepSeek Harness dsh web with phones or another computer on the LAN requires three things at once: a bind address, an allowed port, and device trust. Changing only the bind or only the firewall always fails; the order is bind externally, allow the port, then solve certificates. Binding all interfaces turns a local tool into a LAN service, so be careful on untrusted networks.

Three things LAN access to DeepSeek Harness dsh web requires

Bottom line: the bind address decides who can connect, the firewall decides whether packets pass, and the certificate decides whether browsers trust it. All three must hold.

Three DeepSeek Harness LAN access options

Bottom line: bind externally for temporary sharing on a trusted segment, proxy for the smallest exposure, or tunnel when no port may be opened.

Option A: bind DeepSeek Harness dsh web to all interfaces

Bottom line: change the bind address and allow the port. Two steps; the shortest path for trusted LAN use.

1. Start with an explicit bind address and port (flag names per dsh web --help):

dsh web --host 0.0.0.0 --port 3080
# expected: startup reports listening on 0.0.0.0:3080

2. Verify locally first to rule out service problems:

curl -I http://127.0.0.1:3080      # expected: HTTP response headers

3. Find the machine's LAN address:

# macOS / Linux
ipconfig getifaddr en0 2>/dev/null || hostname -I
# Windows (PowerShell)
# (Get-NetIPAddress -AddressFamily IPv4).IPAddress

4. Open http://<lan-ip>:3080 from the other device.
5. If unsure, use the three-step diagnostic in the last section.

Option B: loopback plus reverse proxy for DeepSeek Harness dsh web

Bottom line: keep dsh web on loopback and let a proxy serve the LAN. This centralizes HTTPS and authentication and suits sharing with a few people.

1. Leave the service on loopback; the proxy listens externally.
2. Satisfy the three hard requirements — WebSocket upgrade, no buffering, long timeouts. See dsh web behind a reverse proxy.
3. Add source restrictions at the proxy — your subnet only, optionally with basic auth.
4. Use a trusted certificate — an internal CA certificate means each device trusts it once.
5. Apply the same three-step diagnostic if access fails.

Option C: SSH tunnel to DeepSeek Harness dsh web

Bottom line: the service stays local and clients forward the port. No external port is opened, which suits temporary single-user use.

1. Start the service normally (loopback is enough).
2. Forward a local port from the phone or another device (illustrative; the exact command depends on your SSH client):

ssh -N -L 3080:127.0.0.1:3080 user@your-computer-ip
# expected: local port 3080 forwards to the remote dsh web

3. Open http://127.0.0.1:3080 locally.
4. Trade-off: you establish the tunnel each time and sharing with several people is awkward, but the service exposure and firewall never change.

Bind address choices for DeepSeek Harness dsh web

Bottom line: loopback is local only, a specific interface IP is subnet-limited, and all interfaces is everything the machine can reach. Choose by who should connect, not by whether they can.

1. 127.0.0.1 (loopback): the default; safest and most often mistaken for a broken service.
2. A specific interface IP (such as 192.168.1.20): limits listening to one interface, useful on machines attached to multiple networks.
3. 0.0.0.0 (all interfaces): listens everywhere, so risk equals every network the machine can reach. Always pair with firewall source restrictions.
4. Switch back after use: treating all-interfaces binding as a permanent default is unnecessary exposure.

Firewall and certificate trust for DeepSeek Harness dsh web

Bottom line: allow exactly port plus source subnet; certificate trust is a one-time action per device, and self-signed means trusting on every device.

1. Pick a high port to avoid reserved ranges and collisions with common services.
2. Allow precisely (illustrative):

# Linux (ufw example)
sudo ufw allow from 192.168.1.0/24 to any port 3080 proto tcp
# expected: your subnet connects, other sources remain blocked

3. Self-signed trust in three steps: generate the certificate, enable HTTPS on the service, then install and trust it on each device (iOS requires enabling trust in certificate settings; Android installs it as a user certificate). Verify after installing.
4. Easier alternative: an internal CA or public-domain certificate removes per-device trust work.
5. Encryption is not authorization: keep source restrictions after trust is established.

Three-step verification for DeepSeek Harness LAN access

Bottom line: curl on the host, ping from the other device, then probe the port. These isolate service, network and firewall problems in that order.

1. Service: curl -I http://127.0.0.1:<port> on the host. Failing here means the service (port taken or permission), not the LAN.
2. Network: ping <lan-ip> from the other device. Failing means the devices are not on the same segment (guest networks and AP isolation are common).
3. Port: ping succeeds but the port does not — a firewall block. Probe the port, then allow it as above.
4. Then check the bind: confirm the startup output shows an external address rather than loopback.
5. Read service logs: whether requests arrive is the fastest way to separate "never connected" from "connected but errored."

DSH plugin troubleshooting for LAN sharing

Bottom line: confirm reachability first, then plugin behavior. They belong to different layers.

1. Network layer first using the three steps above.
2. Application layer next: if the page opens but plugin features fail, treat it as a plugin-side problem such as container or permission prerequisites — see installing DeepSeek Harness in Docker and fixing dsh web port conflicts.
3. Write down the plugin list when sharing, and align it through the installed list in DSH Plugin Hub so "it works here but not there" does not happen.
4. Clean up afterwards: restore the loopback bind and remove temporary firewall rules.
5. LAN and internet are different problems: internet exposure needs a proxy with TLS and auth, not the LAN recipe.
6. Repair status, stated honestly: bind flags and commands follow the official CLI notes; firewall, certificate and SSH tunnel specifics vary by operating system and device. Confirm exact dsh web flag names with --help.

Sources: apps/cli/README.md, Microsoft Learn · WSL networking, nginx Docs · WebSocket proxying.