极空间NAS上使用Docker部署Typecho博客完整指南

如果你手上正好放着一台极空间 NAS，最近又在刷各种“本地部署”的教程，那么这篇 Typecho 部署攻略应该正对你的胃口。Typecho 是一个轻量级的 PHP 博客程序，和 WordPress 相比，它更像一把瑞士军刀——体积小、响应快、折腾门槛低；而极空间 NAS 则给这个博客提供了一个非常理想的落脚点：硬件归自己、数据归自己、域名和篇目也全都归自己。文章会从选型逻辑讲起，一直走到极空间 Docker 界面里的实际部署、安装初始化、伪静态、备份，以及常见问题排查，全程按真实操作习惯来写，不需要你有多深的服务器背景。

这两年大家都在聊本地部署大模型、本地部署各种服务，底层其实都是同一个逻辑：自己的数据、自己的服务、要可控、要不被人拿捏。把博客部署在自己的 NAS 上，本质上也是一样的选择。Typecho 不挑配置、不挑环境，一个容器就能跑起来，正好适合极空间这种“家里放一台、随时能折腾”的私有化设备。下面直接进入正题。

1. 为什么是“极空间 NAS + Typecho”这套组合

1.1 先聊聊为什么不是 WordPress 和 Halo

很多朋友一上来就问：为什么不用 WordPress？不是不好，而是用错地方了。WordPress 生态丰富，插件主题一大堆，但代价是资源占用高、更新频繁、动不动就要处理数据库表前缀和缓存插件之间的兼容问题。放在一台家用 NAS 上，WordPress 有点“杀鸡用牛刀”，而且长期跑下来，风扇转速、磁盘 IO、内存占用都会让你觉得这台 NAS 到底是用来存照片的还是用来跑博客的。

Halo 是另一个热门选择，Java 生态，功能确实强大，但启动内存动不动就上 GB 级别，容器镜像体积也更重。极空间 NAS 本身还有相册备份、影视刮削、下载任务这些日常活儿要干，要是博客服务把资源都吃光了，其他服务就会跟着卡。

Typecho 的优势就在于“刚刚好”。它官方介绍就是“轻量且强大的开源博客程序”，PHP 生态，单进程就能跑，SQLite 模式下连独立数据库都不用装。对个人博客来说，访问量通常在每天几百到几千 PV 这个量级，Typecho 哪怕跑在容器里也毫无压力。它的后台干净、写作体验流畅，主题系统虽然不像 WordPress 那么庞大，但精品主题足够你换风格。如果你追求的只是踏踏实实写文章、记录技术踩坑、存一些学习笔记，Typecho 这套组合能让你把精力放在内容上，而不是花在“伺候系统”上。

1.2 三种部署路径怎么选

在极空间 NAS 上部署 Typecho，实际操作中主要有三条路：

我最推荐的是前两种。第一种适合绝大多数人：数据落在 SQLite 文件里，备份就是一个文件的事，容器没了也不怕，文件还在。第二种适合你预期博客会长期写、以后可能挂一些统计插件或动态功能，用 MariaDB 更稳当，查询速度在数据量大时也更有优势。第三种看着很专业，但对家用场景来说属于过度设计，除非你特别想练手，否则没必要在 NAS 上把 Nginx、PHP-FPM、数据库拆成三四个容器维护。

本篇攻略会把第一种和第二种都讲透。你先按第一种跑通，之后再决定要不要迁到数据库模式——Typecho 后台自带的数据库切换功能可以帮你做迁移，步骤不复杂。

2. 部署前准备：镜像选型和目录规划

2.1 Docker 镜像怎么挑

在极空间的 Docker 界面里，搜索 typecho 会看到不少结果。社区里比较常用的是 80x86/typecho，这个镜像把 Apache、PHP 和 Typecho 本身都打在一起了，拉下来创建容器就能直接进安装向导，省去了自己配 PHP 环境的麻烦。还有基于 Alpine 的变体，体积更小，但在极空间上跑起来差异不大，挑一个 star 高、更新日期近的就行。

如果说得更讲究一点，你也可以用官方 PHP 镜像自己装 Typecho，但这对初学者太不友好，而且后续极空间系统升级、容器重建的时候，自己拼出来的环境容易出兼容问题。集成镜像的优势是门槛低、复现快，哪怕哪一天容器坏了，删掉重新创建一个，挂载同一个数据目录，博客就回来了。

这里有一个关键点：镜像可以随便换，数据目录必须挂稳。Typecho 的所有文章、配置、上传文件都存在站点目录里，只要你把站点目录映射到 NAS 的本机存储上，镜像本身就算是“一次性用品”，坏了拉新的就行。这个思路一定要建立起来，后面备份和迁移都靠它。

2.2 存储目录和端口怎么规划

打开极空间的文件管理，建议在 Docker 目录下单独建一个 typecho 文件夹，路径类似 /vol1/1000/docker/typecho，里面再分一个 data 子目录给站点文件用。如果后续要上数据库，再建一个 mysql 子目录。极空间的文件管理器可以直接创建文件夹，右键属性里能看到完整路径，待会儿创建容器时填路径就用得上。

端口规划也别随手乱填。极空间本身的网页管理界面默认走 5055 还是其他端口，取决于你的系统版本，但为了避免冲突，Typecho 容器建议用 9000 这类不常用的端口来映射。比如容器内部端口是 80，外部映射成 9000，访问时就用 http://NAS的IP:9000。如果你以后想用反代或者绑定域名，外部端口可以再调整，但先把习惯养成：专用服务尽量用专用端口，别挤在 80、443 上，和极空间自带服务抢位置容易出莫名其妙的问题。

另外，极空间的 Docker 界面创建容器时通常会让你填存储空间和内存限制。Typecho 很轻，内存给 512MB 就足够了；存储空间按你自己需求给，一般默认不限制也行。别给太小，PHP 处理页面时偶尔会吃点峰值内存，512MB 是非常安全的线。

3. 极空间 NAS 上部署 Typecho 的完整实操

3.1 在极空间 Docker 界面拉取镜像并创建容器

极空间系统里的 Docker 应用在“应用中心”里可以安装，打开后是一个图形化的容器管理界面。第一步是进入“镜像”页面，搜索 80x86/typecho，点拉取，选一个 tag，一般选 latest 就行。等待拉取完成后，在“容器”页面点新建容器，选择刚才拉好的镜像。

创建容器时有几个必填项需要认真看：

• 容器名称：随便填一个，比如 typecho-blog。
• 端口映射：把本地端口填 9000，容器端口填 80，协议 TCP。
• 存储空间：添加一个卷映射，把 NAS 上的 /vol1/1000/docker/typecho/data 对应到容器内的 /app。这一步非常重要，Typecho 的站点文件会写在容器内的 /app 目录，如果不映射，容器一删数据就全没了。
• 环境变量：很多集成镜像不需要额外环境变量，保持默认即可。如果你用的镜像说明文档里有特殊要求，比如时区设置 TZ=Asia/Shanghai，就在环境变量里加上。

填完这些，点创建，容器就会启动。回到容器列表，确认状态是“运行中”，然后在浏览器里打开 http://NAS的IP:9000。如果一切正常，你会看到 Typecho 的安装欢迎页。

3.2 跑通安装向导：从 install.php 到后台

打开安装页后，Typecho 会引导你填写数据库配置和站点信息。如果走 SQLite 路线，数据库驱动选择 SQLite 即可，数据库文件会直接生成在站点目录的 /usr/... 或 /app/usr 目录下。如果走 MariaDB 路线，数据库驱动要选 MySQL 原生驱动，数据库地址要填数据库容器的服务名或局域网 IP，不是填 localhost。

站点名称、用户名、密码、邮箱这些正常填。有一个容易忽略的地方是“密码”的强度，Typecho 后台默认密码太短容易被暴力扫描，建议直接生成一串 16 位以上的随机密码，然后存到密码管理器里。安装完成后，系统会提示你删除 install.php。集成镜像通常会把这个文件放在 /app/install.php，你可以通过极空间的文件管理直接删除，也可以进容器执行命令删，但图形界面操作最简单。

到这里，博客就已经能访问了。默认的站点标题、默认主题都是 Typecho 开箱即用的状态，你可以在后台“控制台-外观”里换主题，“控制台-插件”里装插件，“撰写-写文章”里开始发第一篇内容。整个过程从拉镜像到写第一篇文章，顺利的话十分钟以内可以搞定。

3.3 更省心的改法：用 Docker Compose 一步部署

如果你不想在图形界面上一个个点，或者以后想方便地重来，极空间 Docker 界面也支持项目文件（Compose）。用 Compose 的好处是：整个部署过程变成一段文本，以后换设备、换 NAS、排障重建，复制粘贴就能拉起一整套。

SQLite 极简方案的 Compose 文件长这样：

yaml复制services:
  typecho:
    image: 80x86/typecho:latest
    container_name: typecho-blog
    ports:
      - "9000:80"
    volumes:
      - /vol1/1000/docker/typecho/data:/app
    environment:
      - TZ=Asia/Shanghai
    restart: unless-stopped

MariaDB 方案则多一个数据库容器：

yaml复制services:
  db:
    image: mariadb:10.11
    container_name: typecho-db
    environment:
      - MYSQL_ROOT_PASSWORD=换一个复杂密码
      - MYSQL_DATABASE=typecho
      - MYSQL_USER=typecho
      - MYSQL_PASSWORD=再换一个复杂密码
    volumes:
      - /vol1/1000/docker/typecho/mysql:/var/lib/mysql
    restart: unless-stopped

  typecho:
    image: 80x86/typecho:latest
    container_name: typecho-blog
    ports:
      - "9000:80"
    volumes:
      - /vol1/1000/docker/typecho/data:/app
    environment:
      - TZ=Asia/Shanghai
    depends_on:
      - db
    restart: unless-stopped

用 Compose 部署时，数据库地址填 db 而不是 IP，容器之间通过 Docker 网络通信。这个方案最大的好处就是“可重复”——你甚至可以把它保存成一个笔记，哪天极空间系统崩溃重装了，重新弄好 Docker，粘贴文件再跑一遍，博客就原地复活。我个人强烈建议至少把 Compose 文件存一份，就算你第一次是通过界面创建的容器，也可以把这段文本留在笔记里当作“灾备记录”。

4. 让博客更好用：固定链接、备份与外网访问

4.1 固定链接和伪静态规则

Typecho 默认的博客地址是 /?p=123 这种形式，虽然能用，但不美观也不利于搜索。进入后台，在“控制台-设置-永久链接”里可以把地址形式改为 美化的地址，比如 /archives/123.html 或自定义格式 /post/{cid}.html。但问题的关键不在后台，而在 Web 服务器支不支持伪静态。

如果你用的是 80x86/typecho 这种 Apache 集成镜像，那么 mod_rewrite 一般是默认开启的。打开固定链接后，Apache 会自动处理路径重写，你只需要在 Typecho 后台选择想要的格式并保存即可。但如果你未来的方案里用了 Nginx 做反代或前置 Web 服务器，就需要手动加一段 rewrite 规则，否则文章页会 404。

Nginx 下的标准规则如下：

nginx复制location / {
    index index.php;
    if (!-e $request_filename) {
        rewrite ^(.*)$ /index.php$1 last;
    }
}

这段规则的意思很直白：如果访问的路径不是真实存在的文件或目录，就交给 /index.php 去处理。Typecho 的路由全靠 index.php 转发，所以没有这段规则，固定链接一定是打不开的。

4.2 备份别只靠“复制文件”

很多人在 NAS 上部署完服务就以为万事大吉了，但备份才是最容易被忽略的坑。SQLite 模式下，备份其实非常简单：把 /vol1/1000/docker/typecho/data/usr 目录整个拷出来，甚至整个 data 目录一起拷，保存到另一个硬盘或网盘，这就是完整备份。恢复的时候，把目录放回去，容器重新挂载一下，网站就回来了。

MariaDB 模式稍微麻烦一点。除了备份站点目录的 usr 文件夹，数据库也要备份。最稳的方式是进数据库容器执行 mysqldump：

bash复制docker exec typecho-db mysqldump -uroot -p typecho > typecho_backup.sql

如果你不想敲命令，也可以把极空间文件管理里的 /vol1/1000/docker/typecho/mysql 目录整个复制走。这样做属于“冷备份”，恢复时直接把目录放回原位再启动容器即可。日常备份频率建议至少每周一次，文章写得勤就每天一次。极空间自带的备份任务可以把指定文件夹同步到外部存储或云盘，去“备份”应用里设置一下，非常省心。

4.3 外网访问的安全取舍

博客搭好了，下一步自然是想在外面也能访问。这一块的安全取舍要特别注意，核心原则是：不要把你的 NAS 管理端口直接暴露到公网。

Typecho 容器本身可以通过端口映射提供服务，但如果你把极空间的管理页面、Docker 管理页面都映射到公网，风险就大了。家用 NAS 设备长期暴露公网，会被各种扫描器盯上。比较稳妥的做法是：

• 用极空间自带的远程访问功能或组网方案进行个人访问，适合自己看、自己维护。
• 如果一定要让博客成为公开站点，优先通过反向代理绑定域名并启用 HTTPS。反代可以装在另一台轻量服务器上，或者用群晖/极空间上的 Nginx 容器来做。这样公网只看到代理服务，不直接碰 NAS 上的其他端口。
• 开启 Typecho 后台强密码 + 二次验证插件。虽然 Typecho 本身没内置两步验证，但社区有相关插件，能极大降低后台被爆破的风险。

总结一句：能通过反代走 80/443 就别直接爆端口，能上 HTTPS 就别用明文 HTTP，能限制访问就加防火墙规则。对自己负责，也对读者负责。

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

5.1 一张表快速定位

5.2 两个容易踩的坑

第一个坑是容器内目录路径和宿主机路径搞混。极空间文件管理里看到的路径，和容器内看到的路径完全不是一个逻辑。创建容器时，你只能通过“存储空间”的映射关系把宿主机路径对应到容器路径，比如宿主机 /vol1/1000/docker/typecho/data 映射到 /app。装完 Typecho 后，不要到容器里瞎找“为什么没有网站文件”，因为它就在你映射出来的宿主机目录里，直接在极空间文件管理里就能看到。

第二个坑是 SQLite 数据库文件权限问题。SQLite 模式虽然方便，但数据库文件一旦属主变成容器内的用户，你在极空间文件管理里用普通账号可能看不到或改不动。遇到这种情况不用急着改权限，记住一个原则就好：容器运行期间，数据库文件归容器管；要备份时，任务计划或手动复制到另一个目录即可。别用文件管理器强行修改属主，改错了容器反而打不开数据库。

5.3 从部署到日常维护的心态建议

最后想分享一个技术之外的体会。很多人把“搭博客”理解成“搞定那一台服务器”，但真正决定博客能写多久的，是备份习惯和写作流程。Typecho 的部署只是起点，如果你开始写，一个月后回看会觉得，最值钱的是那些自己能随时导出的文章数据，而不是当初折腾的 Docker 容器。

我在实际部署中踩过一次印象很深的坑：当时贪方便，没有做目录映射，直接在容器内写文章，结果极空间系统升级容器被重建，文章全没了。那次之后我才养成了“数据一律走映射目录”的习惯。现在不管容器怎么折腾，只要 /data 目录还在，博客就在。把这个习惯也传递给你：容器可以随便换，数据必须挂出来。

这个小技巧也顺带分享：给 Typecho 的 usr/themes 和 usr/plugins 目录单独做个同步任务，这样就算你哪天想换主题、换插件，之前的配置和文件版本也有迹可循。折腾无止境，但数据安全永远要排在第一位。