Dify 本地工作流跑通后，我用 cpolar 给团队开了一个临时验收入口

Dify 在本机跑起来不难，真正麻烦的是验收。

你在浏览器里已经能点通工作流，API 也能 curl 成功，但产品、测试、后端同事看不到你的本地页面。截图只能证明“我这里能跑”，不能证明“团队能按真实流程验收”。

我的做法很简单：Dify 继续跑在本机 Docker 里，只把 Web 页面或 API 端口通过 cpolar 开一个短时 HTTPS 地址。团队拿到链接后，直接验收应用表单、工作流节点、知识库引用、API Key 调用和错误日志。验收结束，关闭 cpolar，公网入口马上失效。

这篇只做一个工程闭环：本地 Dify 可运行、最小工作流可调用、cpolar 临时 HTTPS 可验收、安全边界说清楚。

适用场景

这套流程用在这些场景里很顺手：

• AI 应用还在内测阶段，不想为了半小时验收单独买云服务器和域名
• Dify 工作流已经在本地调通，需要产品同事亲自填表验证输出
• 后端同事要用 HTTPS 地址联调 Dify API，而不是看你贴一段 curl 结果
• 测试同事要复现异常输入、超时、空参数、知识库无命中等边界
• 公司内网机器能跑 Docker，但外部团队成员临时访问不到
• 验收数据已经脱敏，只开放测试应用和测试 token

这里的重点不是“把 Dify 长期挂到公网”，而是“给团队一个短时间、可回收、能真实操作的验收入口”。

最终效果

跑完以后，你会得到三类地址：

• Dify 本地控制台：http://127.0.0.1
• Dify 本地 API：http://127.0.0.1/v1/workflows/run
• cpolar 临时 HTTPS：形如https://xxxx.cpolar.top

团队验收时的访问链路是这样：

同事浏览器 / 后端服务 | | HTTPS v cpolar 临时公网地址 | | 隧道转发 v 本机 Docker 里的 Dify Web / API

产品同事打开 HTTPS 页面验收应用交互，后端同事用同一个 HTTPS 域名调用/v1/workflows/run，你在本机看 Dify 控制台、容器日志和调用记录。

验收结束后，按Ctrl+C停掉 cpolar，或者执行docker compose down停掉 Dify。外部链接随即失效。

环境准备

本文命令以 macOS / Linux 终端为例。Windows 用户在 WSL2 里执行也能跑通。

需要准备这些东西：

• Docker
• Docker Compose v2
• Git
• cpolar 客户端和 authtoken
• 一个可用的模型供应商配置，比如 OpenAI 兼容接口、通义、智谱、硅基流动，或者本地 Ollama

先检查 Docker：

docker --version docker compose version

检查 Git：

git --version

准备一个工作目录：

mkdir -p ~/dify-local-acceptance cd ~/dify-local-acceptance

如果你准备用本地 Ollama 给 Dify 提供模型，先确认 Ollama 能访问：

curl http://127.0.0.1:11434/api/tags

如果你用云端模型供应商，手里要有测试 Key。这里强调“测试 Key”，不要把生产 Key 拿来做验收。

Docker 启动 Dify

Dify 官方仓库已经准备好 Docker Compose 配置，直接拉代码启动。

cd ~/dify-local-acceptance git clone https://github.com/langgenius/dify.git cd dify/docker cp .env.example .env docker compose up -d

第一次启动会拉取多个镜像，耗时和网络有关。启动后查看容器状态：

docker compose ps

正常情况下能看到api、worker、web、db、redis、nginx等服务处于运行状态。

再看一下端口：

docker compose ps nginx

默认配置会通过 nginx 暴露 Web 入口，本机访问：

open http://127.0.0.1

Linux 服务器上没有open命令，可以用：

curl -I http://127.0.0.1

第一次打开 Dify，会进入初始化页面。创建管理员账号后，进入控制台。

如果页面打不开，先看 nginx 和 api 日志：

docker compose logs --tail=100 nginx docker compose logs --tail=100 api

配置模型供应商

进入 Dify 控制台后，打开：

设置 -> 模型供应商

填入你的测试模型配置。

如果使用 OpenAI 兼容接口，通常需要这些字段：

API Key: 你的测试 Key API Base: https://你的模型服务地址/v1 Model: 例如 gpt-4o-mini、qwen-plus、deepseek-chat

如果使用本地 Ollama，Dify 容器内访问宿主机不能直接写127.0.0.1。Docker Desktop 通常使用：

http://host.docker.internal:11434

Linux 环境可以查宿主机网关：

ip route | awk '/default/ {print $3}'

假设输出是172.17.0.1，Ollama 地址就填：

http://172.17.0.1:11434

配置完成后，在 Dify 里点一次模型测试。测试通过，再继续创建工作流。

创建最小工作流和 API

这里不做复杂 Agent，也不接真实业务系统。我们只做一个最小工作流，用来验证 Dify 的“表单输入 -> LLM 处理 -> 结果输出 -> API 调用”。

在 Dify 控制台里按这个路径创建：

工作室 -> 创建空白应用 -> 工作流

应用名称可以写：

团队验收 Demo

工作流节点按下面配置：

1. Start 节点新增一个输入变量

变量名：question 类型：段落文本 必填：是 标签：验收问题

1. 新增 LLM 节点

提示词写成这样：

你是一个企业内部 AI 应用验收助手。 请基于用户输入的问题，输出三部分内容： 1. 你理解到的需求 2. 需要补充确认的信息 3. 可执行的下一步动作 用户问题：{{question}}

模型选择前面已经配置好的测试模型。

1. 新增 End 节点

输出变量选择 LLM 节点的文本结果，例如：

answer = LLM.text

保存并运行一次，输入：

我们要验收一个客服机器人，重点看知识库命中和 API 调用稳定性。

如果页面返回了结构化结果，说明最小工作流已经跑通。

接着发布应用，进入 API 访问页面，创建一个测试 API Key。为了后面命令统一，把 Key 写入环境变量：

export DIFY_API_KEY='app-你的测试APIKey'

本地 API 调用命令如下：

curl -sS http://127.0.0.1/v1/workflows/run \ -H "Authorization: Bearer ${DIFY_API_KEY}" \ -H "Content-Type: application/json" \ -d '{ "inputs": { "question": "请帮我检查这个工作流是否满足团队验收要求" }, "response_mode": "blocking", "user": "acceptance-user-001" }' | python3 -m json.tool

返回里能看到data.outputs，说明 API 也通了。

如果你的 Dify 配置了非 80 端口，把命令里的http://127.0.0.1换成实际本地地址。

用 cpolar 开临时 HTTPS 验收入口

本地页面和 API 都通了，下一步就是把同一个入口临时给团队访问。

安装 cpolar。macOS 可以用 Homebrew：

brew tap probezy/core brew install cpolar

Linux 可以使用官方安装脚本：

curl -L https://www.cpolar.com/static/downloads/install-release-cpolar.sh | sudo bash

配置 authtoken：

cpolar authtoken 你的_cpolar_authtoken

Dify 默认通过本机 80 端口访问，所以直接开 HTTP 隧道：

cpolar http 80

终端里会出现一个 HTTPS 地址，形如：

https://abcd-1234.cpolar.top

把这个地址发给团队，产品同事可以直接打开页面验收应用。

后端同事调用 API 时，把本地地址替换成 cpolar HTTPS 地址：

export DIFY_PUBLIC_URL='https://abcd-1234.cpolar.top' export DIFY_API_KEY='app-你的测试APIKey' curl -sS "${DIFY_PUBLIC_URL}/v1/workflows/run" \ -H "Authorization: Bearer ${DIFY_API_KEY}" \ -H "Content-Type: application/json" \ -d '{ "inputs": { "question": "通过 cpolar HTTPS 调用 Dify 工作流，验证 API 是否可用" }, "response_mode": "blocking", "user": "acceptance-user-remote-001" }' | python3 -m json.tool

如果返回结构和本地一致，公网 HTTPS 到本地 Dify 的链路就跑通了。

团队验收时，我会把测试项拆成下面几类：

看日志的命令：

cd ~/dify-local-acceptance/dify/docker docker compose logs -f api worker nginx

安全边界要提前画清楚

cpolar 解决的是“临时可访问”，不是替你做完整生产安全体系。Dify 里经常有提示词、知识库、API Key、调用日志，这些东西不能随便暴露。

我会按这几个边界执行：

• 只开放测试应用，不开放真实业务应用
• 只使用脱敏输入，不上传客户原始文档、合同、订单、手机号
• API Key 使用测试 Key，验收后立即删除或轮换
• Dify 管理员账号使用强密码，验收账号只给必要权限
• cpolar 只在验收窗口内运行，不后台常驻
• 不把 cpolar 链接发到公开群、论坛、工单截图里
• 不开放数据库、Redis、对象存储、模型服务端口
• 日志里出现 token、手机号、邮箱时，验收后清理对应记录

如果团队只需要验收 API，就不要让所有人都登录控制台。直接给 API 文档、测试 Key 和验收用例即可。

如果团队只需要看页面，就不要把 API Key 发到多人群里。权限越少，事故面越小。

常见问题和排错

1. Dify 容器启动失败

先看容器状态：

cd ~/dify-local-acceptance/dify/docker docker compose ps

再看失败服务日志：

docker compose logs --tail=200 api docker compose logs --tail=200 worker docker compose logs --tail=200 db

端口被占用时，nginx 会起不来。检查 80 端口：

sudo lsof -iTCP:80 -sTCP:LISTEN

如果本机已有 Nginx 或 Apache 占用 80，编辑dify/docker/.env里的外部端口配置，把 Dify 映射到另一个端口，例如8080，然后重启：

docker compose down docker compose up -d

之后本地访问改成：

http://127.0.0.1:8080

cpolar 命令也改成：

cpolar http 8080

2. 模型供应商测试失败

先确认 Dify 容器能访问模型地址。

以 OpenAI 兼容接口为例：

docker compose exec api sh -lc 'python - <<"PY" import urllib.request url="https://api.openai.com/v1/models" req=urllib.request.Request(url, headers={"Authorization":"Bearer YOUR_TEST_KEY"}) try: print(urllib.request.urlopen(req, timeout=10).status) except Exception as e: print(type(e).__name__, e) PY'

把YOUR_TEST_KEY换成测试 Key。这里能返回状态码，说明容器出网没问题。401 代表 Key 或权限错误，超时代表网络或代理问题。

本地 Ollama 访问失败时，重点检查地址不要写成容器内的127.0.0.1。Docker 容器里的127.0.0.1指向容器自己，不是宿主机。

3. API 返回 401

401 基本就是认证问题。按顺序查：

echo "$DIFY_API_KEY"

确认 Header 写法：

Authorization: Bearer app-xxxx

再确认这个 Key 属于当前工作流应用，不是另一个应用的 Key。Dify 的应用 Key 之间不能混用。

4. 工作流页面能跑，API 没输出

检查请求体里的变量名是否和 Start 节点一致。

Start 节点变量叫question，curl 里就必须写：

"inputs": { "question": "你的问题" }

如果写成query、text、prompt，Dify 收不到预期变量，输出就会异常。

再检查 End 节点是否把 LLM 节点结果映射到了输出变量。没有 End 输出，API 返回里就看不到想要的字段。

5. cpolar 地址能打开页面，但 API 调用超时

先在本机调用一次：

curl -sS http://127.0.0.1/v1/workflows/run \ -H "Authorization: Bearer ${DIFY_API_KEY}" \ -H "Content-Type: application/json" \ -d '{"inputs":{"question":"本机 API 测试"},"response_mode":"blocking","user":"local-test"}'

本机也慢，就看 Dify 和模型供应商。公网慢，本机快，就看 cpolar 终端输出和网络链路。

长输出工作流可以把响应模式改成 streaming，但团队验收早期用 blocking 更容易定位问题。

6. 知识库检索为空

本文的最小工作流没有接知识库。如果你在正式验收里接了知识库，按这几个点查：

• 文档是否完成索引
• 检索节点是否接在 LLM 前面
• LLM 提示词里是否引用检索结果变量
• 查询词是否和文档内容同一语言或同一术语
• 文档是否过度脱敏，导致关键词全被替换

排查时用一段短文档做基准，例如只放 5 条 FAQ。短文档能命中，再换大文档。

验收结束后，关闭公网入口

验收最容易被忽略的一步，就是收口。

cpolar 是前台运行时，在终端按：

Ctrl+C

外部 HTTPS 地址就会失效。

如果你用的是后台服务方式运行 cpolar，按你的系统停止服务。Linux 常见命令是：

sudo systemctl stop cpolar

然后处理 Dify 里的测试凭据：

• 删除或轮换本次验收用的 Dify API Key
• 删除临时测试账号
• 清理包含敏感字段的调用日志
• 移除脱敏不彻底的知识库文件
• 把验收结论记录到团队文档里

如果 Dify 本地环境也要停掉：

cd ~/dify-local-acceptance/dify/docker docker compose down

保留数据但停服务，用上面这个命令就够。连数据卷也清掉会删除数据库和上传文件，这个动作要单独确认：

docker compose down -v

写在最后

Dify 的价值不只是“本地能打开一个 AI 应用”，更关键的是让团队能围绕真实输入、真实工作流、真实 API 做验收。

cpolar 在这里扮演的是临时通道：本地继续本地，Docker 继续 Docker，只在需要验收的时间窗打开 HTTPS 入口。它不会把你的本地 Demo 变成生产系统，也不该承担生产网关的职责。

我的习惯是：验收前准备脱敏数据和测试 Key，验收中盯住日志和异常输入，验收后关闭隧道并回收凭据。这个流程跑顺以后，本地 AI 应用从“我这里能跑”到“团队验收通过”，中间就少了很多扯皮。