企业官网建设流程全解析

把Deepseek Harness这类工具从本机搬上云服务器，看起来只是换个环境跑一遍，但实际折腾起来，坑点远比想象中多。这篇文章我直接用自己踩过的流程讲清楚一件事：如何在云服务器上完整部署Deepseek Harness，并且以安全的方式实现公网鉴权访问。适合已经玩过本地版、想让它在云端24小时运行的朋友，也适合想通过公网把Harness分享给协作者、但又不想把服务裸奔在公网上的新手。读完你不仅能复现，还能知道每一步为什么这么做。

这里说的“公网鉴权访问”，绝对不只是开个端口让你在外面能打开页面，而是指：走HTTPS加密、前置身份认证、再配合业务层账号体系的一套访问控制链路。很多人装完Harness就顺手把3000端口暴露了，结果第二天日志里爬满了扫描器。这篇文章的目标，是让你部署完之后，别人访问你的Harness必须过三道关，而不是谁拿到IP就能用。

1. 部署前的整体思路与准备

1.1 为什么要把Deepseek Harness部署到云服务器

先从需求说起。本机跑Deepseek Harness很方便，Docker一条命令就能起来，浏览器里聊聊天、挂几个插件、用AnySearch搜点资料，都挺顺畅。但本机跑有三个硬伤：第一，电脑一关服务就断，零散研究到一半想从手机接着看，根本没门；第二，想让同事或者研究搭子一起用，总不能把本机IP暴露给别人，而且本机网络环境和安全状况你也控制不了；第三，Deepseek Harness装了LLM Wiki这类知识库插件后，会产生大量本地文件和数据，放个人电脑里既占用资源，也不方便多人共同维护。

所以，把它部署到云服务器，本质上不是在“跑一个程序”，而是在搭一个团队可共享、随时在线、数据集中管理的AI研究工作台。部署完之后，你可以在办公室、通勤路上、甚至平板上打开同一个Harness界面，所有插件、会话历史、知识库条目都在服务器上，哪个设备都能接着用。这种体验一旦习惯，很难退回单机版。

1.2 服务器选型与配置要求

服务器怎么选，其实取决于你想怎么用。如果只给自己一个人用，最便宜的学生机、轻量应用服务器就够；如果给一个小团队用，建议2核4G起步，因为插件多了以后，LLM Wiki的向量检索和AnySearch的请求转发都会吃内存。

我实际测试下来，纯文本对话场景下，1核2G的机器能跑，但装完LLM Wiki并建索引的时候，内存占用会冲到80%以上，偶尔会触发OOM。如果你想体验完整插件生态，预算不紧张的话，直接上2核4G，磁盘给到40G以上。Deepseek Harness的会话记录和知识库文件会随使用时间越堆越多，磁盘摸底时尽量留出富余。

系统方面，Ubuntu 22.04 LTS或者Debian 12都行，我推荐Debian 12，占用更小，出问题时的文档也多。CentOS 7这类老系统就不要用了，Docker和Node版本都容易卡脖子。另外，如果你手头有免费云服务器的活动名额，也能拿来跑，但记得重点看两个参数：公网带宽和月流量，这两项太小，网页交互会明显卡顿。

1.3 硬性准备工作清单

部署之前，有几样东西必须提前准备好，别等到中途才发现缺了再回头补：

• 一台云服务器，公网IP固定，操作系统装好，能通过SSH登录。
• 一个域名，最好托管在Cloudflare或阿里云DNS上，用于解析访问地址。
• 一个DeepSeek的API Key，或者你习惯接入的其他兼容模型服务Key。
• 本地准备好SSH密钥对，服务器上关闭密码登录，密钥登录比密码安全得多。
• 安全组规则规划：只放行80/443端口给公网，SSH端口改成非默认端口，管理端口不要暴露。

域名这块，我多说一句。有人觉得直接IP访问省事，但在公网鉴权这个场景下，域名几乎是必需品。HTTPS证书签给域名很顺滑，反向代理的配置也更清晰，而且万一你的IP被运营商封了某个端口，换解析就能绕开，不需要动服务器。没有域名的话，后面所有基于证书的方案你都得自己折腾，很不划算。

2. Deepseek Harness的安装与模型接入

2.1 环境安装与基础依赖

安装Deepseek Harness之前，先把基础环境理顺。用Docker Compose是最省心的方式，因为Harness的依赖项里有不少系统库，手动装很容易缺这个少那个。先更新系统，然后装Docker和Compose插件：

apt update && apt upgrade -y apt install -y curl git ufw curl -fsSL https://get.docker.com | bash systemctl enable docker && systemctl start docker

装完可以用docker compose version确认一下，要能看到类似Docker Compose version v2.x的输出。Compose插件是现在主流形态，别再装那种独立的docker-compose二进制了。接下来建一个干净的部署目录：

mkdir -p /opt/deepseek-harness && cd /opt/deepseek-harness

目录放根目录还是home目录，各人有各人习惯。我喜欢放/opt，因为这是Linux里放应用的标准位置，权限更清晰，也不容易和用户文件混在一起。

2.2 获取镜像或源码：两种方式怎么选

Deepseek Harness的部署方式，网络上流传比较多的是两种：一种是直接拉官方镜像用Compose编排，另一种是Clone源码到服务器然后手动跑。我的建议是：如果你只想用、不想改代码，直接镜像方式；如果你想折腾插件、随时回退代码版本，就源码方式。

镜像方式的高层结构类似这样：

services: harness: image: your-registry/deepseek-harness:latest container_name: harness restart: always ports: - "127.0.0.1:3000:3000" volumes: - ./data:/app/data - ./plugins:/app/plugins environment: - NODE_ENV=production

注意到没有，我把端口映射写成了127.0.0.1:3000:3000，而不是3000:3000。这一步非常关键，等于直接堵死了公网直连应用端口的路。无论你选哪种安装方式，这句话都适用：应用一律只监听本地回环地址，公网访问全部交给前面的反向代理。很多被扫描器打进后台的案例，就是栽在把应用端口直接暴露出来。

如果你更倾向源码部署，流程会多一点，但灵活度最高。Clone下来之后，安装依赖、构建前端、启动服务三步走，每一步都要留意日志输出。我建议还是用pm2或者systemd把进程托管起来，别用裸node server.js去跑，终端一关服务就没了。

2.3 模型接入：配置DeepSeek API Key

Harness安装完之后，第一件事不是急着注册账号，而是先把模型通道配置好。在Harness的设置界面里找到模型配置，填上DeepSeek的API Key，Base URL填官方接口地址。这里有个实操细节：Harness里可以同时配置多个模型源作为后备，如果你有接免费模型的需求，也可以把兼容OpenAI格式的免费模型地址加进来，但默认主模型建议还是用DeepSeek，稳定性和速度都有保障。

还要留意一点：Deepseek Harness桌面版如果是“没账号不能用”，说明新版把用户体系和鉴权做进了产品逻辑里。那么部署到云服务器之后，业务层的登录密码一定要设强，这本身也是公网鉴权访问的最后一层保障。管理员密码、API Key都不要用默认值、不要用弱密码、不要用和服务器root一样的密码，这是三条铁律。

2.4 插件系统：AnySearch与LLM Wiki的最小可用配置

插件是Deepseek Harness的核心卖点。装完主体后，我建议先装两个最常用的：AnySearch联网搜索插件和LLM Wiki知识库插件。前者的作用是让模型能实时检索网络信息，后者是把你的文档变成可检索的知识库。

Harness的插件安装入口一般有两种，一个是在设置界面里打开插件市场直接装，另一个是手动放进plugins目录后重启服务。我建议从界面装，版本匹配问题会少很多。装完AnySearch之后，记得去插件设置里填入搜索API的相关参数，不配的话插件等于白装，因为联网搜索依赖外部搜索服务。

LLM Wiki装完之后，需要指定一个数据目录，并且做一次索引构建。首次构建如果文档很多，会耗时比较久，进程看着像卡住，实际是在逐篇跑向量化。你可以观察CPU占用，占用高说明在干活。这一步做好后，Harness才算真正成为你的个人知识引擎。

3. 公网鉴权访问：从裸奔到三层防护

3.1 总体方案：DNS解析、反向代理、身份验证三层架构

公网鉴权访问，我推荐的方案是：DNS解析 + Nginx反向代理 + HTTPS证书 + Nginx Basic Auth + 业务层账号密码，一共五件事、三层关。第一层是网络入口，只暴露443端口；第二层是前置身份认证，没通过Basic Auth连Harness的登录页都看不到；第三层才是Harness自己的账号体系。这样即使Harness自身出现未授权漏洞，攻击者前面还有一道Basic Auth挡着；反过来，就算Basic Auth被爆破，Harness内部还有一套账号密码。纵深防御，永远好过单点防护。

有人觉得Basic Auth好像很老派，但它是Nginx原生能力，性能开销极小，也不影响后续的WebSocket连接，在这个场景下非常实用。不用它的理由只有一个：你要做细粒度的用户权限区分。如果只是给自己或者三五个人用，Basic Auth够稳也够简单。

3.2 域名解析与HTTPS证书下发

先把域名的A记录解析到服务器公网IP。这一步做好后，等DNS生效再用dig确认一下。接下来装Nginx和Certbot：

apt install -y nginx certbot python3-certbot-nginx

证书申请直接用Certbot的一键模式。签发前要确保域名已经能访问到这台服务器，同时80端口暂时是通的，因为申请证书要做HTTP验证。命令如下：

certbot --nginx -d harness.example.com

如果之前跑过其他服务占用了80端口，Certbot会尝试自动处理，但如果你自己改了Nginx配置结构，建议多看一眼生成的conf文件再继续。证书申请完成后，Certbot会自动续期，你只需要加一个定时任务兜底即可：

echo "0 3 * * * certbot renew --quiet" | crontab -

3.3 Nginx反向代理配置详解

现在把Harness服务接到Nginx后面。在/etc/nginx/sites-available/下新建一个配置文件，核心配置块如下：

server { listen 443 ssl http2; server_name harness.example.com; ssl_certificate /etc/letsencrypt/live/harness.example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/harness.example.com/privkey.pem; auth_basic "Restricted Access"; auth_basic_user_file /etc/nginx/.htpasswd; location / { proxy_pass http://127.0.0.1:3000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; } }

这里面有两处不能省：X-Forwarded-Proto必须带上，否则Harness不知道请求是HTTPS进来的，回调地址会生成成http://，页面会怪怪的；Upgrade和Connection是给WebSocket通道用的，Deepseek Harness的对话流式输出走得是WebSocket或者SSE，不配的话会一会断线、一问全卡。

auth_basic前面永远不要加任何条件限制，就让它全局生效。另外，给Basic Auth建口令时，别用简单的echo "user:pass" | htpasswd方式明文处理，直接：

apt install -y apache2-utils htpasswd -c /etc/nginx/.htpasswd harness

这条命令会交互式地让你输入密码，并且生成加密哈希，比手写明文靠谱得多。

配置完成后启用站点：

ln -s /etc/nginx/sites-available/harness /etc/nginx/sites-enabled/ nginx -t && systemctl reload nginx

这里多说一句：Nginx配置修改后，一定先nginx -t再reload，很多人直接在跑着的Nginx上reload了一个有语法错误的配置，结果服务直接挂掉，所有站点跟着一起瘫痪。

3.4 WebSocket与流式输出的代理处理

流式输出是Harness这类AI工作台最核心的交互体验。如果代理没配好，你会遇到一个问题：页面能打开、登录能过，但一问问题就转圈，等半天没反应，看Nginx日志没有任何错误，感觉就像模型接口挂了。

实际上八成是WebSocket代理没开。上面那段配置里的Upgrade和Connection两行就是干这个的。还有个小细节，如果Harness对proxy_read_timeout很敏感，建议在location里加上：

proxy_read_timeout 300s; proxy_send_timeout 300s;

因为模型推理是个慢活，特别是接入长上下文的问答或者联网搜索的时候，单个请求可能几十秒甚至几分钟才返回。Nginx默认的60秒超时很容易在你最需要它的时候中断连接，别问我怎么知道的。

4. 常见问题与排查实录

4.1 安全组与防火墙导致的“无法访问”

部署完之后最容易遇到的第一道坎，就是服务器外部访问不了。很多人的第一反应是去看Nginx、去看Harness，实际上云平台的安全组规则才是最先要检查的。

每个云厂商的安全组入口不一样，但逻辑一致：在入方向规则里，必须放行TCP:443和TCP:80，来源选择0.0.0.0/0。这里有个细节，很多新手放行的时候会顺手把TCP:3000也放行，理由是方便调试。调试完一定要删掉，你在安全组里多开一个口子，就多给扫描器一个机会。

服务器内部的防火墙也要检查，如果你开了ufw：

ufw allow 80/tcp ufw allow 443/tcp ufw enable

注意，开启ufw的时候SSH端口如果没放行，你会当场被拒之门外。所以ufw allow 你的SSH端口/tcp一定要在ufw enable之前执行。

4.2 502 Bad Gateway与后端启停问题

Nginx配好后，访问域名看到502，这是第二常见的问题。502的含义是Nginx连不到后端的127.0.0.1:3000。排查顺序固定如下：

curl http://127.0.0.1:3000

如果这条命令能返回页面HTML，说明Harness进程是好的，问题出在Nginx配置上，重点看proxy_pass是不是写成了http://localhost:3000。localhost在某些系统上会优先解析成IPv6的::1，而你的Harness可能只监听了IPv4，于是Nginx连不上。不要赌，直接用127.0.0.1写死。

如果curl也连不上，说明Harness进程挂了，去看容器状态或者systemd状态。Docker方式下用docker compose logs --tail 100抓日志，源码方式就用pm2 logs或者journalctl -u harness。

4.3 磁盘空间暴涨与LLM Wiki索引文件

用了一段时间后，你会看到服务器磁盘占用率蹭蹭涨。主要原因集中在三个地方：Harness的会话历史数据库、LLM Wiki的向量索引、Docker的日志文件。尤其是Docker日志，默认情况下会无限制增长，一个暴走容器的日志能在几天内写满整个磁盘。

解决方案是在/etc/docker/daemon.json里加日志轮转限制：

{ "log-driver": "json-file", "log-opts": { "max-size": "50m", "max-file": "3" } }

改完后重启Docker守护进程并重建容器才会生效，所以这个配置最好在第一次部署的时候就写进去。我第一台服务器就是没管这个，跑了一周后磁盘100%，SSH都连不上，最后只能去云控制台扩容，折腾了一整个下午。热词里不是还有“腾讯云服务器扩展空间”嘛，如果真遇到这个场景，扩容本身不难，但能提前避免就别事后补。

4.4 Basic Auth校验失败与密码更新

还有一种很尴尬的情况：你配置了Basic Auth，但浏览器弹窗要求输入账号密码，输对了却一直重复弹窗。这个通常是.htpasswd文件和Nginx的运行用户权限不匹配导致的。Nginx worker进程读取不了这个文件，认证永远失败。解决办法：

chmod 640 /etc/nginx/.htpasswd chown root:www-data /etc/nginx/.htpasswd

改完权限再reload Nginx。如果之后想换密码，重新跑一遍htpasswd命令，不需要删文件重建，它会覆盖对应账号的哈希值。

4.5 插件冲突与代码回退

Deepseek Harness的插件系统虽然好用，但插件之间偶尔会有兼容性问题。尤其是提示词优化插件和AnySearch同时启用时，请求链路会叠加，模型的Prompt格式可能被反复改写，导致输出质量莫名其妙下降。

我的处理方法是：每装一个新插件前，先记下当前版本的commit号，或者给plugins目录打一个tar包做备份。如果新插件导致服务异常，直接用备份回退：

cd /opt/deepseek-harness tar -czf plugins-backup.tar.gz plugins # 出问题时恢复 tar -xzf plugins-backup.tar.gz

代码方式部署的话，git本身就能承担回退功能。新版本拉下来出问题，git reset --hard回退到上一个稳定commit就行。永远不要在升级完当天就把之前的备份删了，至少保留三天再说。这个习惯救过我至少两次。

4.6 关于离线局域网使用的补充说明

经常有人问，Deepseek Harness能不能在离线局域网里用。我的实际经验是：如果只是部署在局域网内、不让外网访问，前面的域名证书鉴权方案可以简化，直接服务器IP加端口、或者内网DNS加Nginx反向代理都行。但要注意，Harness的模型请求默认还是要走DeepSeek等在线API的，真正完全离线跑意味着你得额外接一个本地的模型推理服务，Harness本体只负责编排和界面。所以“离线可用”要拆成两层看：UI和工具链可以在局域网离线部署，但你要用大模型能力，还是得有一个本地模型服务在背后顶着。

最后补几句经验

部署完Deepseek Harness并配置好公网鉴权访问之后，我个人的体会是：这套方案最值钱的部分不是“装上了”，而是“知道怎么收口”。应用端口锁回环、Nginx只开443、Basic Auth前置、业务账号独立，这些步骤单看都不复杂，但它们叠起来之后，服务的暴露面会变得很小。之后如果你想给Harness加更多插件，比如提示词优化、LLM Wiki扩充语料，都可以在同一个架构下平滑扩展，不用再动网络层。

还有一个细节也许能帮到你：经常备份/opt/deepseek-harness/data目录，Harness里所有的会话记录和知识库状态都在里面。我见过太多人玩了大半个月没备份，一次服务器重置全没了。用一个crontab定时任务，每天凌晨把数据目录打包上传到对象存储或者另一台机器，成本几乎为零，但能避免的事情可能是灾难级的。部署完成只是开始，把日常的维护和备份养成习惯，这台云服务器上的Harness才能长期稳定跑下去。