极空间NAS自建Typecho博客：从云服务器迁移到Docker部署实践

1. 为什么我把博客从云服务器搬回了家里的极空间 NAS

前阵子我的云服务器又到期了，续费价格直接翻了一倍。这台服务器上只跑着一个 Typecho 博客，平时流量不大，但我每年要为一台几乎闲置的机器付几百块续费。想想觉得挺不值的，干脆做了一个决定：把博客迁回家里那台极空间 NAS 上。

先说结论：这个方案是完全可行的，而且如果你对博客的要求是"稳定、轻量、数据完全自己掌控"，那它甚至比云服务器更合适。

以前大家提到 NAS，第一反应都是存电影、备份照片、挂下载，很少人会把 NAS 当成一个正经的 Web 服务器来用。但现在的极空间内置 Docker 容器环境，可以跑 Web 服务，有稳定的存储和备份机制，还有手机 App 实时管理。这意味着你完全可以用它来跑博客、跑笔记系统、跑各种工具服务。

这篇内容我尽量写得完整一些，从为什么选 Typecho 而不是 WordPress，到镜像选择、容器配置、反向代理、数据备份、踩坑记录，一路讲下来。不是那种"照着抄就能跑通"的流水账，更多是把我自己在部署过程中的思考和取舍说清楚。

2. 选型逻辑：为什么偏偏是 Typecho 和 NAS 这个组合

2.1 Typecho 到底比 WordPress 好在哪

我最早用 WordPress，后来换到 Typecho，最直接的原因是：WordPress 在 NAS 这种小主机上跑不够轻量。

家里的极空间如果是一般型号，CPU 功耗和性能都有限。WordPress 每次请求都要加载一堆插件和主题资源，PHP 进程吃内存，数据库查询也没那么高效。即便装上缓存插件，体验也只能说"能跑"。而 Typecho 主打的就是轻量，整个程序压缩包才几百 KB，数据库用 SQLite 的话连 MySQL 都不用装，资源占用极低。

这里有个很直观的对比：

对比项	Typecho	WordPress
安装包体积	约 500KB	几十 MB
内存占用	通常 30-50MB 足够	建议 128MB 以上
数据库要求	SQLite / MySQL 均可	建议 MySQL
静态化能力	内置伪静态支持，自带缓存插件	依赖额外缓存插件
升级复杂度	覆盖文件即可，一分钟完成	需要处理主题、插件兼容

对于个人博客来说，Typecho 在功能上完全够用：Markdown 写作、分类、标签、评论、文章归档、RSS，该有的都有。你用 WordPress 写一篇技术文章也要几个小时，Typecho 一样能写，但系统本身在后台节省的资源是实实在在的。

2.2 本地部署和云服务器的实际差距

我没有彻底否定云服务器的意思，它当然有它的价值。公网 IP 稳定、带宽有保障、不用担心家里断电断网。但有一个核心问题是很多人没想明白的：博客的价值在于内容，而内容的数据量其实非常小。

一个写了五年技术的博客，就算是纯文本加少量图片，撑死也就几百 MB。这点数据放云服务器上，每个月为它付服务器租金，其实属于"高射炮打蚊子"。把数据放在自己的 NAS 上，你有完整的磁盘控制权，想怎么备份就怎么备份，想迁移到哪台设备就迁移到哪台设备。

另一个现实问题是备案。如果你用的是国内云服务器，域名要备案才能解析访问；而家庭宽带的 HTTP 服务如果只是自用或者小范围分享，一般不涉及备案环节。当然这里每家宽带运营商的上行带宽和公网 IP 策略不一样，后面我会专门讲怎么用反向代理和 DDNS 解决公网访问的问题。

2.3 极空间在同类 NAS 里的位置

群晖和威联通我也用过，它们最大的优势是生态成熟，套件中心里东西多；但代价是系统相对偏"企业向"，新手刚上手要理解存储池、共享文件夹、权限模型这一套概念，容易懵。极空间更偏家用，初始配置简单，App 端做得比传统 NAS 厂商好很多，Docker 界面也足够直观。对于只是想在家跑个博客、存点文件的人，极空间的上手成本低很多。

而且极空间的系统更新频率这几年一直在上升，Docker 相关的底层能力跟得也比较紧，我在用过程中没有遇到基础功能缺失的问题。

3. 部署前你需要想明白的四件事（不然后面必返工）

3.1 端口规划别随手填

这是新手必踩的坑之一。Docker 容器内部的端口是固定的，但映射到宿主机（也就是极空间 NAS）时，你可以指定任意未被占用的端口。

比如 Typecho 容器里 Nginx 监听 80 端口，你映射到极空间的 8088 端口，那浏览器访问地址就是http://你的NAS-IP:8088。

我建议从一开始就留出固定的一段端口给 Docker 应用，比如 8000-8100。不要把 80、443 直接映射给 Typecho，因为你后面可能还要跑其他 Web 应用，或者其他服务也需要 Web 端口。冲突了排查起来很麻烦，也影响已有服务稳定性。

3.2 存储目录映射：这是数据安全的命根子

容器是一个"用完即走"的临时环境。容器删了重建，如果内部数据没有持久化，那文章、配置、主题全部灰飞烟灭。所以必须把容器内的数据目录映射到 NAS 的存储空间。

Typecho 容器里，/app/usr这个目录存放了所有上传的附件、插件、主题和 SQLite 数据库文件。这句话要刻在脑子里：/app/usr就是 Typecho 的全部家当。

映射方式就是在创建容器时设置存储目录，比如把 NAS 上的~/docker/typecho/usr映射到容器内的/app/usr。这样哪怕容器被删除，数据都在 NAS 本地，重新建一个容器指到同一个目录，博客又回来了。

3.3 用 MySQL 还是 SQLite，别被网上教程带偏

很多人一上来就说"Typecho 要用 MySQL"，其实不是，取决于你的场景。

• 如果博客访问量不大（一天几百 IP 以内），用 SQLite 完全够，省去维护数据库的麻烦
• 如果数据量很大，或者你有未来接评论系统、加统计插件的打算，那 MySQL 更稳
• 极空间本身也可以用 Docker 再跑一个 MySQL 容器，但维护成本会上升

我这边用的是 SQLite，理由很简单：博客已经运行好几年了，日均访问量很小，SQLite 单文件数据库在几百 MB 数据内性能都够用，而且备份起来特别方便，直接把.db文件拷贝走就是一份完整备份。如果你打算用 MySQL，建议部署 MySQL 容器时把数据目录也映射出来，别让数据库数据存在容器内部。

3.4 域名和 HTTPS 的问题提前想好

很多人部署完发现：用 IP 访问好好的，但具体到浏览器里，Chrome 会提示"不安全"，因为 HTTP 没有证书。如果你只是 IP 访问，那无伤大雅。如果你要用自己的域名，而且要套 HTTPS 证书，就需要反向代理工具。

在极空间上，方案有两种：

• 用极空间自带的 Docker 跑一个 Nginx Proxy Manager（简称 NPM）容器做反向代理
• 直接用极空间系统自带的"远程访问"功能映射服务

NPM 我后面会重点讲，因为它还能帮你自动申请和续期 HTTPS 证书，完全是零成本搞定。

4. 在极空间上部署 Typecho 的两种主要方式对比

极空间部署 Docker 应用有两种路径：一个是图形界面的极空间 Docker 应用，另一个是 SSH 登录后用命令行操作。

4.1 方式一：Docker UI 操作（新手最友好）

极空间的 App / 网页端有"容器"功能入口，操作逻辑和 Portainer 这类图形化管理工具很像。流程是：

1. 在"镜像"页面搜索typecho，找到一个 Star 数较高、更新较新的镜像，比如80x86/typecho或bitnami/typecho
2. 点击"下载"拉取镜像
3. 在"容器"页面点击"新增"，选择已下载的镜像
4. 配置三个关键项：
   • 端口映射：容器端口 80 映射到宿主机 8088
   • 存储映射：容器/app/usr映射到 NAS 本地目录，比如/docker/typecho/usr
   • 环境变量：一般不需要额外设置，直接用默认值
5. 启动容器，浏览器访问http://NAS的IP:8088，进入 Typecho 安装界面

在图形界面上配置的好处是直观，每个选项都有提示，不容易漏掉。缺点是可选项少，如果你要对容器做更细粒度的参数调整，就得切到命令行模式。

4.2 方式二：SSH 命令行部署（可定制性更高）

极空间开放了 SSH，登录后可以直接用docker run命令创建容器。先写好参数，一次搞定：

docker run -d \ --name typecho \ --restart=always \ -p 8088:80 \ -v /volume1/docker/typecho/usr:/app/usr \ 80x86/typecho

说明一下各参数的含义：

• -d：后台运行容器
• --name typecho：给容器起名叫 typecho，方便后续管理
• --restart=always：容器异常退出或极空间重启后自动拉起，保证博客服务尽量在线
• -p 8088:80：把容器内 Nginx 的 80 端口映射到 NAS 的 8088 端口
• -v /volume1/docker/typecho/usr:/app/usr：持久化 Typecho 的数据目录

如果你的极空间存储卷名称不是volume1，需要先执行docker volume ls或查看极空间存储路径来确定实际名称。

从最终效果上看，两种方式部署出来的容器没什么差别，都属于"一个 PHP-FPM + 一个 Nginx"的镜像结构。我建议新手先用 UI 方式跑通，再用命令行管理进阶需求，不用一上来就跟命令行死磕。

5. 一步一步完整部署：从拉取镜像到发布第一篇文章

5.1 镜像选择：这几个镜像我都试过

Typecho 官方没有发布 Docker 镜像，社区里有很多人打包了，但质量参差不齐。我先后试过几个不同的镜像，最终留下的是80x86/typecho和bitnami/typecho。

bitnami/typecho的优点是打包规范，环境变量文档齐全，升级路径明确，适合想通过修改环境变量来改配置的人。但 image 体积偏大，启动稍慢。

80x86/typecho是我现在主力在用的，它是一个整合了 Nginx + PHP 的轻量镜像，启动速度快，占内存少。拉取命令：

docker pull 80x86/typecho

拉取完成后，确认一下镜像本地是否存在：

docker images

如果输出列表里有80x86/typecho，就说明拉取成功了。

5.2 创建容器并初始化 Typecho

如果你用 UI 方式，创建容器时注意以下参数：

配置项	值	说明
名称	typecho	自定义
镜像	80x86/typecho	必须已拉取
端口映射	80 -> 8088	根据自己的规划改宿主机端口
存储映射	本地目录 -> /app/usr	必须映射，否则数据丢失
重启策略	always	开机自动启动

启动容器后，浏览器访问：

http://你的极空间IP:8088/install.php

正常会进入 Typecho 的安装引导页面。如果你的端口没有被其他服务占用，这一步基本不会出问题。Typecho 安装界面会让你填站点名称、管理员账号密码、数据库配置。

站点名称可以先随便填，后面可以在后台改。管理员账号和密码要记牢，忘了就只能去数据库里改。

5.3 数据库配置环节怎么选型

如果你选择 SQLite，数据库适配器那一步直接选"SQLite"就行，数据库文件会自动生成到/app/usr对应目录下，也就是 NAS 上你映射出来的那个目录。这个模式下不需要填数据库地址、用户名密码，简单粗暴。

如果你选择 MySQL，需要先确保极空间上已经有一个可用的 MySQL 服务（可以是 Docker 容器），然后填：

• 数据库地址：MySQL 容器的 IP 或域名
• 端口：默认 3306
• 数据库名：比如 typecho
• 用户名密码：提前在 MySQL 里创建好库和账号

这一步有个常见的坑：如果你 MySQL 容器和 Typecho 容器都在自定义 bridge 网络中，那你填 MySQL 的地址时，要用容器名而不是localhost。用localhost会指向 Typecho 容器自身，必然连不上。

我推荐直接用 SQLite 跑起来，后面觉得数据量大了再迁移也不迟。

5.4 后台常用设置：伪静态和永久链接

Typecho 安装完成后，先把永久链接设置改一改，不然文章 URL 会带着一堆参数，既难看也不利于分享。

进入后台 -> "设置" -> "永久链接"，推荐这样选：

• 启用地址重写功能：是
• 自定义站点地址：如果你有域名就填域名，没有的话可以留空或填 IP+端口
• 文章路径格式：/archives/{cid}.html或者/post/{slug}.html，后者对 SEO 更友好

如果你选了"启用地址重写"，Typecho 会尝试生成.htaccess规则。但这只对 Apache 生效，而我们的镜像环境是 Nginx，所以需要手动在 Nginx 配置里加上伪静态规则。

如果你用的是 80x86/typecho 镜像，可以在容器内进入 Nginx 配置目录，找到站点配置文件：

docker exec -it typecho sh vi /etc/nginx/conf.d/default.conf

在server块内加入：

location / { index index.php index.html; if (-f $request_filename/index.html) { rewrite (.*) $1/index.html break; } if (-f $request_filename/index.php) { rewrite (.*) $1/index.php; } if (!-f $request_filename) { rewrite (.*) /index.php; } }

然后重载 Nginx：

docker exec typecho nginx -s reload

改完之后，打开一篇文章看看 URL 是否符合你的预期。如果发现是 404，大概率就是伪静态规则没对上，把规则替换成上面的再试一次。

5.5 上传限制调整：改完才能传大图

默认 PHP 配置对上传文件大小有严格限制，很多镜像默认是 2MB。你一旦想给文章插入一张大一点的截图，就会收到上传失败的提示。

修改方法：进入容器，找到php.ini，修改这几项：

upload_max_filesize = 20M post_max_size = 24M max_execution_time = 300

不同镜像里php.ini的位置不一样，一般在/usr/local/etc/php/目录下，不确定就先执行：

docker exec typecho php --ini

输出里会显示 Loaded Configuration File 的路径，按那个路径改就行。改完记得重启容器：

docker restart typecho

5.6 HTTPS 反代：把访问体验拉到现代水平

只靠 IP+端口访问，在手机浏览器上会一直提示不安全，长链接分享也不方便。最优雅的解决办法是：用一个域名，通过反向代理把流量转到 Typecho 容器上，同时自动加密。

我的方案是再加一个 Nginx Proxy Manager 容器：

docker run -d \ --name npm \ --restart=always \ -p 80:80 \ -p 443:443 \ -p 81:81 \ -v /volume1/docker/npm/data:/data \ -v /volume1/docker/npm/letsencrypt:/etc/letsencrypt \ jc21/nginx-proxy-manager

登录 NPM 管理页面（http://NAS-IP:81）后，添加一条 Proxy Host：

• 域名：填你已经解析到家里的域名
• 转发地址：填 Typecho 容器的地址和端口。如果 NPM 和 Typecho 在同一个 Docker 网络，可以直接填typecho:80；如果不在同一网络，填极空间的局域网 IP 加映射端口，比如192.168.1.100:8088
• 开启 WebSocket 支持（某些主题和插件会用到）
• 在 SSL 标签页选"Request a new SSL Certificate"，填入你的邮箱，开启 Force SSL

证书申请成功后，你的博客就变成了https://你的域名访问，浏览器地址栏带锁，数据全程加密。

6. 数据备份与容灾：把"创作握在自己手里"落实到实处

6.1 到底要备份哪些东西

回到标题那句"把创作握在自己手里"，它不能只是一句口号。内容数据的备份策略，直接决定了这句话是真是假。

Typecho 需要备份的核心数据有两块：

1. /app/usr目录下的 SQLite 数据库文件（或者 MySQL 数据库）
2. /app/usr目录下的uploads附件目录、主题目录和插件目录

如果用 SQLite，备份就是拷贝一个.db文件；如果用 MySQL，需要额外导出 SQL 文件。

极空间的存储空间本身有 RAID 或备份盘保护，但那只针对硬件故障，如果你误删了数据库文件，RAID 也救不了你。所以我强烈建议设置"应用级备份"，而不是只依赖 NAS 的硬件阵列。

6.2 极空间的备份任务如何设置

极空间的"备份中心"可以设置定时备份任务。我会把/docker/typecho/usr整个目录，定时备份到另一块存储空间或外接 USB 硬盘上，频率一般是每天一次。

配置步骤不复杂：

1. 打开极空间的"备份中心"
2. 新建备份任务
3. 源目录选择/docker/typecho/usr
4. 目标目录选择你自己的备份盘
5. 计划任务设置每天凌晨两点执行

另外再推荐一个方案：把 Typecho 的备份目录同步到对象存储上。极空间的很多机型支持挂载网盘或对象存储，可以额外做一份异地备份。考虑到博客数据量不大，一天增量同步一次毫无压力。

6.3 如何从备份恢复

真出了问题也别慌，恢复流程我实测过几遍，很简单：

1. 先把 Typecho 容器停止
2. 将备份的整个usr目录拷回原来的位置
3. 重新启动容器

容器启动后，Typecho 会自动读取目录里的数据库文件和配置，你的文章、主题、插件全部恢复原样。整个过程不到五分钟。

我之前做实验时，故意把数据库文件删了，再从备份恢复，实测没有任何数据丢失。

7. 我把 Typecho 装到极空间后，五个坑和四个性能建议

7.1 坑一：端口映射后，8088 端口在局域网能访问，公网却访问不了

这是最典型的问题。容器映射好了，局域网内用 IP 加端口访问一切正常，但离开家用自己的手机流量访问，死活打不开。

排查思路：

• 检查你的极空间有没有开启"外网访问"或 DDNS 功能
• 检查路由器的端口转发是否把公网端口转发到了极空间的 8088 端口
• 确认运营商是否分配了公网 IP

大多数情况下，问题出在"没有公网 IP"这一层。解决办法是：申请开通公网 IP（部分运营商支持），或者配置 IPv6，又或者用极空间的异地组网功能。如果你是一个人记录生活，不追求公网访问，那局域网访问其实完全够了。

这里我多说一句：如果你决定申请公网 IP，一定记得把路由器默认的远程管理端口关掉，只转发你需要的端口，避免被网上扫描器无差别扫到。

7.2 坑二：容器重启后 Typecho 白屏或数据库损坏

白屏通常由两种原因导致：

• PHP 版本和你用的主题不兼容
• SQLite 数据库文件在容器非正常停止时损坏

我在测试时遇到过几次类似情况。最直接的解决方式是进入容器，查看 PHP 错误日志：

docker logs typecho --tail 100

如果日志里输出 SQLite 相关的错误，说明数据库文件异常。极空间存储层面一般不会出问题，多数是容器断电或强制停止导致。处理方法是恢复备份，或者尝试用 SQLite 工具修复数据库文件。

为了避免这种问题，日常做好两件事：一是容器设置--restart=always，保证异常退出后能自动拉起；二是定时备份数据库。

7.3 坑三：主题和插件装到一半，后台直接打不开

这种情况多发生在插件不兼容或主题代码本身有语法错误时。Typecho 后台通常会启用某个插件/主题后，前端页面直接 500 或白屏。

解决办法也不难：如果你用一个框架主题，启用前先确认它宣称支持的 Typecho 版本。如果已经打不开后台了，可以 SSH 进容器，手动将/app/usr/plugins/刚才安装的插件目录名改名，让 Typecho 检测不到插件，后台就能恢复。

我在测试一些老的插件时踩过这坑，轻则功能异常，重则整个后台白屏。后来我的经验是：新插件先在一个测试环境跑通，再上生产博客；生产环境只装活跃维护的插件。

7.4 坑四：SQLite 数据库文件被锁，导致后台操作超时

如果你用 SQLite，并且同时多个请求插入数据，偶尔会遇到database is locked的报错。Typecho 后台操作频繁时，这个问题会更明显。

解决思路有几个：

• 减少不必要的并发写入，比如关掉不必要的统计类插件
• 如果访问量确实上来了，可以迁移到 MySQL
• 保证容器所在磁盘有足够的可用空间，磁盘满了 SQLite 极其容易出问题

对于个人博客，SQLite 其实是够用的。等到你发现读写频繁、数据库锁的情况频繁出现时，说明你的博客量级该上 MySQL 了。

7.5 性能建议一：开启 PHP OPcache

PHP 是解释型语言，每次请求都要重新解析代码，开启字节码缓存能明显减少 CPU 占用。

在php.ini里启用：

opcache.enable=1 opcache.memory_consumption=64 opcache.max_accelerated_files=10000 opcache.revalidate_freq=60

修改后重启容器。开启后，同样的配置下，响应时间能缩短一半以上，对于低功耗 NAS 来说体感明显。

7.6 性能建议二：国内访问图片走图床或对象存储

NAS 的上行带宽一般不如云服务器，尤其是多篇文章里放了一堆大图时，外部访问体验会受到影响。我的做法是：文章里的大图统一走对象存储，NAS 本地只存代码和数据库，附件和图片都上传到对象存储。

Typecho 支持自定义附件 URL 前缀，在那个配置项里填上对象存储的访问域名，上传附件时会自动重写 URL。这样既减轻了 NAS 出口带宽压力，也保证访问速度。

7.7 性能建议三：定时清理 nginx 日志

Docker 容器跑久了，/var/log/nginx下的日志文件会越来越庞大，磁盘占用变大。听起来不是大事，但极空间的系统盘有限，日积月累也可能造成问题。

我用 cron 定期清理日志，或者直接启动logrotate。容器内执行：

echo "0 3 * * * find /var/log/nginx -name '*.log' -mtime +7 -delete" | crontab -

7.8 性能建议四：容器镜像尽量选轻量版

如果你不止跑一个 Typecho，还打算在极空间上跑其他服务，镜像体积和运行资源最好控制一下。同样一个服务，用 Alpine 版本镜像会比完整版少几百 MB，内存占用也更小。

我有个习惯：部署每个容器前先看一眼镜像的下载量、最后更新时间、镜像描述，尽量选基于 Alpine 或者 slim 版本的。比如 Nginx Proxy Manager 就直接用官方镜像，Typecho 用 80x86 这个轻量的，资源占用加起来都很小。

8. 后续优化：从"能访问"到"更好用"

8.1 换一个清爽的主题

Typecho 默认主题能用，但外观确实比较朴素。我在极空间上用过的主题里，印象比较深的是 JO 和 handsome。JO 轻量且适合文字类博客，handsome 功能比较丰富但配置项也更多。

主题选择上我最看重的三点：移动端适配、中文字体显示、页面加载速度。NAS 上跑服务本来就比云服务器依赖带宽，如果主题加载一堆大体积 JS/CSS，访问体验会很差，所以尽量优先考虑纯净类的主题。

8.2 写文章的体验优化

Typecho 默认编辑器是 Markdown 语法，对老用户来说够用。但你在手机上管理后台，默认界面在窄屏上体验一般。我个人习惯是：后台只用来发布和修改文章，写作还是在本地 Markdown 编辑器里完成，然后粘贴进去。

如果你装了第三方 Markdown 编辑器插件，使用体验会接近 Typora，实时预览、快捷键支持都更好。唯一要注意的是插件要定期更新，长时间无人维护的插件，在 PHP 版本升高后容易出现兼容性问题。

8.3 监控博客是否正常

不再依赖云服务器的监控服务之后，我自己写了个简单的检测脚本，每五分钟请求一次博客首页，如果状态码不是 200，就往极空间的 App 推送通知。极空间自带通知系统，脚本很容易集成。

这不是必需的，但建议有。因为家庭环境不像云服务商那样有完善的 SLA 保障，一旦路由器重启、NAS 升级、断电，你的博客可能不知不觉就掉线了，等你发现已经过了几个小时。有个自动检测机制，能及早发现问题。

9. 写在最后的几点经验

把 Typecho 搬到极空间这段时间，最大的体会是：做这件事的门槛远没有想象中高，但值得认真对待的细节比想象中多。

我个人的经验是，如果你决定尝试，先用最低成本方案跑起来：拉镜像、映射端口、用 SQLite、IP 访问、写好第一篇文章。这个流程走通之后，再一步步加上反代、域名、HTTPS、备份、性能优化。不要一开始就规划得过于完美，反而容易卡在某一步上迟迟动不了手。

目前这套博客方案在我的极空间上已经连续运行了一百多天，没有手动重启过，期间只有断电时由restart: always策略自动拉起。日常访问的响应速度和之前云服务器差不多，但数据都在自己手里，想怎么备份、怎么折腾都不受限制，这种感觉是租一台云服务器给不了的。