DeepSeekDSH
Independent community guideNot affiliated with DeepSeek.Download versions and guide references

Run DSH Behind an HTTP/HTTPS Proxy

Use this when your network requires an HTTP/HTTPS proxy. Check the environment of the process that starts DSH, then verify model connectivity and certificate settings.

On this page
Do not add a proxy if your network does not need one

This guide is for company networks, VMs, restricted environments or local setups where outbound API access must pass through an HTTP/HTTPS proxy. A normal home connection should usually use DSH without these variables.

First prove the failure is a network/proxy problem

If DSH reports fetch failed, ECONNREFUSED, ETIMEDOUT, ECONNRESET or a certificate error while curl/npm work only through a proxy, the model configuration may be fine and the Node process may simply not be using the proxy.

npm view @deepseek-ai/dsh version

Run this in the same terminal that starts DSH. It checks npm Registry access, not the model API. If downloads work but model requests fail, check the model URL, proxy settings and authentication response separately.

STEP 1

Check the DSH and Node.js versions

npx @deepseek-ai/dsh --version node --version

This guide is pinned to 0.1.5-rc.2 / c291e79. This version reads proxy variables at startup; the main process does not require NODE_USE_ENV_PROXY. Older DSH versions, plugins with their own network libraries and Node child processes may behave differently.

Terminal variables may not reach an already-running Desktop app. Follow the startup and proxy instructions for your Desktop version.

STEP 2

Set HTTP_PROXY and HTTPS_PROXY

Use the proxy address supplied by your network administrator or local proxy application.

export HTTP_PROXY=http://proxy.example:8080 export HTTPS_PROXY=http://proxy.example:8080

For PowerShell, set the variables in the same terminal that will launch DSH:

$env:HTTP_PROXY="http://proxy.example:8080" $env:HTTPS_PROXY="http://proxy.example:8080"

Do not publish proxy credentials or embed a real username/password in screenshots.

STEP 3

Preserve local direct connections

The current DSH main process automatically bypasses loopback addresses. For other programs that read proxy variables, include 127.0.0.1,localhost,::1 in NO_PROXY.

Preserve existing internal domains in NO_PROXY before appending local addresses. Use commas; different network libraries may not accept a Windows-style semicolon list.

STEP 4

Start DSH in the same terminal

These examples assume NO_PROXY is not already configured. If it is, merge its existing entries first. HTTP_PROXY and HTTPS_PROXY use the addresses from step 2.

macOS/Linux:

export NO_PROXY=127.0.0.1,localhost,::1 npx @deepseek-ai/dsh web

PowerShell:

$env:NO_PROXY="127.0.0.1,localhost,::1" npx @deepseek-ai/dsh web

Select a configured model and a test workspace, then send a message that does not operate on files. A model reply verifies this connection. If the response becomes 401 or 402, check credentials or balance next; restored network access does not prove the proxy was the only issue.

Corporate TLS inspection may require a CA certificate

Some company networks terminate and re-sign HTTPS traffic. If the proxy route is correct but Node reports certificate-chain errors, your organization may require its trusted CA certificate through Node's NODE_EXTRA_CA_CERTS.

Replace the placeholder path with the PEM CA file supplied by a trusted administrator. Stop the existing DSH process, then restart it in the same terminal after setting the variable; a running process will not re-read it.

macOS/Linux:

export NODE_EXTRA_CA_CERTS="/path/to/company-ca.crt" npx @deepseek-ai/dsh web

PowerShell:

$env:NODE_EXTRA_CA_CERTS="C:\path\to\company-ca.crt" npx @deepseek-ai/dsh web
Use only a certificate supplied by an administrator you trust

Do not download random certificates to suppress TLS errors. A custom CA changes which HTTPS certificates the Node process will trust. Do not disable certificate verification.

Windows-specific notes

  • Use $env:NAME="value" for the current PowerShell session while testing.
  • Persistent setx changes apply to new terminals, not the already-open shell.
  • Use comma-separated NO_PROXY values; do not rely on a semicolon list.
  • A local DSH port error such as EADDRINUSE or Windows reserved-port EACCES is a different problem from an outbound proxy failure.

Common proxy and network failures

curl/npm use the proxy but DSH still connects directly

Set proxy variables before starting DSH and restart the relevant process. Check for conflicting lowercase and uppercase variables; the current implementation prefers lowercase values. Plugins with their own transport need their own instructions.

DSH Web opens, but localhost API calls return 403 through the proxy

Identify the process making the request and its version. Current DSH bypasses loopback; older versions and other clients still need correct NO_PROXY settings.

Only a Node child process bypasses the proxy

Child processes may depend on NODE_USE_ENV_PROXY. The pinned proxy reference notes that Node 22.19/22.20 do not support this path; use 22.21+ or a supporting 24.x release for those children. Do not treat the switch as a requirement for the current DSH main process.

Certificate chain / self-signed certificate error

Ask your administrator whether the network uses TLS inspection and whether Node should trust a company CA via NODE_EXTRA_CA_CERTS.

SOCKS or PAC addresses do not work

The current implementation accepts only HTTP/HTTPS proxy URLs. Unsupported values are reported and skipped, so requests are not guaranteed to use a proxy. Ask your administrator for a supported HTTP/HTTPS address.

NEXTStill failing after network access works?
Open troubleshooting →
Sources and version

Reference snapshot: 0.1.5-rc.2 / c291e79 official proxy reference. Historical context: Node proxy discussion, NO_PROXY discussion and corporate certificate discussion. Do not apply older version requirements to the current implementation without checking.