1. 项目概述：在 VMware 虚拟机中部署 Deerflow 2.0 —— 一条踩过坑才理清的实操路径

Deerflow 2.0 是一个近年在自动化工作流与低代码集成领域快速崛起的开源平台，它不是传统意义上的 BPM 工具，而更像一个“可编程的流程中枢”：前端用 Vue 构建可视化编排界面，后端基于 Python（FastAPI）提供 API 编排能力，同时深度依赖 Node.js 运行时执行 JavaScript 类型的函数节点、处理 Webhook 回调、调用 NPM 生态模块。它不绑定特定数据库，但生产环境强烈推荐 PostgreSQL；不强制要求容器化，但在虚拟机中部署时，对 Linux 系统基础服务的稳定性、Python 包隔离性、Node.js 版本兼容性有明确且不可妥协的要求。我第一次在 VMware Workstation 上部署 Deerflow 2.0 时，卡在“启动成功但前端白屏”整整两天——后来发现是 Node.js v20.x 编译的前端资源包与 Deerflow 2.0 内置的构建脚本存在 runtime 版本错配，而非网络或权限问题。这恰恰说明：这个项目表面是“装个软件”，实质是一次对 Linux 系统环境、Python 工程化实践、Node.js 运行时生态三者协同能力的综合检验。它适合两类人：一是正在从脚本运维转向平台化管理的中小团队 DevOps 工程师，需要一套轻量、可控、可审计的流程引擎；二是 Python/Node.js 双栈开发者，想快速验证一个融合前后端逻辑的完整工作流闭环。如果你只是想跑个 demo，用官方 Docker 镜像是最快路径；但如果你的目标是理解 Deerflow 如何真正“扎根”于 Linux 系统、后续要对接内网数据库、定制认证模块、或做国产化适配（比如麒麟 V10 或统信 UOS），那么亲手在 VMware 的 Linux 虚拟机里走完一遍完整部署，就是绕不开的第一课。下面所有内容，都来自我在 CentOS Stream 8、Ubuntu 22.04 和 openEuler 22.03 三个发行版上反复验证的真实过程，不讲虚的，只说哪一步必须这么做、为什么不能那么做、以及出错了你该先看哪一行日志。

2. 整体设计思路与关键决策依据

2.1 为什么坚持不用 Docker，而选原生 Linux 部署？

Deerflow 官方文档确实优先推荐 Docker Compose 方式，一键拉起 PostgreSQL + Redis + Backend + Frontend 四个容器。但我在给某制造企业做 PoC 时发现，他们内网完全禁止外网镜像拉取，所有组件必须离线部署；同时其安全规范要求所有服务进程必须由 systemd 统一管理，记录完整 audit 日志，并能被 Zabbix 主动采集 CPU/内存指标。Docker 容器虽然隔离性好，但 systemd 无法直接感知容器内进程的生命周期，audit 日志也默认不透传到宿主机。更重要的是，Deerflow 2.0 的flow-engine模块会动态加载用户上传的.py文件作为自定义节点，这些文件需写入宿主机指定目录并由 backend 进程实时监控——在容器里做这件事，要么得挂载复杂 volume，要么得改源码加 inotify 支持，反而增加不确定性。所以最终方案定为：VMware 虚拟机 → 原生 Linux 发行版 → systemd 托管 backend + nginx 托管 frontend + PostgreSQL 独立安装。这个选择牺牲了“5分钟启动”的便捷性，换来了生产级的可观测性、审计合规性和故障定位效率。你可能会问：“那为什么不直接装在物理服务器上？”答案很实在：VMware 提供了快照回滚能力。Deerflow 2.0 的配置项多达 87 个，光是.env文件就分common,backend,frontend三套，改错一个参数（比如REDIS_URL=redis://localhost:6379/1写成redis://127.0.0.1:6379/1），整个流程引擎就静默失败，没有报错日志——这时候一个 2 分钟前的快照，比查 2 小时文档管用得多。

2.2 发行版选型：CentOS Stream 8、Ubuntu 22.04 还是 openEuler 22.03？

网络热词里高频出现“linux国产”，说明国产化适配是真实需求。我横向测试了三者：

• CentOS Stream 8：作为 RHEL 的上游开发流，软件包新、Python 3.9 和 Node.js 16 开箱即用，systemd 版本新（249），对 cgroup v2 支持完善，Deerflow 后端的异步任务队列（Celery）在 cgroup v2 下调度更稳。但它最大的问题是——社区支持周期短（2024 年 5 月 EOL），不适合长期运行的生产环境。

• Ubuntu 22.04 LTS：Python 3.10、Node.js 18（通过 nodesource 仓库可升至 20），apt 包管理成熟，中文文档丰富。但它的 systemd 版本是 249，cgroup 默认仍为 v1，需手动切换；且其 AppArmor 安全模块有时会拦截 Deerflow backend 对/tmp下临时文件的写入，需额外配置策略。

• openEuler 22.03 LTS：这是目前国产化落地最成熟的选项。它基于 Linux Kernel 5.10，预装 Python 3.9 和 GCC 11，对 ARM64 和 x86_64 双架构支持一致；其 iSulad 容器引擎虽不如 Docker 普及，但原生 systemd 集成度极高，journalctl -u deerflow-backend能直接看到 Celery worker 的每条心跳日志。最关键的是，它已通过等保三级基线加固，/etc/security/limits.conf中的nofile限制默认设为 65535，而 Deerflow 在高并发流程触发时，单个 worker 进程可能打开超 3000 个文件描述符——Ubuntu 默认的 1024 根本不够用，每次都要手动调，openEuler 直接省掉这步。

最终结论：如果追求稳定和国产化，选 openEuler 22.03；如果侧重生态兼容和调试便利，选 Ubuntu 22.04；CentOS Stream 8 仅推荐用于短期技术验证。本文后续所有命令和配置，均以 openEuler 22.03 为基准，但会同步标注 Ubuntu 和 CentOS Stream 的差异点。

2.3 Python 与 Node.js 版本锁定：不是越高越好，而是“刚刚好”

Deerflow 2.0 的pyproject.toml明确声明：

requires-python = ">=3.9, <3.12" [project.dependencies] python-dateutil = "^2.8.2" fastapi = "^0.110.0" uvicorn = "^0.29.0"

而其前端package.json中：

"engines": { "node": ">=18.17.0 <21.0.0", "npm": ">=9.6.7" }

这意味着：Python 3.11.9 是当前最稳妥的选择，Node.js 必须落在 18.17.0 到 20.12.0 之间。我试过 Node.js v21.7.0，npm run build能成功，但生成的dist目录下index.html中的<script>标签引用路径全乱了，导致 404；也试过 Python 3.12.3，pip install -e ".[dev]"直接报pydantic-core编译失败——因为 pydantic v2.7.1 尚未完全兼容 Python 3.12 的新语法。所以版本选择逻辑非常清晰：以 Deerflow 官方 lockfile 为准绳，宁可降级，绝不越界。具体操作上，我放弃系统自带的dnf install python3（openEuler 自带 3.9.16），改用pyenv管理多版本 Python；Node.js 也不用apt install nodejs（Ubuntu 自带 18.19.0，刚好卡在边界上），而是用nvm下载 v20.11.1（LTS 最新版，且经 Deerflow 团队在 CI 中验证过）。这样做的好处是：当 Deerflow 升级到 2.1 时，我只需pyenv install 3.12.0 && nvm install 20.12.0，再pip install -U deerflow，整个环境就能平滑迁移，无需重装系统。

2.4 目录结构设计：拒绝“全扔进 /opt”，按 Linux FHS 标准规划

很多教程把 Deerflow 所有文件一股脑丢进/opt/deerflow，然后用chmod 777解决权限问题。这在演示时没问题，但上线后必出事。我采用严格遵循 Linux Filesystem Hierarchy Standard（FHS）的布局：

这个结构的核心逻辑是：代码（code）与数据（data）物理分离，配置（config）与运行时（runtime）权限隔离。比如/var/lib/deerflow/data目录，deerflow用户必须有写权限，但root不能直接写入（避免误删），其他用户完全不可见；而/etc/deerflow/.env文件，root可读写，deerflow用户组可读但不可写，防止 backend 进程意外覆盖配置。这种设计让systemctl restart deerflow-backend时，systemd 能精准控制哪些文件被谁访问，audit 日志里每条openat()系统调用都清晰可溯。后面你会看到，正是这个目录结构，帮我在一次磁盘满故障中，5 分钟定位到是 Celery 的results表没清理，而不是盲目清空/tmp。

3. 核心细节解析与实操要点

3.1 VMware 虚拟机初始配置：不止是“分配 4G 内存”那么简单

很多人以为 VMware 配置就是调内存和 CPU，其实 Deerflow 对底层虚拟化特性有隐性依赖。以下是我在 openEuler 22.03 上验证过的最小可行配置：

• CPU：至少 2 vCPU，且必须勾选“虚拟化 Intel VT-x/EPT 或 AMD-V/RVI”。Deerflow 的flow-engine模块使用concurrent.futures.ProcessPoolExecutor并行执行 Python 节点，若未开启硬件虚拟化，fork 出的子进程会因缺少 CPU 指令集支持而卡死在os.waitpid()。

• 内存：建议 6GB 起步。Deerflow 前端构建（npm run build）峰值内存占用达 3.2GB；PostgreSQL 的shared_buffers设为 1GB 后，总内存需求轻松突破 4GB。我试过 4GB，构建时npm进程被 OOM Killer 杀掉，错误日志只显示Killed，毫无线索。

• 磁盘：必须使用 SCSI 控制器（非 IDE 或 SATA），且磁盘类型选“厚置备延迟置零”。原因在于 Deerflow 的流程实例状态会高频写入 PostgreSQL 的flow_instance表，SCSI 控制器的 IOPS 调度更优；而“厚置备”能避免虚拟磁盘动态扩容时的锁竞争——某次我们模拟 100 并发流程触发，IDE 控制器下的 PostgreSQL WAL 日志写入延迟飙升至 800ms，直接导致流程超时失败。

• 网络：禁用 IPv6。Deerflow 的backend服务默认监听0.0.0.0:8000，但若系统 IPv6 未禁用，netstat -tlnp | grep :8000会显示它同时绑定了:::8000，而某些老旧防火墙规则（如 iptables 的-A INPUT -p tcp --dport 8000 -j ACCEPT）对 IPv6 无效，导致前端请求 502。简单粗暴的解法是在/etc/default/grub中追加ipv6.disable=1，然后grub2-mkconfig -o /boot/grub2/grub.cfg && reboot。

• Guest OS Tools：务必安装open-vm-tools（openEuler/Ubuntu）或VMware Tools（CentOS Stream），并启用拖放（Drag and Drop）和复制粘贴（Copy and Paste）。这不是为了方便，而是因为 Deerflow 的frontend构建产物dist/目录有 1200+ 个文件，用 SCP 上传极易出错；启用拖放后，可直接把本地构建好的dist文件夹拖进 VMware 窗口，自动完成同步，且保持文件权限。

提示：在 VMware Workstation 中，右键虚拟机 → “设置” → “处理器” → 勾选“虚拟化 Intel VT-x/EPT”；“内存” → 设置为 6144MB；“硬盘” → 点击“SCSI”控制器 → “添加” → 选择“SCSI” → 新建磁盘 → “厚置备延迟置零”。

3.2 Linux 系统基础加固：Deerflow 不是免检产品

Deerflow 本身不处理系统层安全，但它的运行会暴露系统弱点。以下加固步骤在安装 Deerflow 前必须完成：

1. 创建专用用户与组：

   sudo groupadd deerflow sudo useradd -r -s /sbin/nologin -g deerflow deerflow

   -r参数创建系统用户，UID 低于 1000，符合 FHS 规范；-s /sbin/nologin禁止登录，杜绝暴力破解入口。

2. 调整文件描述符限制： openEuler 默认nofile为 65535，但需确认生效：

   echo "deerflow soft nofile 65535" | sudo tee -a /etc/security/limits.conf echo "deerflow hard nofile 65535" | sudo tee -a /etc/security/limits.conf # 验证：sudo -u deerflow bash -c "ulimit -n"

3. 配置时间同步： Deerflow 的流程定时触发（Cron-like）依赖系统时间精度。openEuler 默认用chronyd，但需确保其指向内网 NTP 服务器：

   echo "server 192.168.1.100 iburst" | sudo tee -a /etc/chrony.conf sudo systemctl restart chronyd chronyc tracking # 查看同步状态，Offset 应 < 100ms

4. 关闭 SELinux（仅 openEuler/CentOS）： openEuler 默认启用 SELinux，其策略会阻止deerflow用户写入/var/lib/deerflow/data。与其写复杂策略，不如临时禁用（生产环境应定制策略）：

   sudo sed -i 's/SELINUX=enforcing/SELINUX=permissive/g' /etc/selinux/config sudo setenforce 0

5. 防火墙放行端口： Deerflow 需要三个端口：

   • 8000：Backend API（FastAPI）
   • 8080：Frontend 静态服务（nginx）
   • 5432：PostgreSQL（仅本机访问，不对外）

   sudo firewall-cmd --permanent --add-port=8000/tcp sudo firewall-cmd --permanent --add-port=8080/tcp sudo firewall-cmd --reload

注意：firewall-cmd是 firewalld 命令，Ubuntu 用ufw。Ubuntu 用户执行：

sudo ufw allow 8000 sudo ufw allow 8080 sudo ufw enable

3.3 Python 环境搭建：pyenv + venv 的双重保险

Deerflow 2.0 依赖大量 Python 包（fastapi,sqlalchemy,celery,redis），版本冲突是最大雷区。我采用pyenv管理解释器版本，venv隔离包环境，双保险：

1. 安装 pyenv（openEuler/Ubuntu 通用）：

   curl https://pyenv.run | bash export PYENV_ROOT="$HOME/.pyenv" export PATH="$PYENV_ROOT/bin:$PATH" eval "$(pyenv init -)" source ~/.bashrc

2. 安装 Python 3.11.9：

   pyenv install 3.11.9 pyenv global 3.11.9 python --version # 应输出 3.11.9

3. 创建并激活 venv：

   python -m venv /usr/local/share/deerflow/venv source /usr/local/share/deerflow/venv/bin/activate pip install --upgrade pip setuptools wheel

4. 验证 pip 源（提速关键）： 创建~/.pip/pip.conf：

   [global] index-url = https://pypi.tuna.tsinghua.edu.cn/simple/ trusted-host = pypi.tuna.tsinghua.edu.cn

   这能让pip install速度提升 5 倍以上。清华源同步频率高，包完整性有保障。

实操心得：pyenv安装 Python 时，若报zlib not available错误，说明缺少编译依赖。openEuler 执行sudo dnf groupinstall "Development Tools" && sudo dnf install zlib-devel bzip2-devel openssl-devel ncurses-devel sqlite-devel readline-devel tk-devel gdbm-devel db4-devel libpcap-devel xz-devel；Ubuntu 执行sudo apt update && sudo apt install -y build-essential zlib1g-dev libbz2-dev libssl-dev libncurses5-dev libsqlite3-dev libreadline-dev tk-dev libgdbm-dev libdb5.3-dev libexpat1-dev liblzma-dev libpq-dev。

3.4 Node.js 与前端构建：npm ci 比 npm install 更可靠

Deerflow 前端是标准 Vue 3 + Vite 项目，package-lock.json锁定了所有依赖版本。此时npm install会根据package.json重新解析依赖树，可能引入不兼容的间接依赖；而npm ci严格按package-lock.json安装，保证构建产物 100% 一致。

1. 安装 nvm 与 Node.js v20.11.1：

   curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash export NVM_DIR="$HOME/.nvm" [ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh" nvm install 20.11.1 nvm use 20.11.1 node -v # 应输出 v20.11.1

2. 下载并解压 Deerflow 前端源码： 官方 GitHub Release 页面下载deerflow-frontend-v2.0.0.tar.gz，解压到/usr/local/share/deerflow/frontend。

3. 安装依赖并构建：

   cd /usr/local/share/deerflow/frontend npm ci # 关键！不是 npm install npm run build

   构建成功后，dist/目录生成。注意：npm run build默认输出到dist/，但 Deerflow 后端期望前端资源在/var/www/deerflow。所以执行：

   sudo mkdir -p /var/www/deerflow sudo cp -r dist/* /var/www/deerflow/ sudo chown -R deerflow:deerflow /var/www/deerflow

常见问题：若npm ci报Error: Cannot find module 'vue'，说明node_modules残留。执行rm -rf node_modules package-lock.json && npm ci彻底重来。另外，npm run build若卡在Rollup: building...超过 5 分钟，大概率是内存不足，free -h查看 swap 是否启用，未启用则sudo fallocate -l 2G /swapfile && sudo mkswap /swapfile && sudo swapon /swapfile。

4. 实操过程与核心环节实现

4.1 PostgreSQL 15 安装与 Deerflow 专用库初始化

Deerflow 2.0 要求 PostgreSQL ≥ 13，但 15 是当前最稳版本。openEuler 22.03 自带 PostgreSQL 13，需手动升级。

1. 添加 PostgreSQL 官方仓库：

   sudo dnf install -y https://download.postgresql.org/pub/repos/yum/reporpms/EL-8-x86_64/pgdg-redhat-repo-latest.noarch.rpm sudo dnf -qy module disable postgresql sudo dnf install -y postgresql15-server postgresql15-contrib

2. 初始化数据库集群：

   sudo /usr/pgsql-15/bin/postgresql-15-setup initdb sudo systemctl enable postgresql-15 sudo systemctl start postgresql-15

3. 创建 Deerflow 专用用户与数据库：

   sudo -u postgres psql <<EOF CREATE DATABASE deerflow OWNER deerflow; CREATE USER deerflow WITH PASSWORD 'StrongPass123!'; GRANT ALL PRIVILEGES ON DATABASE deerflow TO deerflow; \c deerflow CREATE EXTENSION IF NOT EXISTS "uuid-ossp"; CREATE EXTENSION IF NOT EXISTS "pg_trgm"; EOF

4. 配置 PostgreSQL 允许本地连接： 编辑/var/lib/pgsql/15/data/pg_hba.conf，在末尾添加：

   # TYPE DATABASE USER ADDRESS METHOD local deerflow deerflow md5 host deerflow deerflow 127.0.0.1/32 md5 host deerflow deerflow ::1/128 md5

   然后重启：sudo systemctl restart postgresql-15。

验证：sudo -u deerflow psql -h 127.0.0.1 -U deerflow -d deerflow -c "SELECT version();"应返回 PostgreSQL 版本。注意：-h 127.0.0.1强制走 TCP，避免 Unix socket 权限问题。

4.2 Backend 服务部署：从源码安装到 systemd 托管

Deerflow 后端需从源码安装，因其包含 C 扩展（如psycopg2-binary），二进制包可能不兼容 openEuler 的 glibc 版本。

1. 下载并解压 Backend 源码： 下载deerflow-backend-v2.0.0.tar.gz，解压到/usr/local/share/deerflow/backend。

2. 在 venv 中安装：

   source /usr/local/share/deerflow/venv/bin/activate cd /usr/local/share/deerflow/backend pip install -e ".[dev]"

3. 创建配置文件/etc/deerflow/.env：

   # 数据库 DATABASE_URL=postgresql+psycopg2://deerflow:StrongPass123!@127.0.0.1:5432/deerflow # Redis（Deerflow 用 Redis 做 Celery broker 和 result backend） REDIS_URL=redis://127.0.0.1:6379/0 # 后端监听 BACKEND_HOST=0.0.0.0 BACKEND_PORT=8000 # 前端地址（用于 CORS） FRONTEND_URL=http://localhost:8080 # 密钥（必须修改！） SECRET_KEY=your-32-byte-secret-key-here-change-it # 数据目录 DATA_DIR=/var/lib/deerflow/data LOG_LEVEL=INFO

4. 编写 systemd 服务文件/etc/systemd/system/deerflow-backend.service：

   [Unit] Description=Deerflow Backend Service After=network.target postgresql-15.service redis.service [Service] Type=simple User=deerflow Group=deerflow WorkingDirectory=/usr/local/share/deerflow/backend EnvironmentFile=/etc/deerflow/.env ExecStart=/usr/local/share/deerflow/venv/bin/uvicorn deerflow.main:app --host ${BACKEND_HOST} --port ${BACKEND_PORT} --workers 2 --log-level ${LOG_LEVEL} --proxy-headers Restart=always RestartSec=10 LimitNOFILE=65535 StandardOutput=journal StandardError=journal [Install] WantedBy=multi-user.target

5. 启用并启动服务：

   sudo systemctl daemon-reload sudo systemctl enable deerflow-backend sudo systemctl start deerflow-backend sudo journalctl -u deerflow-backend -f # 实时查看日志

注意：--workers 2是经验值。Deerflow 的 API 请求多为 I/O 密集型（查 DB、调外部 API），2 个 worker 足够应对 50 并发；若 CPU 密集型任务多（如大文件解析），可增至 4，但需同步调高LimitNOFILE。

4.3 nginx 前端反向代理配置：不只是静态文件托管

Deerflow 前端是单页应用（SPA），所有路由（如/flow/123）都需由 nginx 拦截并返回index.html，否则刷新页面会 404。同时，它需将/api/前缀的请求代理到 backend。

1. 安装 nginx：

   sudo dnf install -y nginx sudo systemctl enable nginx

2. 创建 Deerflow 前端配置/etc/nginx/conf.d/deerflow.conf：

   upstream deerflow_backend { server 127.0.0.1:8000; } server { listen 8080; server_name localhost; # 前端静态文件 location / { root /var/www/deerflow; try_files $uri $uri/ /index.html; } # API 代理 location /api/ { proxy_pass http://deerflow_backend/; 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; } # WebSocket（Deerflow 用 WebSocket 推送流程状态） location /ws/ { proxy_pass http://deerflow_backend/ws/; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; } }

3. 启动 nginx：

   sudo nginx -t # 测试配置 sudo systemctl start nginx

验证：浏览器访问http://<VM-IP>:8080，应看到 Deerflow 登录页；打开开发者工具 Network 标签，刷新页面，应看到/api/v1/health返回 200，/api/v1/login可 POST。

4.4 Redis 安装与 Celery Worker 配置

Deerflow 的异步任务（如发送邮件、调用外部 API）由 Celery 执行，Redis 作为消息中间件。

1. 安装 Redis：

   sudo dnf install -y redis sudo systemctl enable redis

2. 修改 Redis 配置/etc/redis.conf：

   bind 127.0.0.1 ::1 protected-mode yes port 6379 # 禁用 AOF，用 RDB 即可，减少磁盘 IO appendonly no save 900 1 save 300 10 save 60 10000

3. 创建 Celery Worker systemd 服务/etc/systemd/system/deerflow-celery.service：

   [Unit] Description=Deerflow Celery Worker After=network.target redis.service [Service] Type=simple User=deerflow Group=deerflow WorkingDirectory=/usr/local/share/deerflow/backend EnvironmentFile=/etc/deerflow/.env ExecStart=/usr/local/share/deerflow/venv/bin/celery -A deerflow.celery_worker.celery_app worker --loglevel=${LOG_LEVEL} --concurrency=2 Restart=always RestartSec=10 LimitNOFILE=65535 [Install] WantedBy=multi-user.target

4. 启动 Celery：

   sudo systemctl daemon-reload sudo systemctl enable deerflow-celery sudo systemctl start deerflow-celery

提示：--concurrency=2表示每个 worker 进程启动 2 个子进程处理任务。Deerflow 的任务粒度小，2 个足够；若任务耗时长（>30s），可增至 4，但需确保DATA_DIR磁盘空间充足，因 Celery 会缓存任务结果。

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

5.1 前端白屏：90% 的原因是 Nginx 配置或跨域

现象：浏览器打开http://<VM-IP>:8080，页面空白，Console 报Failed to load resource: the server responded with a status of 404 (Not Found)，Network 标签里index.html返回 200，但assets/index.XXXXXX.js返回 404。

排查路径：

1. ls -l /var/www/deerflow/assets/—— 确认 JS 文件是否存在。若不存在，是npm run build未成功或路径拷错。
2. curl -I http://localhost:8080/assets/index.XXXXXX.js—— 若返回 404，检查 nginx 配置中root路径是否正确，try_files是否生效。
3. curl http://localhost:8000/api/v1/health—— 若返回 404 或连接拒绝，说明 backend 未启动或端口不对，journalctl -u deerflow-backend查日志。
4. 若curl能通，但浏览器不行，大概率是跨域。检查/etc/deerflow/.env中FRONTEND_URL是否为http://<VM-IP>:8080（而非localhost），因为浏览器同源策略以实际访问 URL 为准。

独家技巧：在 nginx 配置中临时加一行add_header 'Access-Control-Allow-Origin' '*';，可快速验证是否跨域问题。但生产环境必须删除，改用FRONTEND_URL正确配置。

5.2 流程触发后无响应：Celery Broker 连接失败

现象：在 Deerflow UI 创建一个“HTTP Request”节点，点击“运行”，UI 显示“执行中”，但 2 分钟后变“失败”，journalctl -u deerflow-celery无日志。

排查路径：

1. sudo -u deerflow redis-cli -h 127.0.0.1 -p 6379 ping—— 应返回PONG。若失败，Redis 未启动或配置错误。
2. sudo -u deerflow redis-cli -h 127.0.0.1 -p 6379 keys "*"—— 查看是否有celery开头的 key。若无，说明 Celery 未连上 Redis。
3. journalctl -u deerflow-celery | grep -i "connection refused"—— 若有，检查.env中REDIS_URL是否拼写错误（如redis://127.0.0.1:63790多了个 0）。 4