从零自建 Discourse 社区：Cloudflare Tunnel 部署与踩坑全记录

前言：为什么我想自己搭建一个独立社区

长期混迹在各类公共论坛、第三方社区平台，我一直有一种很强烈的束缚感。不管是综合型的技术社区，还是垂直小众的交流板块，规则永远由平台制定，内容随时可能被限流、删除，账号权限完全不在自己手里。想要一个完全属于自己、自由度拉满、可以自定义规则、沉淀内容的线上空间，成了我很久以来的一个想法。

市面上可选的社区程序不少：老牌的 Discuz! 臃肿老旧、现代化交互不足；Flarum 轻量化但生态插件偏少；而 Discourse 作为开源现代社区解决方案，以响应式设计、完善的反垃圾机制、邮件通知系统、Docker 一键部署生态，最终成为了我的选择。我的社区域名定为 nodebyte.cn，取名 NodeByte，寓意由一个个代码字节、独立节点组成的小社区，一个可以自由交流、记录分享的自留地。

整个搭建过程没有选择一键脚本、宝塔面板这类封装化工具，全程采用官方 discourse_docker 原生部署方式，从系统初始化、容器部署、域名解析、HTTPS、Cloudflare Tunnel 内网穿透、真实 IP 修复、离线 IP 地理位置库挂载，一步步踩坑、调试、完善，最终完成一套稳定、可维护、全自定义的独立社区。这篇文章记录我完整的搭建心路历程与配置思考。

一、前期准备：基础环境与方案选型

1.1 服务器与系统规划

我选用的是 Debian 系纯净服务器，没有预装任何多余面板软件。Discourse 官方最低要求内存 2GB，生产环境推荐 4GB 以上，同时必须开启 Swap 分区防止编译 OOM 崩溃。 在正式部署之前，我先完成服务器基础加固：更新系统源、配置 SSH 密钥登录、关闭密码登录、设置时区、安装基础依赖 git、curl、wget。全程使用官方推荐的 Docker 运行环境，所有服务容器化隔离，避免污染宿主机环境，后续迁移、备份、重建都只需要一份 app.yml 配置文件。

1.2 访问方案抉择：公网端口 vs Cloudflare Tunnel

常规部署 Discourse 的方案分为两种：直接在服务器开放 80/443 端口，域名解析指向服务器公网 IP；或者使用 Cloudflare Tunnel（原 Argo Tunnel）。 直接暴露公网端口会面临不少问题：端口扫描、恶意爬虫、CC 攻击，国内网络环境还会有 IP 封禁、备案相关的限制。而 Cloudflare Tunnel 的优势在于：服务器不需要暴露任何端口到公网，由客户端主动向外建立加密隧道连接 Cloudflare 边缘节点，流量经过 Cloudflare 的 CDN、WAF 防护，隐藏真实服务器 IP，不需要处理复杂的防火墙规则。 于是我确定了最终架构：宿主机或者容器内部运行 cloudflared 客户端建立隧道，域名在 Cloudflare 后台托管解析，流量走隧道加密回源，对外只暴露域名，不泄露服务器真实地址。

这里我做了一个关键的决定：将 cloudflared 客户端直接集成进 Discourse 容器内部托管，而不是宿主机 systemd 服务。好处是整个社区环境一体化，迁移服务器时，只需要复制一份配置文件，重建容器即可完整恢复整套服务，不需要单独维护宿主机后台进程，所有服务统一由 discourse_docker 的 runit 进程管理器托管。

二、Discourse 官方基础部署：构建第一个可用社区

2.1 拉取官方部署仓库

Discourse 官方部署工具 discourse_docker 是整套系统的核心，它封装了 PostgreSQL、Redis、Nginx、Sidekiq 整套依赖，通过单一配置文件 app.yml 控制全部变量、挂载目录、自定义脚本。 我在 /mnt/4sd/discourse 目录存放整套部署文件，执行 git 拉取官方仓库，复制 standalone 模板作为基础配置文件。基础配置里填写域名 DISCOURSE_HOSTNAME=nodebyte.cn、SMTP 邮件发件配置、管理员邮箱，设置共享数据卷，将 /shared 目录挂载到宿主机持久化存储，保证重建容器时上传的图片、备份文件、日志不会丢失。

初次执行 ./launcher rebuild app 的过程非常漫长，脚本会自动拉取基础镜像、安装全部依赖、编译前端资源、初始化数据库、第一次等待十几分钟后，一个空白的 Discourse 论坛已经可以访问。

但此时只是一个基础可用版本，还有大量优化、代理兼容、安全细节没有处理，接下来就是漫长的精细化调试阶段。

三、接入 Cloudflare Tunnel：容器内部署 cloudflared 隧道客户端

3.1 两种部署模式的坑点

最开始我测试过宿主机安装 cloudflared service install 系统服务，隧道正常连通后发现一个问题：宿主机代理访问容器内的 Nginx，日志全部记录为 127.0.0.1，拿不到用户真实访客 IP。 如果把 cloudflared 放进容器内部，又有新的细节需要处理：Debian 容器默认没有 cloudflared 软件源，需要手动下载 deb 离线包；容器使用 runit 管理服务，不能使用宿主机的 systemd；隧道凭证需要通过官方的 service install 命令写入，云端隧道提前在 Cloudflare 后台创建完成，本地客户端只需要认证令牌，不需要在配置文件内定义隧道路由。

3.2 编写自定义 run 配置块

我在 app.yml 的 run 节点追加一整套自动化部署脚本：

1. 执行 apt update 更新软件源，安装 wget 下载工具；
2. 通过国内加速镜像下载指定版本 cloudflared-linux-386.deb 安装包；
3. 使用 dpkg -i 安装客户端，依赖缺失时自动修复安装；
4. 执行 cloudflared service install + 隧道令牌，写入隧道认证凭证；
5. 创建 /etc/service/cloudflared runit 服务目录，编写可执行 run 脚本，后台运行 cloudflared tunnel run。

这里踩了一个 discourse_docker 的语法大坑：exec.cmd不支持数组分行执行多条独立命令，每一条 cmd 都会开启一个独立临时 shell，环境变量、文件操作无法传递，必须使用 bash -c "" 把整套安装命令串联在同一个进程内执行，否则安装流程会中途失效。 修正格式后的配置可以在每次重建容器时，自动下载、安装、注册隧道凭证，拉起后台隧道进程，不需要任何人工干预。重建完成后，进入容器执行 sv status cloudflared，状态显示 run，代表隧道客户端正常运行，Cloudflare 后台隧道状态变为活跃。

四、真实 IP 问题排查：一个破折号引发的代理故障

4.1 诡异的日志问题

隧道跑通之后，访问网站一切正常，但是查看 Nginx 访问日志、后台用户登录记录，所有访问 IP 全部是 127.0.0.1，没有拿到外网用户真实 IP。 Discourse 官方提供了 cloudflare.template.yml 模板，它的作用是自动配置 Nginx 的 real_ip_header，并且定期拉取 Cloudflare 官方节点 IP 段作为信任代理列表。启用模板之后依然无效，我打开了容器内的配置文件 /etc/nginx/conf.d/outlets/server/real-ip-header.conf，终于找到了根源：文件里面的 cf‑connecting‑ip 并不是标准英文短横线，而是复制粘贴带来的 Unicode 长破折号非法字符。 Nginx 无法识别这个错误的指令，直接忽略整套真实 IP 解析规则，导致代理 IP 完全没有被替换。

4.2 永久修复 real‑ip 配置

想要一劳永逸解决这个问题，不能手动修改容器内临时文件，每次重建容器官方模板都会重新生成错误配置。我直接在 app.yml 的 run 配置块中，通过 file 指令强制覆盖三个关键 Nginx 配置文件：

1. real-ip-header.conf：强制写入标准 real_ip_header cf-connecting-ip;；
2. real-ip-recursive.conf：开启递归代理解析；
3. set-real-ip-from-tunnel.conf：额外信任本地回环、内网网段，适配容器内部的 cloudflared 代理。

重建容器之后，我手动使用 curl 携带 CF-Connecting-IP 请求头测试访问，查看日志第二条 IP 字段成功替换为测试 IP，真实 IP 解析功能彻底修复。 这一步是整套配置里最重要的一环：没有真实 IP，后台封禁账号、登录审计、IP 归属地查询全部失去意义，后续所有 IP 相关功能都建立在这个配置之上。

五、IP 地理位置库：可选的管理员增强工具

5.1 MaxMind GeoLite2 的两种方案

Discourse 后台用户管理面板，自带一个「IP Lookup」按钮，可以查看登录 IP 对应的国家、城市、运营商归属地，这个功能依赖 MaxMind GeoLite2 数据库。 开启方式分为两种：第一种是填写官网 License Key，程序自动每周在线下载数据库；第二种是下载开源镜像站的离线 .mmdb 文件，通过数据卷挂载到容器内部，不需要注册账号、不受官网协议下载限制。

我在 GitHub 镜像站下载了最新日期的 GeoLite2‑City.mmdb 和 GeoLite2‑ASN.mmdb 两个核心库文件，前者负责城市定位，后者查询运营商信息，GeoLite2‑Country.mmdb 精度不足，没有使用。 随后修改 volumes 挂载配置，在原有共享卷的基础上新增一条挂载规则：宿主机 maxmind 文件夹映射到容器程序的数据目录，离线数据库永久持久化，重建容器文件不会丢失。

5.2 必要性思考：非刚需，但锦上添花

配置完成之后我也仔细权衡过这个功能的价值：它并不是社区运行的必需品。就算不配置 IP 库，网站发帖、注册、登录、封禁功能完全不受任何影响，管理员依然可以看到原始公网 IP，手动复制到第三方网站查询归属地。 开启之后带来的增益，更多是管理层面的便利：一键查看恶意注册账号的地区、陌生登录地点告警、账号安全审计。对于我这个小规模个人社区来说，属于一个加分的可选配置，所以我选择离线挂载的方式，作为附加功能开启，而不是强制依赖在线密钥。

六、完整配置文件梳理：所有自定义项整合

整套部署全部基于官方原生 YAML 语法，没有自定义 Compose 字段，完全兼容 discourse_docker 的重建、升级脚本。配置文件分为几个清晰的模块：

1. 基础模板：PostgreSQL、Redis、Web 服务、限流、Cloudflare 官方 IP 白名单模板；
2. 环境变量：域名、邮件、系统语言等基础参数；
3. 持久化卷：网站资源备份目录、离线 IP 库挂载目录；
4. Run 执行脚本：自动安装 cloudflared、创建 runit 后台服务；
5. Nginx 强制覆盖配置：修复破折号 bug、信任隧道代理网段；

所有自定义逻辑全部追加在原有配置下方，不改动官方模板代码，后续升级官方部署仓库不会覆盖我的个性化配置。整个系统具备极强的可移植性：备份一份 app.yml 和宿主机 shared 文件夹，在任意一台新服务器，只需要安装 docker、git，执行重建命令，几分钟就能复原一套一模一样的 NodeByte 社区。

七、踩坑复盘：搭建过程里值得记录的细节

1. YAML 语法规范：discourse_docker 的解析器对格式极其敏感，缩进错误、多行命令写法错误，都会导致构建失败，exec 多条命令必须使用 bash 串联执行；
2. 字符隐形 bug：复制配置的时候，中文输入法、网页复制带来的特殊符号，会让 Nginx、配置文件静默失效，没有报错提示，排查难度极高；
3. 隧道模式区分：宿主机 systemd 客户端 和 容器内 runit 客户端不能共存，两套进程会争夺隧道连接，部署前必须清理另一种模式；
4. 代理信任网段：Cloudflare 官方模板只信任公网节点 IP，本地隧道回环地址必须手动添加信任，否则 real‑ip 不会生效；
5. 功能取舍：搭建服务器很容易陷入「功能堆砌」的误区，看到插件、增强工具就想全部装上，实际上一个稳定简洁的社区，核心功能才是第一位，IP 库这类附加功能按需开启即可。

八、后续规划：NodeByte.cn 的未来

现在打开 nodebyte.cn，一个干净现代、安全加固、部署完整的独立社区已经正式运行。从空白服务器，到域名、隧道、真实 IP、离线 IP 库全套配置落地，整个过程与其说是搭建一个网站，不如说是一次完整的运维实践。 未来我不会盲目堆砌插件和花哨功能，优先保证系统稳定、定期备份、维护数据安全。我会在这里记录技术笔记、分享折腾心得，邀请同好一起交流，把它真正打造成一个属于我自己、完全可控的线上自留地。 自建社区最大的意义，从来不是一个域名、一套程序，而是掌握属于自己的数据与话语权，在繁杂的互联网里，拥有一块完全自由、不受平台规则裹挟的数字空间。

结语

很多人觉得自建论坛是一件门槛很高的事情，但借助 Discourse 优秀的容器化设计，只要愿意一点点调试配置、排查报错，普通人也可以拥有一个独立社区。这次搭建经历，让我对反向代理、隧道网络、Nginx 真实 IP、容器持久化这些知识点，有了更加具象深刻的理解。 如果你也想拥有一个属于自己的小社区，不妨从一份简单的配置文件开始，一步一步踩坑、调试、完善，最终收获完全属于自己的站点。NodeByte 的故事，才刚刚开始。