用海外云服务器搭建 Wiki.js 团队知识库完整教程：自建 Wiki + 全文检索 + 权限管理（2026最新版）

Meta Description: 手把手教你用海外云服务器搭建 Wiki.js 团队知识库：从选配置、用 Docker Compose 一键拉起 PostgreSQL + Wiki.js，到 Nginx 反向代理、Let's Encrypt 免费 HTTPS、中文界面、PostgreSQL 全文检索与权限加固，附服务器配置价格对照表和 12 条常见问题 FAQ。

> 关键词：Wiki.js 部署、自建 Wiki、团队知识库、海外云服务器搭建、Docker 搭建 Wiki、Wiki.js 教程、自建知识库、PostgreSQL、Nginx 反向代理、阿里云国际版

前言

如果你管理过任何一个三人以上的小团队，一定经历过这样的场面：产品需求散在几十个微信群里，服务器密码躺在某人的备忘录里，新同事入职第一周要翻三个月聊天记录才搞明白"这个服务到底怎么重启"。大家嘴上都说"我们有文档"，实际上文档在三个人的电脑上、五个网盘里、以及某个人离职后永远打不开的账号中。

大厂用 Confluence、Notion、语雀解决这个问题，但它们的共同点是：按人头每月收费，而且数据存在别人公司的服务器上。一个 20 人的团队，Confluence 云版一年要烧掉几千美元；更麻烦的是，一旦把内部方案、客户信息、密钥说明放上去，就等于把公司知识资产托管给了第三方。

于是越来越多团队选择自建一个 Wiki：部署在自己买的海外云服务器上，数据完全归自己，一次性几美元的月租就能跑起来，还能顺带练一遍 Nginx、Docker、SSL 证书这些运维基本功。

本篇要装的 Wiki.js 是目前自建知识库里最"刚刚好"的选择：界面现代、Markdown 友好、原生支持中文、内置权限与全文检索、官方提供一条命令就能跑的 Docker 镜像。它不像 MediaWiki 那样老旧笨重，也不像 Confluence 那样强制绑定商业授权，非常适合中小团队自建"内部手册 + 技术文档 + 新人培训库"。

读完这篇教程，你会得到一套可以直接复制执行、从零到"域名能打开知识库"的完整步骤，包括：服务器选型与价格、Docker Compose 部署、管理员初始化、中文界面、Nginx 反代、Let's Encrypt 证书，以及关于安全、备份、升级的实战建议。全文命令均可直接粘贴执行，遇到报错可以对照最后的 FAQ 排查。

> 💡 部署建议：本站所有搭建教程都建议使用海外云服务器（阿里云国际版 / AWS / 腾讯云国际版），选择支持 Docker 的 Ubuntu 22.04 或 24.04 系统镜像即可。通过 5.chengzicloud.cloud 购买可享专属折扣，支持支付宝与信用卡付款，免实名、开箱即用。

一、先划边界：Wiki.js 管的是"知识层"，不是网盘也不是文档扫描

自建服务最怕"装了一堆，功能互相打架"。Wiki.js 解决的是一个非常明确的场景——把知识结构化地沉淀下来，并且让正确的人能读到、让有权限的人能改。它和本站已经写过的几个自建方案是互补关系，不是替代关系。先看这张边界表，搞清楚你该装哪个、或者该同时装哪几个：

| 方案 | 它真正回答的问题 | 前提条件 | 在本站内链 | |---|---|---|---| | Wiki.js（本篇） | 团队知识怎么结构化沉淀、可链接、可搜索、可授权 | 有一台 VPS + 一个独立子域名 + 会维护一个数据库 | 本篇 | | Paperless-ngx | 一堆扫描件/PDF 里的字怎么搜出来 | 有一批要归档的纸质/电子文档 | 文档管理篇 | | ONLYOFFICE Docs | docx/xlsx/pptx 怎么在线实时协同编辑 | 大家要在线改 Office 文件 | 在线文档协作篇 | | Nextcloud | 文件怎么多端同步、像私有网盘一样用 | 要同步原始文件（照片、附件、工程文件） | 私有云盘篇 | | Gitea / GitLab | 代码怎么托管、怎么做 CI/CD | 团队要管代码仓库 | Git 服务篇 / GitLab 篇 | | Discourse / Rocket.Chat | 怎么讨论、怎么即时沟通 | 要一个社区或一个团队 IM | 论坛篇 / IM 篇 | | Meilisearch | 想给自己的数据加一个搜索内核 | 你要做的是搜索功能本身，不是文档站 | 搜索服务篇 | | Notion / Confluence 云版 | 开箱即用、不用运维 | 接受数据存在别人服务器上、接受按人头付费 | —— |

这张表的读法是：如果你要的是"文件本体的同步"，去装 Nextcloud；如果你要的是"扫描件能搜",去装 Paperless-ngx；如果你要的是"文档能协同编辑",去装 ONLYOFFICE。而如果你要的是"团队的知识能被写成一篇篇互相链接的文档，并且按人按组控制谁能看谁能改"——那才是 Wiki.js。

一个很常见的组合是：Wiki.js 当"入口与索引"，把关键文档与操作手册写在 Wiki 里；原始的大文件、安装包、设计稿放 Nextcloud 或对象存储；需要协同编辑的正式文档用 ONLYOFFICE。三者各司其职，互不越界。

具体到 Wiki.js 的能力清单，它至少提供这些你在选型时真正会用到的东西：

- Markdown 优先：所有页面默认用 Markdown 编写，也内置了可视化的富文本编辑器，不写 Markdown 的同事也能上手。 - 版本历史：每次编辑都留档，可以对比、可以回滚，谁改了什么一目了然。 - 细粒度权限：按用户、按用户组、按页面路径授权，可以做到"技术组能看运维手册，全员只能看新人指南"。 - 全文检索：接 PostgreSQL 的检索引擎，中文也能搜。 - 多语言界面：自带简体中文，界面不用汉化。 - 评论与分享：页面可以开放评论、可以生成分享链接。 - 开放集成：提供 GraphQL API，可以对接自动化脚本。 - 存储后端可外置：内容存在数据库里，同时可以再同步一份到 Git 仓库或对象存储做备份与版本留痕。

看到这里你应该已经明白：Wiki.js 的价值不在于"能写文档"，而在于"让一个团队的文档体系长期可维护"。下面进入正题。

二、动手前必须知道：Wiki.js 官方明确写着的三条"红线"

很多教程踩坑，都是因为没先读官方文档里那几句"我做不到"。Wiki.js 官方文档里有三条硬性约束，务必在买机器、解析域名之前就搞清楚，否则后面大概率返工：

红线一：必须使用独立域名或子域名，不能装在子目录里。

官方在「Requirements」页写得很直白：Wiki.js 需要一个专门的子域名（例如 wiki.example.com），你不能把它映射到一个子文件夹（比如 example.com/wiki）。这意味着它不像 WordPress 那样可以挂到已有的站点路径下——你必须准备好一个子域名，并在 Nginx 里为它单独配一个 server 块。规划域名时请提前想好。

红线二：Wiki.js 不自带数据库，数据库必须你先建好。

官方文档原文：Wiki.js 不会帮你创建数据库，数据库必须已经存在。它支持 PostgreSQL、MySQL、MariaDB、MS SQL Server 和 SQLite 五种引擎，但官方强烈推荐 PostgreSQL，因为它性能最好、功能最全、且面向未来兼容。用 Docker Compose 部署时，最省事的做法就是同时拉起一个 PostgreSQL 容器——本篇走的就是这条路。

红线三：MySQL/MariaDB/SQLite 能用，但"下个大版本将不再支持"。

官方在「Requirements」里加了一条非常重要的提示：MySQL、MariaDB、MS SQL Server 和 SQLite 这四种引擎，在 Wiki.js 的下一个主版本（3.x）中将不再被支持。此外官方明确写 SQLite 不推荐用于生产环境。所以结论很清楚：新部署一律选 PostgreSQL。如果你图省事用了 SQLite，未来升级 3.x 时要么迁移数据库，要么被迫重新搭建，得不偿失。

除了这三条红线，还有几个"提前知道能省一整晚"的点：

- 搜索功能依赖 PostgreSQL 的 pg_trgm 扩展。官方检索引擎「DB - PostgreSQL」要求数据库启用 pg_trgm 扩展，它是 postgresql-contrib 包的一部分，官方 PostgreSQL Docker 镜像已经内置了它；但扩展要按数据库逐个启用，本篇第六节会给启用命令。 - Node.js 22 或 24 是运行要求，但用 Docker 的话不用你操心——官方镜像里已经打包好了 Node.js 运行时，宿主机完全不需要装 Node。 - 反代存在时，SSL 由反代终止，不要交给 Wiki.js。官方配置文档明确说明：如果用 Nginx/Apache 做反向代理，HTTPS 终止应交给反代处理，不要让 Wiki.js 自己管证书。 - 硬件门槛其实很低：单核就能跑，但官方推荐 2 核以上以充分利用后台任务；Linux 系统至少 1GB 内存。进程本身常驻只占约 70MB，但页面渲染、索引等操作会有瞬时内存峰值。 - 磁盘建议至少预留 1GB 给 Wiki.js 本身，纯文字型 Wiki 通常只有几 MB，但一旦开始上传图片、视频、附件，就要按内容量另行规划。

把这几条记住，后面的部署就会非常顺。最后补一条关于操作系统的建议：官方镜像已经是全容器化的，宿主机只要能跑 Docker 即可，CentOS 7 的 glibc 2.17 不是障碍；但 CentOS 7 已于 2024 年停止维护（EOL），且需要手动补 Docker Compose v2 插件，所以新机器强烈建议直接用 Ubuntu 22.04 / 24.04 或 Debian 12。

三、服务器怎么选：配置与价格对照表

Wiki.js 是"轻算力、重数据库"型的应用——它对 CPU 不敏感，但对内存和磁盘 I/O 有一定要求（背后是 PostgreSQL）。因此选型原则是：内存优先，其次是磁盘。下面按团队规模给出三档推荐：

| 使用场景 | 建议配置 | 磁盘 | 说明 | |---|---|---|---| | 个人 / 2~5 人小团队，纯 Markdown 文档 | 1 vCPU / 1GB 内存 | 25GB SSD | 能跑，但建议加 1~2GB swap，升级/备份时更稳 | | 10~30 人团队，含图片与附件 | 2 vCPU / 2GB 内存 | 50~60GB SSD | 官方推荐配置，检索与后台任务流畅 | | 50 人以上，附件多、检索频繁 | 2~4 vCPU / 4GB 内存 | 80GB+ SSD | 数据库与 Wiki 可分容器/分机器部署 |

下面这张表是当日直读官方定价页整理的主流服务商价格参考（金额单位美元/月）：

| 服务商 / 套餐 | 内存 | vCPU | SSD | 月流量 | 月费 | |---|---|---|---|---|---| | DigitalOcean Droplet 基础档 | 1 GB | 1 | 25 GB | 1 TB | $6 | | DigitalOcean Droplet | 2 GB | 1 | 50 GB | 2 TB | $12 | | DigitalOcean Droplet | 2 GB | 2 | 60 GB | 3 TB | $18 | | DigitalOcean Droplet | 4 GB | 2 | 80 GB | 4 TB | $24 | | DigitalOcean Droplet | 8 GB | 4 | 160 GB | 5 TB | $48 | | AWS Lightsail | 1 GB | 2 | 40 GB | 2 TB | $7 | | AWS Lightsail | 2 GB | 2 | 60 GB | 3 TB | $12 | | AWS Lightsail | 4 GB | 2 | 80 GB | 4 TB | $24 | | AWS Lightsail | 8 GB | 2 | 160 GB | 5 TB | $44 | | AWS Lightsail | 16 GB | 4 | 320 GB | 6 TB | $84 | | 阿里云国际版轻量/ECS | 1~2 GB | 1~2 | 40~60 GB | 视套餐 | 约 $5~$15 | | 腾讯云国际版 Lighthouse/CVM | 2 GB | 2 | 50~60 GB | 视套餐 | 约 $6~$18 |

> 声明：本文价格数据采集于 2026 年 10 月，仅为公开官网参考区间，实际以各服务商官网结算页为准；DigitalOcean 与 AWS Lightsail 的价格为当日直读官网定价页所得，阿里云国际版 / 腾讯云国际版因促销活动频繁，仅给出区间。金额单位均为美元（USD）。

选型一句话结论：个人或小团队直接上 2GB 内存档（DigitalOcean $12 / Lightsail $12），这是跑 Wiki.js + PostgreSQL 最舒服的性价比档位；如果预算极紧，1GB 档（$6~$7）也能跑，但一定要配 swap。

> 💡 省钱提示：海外云服务器的价格差异很大，同一档配置在不同渠道、不同活动下能差出一半。通过 5.chengzicloud.cloud 购买阿里云国际版 / AWS / 腾讯云国际版，可享专属折扣，新用户还有额外首购优惠。

四、开工前准备：域名解析 + 系统初始化 + 安装 Docker

第 0 步：先把域名解析做好

买好服务器后，先在你的域名服务商（或 Cloudflare）后台添加一条 A 记录，把这个子域名指向服务器公网 IP。例如：

`text 类型: A 名称: wiki 内容: 你的服务器公网IP `

解析生效后（通常几分钟到十分钟），用下面这条命令确认已经指向你的服务器。注意：如果你的域名托管在 Cloudflare 且开启了小云朵代理，请先临时关闭代理（切成 DNS only），否则后面签 Let's Encrypt 证书时会因为流量走 CDN 而校验失败。

`bash ping -c 2 wiki.example.com `

看到回显的 IP 就是你的服务器 IP，说明解析 OK。（把示例域名 wiki.example.com 换成你自己的子域名，下同。）

第 1 步：登录服务器并做基础初始化

用 SSH 登录你的服务器（Ubuntu 下是 root 用户）：

`bash ssh root@你的服务器IP `

然后更新系统并安装基础工具。以下命令在 Ubuntu 22.04 / 24.04 / Debian 12 上通用：

`bash apt update && apt upgrade -y apt install -y curl gnupg ca-certificates git ufw `

顺手把时区和防火墙配好。防火墙只开 SSH、HTTP、HTTPS 三个端口就够，Wiki.js 的 3000 端口不要对外开放——它只给本机的 Nginx 用：

`bash timedatectl set-timezone Asia/Shanghai ufw allow 22/tcp ufw allow 80/tcp ufw allow 443/tcp ufw --force enable `

第 2 步：安装 Docker 与 Docker Compose

Docker 官方提供了一键安装脚本，在 Ubuntu/Debian 上最省事：

`bash curl -fsSL https://get.docker.com | sh systemctl enable --now docker `

验证安装是否成功——只要看到 Docker 版本号和 Compose 版本号，就说明两个都装好了：

`bash docker --version docker compose version `

> CentOS 7 用户注意：CentOS 7 自带的 yum 源里 Docker 版本较老，且默认不带 Compose v2 插件。先按 Docker 官方文档添加 Docker CE 源再安装，装完务必手动确认 docker compose version 能返回版本号（没有的话单独补装 docker-compose-plugin）。如果没把握，建议直接重装成 Ubuntu 22.04。

五、用 Docker Compose 部署 Wiki.js + PostgreSQL（完整步骤）

接下来是核心步骤。我们用一个 docker-compose.yml 同时拉起两个容器：db（PostgreSQL 数据库）和 wiki（Wiki.js 本体）。官方文档给出的标准 Compose 结构就是我们下面这个模板的蓝本。

第 3 步：创建部署目录

把服务统一放在 /opt 下，便于管理：

`bash mkdir -p /opt/wikijs cd /opt/wikijs `

第 4 步：编写 docker-compose.yml

新建 /opt/wikijs/docker-compose.yml，内容如下。务必把两处 换成一个强密码 替换成你自己生成的强密码（两处必须一致，数据库和 Wiki.js 要用同一个密码连）：

`yaml services: db: image: postgres:15-alpine restart: unless-stopped environment: POSTGRES_DB: wiki POSTGRES_USER: wikijs POSTGRES_PASSWORD: 换成一个强密码 volumes: - db-data:/var/lib/postgresql/data logging: driver: none

wiki: image: ghcr.io/requarks/wiki:2 depends_on: - db init: true restart: unless-stopped environment: DB_TYPE: postgres DB_HOST: db DB_PORT: 5432 DB_USER: wikijs DB_PASS: 换成一个强密码 DB_NAME: wiki ports: - "127.0.0.1:3000:3000"

volumes: db-data: `

关于这份配置，有几个关键点值得解释，理解了才不会踩坑：

- 镜像标签用 :2 而不是 :latest。官方文档明确建议不要使用 latest 标签，而是固定到主版本号（这里即 2）。这样你后续 docker compose pull 时不会意外跨大版本升级导致数据库 schema 不兼容。 - DB_HOST: db 必须和上面 db 服务名一致。Compose 里同一网络下容器互相用服务名解析，官方文档特别强调：如果你给服务起了 container_name，这里就要填 container_name 的值。填错 = Wiki.js 连不上数据库。 - 端口映射写成 127.0.0.1:3000:3000。意思是对外只暴露到本机回环地址，公网访问不到 3000 端口，所有外部流量都必须经过 Nginx 反向代理。这是生产环境的标准做法——千万不要写成 3000:3000，那样等于把没有任何 HTTPS 保护的 Wiki 直接裸奔在公网上。 - logging: driver: none 给数据库关掉日志。PostgreSQL 容器默认日志量大，在 1GB 内存的小机器上容易把磁盘写满，关掉更省心（排障时再临时删掉这行）。 - 数据卷 db-data 是命根子。所有页面、用户、版本历史都在这里。它被 Docker 托管在 /var/lib/docker/volumes/ 下，不要手动删这个卷，备份也要针对它做（见第九节）。

第 5 步：启动并观察首次初始化

保存文件后，在 /opt/wikijs 目录下执行：

`bash cd /opt/wikijs docker compose up -d `

第一次启动会先拉取镜像（PostgreSQL 与 Wiki.js 两个镜像加起来几十 MB 到一百多 MB，视网络而定），然后启动数据库，等数据库就绪后再启动 Wiki.js。用下面的命令实时看日志，当你看到 Wiki.js 打印出类似 HTTP Server on port 3000 的信息，就说明启动成功了：

`bash docker compose logs -f wiki `

按 Ctrl + C 退出日志查看（注意：这只是退出查看，不会停掉容器）。

第 6 步：确认容器状态与数据库连通性

确认两个容器都处于 running（而非 restarting 或 exited）状态：

`bash docker compose ps `

再验证 Wiki.js 到数据库的连接是否正常。如果 Wiki.js 能启动并打印出监听端口，基本就说明数据库连接没问题（连不上时它会反复重启并在日志里报数据库连接错误）。这两步都通过后，Wiki.js 已经在 127.0.0.1:3000 上待命，接下来配 Nginx 让它能通过域名访问。

六、Nginx 反向代理 + Let's Encrypt 免费 HTTPS

Wiki.js 自己虽然内置了 Let's Encrypt 功能（设置 SSL_ACTIVE 等环境变量即可），但官方配置文档明确建议：当你在前面放了 Nginx 反向代理时，HTTPS 的终止应该交给反向代理处理，而不是让 Wiki.js 自己管证书。原因很简单——反代接管证书后，Wiki.js 可以专心当应用，证书续期、HTTP 跳转、访问日志都在一处管理，后续想加缓存、加限流也方便。

所以我们走"Nginx 反代 + certbot"这条更通用、更可控的路线。

第 7 步：安装 Nginx 并配置反向代理

安装 Nginx：

`bash apt install -y nginx systemctl enable --now nginx `

新建配置文件 /etc/nginx/sites-available/wikijs.conf，内容如下（把 wiki.example.com 换成你的子域名）：

`nginx server { listen 80; server_name wiki.example.com;

client_max_body_size 20m;

location / { proxy_pass http://127.0.0.1:3000; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; 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; } } `

这份配置里有两处是"不写就出问题"的关键：

- Upgrade 与 Connection "upgrade" 两个头必须传。Wiki.js 的编辑器与部分实时功能依赖 WebSocket，反代如果不透传 Upgrade 头，页面会出现"一直转圈""保存没反应"这类玄学故障。 - client_max_body_size 20m 要显式设置。Nginx 默认只允许 1MB 请求体，而 Wiki.js 默认单文件上传上限是 5MB（maxFileSize 默认 5242880 字节），附件稍大就会在前端返回 413，让人摸不着头脑。这里先放宽到 20MB。

启用站点并让 Nginx 重载配置：

`bash ln -s /etc/nginx/sites-available/wikijs.conf /etc/nginx/sites-enabled/ nginx -t systemctl reload nginx `

nginx -t 返回 syntax is ok 与 test is successful 才算配置正确。此时用浏览器访问 http://wiki.example.com，应该已经能看到 Wiki.js 的初始化界面了。

第 8 步：申请 Let's Encrypt 免费证书

安装 certbot 的 Nginx 插件：

`bash apt install -y certbot python3-certbot-nginx `

然后一条命令自动完成证书签发 + 自动改 Nginx 配置 + 配置自动续期：

`bash certbot --nginx -d wiki.example.com `

过程中会提示你填邮箱（用于证书到期提醒）并同意条款。执行完成后，certbot 会自动在你的 server 块里加上 443 监听和证书路径，并把 80 端口的请求重定向到 443。验证一下自动续期是否正常：

`bash certbot renew --dry-run `

看到 Congratulations 之类字样即表示续期演练通过。certbot 会自己装一个 systemd timer 定时续期，你基本不用再管它。

七、首次访问初始化：建管理员、切中文、开搜索

打开 https://wiki.example.com，你会看到 Wiki.js 的初始化向导——这是它第一次运行时的建站流程，只在第一次访问时出现。

第 9 步：创建管理员账号

向导第一步会让你填写管理员信息：

- Administrator Email：管理员登录邮箱，务必填一个你能长期收到的邮箱（后面忘记密码、发通知都要用它）。 - Password / Confirm：管理员密码，设置一个强密码。 - Site URL：站点对外访问地址，填 https://wiki.example.com。

点击 Install，几秒钟后即可用这个邮箱和密码登录后台。记牢这个邮箱——官方文档说明，密码是无法"找回"的，只能通过数据库手动覆盖（见 FAQ）。

第 10 步：切换中文界面并确认站点 URL

登录后进入左上角的 Administration（管理区），做三件必做的事：

1. 设置站点 URL：在 General（常规） 里确认 Site URL 已填成 https://wiki.example.com。官方网站文档特别指出：如果没设置 Site URL，会出现"无法从管理区升级"等问题。这一步很多人会漏。 2. 切换界面语言：在 Locale（本地化） 里把语言设为 简体中文（zh-CN），保存后界面即刻变成中文。 3. 配置时区：同样在常规设置里，把时区设为 Asia/Shanghai，这样页面编辑时间、版本历史时间才是正确的。

第 11 步：启用 PostgreSQL 全文检索

Wiki.js 的内容搜索需要一个搜索引擎模块。用 PostgreSQL 时，官方推荐启用「DB - PostgreSQL」引擎，但它依赖 pg_trgm 扩展。虽然官方 PostgreSQL 镜像已经内置了该扩展，但扩展需要按数据库逐个启用。执行这一条命令即可：

`bash docker compose exec db psql -U wikijs -d wiki -c "CREATE EXTENSION IF NOT EXISTS pg_trgm;" `

然后回到管理区，点击侧边栏的 Search Engine（搜索引擎），选择 DB - PostgreSQL，点击 Apply（应用），系统会自动创建索引。如果你在启用之前已经写过一些页面，记得再点一次 Rebuild Index（重建索引），把已有内容全部纳入搜索。之后再新增、修改、删除页面都会自动更新索引。

第 12 步：开启 HTTP 自动跳转 HTTPS

回到管理区的 SSL 项，开启 HTTP → HTTPS 重定向。这样即使用户输入的是 http:// 开头的地址，也会自动跳到 HTTPS，避免到默认协议下漏出明文。至此，你的知识库已经可以通过域名以 HTTPS 正常访问了。

八、安全加固：别把"知识库"变成"公开情报站"

Wiki.js 里往往放着公司最敏感的东西——服务器口令、业务流程、客户资料。公网可访问的自建服务是攻击的重灾区，下面这份清单请逐条过一遍：

1. 确认 3000 端口没有对外暴露。 回到服务器上执行 ss -tlnp | grep 3000，看它监听在 127.0.0.1:3000 还是 0.0.0.0:3000。如果你按本篇 Compose 写法用了 127.0.0.1:3000:3000，那它就是对的；如果显示 0.0.0.0，说明外部可以直连无 HTTPS 的裸端口，必须改回本机回环。

2. 关闭公开自助注册。 进入管理区的用户 / 认证（Authentication）设置，检查本地登录方式是否开放了自助注册。内部知识库的正确姿势是：关闭公开注册，只由管理员手动创建账号或邀请成员。多一个人能注册，就多一个被撞库的入口。

3. 给管理员账号开启两步验证（2FA）。 Wiki.js 的本地账号支持基于 TOTP 的双因子验证。管理员是最高权限账号，务必开启，并妥善保存恢复码。

4. 用防火墙兜住入口。 前面第 1 步我们已经用 ufw 只放了 22/80/443。建议再加一层 fail2ban，对 SSH 暴力破解做自动封禁：

`bash apt install -y fail2ban systemctl enable --now fail2ban `

5. 按"最小权限"授权。 Wiki.js 的权限是按用户组 + 页面路径控制的。建议至少分三层：全员组（只读公共手册）、技术组（可写技术文档）、管理员组（可管理与授权）。不要给所有人开放"编辑全站"——一次误删或恶意破坏，可能让你辛苦积累的文档一夜归零。

6. 定期更换数据库密码。 修改 /opt/wikijs/docker-compose.yml 里的两处密码后，需要同步修改数据库里用户的密码，再 docker compose down && docker compose up -d 重启整个栈。密码泄露时这是必做动作。

7. 别在 Wiki 里明文存真正的高危凭据。 知识库适合放"流程与说明"，真正的服务器密钥、数据库主密码建议放在专门的密管工具里（可参考本站 Vaultwarden 篇），Wiki 里只写"去哪儿取"。

九、备份、升级与日常维护

备份——只做一件事就够了：定期导出数据库。 官方文档写得很清楚：Wiki.js 的所有内容（页面、用户、版本历史）都存在数据库里。所以备份的核心就是备份 db 容器的 PostgreSQL 数据。一条命令导出 SQL 文件：

`bash mkdir -p /root/wikijs-backup docker compose exec db pg_dump -U wikijs wiki > /root/wikijs-backup/wiki-$(date +%F).sql `

建议把这条命令写进 crontab，每天凌晨自动执行一次，并把导出的 .sql 再同步一份到异地（比如对象存储）。恢复时，把一个空的 PostgreSQL 容器跑起来，再用 psql 把 .sql 导入即可；由于内容全在数据库，恢复后 Wiki.js 立即可用。

升级——先备份，再升级，且不可回退。 官方文档有三条硬提醒：

1. 升级前必须备份数据库。虽然升级通常安全，但万一出问题，回滚的唯一希望就是那份备份。 2. 一旦数据库 schema 被升级，就无法再回到旧版本。所以别在没备份的情况下赌一把。 3. 升级步骤很简单：先改 docker-compose.yml 里要升到的主版本号（本项目前仍是 2 系列内的次版本），然后：

`bash cd /opt/wikijs docker compose pull docker compose up -d `

> 补充：官方还提示，如果从管理区点击升级没反应，可能是升级伴随容器（wiki-update-companion）版本过旧，把它单独更新到最新即可。为省心，建议始终用命令行 docker compose pull && up -d 的方式升级。

日常巡检。 关注三件事：docker compose ps 看容器是否一直 running；df -h 看磁盘（数据库和附件会慢慢长大）；docker compose logs --tail=100 wiki 看有没有异常报错。有条件的，再按本站《服务器监控》篇接一个 Prometheus + Grafana，或按《Uptime Kuma》篇加一个"站点活着吗"的可用性告警。

十、常见问题 FAQ

Q1：CentOS 7 能装吗？ 可以。Wiki.js 官方镜像是全容器化的，宿主 CentOS 7 的 glibc 2.17 和 3.10 内核都不是障碍。但 CentOS 7 已 EOL、且需要手动补 Docker Compose v2 插件，新机器建议直接用 Ubuntu 22.04 / 24.04 或 Debian 12。

Q2：能装在 example.com/wiki 这样的子目录吗？ 不能。官方明确规定：Wiki.js 需要一个独立子域名，不能映射到子文件夹。请提前准备一个子域名（如 wiki.example.com），并在 Nginx 里单独配一个 server 块。

Q3：数据库一定要用 PostgreSQL 吗？MySQL 或 SQLite 行不行？ 能跑，但强烈不推荐。官方注明：MySQL、MariaDB、MS SQL Server、SQLite 在下一个主版本（3.x）中将不再被支持；且 SQLite 不推荐用于生产。新部署一律选 PostgreSQL。

Q4：忘记管理员密码了怎么找回？ 密码无法"读出来"，也无法通过邮件找回——它是 bcrypt 单向哈希。唯一办法是用数据库手动覆盖。先用一个 bcrypt 生成工具（轮数必须设为 12）生成新密码的哈希，再执行：

`bash docker compose exec db psql -U wikijs -d wiki -c "UPDATE users SET password = '把这里换成bcrypt哈希' WHERE email = '你的邮箱';" `

Q5：上传附件报 413 / 保存失败？ 两个上限都要检查：一是 Nginx 的 client_max_body_size（本篇已设 20MB，默认只有 1MB）；二是 Wiki.js 自己的 uploads.maxFileSize，默认是 5MB、单次最多 10 个文件。要传更大的附件，两边都要放宽。

Q6：页面一直转圈、点保存没反应？ 九成是反代没透传 WebSocket 头。检查 Nginx 配置里是否带了 proxy_set_header Upgrade $http_upgrade; 和 proxy_set_header Connection "upgrade"; 这两行。

Q7：搜索搜不出内容？ 先确认 pg_trgm 扩展已启用（CREATE EXTENSION IF NOT EXISTS pg_trgm;），再确认管理区里搜索引擎选了「DB - PostgreSQL」并点了 Apply。如果启用前已有页面，必须再点一次 Rebuild Index 重建索引。

Q8：2 核 1G 的小机器能跑吗？ 能。官方说单核即可运行，但推荐 2 核、Linux 至少 1GB 内存。1GB 档建议加 2GB swap 防止升级/备份时内存吃紧。纯文字 Wiki 常驻占用很低。

Q9：内容存在哪？到底要备份哪些？ 所有内容都在数据库里。 备份的核心就是定时 pg_dump 导出，再同步到异地。数据库数据卷 db-data 是命根子，不要手删。

Q10：附件能外置到对象存储吗？ 可以。Wiki.js 有"存储模块"，支持 AWS S3、Azure Blob、DigitalOcean Spaces、SFTP、Git 和本地文件系统等。但要注意：内容始终首先存在数据库里，这些模块是用于备份和同步的补充，不是把主存储挪走。其中 Git 模块支持双向同步，很适合把 Wiki 内容版本化留痕。

Q11：怎么升级到新版本？ 先备份数据库，再 docker compose pull && docker compose up -d。注意：数据库 schema 一旦升级就无法回退到旧版本，所以升级前的那份备份是唯一的后悔药。

Q12：想跑多个实例做高可用怎么办？ Wiki.js 支持高可用（ha: true），但该功能要求必须使用 PostgreSQL，其它数据库引擎都不行。而且必须先用单实例完成初始化，初始化完成后再增加实例数量。

Q13：支持中文吗？需要汉化吗？ 官方自带简体中文界面，无需任何汉化插件。在管理区的本地化设置里把语言切到 zh-CN 即可，页面内容本身用中文编写没有任何限制。

Q14：数据库端口要对外开放吗？ 不要。 数据库容器和 Wiki.js 在同一 Docker 网络内互相用服务名通信，根本不需要把 5432 暴露到公网。本篇的 Compose 里 PostgreSQL 完全没有端口映射，这正是最佳实践。

结语

到这一步，你的团队已经拥有一个完全属于自己的知识库：公网可访问、HTTPS 加密、中文界面、有全文检索、有权限控制、有版本历史，而且每个月的成本只是一台入门级云服务器的钱。

把全文的关键决策再压缩成 5 句话，方便你回顾：

1. 选 PostgreSQL，不用 SQLite。 这是官方对"未来能不能顺利升级"给出的最明确态度。 2. 必须独立子域名。 Wiki.js 不能装子目录，规划时先想好域名。 3. 端口只绑本机回环。 3000 端口交给 Nginx，别裸奔公网。 4. 反代必须传 WebSocket 头。 否则页面转圈、保存失效。 5. 备份只备份数据库。 所有内容都在库里，定时 pg_dump 再异地存一份。

自建知识库最大的坑其实不在技术，而在"没人维护"。建议你上线后立刻做两件事：一是把它设成团队新人的入职培训入口，二是约定一个"文档更新日"，让知识库真正活起来——一个没人更新的 Wiki，和没有 Wiki 没有区别。

如果你还没有服务器，或想换一台更合适的机器来跑 Docker，可以看看下面这些延伸内容。

延伸阅读：

- 用海外云服务器搭建 Paperless-ngx 文档管理系统（OCR 全文检索） - 自建 ONLYOFFICE Docs 在线文档协作（在线 Office 套件） - 用海外云服务器搭建 Nextcloud 私有云盘（多端同步） - 自建 Meilisearch 搜索服务（给自有数据加搜索内核） - 海外云服务器搭建 Server 监控：Prometheus + Grafana 完整教程 - 服务器备份与灾难恢复实战：快照、异地、演练

> 本文由 5.chengzicloud.cloud 提供，点击访问首页了解更多海外云服务器部署方案和专属优惠。