简介

n8n Ubuntu Cloudflared Docker：本文记录在 Ubuntu 服务器上，使用 Docker 与 Cloudflared（Cloudflare Tunnel）部署 n8n 的完整过程，适用于无公网 IP、无端口转发的环境，并确保域名 HTTPS 访问与 webhook 正常工作。

• 场景：无公网 IP / 无端口转发
• 目标：域名 HTTPS 访问 n8n + webhook 可用
• 方法：Ubuntu + Docker Compose + Cloudflare Tunnel
• 产出：可复现步骤 + 常见坑 + 基本安全建议

1. n8n Ubuntu Cloudflared Docker架构与数据流

本方案的目标是在 没有公网 IP、没有端口转发 的前提下，将 n8n 稳定、安全地暴露到公网，并保证 webhook 可正常回调。

1.1 整体访问路径

外部访问与数据流向如下：

用户浏览器 / 外部服务
        ↓
Cloudflare（HTTPS / WAF / Access）
        ↓
Cloudflare Tunnel（仅出站连接）
        ↓
n8n 容器（Docker 内部网络）

1.2 核心机制说明

• 无需开放任何入站端口
  服务器只主动向 Cloudflare 建立出站连接，本地不监听 80 / 443，也不需要端口转发或公网 IP。
• HTTPS 在 Cloudflare 侧终止
  TLS 证书由 Cloudflare 管理，本地 n8n 服务使用 HTTP 即可，减少证书与反向代理配置复杂度。
• Cloudflare Tunnel 作为唯一入口
  cloudflared 负责将来自 Cloudflare 的请求安全转发到本地 Docker 网络中的 n8n 服务。
• 本地服务对公网不可见
  n8n 不直接暴露在公网，无法被端口扫描或直接访问，基础安全性更高。

1.3 域名与访问方式

你需要准备一个已接入 Cloudflare 的域名，例如：

n8n.dexo.de5.net

该域名将绑定到 Cloudflare Tunnel，并作为：

• n8n Web UI 的访问地址
• 所有 webhook 的统一回调地址（WEBHOOK_URL）

后续所有对外访问均通过该域名完成，本地服务本身不感知公网网络环境。

1.4 适用场景说明

该架构适用于以下情况：

• 服务器没有公网 IP（家庭宽带 / 内网 / NAT 环境）
• 不希望暴露任何服务器入站端口
• 需要稳定的 HTTPS 与 webhook 回调能力
• 希望减少反向代理与证书管理成本

2. 前置条件与约束

• Ubuntu 版本（22.04/24.04）
• 域名已接入 Cloudflare（DNS 在 CF）
• SSH 可用（sudo）
• 你选择的部署方式：cloudflared 容器化（推荐）或宿主机安装（二选一写到底）

3. 安装 Ubuntu 前的准备

3.1 获取 Ubuntu Server 安装镜像

我使用的是 Ubuntu Server 24.04 LTS (amd64)（推荐用于服务器场景）。

• 版本：24.04 LTS
• 架构：amd64（x86_64）
• 类型：Server（不是 Desktop）

下载完成后，建议校验一次文件完整性（可选）：

• Windows：对比官网提供的 SHA256

3.2 制作启动介质（Windows / Rufus）

我在 Windows 上用 Rufus 制作启动盘。

操作步骤：

1. 插入 U 盘（注意：会清空数据）
2. 打开 Rufus
3. Device 选择你的 U 盘
4. Boot selection 选择刚下载的 Ubuntu ISO
5. 关键选项建议：

• Partition scheme：优先选 GPT
• Target system：UEFI (non CSM)

1. 点击 START 开始写入

写入完成后，从 U 盘启动进入 Ubuntu 安装器。

3.3 Ubuntu 24.04 安装记录：n8n Ubuntu Cloudflared Docker 环境准备

目标：装好一个可远程管理、网络明确、存储规划清晰的 Ubuntu 24.04 Server。
要点：安装 OpenSSH Server；后续所有操作使用普通用户 + sudo（不启用 root 远程登录）。

3.3.1 启动安装器

3.3.2 选择语言

3.3.3 安装器更新提示

如果提示安装器有更新：按提示继续即可（不影响后续流程）。

3.3.4 键盘布局

默认即可。

3.3.5 选择安装类型

3.3.6 网络配置

建议：服务器场景最好有明确的 IPv4（静态或 DHCP reservation），避免后续 SSH / 维护地址漂移。

3.3.6.1 IPv4（手动

3.3.6.2 按你的网络环境填写（示例仅供参考）

3.3.6.3 IPv6（DHCP）

3.3.6.4 配置完成后继续

3.3.7 代理配置（Proxy）

一般留空即可（除非你在受限网络必须走代理）。

3.3.8 镜像源配置（Mirror）

默认继续。

3.3.9 存储与分区（Guided Storage）

3.3.9.1 删除默认根分区并重新规划

3.3.9.2 创建分区

3.3.10 交换分区（Swap）

结论先给：如果你只是跑 Docker / n8n，且 不需要休眠（hibernation），Swap 主要用于“兜底缓冲”，不用按 RAM 线性放大。
安装阶段为了简单可控，我这里选择创建一个 Swap 分区（你也可以装完后改用 swapfile，见下文）。

3.3.10.1 先决定：是否需要休眠（hibernation）

• 需要休眠：Swap ≥ RAM（更稳妥：Swap = RAM + 1–2GB）
• 不需要休眠（多数 Server）：Swap 只做缓冲/兜底，不必跟着 RAM 增长

3.3.10.2 不休眠场景：推荐 Swap 大小（按 RAM 档位）

大内存机器不需要用 Swap 当“第二块内存”。Swap 更像安全气囊。

---

• RAM ≤ 4GB：Swap 2–4GB（极端紧张可 4–8GB）
• RAM = 8GB：Swap 4–8GB
• RAM = 16GB：Swap 8GB（常用）
• RAM = 32GB：Swap 8GB（重负载可 8–16GB）
• RAM = 64GB：Swap 8–16GB（看是否跑大量容器/编译/数据库高峰）
• RAM ≥ 128GB：Swap 16GB（一般不建议更大，除非你明确需要）

3.3.10.3 风险与取舍（别误解 Swap 的作用）

• Swap 太小：内存峰值时可能触发 OOM Killer，关键进程会被杀
• Swap 太大：不等于更稳，可能出现 swap storm（系统慢到像卡死），更难排障

原则：给足够 Swap 让系统“缓冲”，但不要让机器靠 Swap 长期续命。

3.3.10.4 Swap 分区 vs Swapfile：怎么选（给出明确建议）

• 优先建议（大多数 Server）：用 swapfile（灵活、后期改大小不用重分区）
• 更适合 Swap 分区的情况：
• 你已经在安装时规划好了分区并希望结构固定
• 特殊存储/加密策略要求
• 你明确知道自己为什么要分区（不是“感觉更专业”）

本文后续部署 n8n 与 Tunnel，对 Swap 的要求不苛刻：能兜底即可。

3.3.10.5 快速决策模板（填完就能定值）

• RAM：__ GB
• 是否休眠：yes / no
• 负载类型：轻量（少容器）/ 中等（多容器）/ 重（编译/数据库）

输出：Swap = __ GB

按模板填完就能给出一个明确 swap 数值（不是范围）。

3.3.11 根分区（/）

这里不做更多分区：剩余空间全部分配给根分区（维护成本更低）。

3.3.12 确认分区并开始写盘

3.3.12.1 确认继续（会写入磁盘）

3.3.13 创建默认用户（用于登录）

这里创建的用户将用于后续所有运维工作（配合 sudo）。不要把 root 当日常登录账号。

3.3.14 Ubuntu Pro（跳过）

默认不启用即可。

3.3.15 安装 OpenSSH Server（必须）

后续要通过 SSH 远程管理服务器，这一步必须安装。

3.3.16 可选软件（不选）

为了减少变量与后续排障成本，这里不选额外组件。

3.3.17 等待安装完成

3.3.18 安装完成并重启

3.3.18.1 按提示回车

3.3.19 首次登录系统

3.3.20 （可选/不推荐）设置 root 密码（仅限本地控制台）

⚠️ 仅在你明确需要在本地控制台以 root 身份操作时使用。
⚠️ 不要开启 root 的 SSH 远程登录；不要开启 SSH 密码登录。本文后续仍以普通用户 + sudo 为主。

为 root 设置密码：

sudo passwd root

3.3.21 安装后初始化 & 安装 nano（必做）

说明：先更新系统并安装基础工具，避免后续安装 Docker / cloudflared 时出现兼容问题。

---

sudo apt update
sudo apt -y upgrade
sudo apt -y install nano curl ca-certificates gnupg lsb-release
sudo reboot

---

3.3.22 修改 SSH 配置（建议：禁 root、禁密码、启用密钥）

⚠️ 先确保你已能用 SSH key 登录，再禁用密码登录。
改配置前保持一个已登录会话，避免把自己锁在外面。

编辑配置文件：

sudo nano /etc/ssh/sshd_config

建议确保以下配置存在（没有就加，有就按此值修改）：

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes

重启 SSH 生效：

sudo systemctl restart ssh
sudo systemctl status ssh --no-pager

在另一台机器新开终端测试 SSH 登录，确认正常后再继续下一章

4. 安装 Docker & Docker Compose （Ubuntu 官方源 / Docker 官方源）

本节目标：在 Ubuntu 上安装 Docker Engine（官方源） 与 Docker Compose v2（plugin），并完成最小验证，确保后续部署 n8n 不踩环境坑。

---

4.1 安装 Docker Engine（Docker 官方源）

先卸载可能存在的旧版本或冲突组件（即使没装过也不会报错）：

sudo apt remove -y docker docker-engine docker.io containerd runc

安装 Docker 官方依赖：

sudo apt update
sudo apt install -y ca-certificates curl gnupg

添加 Docker 官方 GPG key：

sudo install -m 0755 -d /etc/apt/keyrings

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | \
sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg

sudo chmod a+r /etc/apt/keyrings/docker.gpg

添加 Docker 官方 APT 源：

echo \
"deb [arch=$(dpkg --print-architecture) \
signed-by=/etc/apt/keyrings/docker.gpg] \
https://download.docker.com/linux/ubuntu \
$(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

安装 Docker Engine 及相关组件

sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io

启动并设置 Docker 开机自启：

sudo systemctl enable docker
sudo systemctl start docker

4.2 安装 Docker Compose（plugin 方式）

Ubuntu 24.04 官方推荐使用 Docker Compose v2 plugin（不是旧的 docker-compose 单独二进制）。

sudo apt install -y docker-compose-plugin

4.3 （可选）将当前用户加入 docker 组

作用：避免每次运行 Docker 都要加 sudo。
注意：这是便利性设置，不是必须。

sudo usermod -aG docker $USER

使组权限生效（任选其一）：

• 注销并重新登录
• 或直接执行：

newgrp docker

4.4 验证 Docker 与 Compose 是否正常

查看 Docker 版本：

docker version

查看 Docker Compose 版本（注意是 docker compose，不是 docker-compose）：

docker compose version

运行官方测试容器：

docker run --rm hello-world

如果看到类似输出，说明 Docker 运行正常：

Hello from Docker!
This message shows that your installation appears to be working correctly.

至此，Docker 与 Docker Compose 环境准备完成。
下一步将创建 n8n 的部署目录结构，并配置 Cloudflare Tunnel。

5. 创建部署目录与基础规范

本章目标：统一目录结构与配置管理方式，确保后续 docker-compose.yml 可复现、可迁移、可备份。

---

5.1 目录规划（推荐）

我将 n8n 相关文件统一放到：

/opt/n8n

创建目录结构：

你这套就够了，compose/ 目录可要可不要。我建议保留一个目录放 compose 文件，避免 /opt/n8n 乱：

sudo mkdir -p /opt/n8n
sudo mkdir -p /opt/n8n/compose
sudo mkdir -p /opt/n8n/data
sudo mkdir -p /opt/n8n/postgres
sudo chown -R $USER:$USER /opt/n8n

目录用途说明：

• compose/：存放 docker-compose.yml 与 .env
• data/：n8n 持久化数据（关键，必须备份）
• postgres/：Postgres 数据目录（如果使用 Postgres）

---

5.2 使用 .env 管理配置（推荐）

原则：把“会变化的配置”和“敏感信息”放进 .env，避免硬编码在 compose 文件里。

在 /opt/n8n/compose/ 创建 .env：

cd /opt/n8n/compose
nano .env

示例（按你的实际情况替换）：

# 基础
TZ=Asia/Shanghai

# 对外域名（Cloudflare Tunnel 的 hostname）
N8N_HOST=n8n.dexo.de5.net
N8N_PROTOCOL=https
WEBHOOK_URL=https://n8n.dexo.de5.net
N8N_EDITOR_BASE_URL=https://n8n.dexo.de5.net

# Postgres
POSTGRES_DB=n8n
POSTGRES_USER=n8n
POSTGRES_PASSWORD=n8n_password

权限建议（避免其他用户读到敏感信息）：

cd /opt/n8n/compose
nano .env
chmod 600 .env

下一步进入 Cloudflare Tunnel 配置（核心章节），将域名 n8n.dexo.de5.net 绑定到 Tunnel 并转发到本地 n8n 服务。

6. Cloudflared（Cloudflare Tunnel）配置：Ubuntu Docker 部署 n8n

6.1 下载 Cloudflared （按 CPU 架构选择）

⚠️ 先确认你的服务器架构，再下载对应的 cloudflared。下载错架构最常见，表现就是“无法执行 / Exec format error”。

查看架构（Ubuntu）：

uname -m
dpkg --print-architecture

常见结果与对应下载建议：

• x86_64 / amd64 → 下载 linux-amd64（多数云服务器/PC 服务器都是这个）
• aarch64 / arm64 → 下载 linux-arm64（树莓派、部分 ARM 服务器）
• armv7l → 下载 linux-arm（较老的 32 位 ARM）

本文示例以 amd64（x86_64） 为例；如果你的输出不是 amd64，请到 Release 页面选择与你架构匹配的文件再继续。

6.1.1Ubuntu amd64（24.04/22.04）推荐用 .deb：

cd /tmp
wget -O cloudflared-linux-amd64.deb \
  https://github.com/cloudflare/cloudflared/releases/download/2026.2.0/cloudflared-linux-amd64.deb

sudo dpkg -i cloudflared-linux-amd64.deb || sudo apt-get -f install -y
cloudflared --version

6.2 使用 cloudflared 创建 Cloudflare Tunnel（Docker 容器方式，本地管理）

本节采用 本地管理模式（local management）：先用 cloudflared tunnel login 完成 OAuth 授权，在服务器本地生成凭据文件，再创建 Tunnel。
不要混用 token 远程管理方式（那条路不需要 tunnel login，逻辑完全不同）。

6.2.1 先在网页端登录 Cloudflare

在浏览器先登录 Cloudflare Dashboard（保持登录状态即可），后续终端授权时会直接跳到已登录账号，减少重复登录/验证码操作。

6.2.2 在服务器终端执行 cloudflared 授权登录

在服务器终端执行以下命令：

cloudflared tunnel login

执行后，终端会输出一个授权 URL。

1. 复制该 URL
2. 在浏览器中打开
3. 选择需要授权的 Cloudflare 账号与域名并确认

授权完成后，终端会提示登录成功，并在本机生成 Cloudflared 的凭据文件（用于后续创建和运行 Tunnel）。

说明：

• 该步骤是 必须的授权步骤
• 仅用于让当前服务器具备管理 Cloudflare Tunnel 的权限
• 网页端提前登录只是为了方便，不会替代此步骤

6.2.3选择要使用的域名

6.2.4 为dexo.de5.net授权隧道

6.2.4 成功授权隧道

6.3 创建 Cloudflare Tunnel（隧道）

完成 cloudflared tunnel login 授权后，在服务器上创建一个 Tunnel。

6.3.1 创建 Tunnel

将 n8n-tunnel 替换成你自己的名字（建议与用途一致）：

cloudflared tunnel create n8n-tunnel

成功后会输出 Tunnel 的 UUID，同时在本机生成 Tunnel 凭据文件（后续运行隧道要用）。

6.3.2 查看 Tunnel 列表与确认 UUID

cloudflared tunnel list

你会看到类似：

• NAME：n8n-tunnel
• ID（UUID）：xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

记录这个 UUID，后面绑定域名、创建 DNS 记录、配置 ingress 都会用到。

6.4 检查凭据文件与编写 Cloudflare Tunnel 配置文件（config.yml）

现在的 Tunnel 信息：

• Tunnel 名称：n8n-tunnel
• Tunnel UUID：95b9531d-dc85-47d2-afe9-301205c85e3f

这一节只做两件事：确认凭据文件存在，然后 写 config.yml（ingress 路由规则）。

---

6.4.1 检查 cert.pem 与 Tunnel 凭据文件是否存在

先检查目录内容：

ls -la ~/.cloudflared

你应该至少看到：

• cert.pem（来自 cloudflared tunnel login）
• 95b9531d-dc85-47d2-afe9-301205c85e3f.json（来自 cloudflared tunnel create）

如果没有 .json，说明你并没成功创建 tunnel；如果没有 cert.pem，说明 login 授权没成功。

---

6.4.2 编写 ~/.cloudflared/config.yml

编辑配置文件：

nano ~/.cloudflared/config.yml

# Cloudflare Tunnel 配置文件
tunnel: 95b9531d-dc85-47d2-afe9-301205c85e3f
credentials-file: /root/.cloudflared/95b9531d-dc85-47d2-afe9-301205c85e3f.json

# 全局连接设置（可选）
originRequest:
  connectTimeout: 30s

# 入口规则（重点）
ingress:
  # n8n Web UI / webhook 统一入口
  - hostname: n8n.dexo.de5.net
    service: http://localhost:5678

  # 默认规则：未匹配的域名一律 404（别省略）
  - service: http_status:404

两条硬性要求：

1. credentials-file 路径必须指向你的 UUID 对应的 .json
2. 最后一条 http_status:404 必须保留，否则“匹配不到的请求”会乱转发，排障极其痛苦

如果你的 cloudflared 是用普通用户运行（不是 root），credentials-file 不应该写 /root/...，而要写该用户的 home 路径，比如 /home/你的用户名/.cloudflared/...json。你这点如果写错，cloudflared 会直接启动失败或循环重启。

---

6.4.3 快速校验配置是否写对（建议做一次）

只检查是否能读取配置并尝试启动（前台运行，方便看报错）：

cloudflared tunnel --config ~/.cloudflared/config.yml run

看到连接成功的日志再 Ctrl + C 退出，进入下一章再做常驻运行（systemd 或 docker-compose 任选其一，但别混写）。

---

6.4.4 配置 cloudflared 启动文件（systemd）

目标：让 cloudflared 作为系统服务开机自启、异常自动重启，并使用你刚写好的 config.yml。

1）创建/编辑 systemd 服务文件

sudo nano /etc/systemd/system/cloudflared.service

写入下面内容（把 tunnel 名称 改成你的：n8n-tunnel）：

[Unit]
Description=cloudflared (Cloudflare Tunnel)
After=network-online.target
Wants=network-online.target

[Service]
TimeoutStartSec=0
Type=simple
ExecStart=/usr/bin/cloudflared --loglevel info --transport-loglevel warn --config /root/.cloudflared/config.yml tunnel run n8n-tunnel
Restart=on-failure
RestartSec=5s

[Install]
WantedBy=multi-user.target

关键点：

• --config /root/.cloudflared/config.yml 必须指向你实际的配置文件路径
• tunnel run n8n-tunnel 这里用 tunnel 名称（你的是 n8n-tunnel），也可以用 UUID，但别乱写成别的机器名

如果你不是以 root 安装/运行 cloudflared，或者你的 config.yml 不在 /root/.cloudflared/，这里必须改成对应路径，否则服务会启动失败。

2）加载配置并启动服务

sudo systemctl daemon-reload
sudo systemctl enable --now cloudflared

查看状态：

sudo systemctl status cloudflared --no-pager

查看最近日志（排障必备）：

sudo journalctl -u cloudflared -n 200 --no-pager

3）常见启动失败原因（你这里最容易踩）

ExecStart=/usr/bin/cloudflared 路径不对
用这个确认实际路径：

which cloudflared

credentials-file 指向 /root/.cloudflared/*.json，但服务不是 root 跑 → 无权限/找不到文件

tunnel run 后面写错（名称拼错、或写成别的 tunnel）

6.5 绑定域名并创建 DNS 路由（将 n8n.dexo.de5.net 指向 Tunnel）

这一节的目标只有一个：
让 dexo.de5.net 的所有请求，通过 Cloudflare DNS → Tunnel → 转发到本地 n8n。

前提假设（不满足就别往下走）：

• Tunnel 已创建（你的是 n8n-tunnel）
• cloudflared 服务已能正常启动
• config.yml 中已经写好 hostname: n8n.dexo.de5.net

---

6.5.1 创建 DNS 路由（CNAME → Tunnel）

正确做法只有一种：用 cloudflared 创建 DNS 路由。
不要手写 DNS，不要指 IP，不要乱加 A 记录。

执行：

cloudflared tunnel route dns n8n-tunnel n8n.dexo.de5.net

成功后会看到类似输出：

Added CNAME n8n.dexo.de5.net which will route to this tunnel tunnelID=95b9531d-dc85-47d2-afe9-301205c85e3f

这一步等价于在 Cloudflare DNS 中创建一条：

• 类型：CNAME
• 主机名：n8n.dexo.de5.net
• 目标：<UUID>.cfargotunnel.com
• Proxy：开启（橙云）

你不用也不应该手动改 DNS。
cloudflared 会帮你做 正确且可追溯 的配置。

6.5.2 校验 DNS 是否已绑定到 Tunnel

查看 DNS 记录（命令行）：

cloudflared tunnel route dns n8n-tunnel dexo.de5.net

6.5.3 重启 cloudflared

重启服务，强制加载最新配置：

sudo systemctl restart cloudflared

查看状态：

sudo systemctl status cloudflared --no-pager

查看最近日志（排障必备）：

sudo journalctl -u cloudflared -n 200 --no-pager

7. Docker Compose 部署 n8n（Postgres 推荐）

本章目标：用 Docker Compose 在 Ubuntu 上部署 n8n + Postgres，并确保与 Cloudflare Tunnel 的域名 n8n.dexo.de5.net 完整对齐（UI + webhook 都正确）。

7.1 数据库选择

Postgres（推荐）：稳定、可备份、可迁移，适合长期运行（本文使用）

SQLite：部署最简单，但不适合长期运行（数据安全、并发、迁移、备份都更难控）

7.2 编写 docker-compose.yml

位置：/opt/n8n/compose/docker-compose.yml

cd /opt/n8n/compose
nano docker-compose.yml

sudo chown -R 1000:1000 /opt/n8n/data
sudo chmod -R u+rwX,g+rwX /opt/n8n/data

sudo chown -R 999:999 /opt/n8n/postgres

粘贴以下内容：

version: "3.8"

services:
  # ===============================
  # PostgreSQL 数据库
  # ===============================
  postgres:
    image: postgres:16
    container_name: n8n-postgres
    restart: unless-stopped
    networks:
      custom-net:
        ipv4_address: 172.16.0.11
    environment:
      POSTGRES_USER: ${POSTGRES_USER}
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
      POSTGRES_DB: ${POSTGRES_DB}
    volumes:
      - /opt/n8n/postgres:/var/lib/postgresql/data

  # ===============================
  # n8n 自动化服务
  # ===============================
  n8n:
    image: docker.n8n.io/n8nio/n8n
    container_name: n8n
    restart: unless-stopped
    networks:
      custom-net:
        ipv4_address: 172.16.0.10
    depends_on:
      - postgres
    environment:
      # DB
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
      - DB_POSTGRESDB_PORT=5432
      - DB_POSTGRESDB_DATABASE=${POSTGRES_DB}
      - DB_POSTGRESDB_USER=${POSTGRES_USER}
      - DB_POSTGRESDB_PASSWORD=${POSTGRES_PASSWORD}

      # n8n 对外访问（关键：webhook 必须对齐域名/协议）
      - N8N_HOST=${N8N_HOST}
      - N8N_PORT=5678
      - N8N_PROTOCOL=${N8N_PROTOCOL}
      - WEBHOOK_URL=${WEBHOOK_URL}
      - N8N_EDITOR_BASE_URL=${N8N_EDITOR_BASE_URL}

      # 基础
      - TZ=${TZ}

      # 文件与执行策略（按你现有习惯保留）
      - N8N_DEFAULT_BINARY_DATA_MODE=filesystem
      - N8N_FILES_BASE_PATH=/files
      - N8N_NODE_EXECUTE_COMMAND_ENABLED=true
      - N8N_NODE_LOCAL_FILE_TRIGGER_ENABLED=true
      - N8N_PUBLIC_API_DISABLED=false
      - N8N_ALLOW_EXTERNAL_REQUESTS=true
      - N8N_MCP_TELEMETRY_DISABLED=true
      - N8N_COMMUNITY_PACKAGES_ALLOW_TOOL_USAGE=true

      # 反代/隧道场景：必须信任代理头
      - N8N_TRUST_PROXY=all
      - N8N_PROXY_HOPS=1

      # 你选择关闭限流（保留）
      - N8N_RATE_LIMIT_ENABLED=false

    # 端口映射（按你现有方案保留）
    ports:
      - "5678:5678"

    volumes:
      - /opt/n8n/data:/home/node/.n8n
      - /opt/n8n/data/files:/files
      - /opt/n8n/data/n8n-files:/home/node/.n8n-files

    # 高权限（按你现有配置保留）
    privileged: true
    cap_add:
      - NET_ADMIN
      - NET_RAW

# ===============================
# 自定义 bridge 网络（按你现有方案保留）
# ===============================
networks:
  custom-net:
    driver: bridge
    enable_ipv6: true
    ipam:
      driver: default
      config:
        - subnet: 172.16.0.0/24
          gateway: 172.16.0.254

7.3 启动与验证

启动：

cd /opt/n8n/compose
docker compose up -d

确认容器运行：

docker ps

查看 n8n 日志：

docker logs -f n8n

本机访问（端口映射存在，直接测）：

curl -I http://127.0.0.1:5678/

对外访问（走 Cloudflare Tunnel）：

curl -I https://n8n.dexo.de5.net/

访问验证：
打开 https://n8n.dexo.de5.net，页面可正常加载并进入注册初始化流程。

功能验证：
已完成基础验收：工作流创建与执行正常；节点与插件安装可用；常用模块运行无异常。
本章不再展开功能细节，下一节进入 webhook 与 Tunnel 回调的专项验证。

8. 启动、验证与“最容易翻车的点”

8.1 启动

在 n8n compose 目录启动：

cd /opt/n8n/compose
docker compose up -d

检查容器状态：

docker ps

查看日志（遇到问题先看这里）：

docker logs -f n8n
docker logs -f n8n-postgres
sudo journalctl -u cloudflared -n 200 --no-pager

---

8.2 基础验证（先内后外）

8.2.1 本机验证（排除 Tunnel 干扰）

curl -I http://127.0.0.1:5678/

• ✅ 返回 200/302：n8n 本地服务正常
• ❌ 连接失败：先修 Docker / n8n，不要怪 Tunnel

8.2.2 外网验证（走 Cloudflare Tunnel）

curl -I https://n8n.dexo.de5.net/

• ✅ 返回 200/302：域名 → Tunnel → 本机转发链路正常
• ❌ 404/502：看 8.4 对照表，别瞎猜

curl -i https://n8n.dexo.de5.net/webhook/ping

• ✅ workflow 被触发：Webhook 链路完整
• ❌ 返回 404 / 无触发：看 8.3 对照表

注意：
Production URL 的调用不会显示在画布上，只会出现在 Executions 列表，这是 n8n 的正常行为。

---

8.2 Webhook 验证的核心一致性检查

以下三处 必须完全一致，任何一处不一致都会导致 webhook 异常：

1. n8n 环境变量
   • N8N_HOST = n8n.dexo.de5.net
   • N8N_PROTOCOL = https
   • WEBHOOK_URL = https://n8n.dexo.de5.net/
   • N8N_EDITOR_BASE_URL = https://n8n.dexo.de5.net/
2. Cloudflared ingress

- hostname: n8n.dexo.de5.net
  service: http://localhost:5678

1. Cloudflare DNS
   • n8n.dexo.de5.net
   • CNAME → *.cfargotunnel.com

---

8.3 最容易翻车的点（症状 → 原因 → 解决）

A) 返回 404：webhook not registered

原因：

• workflow 未激活
• 调用的是 Test URL，却用 Production URL 请求
• HTTP Method 不匹配（POST 节点却用 GET）

解决：

• 确认 workflow 为 Active
• 复制 Webhook 节点里的 Production URL
• 使用与节点一致的 HTTP Method

---

B) UI 正常，但 webhook 永远不触发

原因：

• WEBHOOK_URL / N8N_HOST / 协议 与实际域名不一致

解决：

• 强制对齐域名与协议
• 修改后重启 n8n：

docker compose restart n8n

C) 访问返回 502

原因：

• cloudflared ingress 指向的地址或端口不通

检查顺序：

1. 本机是否能访问： curl -I http://127.0.0.1:5678/
2. cloudflared 日志： sudo journalctl -u cloudflared -n 200 --no-pager

---

D) 重启后需要重新注册 / 数据丢失

原因：

• n8n 数据目录未正确挂载
• 宿主机目录权限错误

检查：

• /opt/n8n/data 是否存在且可写
• 是否挂载到 /home/node/.n8n

. n8n Ubuntu Cloudflared Docker 生产化最小集（只写必要的）

判定标准只有四条：

• 出事能恢复
• 能安全更新
• 能快速排障
• 不裸奔

做不到这四点，不要称“生产可用”。

---

9.1 备份与恢复（必须能演练）

9.1.1 n8n 数据目录备份（核心）

n8n 的所有关键资产（工作流、凭据、用户配置）都在宿主机目录：

/opt/n8n/data

最简单、可靠的离线备份方式：

sudo tar -czf /opt/backup_n8n_data_$(date +%F).tar.gz /opt/n8n/data

注意：

• 只备份 docker-compose.yml 没意义
• /opt/n8n/data 才是真正值钱的部分
• 备份文件必须放到不同磁盘 / 不同机器

---

9.1.2 Postgres 备份（推荐使用 dump）

使用 pg_dump，而不是“相信 volume 不会坏”。

docker exec -t n8n-postgres \
  pg_dump -U n8n n8n > /opt/backup_n8n_pg_$(date +%F).sql

9.1.3 恢复演练（不做等于没备份）

Postgres 恢复：

docker exec -i n8n-postgres \
  psql -U n8n n8n < backup_n8n_pg_YYYY-MM-DD.sql

n8n 数据目录恢复：

docker compose down
rm -rf /opt/n8n/data
tar -xzf backup_n8n_data_YYYY-MM-DD.tar.gz -C /
docker compose up -d

至少完整演练一次。
没演练过的备份 = 心理安慰。

---

9.2 更新与回滚（必须有退路）

标准更新流程（不要即兴发挥）：

# 1. 更新前必须先备份（9.1）
# 2. 拉取新镜像
docker compose pull

# 3. 启动
docker compose up -d

如果更新后异常：

• 查看日志（见 9.3）
• 无法快速修复 → 立即回滚

docker compose up -d --no-deps n8n:<旧镜像tag>

没有回滚路径的更新 = 事故预备动作。

---

9.3 排障固定入口（只认这三个）

不要从 UI 猜问题，先看日志。

# n8n 本体
docker logs -f n8n

# Postgres
docker logs -f n8n-postgres

# Cloudflare Tunnel
sudo journalctl -u cloudflared -n 200 --no-pager

原则：

• UI 报错 ≠ 根因
• 日志是唯一可信来源

---

9.4 安全红线（不满足别上线）

你已经把 n8n 暴露到公网（通过 Cloudflare Tunnel），必须至少加一道门槛，否则就是高价值攻击面。

二选一（至少）：

• Cloudflare Access（强烈推荐）
  仅允许指定账号 / 邮箱组访问 n8n.dexo.de5.net
• Basic Auth（次选）
  至少挡住脚本扫描和低成本攻击

明确结论：

• Tunnel ≠ 认证
• 没有 Access / Auth 的 n8n，不叫生产
• “先跑起来再加安全”是事故前兆

---

9.5 生产最低自检清单（上线前 30 秒）

• /opt/n8n/data 已定期备份
• Postgres dump 能成功恢复
• 更新流程和回滚路径已验证
• 日志入口清楚、能第一时间查看
• Cloudflare Access / Auth 已启用

缺一条，都不该对外暴露。

---

一句结束语（别删）

---

10 n8n Ubuntu Cloudflared Docker 参考链接

以下链接覆盖本文所用到的唯一权威来源，用于查官方行为、参数含义与边界条件。不列博客、不列二手教程，避免信息漂移。

n8n 官方

• n8n 官方文档（部署 / 环境变量 / Webhook 行为）：
  https://docs.n8n.io/
• n8n Docker 官方镜像说明：
  https://hub.docker.com/r/n8nio/n8n
• n8n Webhook（Production vs Test URL 机制）：
  https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.webhook/

Cloudflare Tunnel / Cloudflared

• Cloudflare Tunnel 官方文档（总体概念）：
  https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-tunnel/
• cloudflared 下载（Release / 架构区分）：
  https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-tunnel/downloads/
• cloudflared CLI（tunnel / route / config.yml）：
  https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-tunnel/configure-tunnels/
• Cloudflare Access（零信任访问控制）：
  https://developers.cloudflare.com/cloudflare-one/identity/

Docker / Docker Compose

• Docker Engine 官方文档（Linux）：
  https://docs.docker.com/engine/install/ubuntu/
• Docker Compose v2 官方文档：
  https://docs.docker.com/compose/
• Docker volumes / bind mounts（权限与持久化）：
  https://docs.docker.com/storage/

PostgreSQL

• PostgreSQL 官方文档（备份与恢复）：
  https://www.postgresql.org/docs/current/backup.html

---

说明：

• 所有行为以官方文档为准，第三方教程只用于补充理解，不作为依据。
• 当本文与官方文档存在差异时，应优先以官方文档的当前版本为准。