企业官网建设流程全解析

1. 为什么要在云服务器上折腾 Deepseek Harness

先把话说在前头：Deepseek Harness 不是一个“下载完双击就能用”的桌面软件，它更像是一套围绕大模型能力构建的本地化工作台——你可以把它理解成一个“模型能力调度中枢”，负责把提示词、插件、技能（Skill）、文件读写、代码回退这些零散能力串成一条可复用的工作流。很多人第一次接触它，是在自己笔记本上跑通了，感觉挺爽，然后就想：能不能把它丢到云服务器上，让团队里其他人也能用，甚至在外面用手机也能连回来？

这个需求非常真实。本地跑有几个绕不过去的坎：一是机器一关服务就没了；二是多人协作时每个人的环境不一样，插件版本、模型配置、文件路径全是坑；三是有些重活儿（比如批量处理文档、跑长任务）本地机器扛不住。所以把 Deepseek Harness 部署到云服务器，再通过公网鉴权访问暴露出去，是一个很自然的选择。

但“部署到云服务器”这六个字背后，藏着一堆细节：Linux 环境怎么准备、依赖怎么装、服务怎么常驻、端口怎么暴露、Nginx 或 Caddy怎么做反向代理、鉴权怎么做才不至于把服务裸奔在公网上。这篇就按我自己的实操顺序，把整条链路拆开讲清楚。适合两类人看：一是有基本 Linux 命令基础、想把 Harness 搬到云上的开发者；二是已经部署过但卡在反向代理或鉴权环节、想找个能抄的配置的人。

我下面提到的所有步骤，都是基于“一台干净的云服务器 + 公网 IP + 一个域名”这个最常见的前提。如果你连域名都还没有，也别急，纯 IP 加端口也能先跑起来，鉴权部分我会给两种方案。

2. 部署前的整体设计与方案选型

2.1 先想清楚：Harness 到底跑在哪一层

很多人一上来就问“Deepseek Harness 怎么安装”，其实更该先问的是“它在我这套架构里处于什么位置”。我的理解是，Harness 本身是一个应用层服务，它下面要接模型（可以是本地模型，也可以是远端 API），上面要接用户（浏览器、桌面客户端、或者别的程序）。所以整条链路大概是这样的：

• 最底层：云服务器操作系统（我用的 Ubuntu 22.04，CentOS 9 也行）
• 中间层：运行时环境（Node.js 或 Python，取决于你拿到的 Harness 发行形态）+ 模型接入配置
• 服务层：Harness 主进程，监听某个本地端口（比如 3000 或 8080）
• 接入层：Nginx 或 Caddy 做反向代理，处理 TLS、域名、鉴权
• 最外层：公网访问，带身份验证

这个分层很重要，因为它决定了你后面排查问题时该看哪一层。比如浏览器报 404，可能是 Nginx 的 location 没配对；报 502，多半是 Harness 进程没起来或者端口不对；报证书错误，那就是 TLS 层的事。

2.2 Nginx 还是 Caddy，我为什么两个都留了

热词里 Nginx 和 Caddy 都出现了，这不是巧合。这两个是目前反向代理最主流的选择，但性格完全不同。

Nginx 是老牌选手，性能强、生态成熟、资料多，缺点是配置语法偏“工程化”，尤其是 location 的匹配规则，新手很容易写错。Caddy 是后起之秀，最大的卖点是自动申请和续期 TLS 证书，配置文件短到令人发指，几行就能搞定一个带 HTTPS 的反向代理。

我的实际选择是：如果你只是想让 Harness 跑起来并且有 HTTPS，用 Caddy，省心。如果你还要做复杂的路径转发、多站点、限流、缓存，用 Nginx。这篇两种配置我都会给，你可以按需取用。顺便说一句，Caddy 和 WebDAV 搭配也很常见，如果你后面想把 Harness 产出的文件通过 WebDAV 挂载出去，Caddy 的配置会更顺手。

2.3 鉴权方案：别让服务裸奔

公网鉴权访问是标题里的关键词，也是最多人偷懒的地方。我见过太多人直接把 Harness 端口开到公网，结果被扫到之后各种奇怪请求。鉴权我推荐三个层次，按强度递增：

1. 反向代理层的基础认证：Nginx 的auth_basic或 Caddy 的basicauth，最省事，适合个人用。
2. 应用层 Token：Harness 如果自带 API Key 或访问令牌机制，一定要开。
3. 网络层限制：云服务器安全组只放行 80/443，其他端口一律不开。

下面实操部分我会把这三层都串起来。

3. 云服务器环境准备与 Harness 安装实操

3.1 服务器选型与基础环境

云服务器的选择上，我个人的经验是：2 核 4G 起步，系统盘 40G 以上。Harness 本身不重，但如果你要在同一台机器上跑本地模型或者做文档处理，内存会被吃得很厉害。系统我推荐 Ubuntu 22.04 LTS，软件源新、社区资料多，遇到问题好搜。

登录服务器后，第一件事是更新系统并装基础工具：

sudo apt update && sudo apt upgrade -y sudo apt install -y curl wget git vim ufw

防火墙这块，我建议用云厂商的安全组 + 系统自带 ufw 双保险。ufw 只放行 SSH、HTTP、HTTPS：

sudo ufw allow 22/tcp sudo ufw allow 80/tcp sudo ufw allow 443/tcp sudo ufw enable

注意：启用 ufw 之前一定要确认 22 端口已放行，否则你会把自己锁在服务器外面。这个坑我踩过一次，最后只能去云控制台用 VNC 救回来。

3.2 安装运行时环境

Harness 的发行形态不同，依赖也不同。如果是 Node.js 形态，用 nvm 装最干净：

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash source ~/.bashrc nvm install 20 nvm use 20 node -v

如果是 Python 形态，用系统自带的 python3 加 venv 隔离：

sudo apt install -y python3 python3-pip python3-venv python3 -m venv ~/harness-env source ~/harness-env/bin/activate

我强烈建议不要用系统全局环境直接装依赖，因为 Harness 的依赖版本可能和你系统里其他服务冲突。用 nvm 或 venv 做隔离，后面升级、回退都方便。热词里提到的“代码回退”需求，环境隔离就是第一层保障。

3.3 Harness 安装与首次启动

把 Harness 的发行包拉到服务器上，解压到/opt/harness这类标准目录：

sudo mkdir -p /opt/harness sudo chown $USER:$USER /opt/harness cd /opt/harness # 假设你拿到的是压缩包 tar -xzf deepseek-harness.tar.gz --strip-components=1

然后按官方说明安装依赖。Node 形态一般是：

npm install --production

Python 形态是：

pip install -r requirements.txt

首次启动建议前台运行，方便看日志：

node server.js # 或 python main.py

看到类似listening on 127.0.0.1:3000的输出，说明服务起来了。这时候在服务器上用 curl 测一下：

curl http://127.0.0.1:3000

有响应就说明应用层没问题，接下来才是反向代理的事。

实操心得：Harness 默认监听127.0.0.1比监听0.0.0.0更安全。因为反向代理和 Harness 在同一台机器上，走本地回环就够了，没必要让 Harness 直接对外。这一步能挡掉大量扫描。

3.4 用 systemd 让服务常驻

前台跑通之后，必须做成系统服务，否则 SSH 一断服务就没了。写一个 systemd unit：

[Unit] Description=Deepseek Harness Service After=network.target [Service] Type=simple User=youruser WorkingDirectory=/opt/harness ExecStart=/usr/bin/node /opt/harness/server.js Restart=on-failure RestartSec=5 Environment=NODE_ENV=production Environment=PORT=3000 [Install] WantedBy=multi-user.target

保存到/etc/systemd/system/harness.service，然后：

sudo systemctl daemon-reload sudo systemctl enable harness sudo systemctl start harness sudo systemctl status harness

看到active (running)就对了。以后改配置只需要sudo systemctl restart harness。

4. 反向代理配置：Nginx 与 Caddy 双方案

4.1 Nginx 方案：location 匹配机制先搞懂

Nginx 的 location 是新手最容易翻车的地方，热词里“nginx中location工作流机制”“nginx中location工作原理”反复出现，说明大家都在这卡过。简单说，Nginx 收到请求后，会按优先级匹配 location：

理解这个表，你就能明白为什么有时候你写的 location 不生效——多半是被更高优先级的规则截胡了。

安装 Nginx：

sudo apt install -y nginx

给 Harness 写一个站点配置/etc/nginx/sites-available/harness：

server { listen 80; server_name harness.yourdomain.com; location / { proxy_pass http://127.0.0.1:3000; proxy_http_version 1.1; 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_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_read_timeout 300s; } }

几个关键点解释一下：proxy_set_header Upgrade和Connection "upgrade"是为了支持 WebSocket，Harness 如果有实时推送功能，不加这两行会连不上。proxy_read_timeout 300s是因为大模型任务可能跑很久，默认 60 秒会断。

启用站点：

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

nginx -t是必做动作，配置语法错误会在这里暴露，别跳过。

4.2 给 Nginx 加上基础认证

在 location 里加两行：

auth_basic "Restricted"; auth_basic_user_file /etc/nginx/.htpasswd;

生成密码文件需要htpasswd工具：

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

输入两次密码即可。之后访问就会弹出登录框。这是最省事的鉴权方式，适合个人和小团队。

4.3 Caddy 方案：几行搞定 HTTPS

Caddy 的配置短到夸张。装好 Caddy 后，编辑/etc/caddy/Caddyfile：

harness.yourdomain.com { basicauth { youruser $2a$14$xxxxxxxxxxxxxxxxxxxxxxxx } reverse_proxy 127.0.0.1:3000 }

密码哈希用caddy hash-password生成。Caddy 会自动去申请 Let's Encrypt 证书，你什么都不用管。前提是域名已经解析到这台服务器，并且 80/443 端口对公网开放。

注意：Caddy 自动申请证书需要域名能正常解析。如果你用的是纯 IP，Caddy 默认会走内部自签证书，浏览器会报net::err_cert_common_name_invalid这类错误。这种情况要么上域名，要么在客户端手动信任证书。

4.4 两种方案怎么选

我的建议是：第一次部署用 Caddy 快速跑通，等业务复杂了再换 Nginx。两者可以共存，只是别同时监听 80/443。

5. 公网鉴权与安全加固的完整落地

5.1 三层鉴权怎么串

前面说的三层鉴权，落地时是这样配合的：

• 云安全组：只开 22、80、443，Harness 的 3000 端口绝对不对公网开放。
• 反向代理：Nginx 的auth_basic或 Caddy 的basicauth挡住未授权访问。
• 应用层：Harness 自带的 Token 或 API Key 机制，在配置文件里开启。

这样即使有人绕过了某一层，还有下一层兜底。我实测下来，只做反向代理认证就已经能挡掉 99% 的扫描流量。

5.2 域名与 HTTPS 的细节

域名解析用 A 记录指向服务器公网 IP。DNS 生效一般几分钟到几小时，可以用dig harness.yourdomain.com确认。

HTTPS 证书方面，Nginx 配 certbot：

sudo apt install -y certbot python3-certbot-nginx sudo certbot --nginx -d harness.yourdomain.com

certbot 会自动改 Nginx 配置并设置续期定时任务。Caddy 则完全不用管。

实操心得：证书续期失败最常见的原因是 80 端口被占用或防火墙拦截。certbot 验证时需要 80 端口可达，别把它关了。

5.3 日志与监控

Nginx 访问日志在/var/log/nginx/access.log，错误日志在error.log。Windows 上想看 Nginx 日志可以用 Notepad++ 或 glogg 这类工具，Linux 上直接tail -f就行。

Harness 自己的日志通过journalctl -u harness -f看。建议把这两个日志都接一个简单的日志轮转，避免磁盘被写满：

sudo logrotate -d /etc/logrotate.d/nginx

6. 常见问题与排查技巧实录

6.1 高频问题速查表

6.2 几个我踩过的坑

坑一：Harness 装完启动报权限错误。热词里“skill读取文件报权限问题”就是这个。原因是 systemd 里指定的 User 对 Harness 的工作目录没有写权限。解决方法是chown -R youruser:youruser /opt/harness，并且确认 Skill 要读写的目录也在权限范围内。

坑二：Nginx 最大并发连接数老是用超。默认worker_connections是 512，worker_processes是 1。改成：

worker_processes auto; events { worker_connections 4096; }

改完nginx -t再 reload。

坑三：离线局域网能不能用。可以，但要把所有依赖提前打包好，包括模型文件、插件、Skill。Harness 本身不依赖公网，但如果你接的是远端模型 API，那离线环境就得换成局域网内的模型服务。

坑四：插件装不上。多半是网络问题或版本不兼容。先在本地环境验证插件能用，再往服务器上搬。插件推荐方面，我常用的有提示词优化类、文件读写类、代码回退类，这几个在 coding 场景下最实用。

6.3 性能调优的几个参数

如果 Harness 要处理长任务，除了前面说的proxy_read_timeout，还要注意：

• Nginx 的proxy_buffering off：流式输出场景下关掉缓冲，响应更及时。
• client_max_body_size：默认 1M，上传大文件会 413，按需调大。
• Harness 自身的并发配置：看它有没有 worker 数量或队列长度的设置。

7. 后续扩展与个人体会

这套架构跑通之后，扩展空间其实很大。比如你可以把 Harness 和 Ollama 放在同一台机器上，用 Nginx 做统一入口，一个域名下挂多个服务；也可以用 Docker 把 Harness 容器化，配合 Kubernetes 做多副本部署，热词里“kubernetes 部署 nginx”就是这个思路的延伸。再进一步，把 Harness 产出的文件通过 WebDAV 暴露出去，Caddy 配 WebDAV 只需要几行，团队共享文件会方便很多。

我个人在实际操作中的体会是：部署这件事，80% 的时间花在排查环境问题上，20% 花在真正的配置上。所以与其追求一步到位，不如先把最小链路跑通——服务器上 curl 能通、反向代理能转发、鉴权能挡住——然后再一层层加东西。每次只改一个变量，出问题才好定位。

最后分享一个小技巧：把整个部署过程写成一个 shell 脚本，包括装依赖、写 systemd、配反向代理。下次换服务器或者重装系统，一条命令就能重建环境。这个习惯帮我省了无数次重复劳动，也让我对每个步骤的依赖关系理解得更清楚。