零、开始前的准备#

一、这套方案解决什么问题#

先说需求：我有一台白群晖（存了几年照片和资料，是数据源），一台 unRAID 服务器（i5-12400 + 32G 内存 + 16T 机械盘 + 一块 SSD），两台机器不在同一个物理网络。目标是：

1. 把群晖的照片、资料异地备份到 unRAID 的 16T 盘上；

2. 在 unRAID 上搭一个** Immich 相册库**，方便随时翻照片。

一开始最自然的想法是「群晖用 Hyper Backup 主动推到 unRAID」，但实操下来发现这条路坑特别多，最后改成了「unRAID 主动拉取」，反而更稳。这篇文章就是这套最终方案的完整教程。

二、整体架构一览#

整个流程就三步：

1. 组网：用 EasyTier 把两台机器打通（去中心化虚拟局域网，P2P 直连）；

2. 备份：unRAID 定时用 SSH + rsync 把群晖照片「拉」到本地 16T 盘；

3. 相册：Immich 以「外部库」方式挂载拉下来的照片，只建索引、不重复占空间。

涉及到的软硬件清单：

三、EasyTier 组网#

两台机器跨公网，先得让它们互相能访问。我用的是 EasyTier。安装可见我之前写的一篇文章EasyTier 私有虚拟网络搭建全流程 - 阿雷的小窝

EasyTier 组好网后，出现了一个诡异的现象：从群晖主动连 unRAID 时，ping 通、但 TCP 连不上。

1
ping -c 3 10.x.x.4        # 3/3 通，11ms ✅
2
timeout 5 bash -c 'cat < /dev/null > /dev/tcp/10.126.126.4/873' && echo "通" || echo "不通"

查了半天，靠 easytier-cli peer 揪出规律：EasyTier 2.6.4 在「群晖出站」方向上的 TCP 有问题——群晖主动发起的 TCP、目标也是 2.6.4 节点时会不通；但反过来（unRAID 主动连群晖）完全正常。

也就是说：

• ❌ 群晖主动连 unRAID（推模式）→ 不行

• ✅ unRAID 主动连群晖（拉模式）→ 正常

这个「ping 通、TCP 断」的判断过程，浓缩成一张决策树（排查时照着走，少绕弯）：

搞了半天没解决，决定不跟这个 bug 死磕，直接改用拉模式（unRAID 主动 SSH 到群晖），方向反过来就绕开了。

四、群晖端准备#

4.1 先开三个开关（缺一不可）#

位置	操作
控制面板 → 终端机和 SNMP → 终端机	勾选「启用 SSH 服务」
控制面板 → 文件服务 → rsync	勾选「启动 rsync 服务」
控制面板 → 用户与群组 → 高级	勾选「启用家目录服务」

这三条是 DSM 的硬约束：

1. SSH 登录只对 administrators 组开放——普通用户 shell 是 /sbin/nologin，连上直接 Permission denied；

2. 不开家目录服务，authorized_keys 无处安放，报 Could not chdir to home directory；

3. 不开 rsync 服务，即使走 SSH 也会报 rsync error: service disabled (code 52)。

1
Authentication refused: bad ACL permission for file /volume1/homes/backup/.ssh/authorized_keys

1
synoacltool -del /volume1/homes/backup/.ssh/authorized_keys
2
synoacltool -del /volume1/homes/backup/.ssh
3
synoacltool -del /volume1/homes/backup
4
chmod 755 /volume1/homes/backup
5
chmod 700 /volume1/homes/backup/.ssh
6
chmod 600 /volume1/homes/backup/.ssh/authorized_keys
7
chown -R backup:users /volume1/homes/backup/.ssh

1
ls -la /volume1/homes/backup/.ssh/    # authorized_keys 应为 -rw-------，且无 + 号

五、unRAID 端配置免密拉取#

群晖端就绪后，回到 unRAID 配置 SSH 免密和拉取脚本。

1
mkdir -p /boot/config/ssh
2
ssh-keygen -t ed25519 -N "" -f /boot/config/ssh/syno_pull

1
ssh-copy-id -i /boot/config/ssh/syno_pull.pub backup@10.x.x.20

5.3 密钥持久化（关键一步）#

/boot 是 FAT32，权限位不持久，私钥直接放上面会是 777，被 OpenSSH 以「权限过宽」拒绝。所以正确姿势是「U 盘存源 + 开机复制到内存 + chmod」。

先装 User Scripts 插件（如果没有）：

• Unraid 网页 → Apps（Community Applications） → 搜索 User Scripts → 安装；

• 装完左侧导航栏会出现 User Scripts 入口。

然后在 User Scripts 里新建脚本（点 ADD NEW SCRIPT），运行时机选 At Startup of Array：

1
#!/bin/bash
2
mkdir -p /root/.ssh
3
cp /boot/config/ssh/syno_pull     /root/.ssh/syno_pull
4
chmod 600 /root/.ssh/syno_pull
5
ssh-keyscan 10.x.x.20 >> /root/.ssh/known_hosts 2>/dev/null

5.4 验证免密登录#

1
ssh -i /root/.ssh/syno_pull backup@10.x.x.20 "whoami"

成功的标志：直接输出 backup、不提示密码：

1
backup

如果还提示 backup@10.x.x.20's password:，说明公钥没被接受，回头查 4.3 的 ACL。

---

六、正式备份与定时#

1
ls /volume1/

1
rsync -av --dry-run --stats \
2
  --exclude '@eaDir' --exclude '#recycle' --exclude '@tmp' \
3
  --exclude '@snapshot' --exclude '.DS_Store' --exclude 'Thumbs.db' \
4
  -e "ssh -i /root/.ssh/syno_pull -o BatchMode=yes" \
5
  backup@10.x.x.20:/volume1/photo/ /mnt/user/backup-photos/ 2>&1 | tail -10

1
Number of files: 34,713 (reg: 28,878, dir: 5,725, link: 110)
2
Total file size: 53,988,164,580 bytes

6.3 正式拉取#

去掉 --dry-run，加上断点续传：

1
rsync -av --partial --info=progress2 \
2
  --exclude '@eaDir' --exclude '#recycle' --exclude '@tmp' \
3
  --exclude '@snapshot' --exclude '.DS_Store' --exclude 'Thumbs.db' \
4
  -e "ssh -i /root/.ssh/syno_pull -o BatchMode=yes" \
5
  backup@10.x.x.20:/volume1/photo/ /mnt/user/backup-photos/

七、Immich 搭建与照片管理#

照片备份到本地后，用 Immich 做相册。这一步有个致命坑必须避开，否则重启就丢数据。

7.1 用 Docker Compose 部署（完整配置）#

先装 Docker Compose Manager 插件（如果还没有）：

• Unraid 网页 → Apps（Community Applications） → 搜索 docker compose manager → 安装；

• 装完在 插件 页面能看到它，点开就是 Compose 管理界面。

新建 stack：点 ADD NEW STACK → 名字填 immich → 点进齿轮 → EDIT STACK → 选 COMPOSE FILE，把下面这份 完整可用的 docker-compose.yml（按需进行修改）粘贴进去：

1
name: immich
2

3
services:
4
  immich-server:
5
    container_name: immich_server
6
    image: ghcr.io/immich-app/immich-server:${IMMICH_VERSION:-release}
7
    volumes:
8
      - ${UPLOAD_LOCATION}:/data                 # 上传目录（在 .env 里定义）
9
      - /etc/localtime:/etc/localtime:ro
10
      - /mnt/user/backup-photos:/mnt/nas_photos:ro   # 外部库：挂 rsync 同步下来的照片
11
    env_file:
12
      - .env
13
    ports:
14
      - '2283:2283'
15
    depends_on:
16
      - redis
17
      - database
18
    restart: always
19

20
  immich-machine-learning:
21
    container_name: immich_machine_learning
22
    image: ghcr.io/immich-app/immich-machine-learning:${IMMICH_VERSION:-release}
23
    # 想用核显加速（i5-12400 有 UHD 730），改成下面三行，见 7.5：
24
    #   image: ghcr.io/immich-app/immich-machine-learning:release-openvino
25
    #   devices: [ "/dev/dri:/dev/dri" ]
26
    #   device_cgroup_rules: [ 'c 189:* rmw' ]
27
    volumes:
28
      - model-cache:/cache
29
    env_file:
30
      - .env
31
    restart: always
32

33
  redis:
34
    container_name: immich_redis
35
    image: docker.io/valkey/valkey:9
36
    volumes:
37
      - /mnt/user/appdata/immich/redis:/data     # redis 持久化（否则重启丢任务队列）
38
    restart: always
39

40
  database:
41
    container_name: immich_postgres
42
    image: ghcr.io/immich-app/postgres:14-vectorchord0.4.3-pgvectors0.2.0
43
    environment:
44
      POSTGRES_PASSWORD: ${DB_PASSWORD}
45
      POSTGRES_USER: ${DB_USERNAME}
46
      POSTGRES_DB: ${DB_DATABASE_NAME}
47
      POSTGRES_INITDB_ARGS: '--data-checksums'
48
    volumes:
49
      - ${DB_DATA_LOCATION}:/var/lib/postgresql/data   # 必须落 SSD，见 7.2 的坑
50
    shm_size: 128mb
51
    restart: always
52

53
volumes:
54
  model-cache:

展开收起

配套的 .env：

1
# 上传照片的存储位置（unRAID 的用户共享路径）
2
UPLOAD_LOCATION=/mnt/user/appdata/immich/photo/
3

4
# 数据库存储位置：必须是 SSD cache 盘（见 7.2 的坑）
5
DB_DATA_LOCATION=/mnt/cache/appdata/immich/db
6

7
# Immich 版本（固定主版本，避免滚动升级出兼容问题）
8
IMMICH_VERSION=v3
9

10
# postgres 密码：改成你自己的强密码
11
DB_PASSWORD=your-strong-password
12
DB_USERNAME=postgres
13
DB_DATABASE_NAME=immich
14

15
# 国内必加：模型下载走 hf-mirror 镜像（见 7.4.1）
16
HF_ENDPOINT=https://hf-mirror.com

展开收起

几个要点：

• 数据库路径用变量 DB_DATA_LOCATION，统一在 .env 里改，别在 compose 里硬编码（避免 .env 和 compose 两处路径不一致的坑）；

• 外部库挂载 /mnt/user/backup-photos:/mnt/nas_photos:ro，把 rsync 拉下来的照片只读挂进容器；

• HF_ENDPOINT 国内必加；

• IMMICH_VERSION 固定主版本（如 v3），不要用会滚动的 release，避免升级踩兼容坑。

启动：填完 compose 和 env，回到 stack 页面点 COMPOSE UP，等镜像拉取完成（第一次会拉几个 GB）。

首次初始化（第一次打开）：

1. 浏览器访问 http://unraid-ip:2283；

2. 第一次会进入 创建管理员 页面，填邮箱 + 密码（这就是你的 Immich 管理员账号，记牢）；

3. 进入后就是正式界面了。

1
database:
2
  volumes:
3
    - /mnt/cache/appdata/immich/db:/var/lib/postgresql/data

7.3 用「外部库」管理照片#

照片已经在 /mnt/user/backup-photos/ 了，Immich 不用重新上传，直接挂成外部库只做索引。在 compose.yml 的 immich-server 服务里加一个只读挂载：

1
immich-server:
2
  volumes:
3
    - /mnt/user/backup-photos:/mnt/nas_photos:ro

改完 docker compose up -d 重启，然后在 Immich 后台：管理 → 外部库 → 创建外部库 → 导入路径填 /mnt/nas_photos。

外部库是只读索引：Immich 不改动照片原件，只建数据库索引。照片在 /mnt/user/backup-photos/，索引在 postgres——这也再次说明 postgres 必须持久化，否则索引每次重建。

7.4 开启人脸识别#

人脸识别默认就是开启的，由 immich-machine-learning 容器承担，不需要改任何配置。但外部库的照片不会自动全部处理，需要手动触发，而且顺序很关键：先检测、后识别。

1. 先扫描外部库：管理 → 外部库 → 你的库 → 扫描（Scan），让照片进库；

2. 管理 → 任务（Jobs）→ 人脸检测（Face Detection），点右侧 全部（All）；

3. 等检测跑完（Jobs 页有进度条），再点 人脸识别（Facial Recognition） 的 全部（All）；

4. 全部跑完后，到 探索（Explore）→ 人物（People），给聚类出的人脸命名，之后 Immich 会自动归类同名的人。

为什么「人脸识别显示 0」？ 因为人脸识别依赖人脸检测先跑——检测没跑，识别队列永远是 0；而照片没 scan 进库，检测又无从谈起。所以卡在 0 时，从「外部库有没有扫描」往上查。

7.4.1 国内必踩的坑：模型下载失败#

人脸识别依赖的 buffalo_l 模型（以及智能搜索的 CLIP 模型）默认从 HuggingFace 下载，国内直连不通，会出现典型的死循环：

1
Downloading detection model 'buffalo_l' ... This may take a while.
2
Failed to load detection model 'buffalo_l'. Clearing cache.
3
Attempted to clear cache for model 'buffalo_l', but cache directory does not exist

解决：在 .env 里加一行，把模型下载源切到国内镜像：

1
HF_ENDPOINT=https://hf-mirror.com

然后重启 ML 容器：

1
docker compose up -d immich-machine-learning

重启后再看日志，出现 Fetching ... 100% 和 Loading detection model 'buffalo_l' to memory 就说明下载成功、可以正常识别了。

成功的标志（加了 HF_ENDPOINT 后，日志从「下载失败」变成「下载成功」）：

1
Downloading detection model 'buffalo_l' ... This may take a while.
2
Fetching 4 files: 100%|██████████| 4/4 [00:06<00:00, 1.60s/it]
3
Loading detection model 'buffalo_l' to memory
4
Loading recognition model 'buffalo_l' to memory

关键看 Fetching ... 100%（下载成功）和 Loading ... to memory（加载成功）——之前失败时是 Failed to load ... Clearing cache。

7.5 硬件加速（可选）：用核显 OpenVINO#

默认用 CPU 跑，几万张照片会偏慢。i5-12400 自带 UHD 730 核显，可改成 OpenVINO 加速——前提是核显没被其他虚拟机直通占用。

先确认核显可用：

1
ls /dev/dri        # 能看到 renderD128 之类即说明核显可用

改 compose（⚠️ unRAID 上 device_cgroup_rules 这行必须加，否则容器访问不到 /dev/dri）：

1
immich-machine-learning:
2
  image: ghcr.io/immich-app/immich-machine-learning:release-openvino
3
  devices:
4
    - /dev/dri:/dev/dri
5
  device_cgroup_rules:
6
    - 'c 189:* rmw'

改完拉新镜像并重启：

1
docker compose pull immich-machine-learning
2
docker compose up -d immich-machine-learning

怎么确认用上了核显？ 看 ML 日志的 execution provider：

1
docker logs immich_machine_learning 2>&1 | grep -i "execution provider"

• CPUExecutionProvider → 还在用 CPU

• OpenVINOExecutionProvider → 核显生效 ✅

成功的标志：日志里 OpenVINOExecutionProvider 排在第一位（CPU 只作为 fallback 排第二），说明核显已接管推理：

1
Setting execution providers to ['OpenVINOExecutionProvider', 'CPUExecutionProvider'], in descending order of preference

对比改造前（纯 CPU）：['CPUExecutionProvider'] —— 前后一字之差，就是核显是否生效的分水岭。

device_cgroup_rules: 'c 189:* rmw' 是给容器开放 /dev/dri（字符设备 189）的读写权限。unRAID 的 Docker 默认 cgroup 限制较严，漏了这行即使挂载了 /dev/dri 也访问不到——这是 unRAID 上特有的坑。

1
    redis:
2
      volumes:
3
        - /mnt/user/appdata/immich/redis:/data

1
XLM-Roberta-Base-ViT-B-32__laion5b_s13b_b90k

八、常见问题排查（FAQ）#

总结#

折腾了这么一圈，总算把「群晖相册 → unRAID 备份」这条路走通了。最大的意外收获是 Immich——它有全平台客户端，用下来比 Synology Photos（DS Photos）顺手不少，尤其是后者看照片地图时经常崩溃的问题，在 Immich 这边完全不存在。

所以我现在是这么分工的：上传和同步交给 Synology Photos，白嫖它的 QuickConnect 远程能力；照片的处理、查看交给 Immich，人脸识别、智能搜索都在这边跑。两者各干各擅长的，互补着用。

整套方案从组网到备份再到相册搭建，全部配置和踩过的坑都写在上面了，照着做基本能一次到位。如果你也有异地备份照片的需求，不妨试试这套组合，应该不会让你失望。

参考#

1. Immich
2. rsync | DSM - Synology 知识中心
3. Unraid Rsync 适用于Unraid
4. 使用hyper backup与rsync将数据备份到unraid-腾讯云开发者社区-腾讯云
5. Immich 智能搜索 - 支持中文的 CLIP 大模型 | 一起玩 NAS!
6. immich：从零开始，自建 NAS 相册 - 初之音

一、周五晚上10点，株洲站出发#

我们几个都是从株洲出发的，火车是晚上的卧铺车，10 点出发，第二天凌晨 5<40> 到铜仁。一张硬卧 138 块，直接把住宿和一程高铁钱都省下来了。

不过我们还是有点高估自己的睡觉质量，在卧铺上，我才堪堪睡了 30 分钟，第二天全靠一杯魔爪提神。

凌晨出站的时候天还黑着，铜仁的空气凉得舒服。

梵净山有两个门：东线在江口县，主流游客走这里，索道上下、轻松；西线在印江县，山门叫护国寺，从护国寺到徒步起点需要坐景交车上山，然后徒步上去。

我们选择的是西上东下线，从西门徒步上到金顶，再在东线坐索道下山。西线相对东线便宜一些，但交通不太方便，推荐提前约好顺风车，不然临时打车会非常贵。我们提前一周联系了一个顺风车师傅，这趟顺风车花了 200 出头，几个人平摊下来还好。

在去西线的路上，我们还遇到了一群黔金丝猴，听说这种”牢底坐穿兽”只有贵州才有。

西线盘山公路非常绕，本来就没休息好的我，直接被绕晕车了，这还没开始爬，人就已经半血了。闷头坐了 2 个多小时车，到西线山门的时候已经 8 点。

二、西线徒步#

门票 + 景交车 + 东线下行索道一共 190 元（这是西上东下的标准买法，从山门坐景交车到棉絮岭徒步起点，回程从东线索道下山）。

为什么要选西线而不是东线索道？ 因为它沿途是原始杜鹃林和阔叶林，台阶大多埋在树影里，绿得发亮。我们这个时间（9 月初）花早就没了，但可以想象：4 月杜鹃满开的时候这条路会是什么样。

棉絮岭起步不久，就看到了万米睡佛——这是西线专属的一个景点，在观景台上远眺，远处起伏的山脊线刚好构成一尊绵延万米的卧佛轮廓。这是走东门看不到的补偿。

接着是黑巷子、十月怀胎树、剪刀峡、拜佛台……每个名字都不一样。台阶湿漉漉的，风穿过树梢，一路上都非常凉爽，怪不得徒步都推荐来西线呢。

建议在保存红云金顶的预约二维码，不用到普渡广场，在路上就可以预约红云金顶，我是走了半路上才可以，搭子的手机刚进进去再棉絮岭就可以预约了。

三、普渡广场，300 号的红云金顶#

10<00> 不到，我们就到了普渡广场。这是山顶的核心枢纽，去红云金顶、老金顶、蘑菇石都要在这里分叉。

我们从西线过来，首先会经过老金顶和蘑菇石，因为红云金顶太火爆了、还需要预约，所以我们选择直冲红云金顶，后面回头再来老金顶。

因为我们来得比较早，取号的时候才 300 号，红云金顶都还没开始叫号排队，我们直接上去就行。

红云金顶在一座独立的尖峰上，山体陡峭，要靠铁链手抓脚踩。下半段还算稳，到中段开始，真正只容一人通过，两边是悬空。

登顶的那一刻，金顶被云雾包着，时隐时现。远处的山尖像漂浮的小岛。风是真的大，把衣服吹得噼啪响。

四、老金顶与蘑菇石，大部队来了#

从红云金顶下来，已经 11 点左右，这时候大部队陆续上山。

我们原路返回普渡广场，往老金顶方向走。老金顶比红云金顶海拔高一点（2493 米），但坡相对缓，有一段需要手脚并用的险路。

老金顶上堵得水泄不通。人一多，游客挤成一锅粥卡在窄台阶上，险段还有人停下来自拍——台阶本来就只够一人通行，一人自拍，全员堵车。

蘑菇石离老金顶不远，一块 14 亿年的巨石，立在另一块石头上，看似随时要倒，就是不倒——梵净山的 logo。拍照要排队，但至少脚下稳。

整个老金顶 + 蘑菇石，我们花了将近 1 个小时，到 12<30> 左右才回到普渡广场。雾散了一点，我们找准机会，才拍到了云雾中的红云金顶。

五、坐东线下行索道，回铜仁#

下午一点多从普渡广场出发，沿着指示牌走一段木栈道，就到了东线下行索道，然后转景区公交车到景区门口，已经是下午两点多了。景区门口有不少拉客的司机，拼车 35 块一个人，可以直接到铜仁站。

六、铜仁美食：施秉全牛自助#

从梵净山下来，我们立马买了回长沙的高铁票，但铜仁回长沙的高铁只有晚上 19<30> 那一趟，还有四五个小时，这下不得不去铜仁觅个食了。

各种社交平台刷了一遍，最后选了家老字号——施秉全牛馆，自助 55 一位，牛肉随便吃。兄弟几个一听到”牛肉随便吃”就走不动道了，直接拍板。

我们吃的是酸汤锅底加干锅牛肉。酸汤锅底放了山胡椒油，我个人是一点也顶不住，味道只能说中规中矩；干锅牛肉稍微咸了点，但对于刚爬完山、出了一身汗的我来说刚刚好。

如果这顿是 100 元的自助，完全不值；但它 55 一个人，我只能说完全没毛病。

七、费用#

总共算了一下出行费用，不算饮食，而且我们也没有住宿：

• 株洲→铜仁卧铺：~138元

• 铜仁→梵净山西线顺风车/拼车：~200/3=66（往返，平摊）

• 山顶门票 + 景交车 + 东线下行索道：190元

• 梵净山东线→铜仁站：~35元

• 铜仁→长沙回程：~184元

加起来 ~613 元，没超预算，纯特种兵出行，连住宿都免了。

八、总结#

1. 西线 vs 东线怎么选？

• 带老人小孩、想舒服：东线，索道上下（贵一些，大概 264 一整套）

• 朋友组队、想徒步、原生态：西线徒步上 + 东线索道下（这次我们走的路线，爬升约800米，全程下来4个小时）

  

• 纯徒步，不上金顶：东线徒步，全程爬升1600米，时间上会非常赶，到时候红云金顶排队会非常严重，而且可能赶上下山索道、景交车高峰期，会比较折磨。

2. 红云金顶怎么免排队？

进山后直接扫码预约，不一定要到普渡广场，有时候老远就能预约到了。如果你到达比较早，每天前 500 人直接上、不用等叫号。超过 500 号要在原地等叫号。

3. 西线专属景点：万米睡佛

只有走西线的徒步客能看到。在棉絮岭观景台。东线的游客看不到——这一点作为西线的精神补偿还算值。

4. 装备清单（雾天尤其重要）

• 防滑运动鞋（湿石很滑）

• 薄手套（抓铁链、雾天铁链冰凉）

• 冲锋衣（山顶比山下低 6-8℃）

• 一次性雨衣（雾天飘的水珠跟下雨一样）

5. 关于猴子

山下到山门盘山路上，如果停着车等人，或者经过有树有水的地方，留意一下树梢。梵净山的黔金丝猴是国家一级保护动物，运气好能碰上，但别喂、别追、别下车。

一、创建 Notion 内容页#

1. 复制官方模板#

打开 NotionNext官方配置模板，点击页面右上角 Duplicate，将模板复制到自己的 Notion 工作区。

2. 获取页面 ID#

1. 打开复制后的配置页面，依次点击右上角 Share → Publish → 开启 Share to web，复制页面共享链接。
2. 提取规则：链接中连续 32 位的字母数字串即为页面 ID，需剔除 ?v=、?pvs= 及之后的所有参数。
   • 示例： https://www.notion.so/tanghh/02ab3b8678004aa69e9e415905ef32a5?v=b7eb...
   • 页面 ID：02ab3b8678004aa69e9e415905ef32a5
3. 关键提醒：必须开启公开分享，否则站点无法拉取 Notion 数据。

---

二、复刻项目源码#

1. 打开 NotionNext GitHub 官方仓库，点击右上角 Fork，将项目完整复刻到自己的 GitHub 账号下。
2. 后续所有部署、配置修改均基于你自己的仓库完成，支持版本管理和个性化二次开发。

三、腾讯云 EdgeOne 部署#

1. 进入 Makers控制台#

登录腾讯云控制台，搜索「边缘安全加速平台 EO」，左侧导航选择「Makers」，点击「创建项目」。

2. 导入 Git 仓库#

1. 选择「导入 Git 仓库」，完成 GitHub 账号授权，建议仅授权指定的 NotionNext 仓库。
2. 仓库选择上一步 Fork 的项目，生产分支选择 main。

3. 构建配置（核心步骤）#

系统会自动检测项目的框架，并且预填写构建命令

1. 构建命令请使用静态导出：yarn export。若托管面板模板仍显示 npm run build / npm run export，请按仓库习惯改为 Yarn。前者是动态站点，后者是静态。
2. 项目名称要修改一下，名称长度必须为5到63个字符，只能包含小写字母、数字和连字符。
3. 环境变量中添加您的NOTION_PAGE_ID

补充说明：静态部署后，Notion 内容更新需重新触发构建才能同步到站点。

4. 启动部署#

1. 确认配置无误，点击「开始部署」，首次构建约 3-5 分钟。
2. 部署成功后，系统分配默认访问域名，可直接打开验证站点效果。

5. 绑定自定义域名（可选）#

1. 前提：域名已完成工信部 ICP 备案。
2. 操作路径：项目设置 → 域名管理 → 添加自定义域名，按提示在域名服务商处添加 CNAME 解析记录。
3. 解析生效后系统自动签发 SSL 证书，默认开启 HTTPS 访问。

---

四、备选方案：Vercel 一键部署#

适用场景：海外读者为主，或需要 Notion 内容实时自动同步。

1. Vercel 官网使用 GitHub 账号登录。
2. 导入 Fork 的 NotionNext 仓库，框架会自动识别为 Next.js。

1. 添加环境变量 NOTION_PAGE_ID，点击 Deploy 即可完成部署。

1. 优势：支持 ISR 增量静态再生，Notion 修改内容后数分钟内自动同步，无需手动重建。

五、站点基础配置#

1. 发布文章#

在 Notion 数据库中新增一行：

• type 选择 Post（普通博客文章）
• status 设为 Published（公开可见）
• 填写标题、分类、标签、摘要后，点击进入页面，即可用 Notion 原生块编辑器撰写内容。

3. 内容更新规则#

• EdgeOne 静态部署：Notion 修改内容后，需在 EdgeOne 控制台手动触发重新部署，站点才会同步更新。

• Vercel 部署：默认开启增量缓存，无需手动操作，数分钟内自动同步。

---

搭建的博客首页样式如图所示

六、常见问题#

1. 站点不显示文章
   • 检查页面 ID 是否准确，Notion 页面是否开启公开分享。
   • 确认文章 status 为 Published。
2. EdgeOne 构建失败
   • 确认构建命令为 npm run export。
   • 可添加环境变量 NODE_VERSION=18 指定 Node 版本，清空构建缓存后重试。
3. 国内访问加载慢
   • 建议替换谷歌字体为国内源，图片资源改用国内图床。
   • 在 EdgeOne 控制台配置缓存规则，提升静态资源命中效率。

总结#

总的来说，这套 Notion + NotionNext 的建站方案，最大的好处就是把「写内容」和「搭网站」拆得特别舒服。你不用像用 WordPress 那样操心服务器运维，也不用像用 Hexo 那样在本地编辑器和最终部署效果之间反复横跳 —— 平时写文章就正常用 Notion，排版、分类、插代码嵌图片都所见即所得，写完发布顺手就能同步到网站上，门槛低了很多。

对国内用户来说，部署到腾讯云 EdgeOne 是性价比很高的选择，国内访问速度稳，个人博客用免费额度基本就够；如果想图省事一键搭建，或者主要面向海外读者，Vercel 方案也完全能用。

📎 参考文章#

• 从这里开始 | NotionNext 使用说明
• (77 封私信 / 80 条消息) 如何用Notion搭建个人博客网站？ - 知乎
• 基于NotionNext的个人网站|博客搭建与部署实例教程-CSDN博客

✨出行省钱小技巧#

出发前专门囤了株洲文旅惠民卡！抖音入手只要100块，真的巨划算！不光能玩遍株洲本地文旅项目，萍乡超多景点也能通用抵扣，五一出游直接省下一大笔门票钱，自驾周边游必入！

📅四天三晚完整行程实况#

Day1 5.2｜打卡天下第一洞·孽龙洞#

第一天主打轻松休闲，自驾直奔萍乡孽龙洞！号称“天下第一洞”，网上名气超大，实际逛完真心觉得期望值拉太高了。

整体就是很常规的溶洞景观，石笋、石幔这些溶洞标配景色都有，没有特别惊艳的亮点。景区步道全程超长，足足四五公里，慢慢逛走完要3个小时左右，全程一直在走路，逛到后面纯纯审美疲劳，普通游客可去可不去，性价比一般。

Day2 5.3｜治愈竹筏+超嗨游乐项目#

上午慢悠悠打卡十里竹筏！这一站真的很惊喜，完全是小众治愈秘境。四周青山环绕，溪水清澈透亮，山清水秀氛围感拉满，吹着山间清风坐竹筏超舒服，人少景美，很适合拍照打卡，放松散心超合适。

下午直接冲武功山山脚，解锁两大游乐项目：滑草+越野车！

滑草项目性价比超高，套餐里包含射箭、水滑等多个小项目，一票通玩，趣味性很足，老少皆宜，玩得超尽兴。

重点夸爆山地越野车！绝对是本次旅途最佳项目No.1！全程颠簸刺激，山路弯道超多，油门踩到底的快乐谁懂！自由度很高，可玩性拉满，玩完还意犹未尽，来萍乡一定要冲！

玩完所有项目，晚上直接驱车赶往龙山村入住，为第二天反穿武功山提前占位。

Day3 5.4｜武功山二刷反穿！#

这天是我二刷武功山反穿路线！去年9月就挑战过一次完整版武功山反穿，全程12小时暴走20公里，当时就整理了超详细的路线解析、徒步装备、食宿避坑完整攻略，没看过首次反穿细节的朋友可以先补课👉武功山一日反穿完整版攻略！

本以为有第一次的徒步经验，五一二刷肯定能轻松拿捏，结果完全翻车！平时工作日、淡季徒步和五一旺季徒步，体验感天差地别，累度直接翻倍，还踩了自驾停车的致命大坑，今天就好好跟大家聊聊两次反穿的真实差别，给旺季爬山的朋友避大雷！

依旧是早上6点准时起床摸黑出发，和第一次淡季空旷的山路完全不同，五一山上人山人海，全程走走停停。同样是龙山村反穿金顶的路线，全程20公里徒步、12小时超长续航，从清晨走到傍晚，硬生生熬到晚上6点才登顶金顶。下山人流拥堵严重，折腾到晚上8点才下到索道口，排队等索道直接排到夜里10点，对比第一次淡季不用排队、畅通无阻，五一旺季爬山真的折磨加倍！

这里必须给所有自驾游客掏心窝避坑忠告！！！

千万别把车停龙山村！！！我们自驾车停在龙山村，下山在游客中心，距离超远，深夜下山还要额外打车折返取车，又累又麻烦，心态直接崩了。

正确自驾操作（沿用首次反穿靠谱经验）：之前9月反穿，我们就是车停武功山游客中心，打车去龙山村起步，下山直达停车场，全程顺畅不折腾。结果这次五一偷懒换了停车方式，直接踩雷！真心建议所有自驾党，无脑照搬这个正确路线，千万别乱改！下山直接到游客中心开车，完美避开深夜折返跑路，省力又省心！

🏨三晚住宿真实测评（平价+实景）#

全程三晚住宿，性价比、体验感参差不齐，真实分享给大家：

第一晚｜芦溪县城 礼萍宾馆

性价比直接封神！！两个标间才花200块，人均超级便宜，临时过渡住一晚完全够用，干净整洁，预算党闭眼冲不亏哈哈哈。

第二晚｜龙山村 龙门山庄

靠近武功山徒步起点，位置绝佳，主打一个方便徒步，周边配套齐全，爬山前落脚首选。

第三晚｜归隐栖心酒店

环境安静舒适，设施比较新，暴走爬山后住这里休整，休息体验感很不错。

🍜全程美食真实吐槽｜无滤镜实况#

萍乡美食有惊喜也有踩雷，全部真实口感分享：

Day1午餐｜大掌柜家常菜

真心踩大雷！味道很普通，关键是超级辣，不能吃辣的慎入！最离谱的是空心菜都没炒熟，口感巨差，整体体验很一般，不推荐。

Day1晚餐｜昭萍宴

中规中矩的网红店，没有惊艳的味道，整体平平无奇，吃完没什么记忆点，可吃可不吃。

Day2午餐｜8号餐厅（全场最佳）

整趟旅途最满意的一餐！直接封神yyds！招牌莲花血鸭正宗地道，香辣入味，越吃越上头，我们直接吃到过瘾，来萍乡必吃！

Day2晚餐｜本地炒粉

玩累了随便找店解决，本地特色炒粉，味道家常，饱腹刚刚好。

Day3早餐｜龙门山庄炒粉

15元一碗的农家炒粉，性价比尚可，简单吃完补充体力，开启暴走爬山模式。

Day4晚餐｜季季红火锅

旅途收尾整顿好的！爬山累瘫后炫一顿火锅，治愈所有疲惫，完美收官本次萍乡之行。

💥总结碎碎念#

这次萍乡四天自驾，属于一半惊喜一半踩坑！也是我时隔大半年二刷武功山反穿，两次体验反差真的超大！淡季徒步人少路顺、体验感拉满，五一旺季人挤人、排队崩溃，还踩了自驾停车大坑。整体来说，十里竹筏、山地越野车、8号餐厅莲花血鸭完全值得冲，孽龙洞性价比一般。虽然两次反穿都累到腿废，但武功山的草甸全景、山野风光永远让人着迷，每次登顶都有不一样的治愈感！

最最重要的就是自驾停车避坑！听劝！千万别复刻我们折返取车的悲惨经历！

一、全程交通｜超详细换乘#

我们的路线：株洲→长沙→黄山北站→黄山景区，全程公共交通，不想自驾的朋友完全可以这么走，省事又省钱。

4、返程超级大坑（很多人踩雷）#

我们是云谷索道下山，返程买票一定要注意！两个路段用的是不同小程序，千万别搞错：

• 云谷寺→汤口换乘中心：黄山旅游官方小程序买票

  

• 换乘中心→黄山北站：中交出行小程序买票！官方小程序买不了！现场排队巨多人，千万别临时买！

✨小提醒：班车有运营时间，下午尽量早点下山，别卡点赶末班车，真的会焦虑！

二、两日行程实况｜20公里暴走累瘫但巨值！#

Day1 周六｜冲天都峰、看日落、住白云宾馆#

✅ 前一晚：株洲出发到长沙，住在高铁站旁边，第二天早起赶车超级方便，不用慌慌张张。

✅ 早上7点高铁：长沙出发直奔黄山，时间卡得刚刚好。

✅ 下午1点进慈光阁：这里重点提醒！天都峰下午2<30就停止检票>！我们到的时候时间特别赶，全程小跑不敢停。刚进山的路超级友好，坡度很缓，一路上都是树，还有小溪流水，风吹着全是草木清香，完全是轻松热身的状态，走起来特别舒服。

✅ 天都峰攀爬实况（全程心惊胆战）：走完热身路段，从新道口进去就是天都峰硬核路段，难度直接翻倍！好多阶梯几乎90度垂直，全程必须抓着铁链慢慢挪，真的步步惊心。中途会经过一线天，最吓人的就是鲫鱼背，短短十几米，最窄的地方只能一个人过，两边都是悬空的，恐高的朋友真的会腿软。

咬牙登顶之后，一路走到玉屏峰，打卡标志性的千年迎客松，现场看真的超有氛围感。慢慢往光明顶方向走，傍晚刚好遇上山间日落，漫天余晖真的太治愈了！不过爬完整个人累到不行，双腿巨酸。而且山顶信号超级差，我的小米手环全程没记录到徒步轨迹，白白暴走一天，真的有点可惜。

✅ 住宿：白云宾馆：好不容易抢到的标间，1500一晚，说实话真的肉疼，钱包直接被掏空！但不得不说山顶位置真的绝，看完日落走路就能到，不用折腾。酒店福利也很贴心，免费借看日出的棉服、头灯，还含第二天早餐，不用自己背厚重衣服，这点真的救大命。休整一晚，准备凌晨冲日出！

Day2 周天｜凌晨追日出、暴走西海大峡谷、圆满下山#

✅ 凌晨4点冲光明顶：为了看日出真的拼了！四点直接起床，空腹摸黑上山，靠着酒店借的头灯照明。到山顶的时候已经挤满人了，赶紧抢占位置蹲日出。亲眼看着太阳从云海里面慢慢升起来，金光铺满整座山谷，那一刻真的觉得早起、累全都值了！

✅ 意外收获：绝美流动云海：看完日出准备走，回头突然看到大片流动的云海！云雾绕着群山飘来飘去，仙气满满。别人说看黄山风景“八分饱”是最好的状态，这次真的被风景喂饱了，运气直接拉满！

✅ 早上6点早餐休整：看完云海回酒店吃早餐，狠狠补充体力，因为接下来的路才是最虐的！

✅ 徒步西海大峡谷（9.5公里纯暴走）：休整完直接冲西海大峡谷！全程9.5公里，前一天爬完天都峰，我的膝盖和腿已经完全肌无力了，但还是坚持全程徒步，没坐小火车。

这条路真的巨虐！先一路陡坡下到海拔1000米的谷底，峡谷风景确实震撼，视野超级开阔。但下得有多爽，爬上来就有多累！全程高强度爬坡，中途还遇到超窄超陡的小鲫鱼背路段，必须小心翼翼慢慢走，走完整个人直接累瘫，但景色真的绝美。

✅两日20公里圆满收官：艰难走出西海大峡谷，经过北海景区，最后走到云谷索道路口下山。整整两天，累计暴走20公里！

真心觉得黄山又险又美，虽然全程腿废、钱包也空，但亲眼看到了日出、云海、奇松、峡谷，所有疲惫全部抵消，这趟旅程真的超值得！

三、重点避坑注意事项#

2、天都峰预约比门票更卷！#

划重点！先买黄山门票，才能预约天都峰，预约是免费的，但名额极少，一天只放3000个！必须提前三四天预约，纯纯手慢无。我同行的小伙伴就没约上，全程没能登顶天都峰，真的巨遗憾！

四、总结#

这条两日路线还挺适合株洲、长沙周边周末短途出游。行程紧凑但不瞎赶路，黄山核心美景全部打卡到位。只要提前抢好门票和约好天都峰，新手也能轻松玩转！

一、生活：简单而纯粹#

2025年生活主打一个简单纯粹，住公司宿舍，两点一线（公司→宿舍），没有复杂的琐事，也没完成去年定下的脱单小目标😂 日常下班回去，要么打打球放松身心，要么玩会儿游戏解压，平淡却也充实，除此之外，还有几个值得纪念的小瞬间。

1）提车时刻：2025年最值得纪念的小事就是我终于提车辣，在爸妈千呼万唤的催促下，我终于拥有了自己的小车，出行不用打车看城铁颜色了，偶尔开车出去兜兜风，去周边徒徒步，解锁了新的生活形态~

2）厂BA回忆：今年公司组队参加了厂BA，一闯进淘汰赛，就拉着我们去当啦啦队，也算正式体验了一把现场篮球观赛的快乐！可惜我一到场，公司球队就输了，真的太扎心了so sad。

3）湘超狂热粉日常：作为实打实的足球迷，今年湘超一开始举办，我就全程蹲守赛事！只要能抢到票，每一场比赛都不会缺席，可最大的难题就是抢票太难了，忍不住吐槽一句：湘超的票到底是谁在抢啊😭 株洲队常规赛发挥超稳，可惜最后淘汰赛状态拉胯，完全没打出我理想中的水平，真的有点遗憾。

4）KPL线下初体验：虽然我不怎么看KPL，王者荣耀也弃坑好久了。这次KPL季后赛，被龙哥硬拉着去看狼队比赛——我之前常线上看LPL，从来没去过线下观赛，也算曲线救国，补齐了没看过电竞现场的遗憾。没想到重庆狼队在不被看好的情况下，一路逆袭杀进鸟巢决赛，可惜最后惜败，没能见证夺冠，有点小可惜。

二、2025年度游戏回顾：快乐就好#

2025年我的精力主要放在户外运动上，游戏上花的时间比往年少了很多，除了朋友拉着联机开黑，平时几乎不主动上线，主打一个劳逸结合，用游戏缓解上班带来的疲惫，不沉迷、不内耗，快乐就好～

1）三角洲行动：今年上半年一度玩得特别上头，可深入玩下去后，彻底感受到了策划的深深恶意😭 游戏里养了一堆工作室，还一个劲打压普通玩家的游戏生态，对外挂更是放任不管，我这种鱼塘局都能遇到一堆外挂，举报了也不封号。经历几次策划“不做人”的操作后，我彻底对这款游戏无感，下半年就果断弃坑了。

2）英雄联盟：我本来就是个玩了好几年的大乱斗咸鱼玩家，之前已经有点玩腻了，上号频率越来越低。没想到今年策划搞了个roguelike模式的海克斯大乱斗，直接把大乱斗的随机性和趣味性拉满！年底连着玩了一个月海克斯大乱斗，真的玩爽了，瑞天帝、双刀流薇恩、一板一眼杰斯，哪怕是抑郁症过来，玩上几局都得笑出声😂

3）崩坏星穹铁道：崩铁算是我今年游戏里的意外惊喜！本来我都处于半退坑状态了，结果周年庆抽奖时，居然靠狗运抽到了一本纪念册设定集——别人都得满勤做任务才能拿到，我这个常年不满勤的人居然抽中了，当时开心到起飞～

4）赛尔号：这波真的是爷青回！之前因为忘记密码，尝试了好多次都没能找回米米号，本来都不抱希望了，大概是淘米快撑不住了？今年账号找回变得异常简单，只需要提交一些简单的验证材料，居然真的把童年的账号找回来了！上号第一件事就冲了个年费，不为别的，就为了弥补自己曾经逝去的童年回忆。

今年大部分精力都放在户外徒步和运动上，游戏时间减少其实也是件好事。毕竟上班对着电脑，下班玩游戏还是对着电脑，对眼睛和腰背都不太友好，非必要确实要尽量减少电脑游戏时间，但要说戒掉游戏，那是不可能的～ 游戏依旧是我忙碌生活里，不可或缺的解压小方式。

三、运动：步履不停，在热爱里找回活力#

去年一年深陷工作忙碌，每天5点吃完晚饭就回工位继续加班，完全没有保持任何运动量，久而久之，体重直接飙升了10斤。当体重秤上的数字变得刺眼，我才真正意识到问题的严重性，于是2025年，我开始有意识地控制体重、坚持运动，把更多精力放在了自己的身体上，也慢慢找回了活力满满的状态～

**羽毛球：**今年最大的收获之一，就是重新捡回了羽毛球这项运动。慢慢凑起了几个固定的球搭子，默契十足，每周二、四、六下班，我们都会第一时间冲去羽毛球场，卸下一天的工作疲惫，酣畅淋漓打一场球。这一年下来，羽毛球技巧确实有了长足进步，但说实话，依旧没摸到入门的门槛，失误率还是很高，反手要么打不过渡球，要么根本打不到后场，短板十分明显。

身边也有人建议我请个私教系统学习，但我觉得没必要太过较真，没有请私教，就和球搭子们随意打、开心打，哪怕进步慢一点也没关系。运动的初衷本就是放松和解压，不用追求专业水准，能在挥洒汗水中收获快乐，就足够了。

**减肥：**运动之外，饮食控制也提上了日程。我给自己制定了简单易坚持的饮食计划：早午餐以牛奶咖啡搭配全麦面包、玉米或鸡蛋为主，清淡又顶饱；中午在公司食堂就餐，尽量避开高脂肪、高热量的食物，多吃蔬菜和豆制品，保证营养均衡。

在不打羽毛球的日子里，我就去公司健身房爬坡一小时，不追求高强度运动，只坚持有氧运动，慢慢燃烧脂肪。经过一段时间的坚持，体重也在一点点稳步下降，虽然还没达到预期目标，但我知道，减肥是一场持久战，“革命尚未成功，同志仍需努力”。2026年，我的小目标是把体重控制到55kg，继续加油！

**徒步：**我对徒步和旅游做了个简单的划分：省内的爬山都归为徒步，省外的出行则算旅游。今年一旦打开了徒步这个“开关”，就彻底停不下来了，和几个徒步搭子更是一拍即合，一到周末就嚷嚷着要去爬个山，要是一周不爬山，就浑身不自在，感觉身上有蚂蚁在爬哈哈哈，妥妥的爬山上瘾体质～

1）我的徒步之旅，是从老朋友衡山开始的。今年和兄弟们一起，连续爬了两次衡山，一次走常规路线，一次抄了近道——曾国藩古道。能明显感觉到，经过三个月的运动锻炼，我的体能提升了不少，第二次爬山的速度比第一次快了很多，也轻松了很多，那种循序渐进的进步，真的很有成就感。

2）后来入坑了两步路APP，开始尝试走野路子，现在想想还想吐槽一句：这到底是谁在两步路上传的路线啊哈哈哈哈哈！汉王陵-谷山-尖山三穿，直接把我走懵了，尤其是尖山那段，全程都是野路子，需要钻树林、爬陡坡，我们几个人全程骂骂咧咧，累得气喘吁吁，但走完之后，又有种征服困难的快感。

3）狮峰山环线：狮峰山的环线整体不算累，但最后一段路真的让我印象深刻——全程特别滑，我至少滑了十多次，最后裤子上沾满了灰尘，狼狈又好笑。要知道，我当时穿的还是迪卡侬MH500的徒步鞋，防滑效果已经不算差了，真不敢想象，要是穿普通运动鞋来，得滑成什么样。

4）黑麋峰环线：黑麋峰环线相较于之前爬的山，距离更远一些，从株洲开车过去都要一个多小时。这条环线会途经两个森林公园，从黑麋峰森林公园出发，转到北山森林公园，最后再折回黑麋峰，好在全程路程不算长，我们很轻松就走完了。不过有个特别气人的小插曲：当时我用action4录制徒步视频，不小心调成了1/8倍速，导致全程都没有录到声音，给我气的半死。

5）九郎山环线：九郎山算是我们的徒步老朋友了，经典环线几乎没有任何难度，谁让株洲50公里以内，好玩的山就没几座呢～ 2025年的徒步收尾，就交给了九郎山。这里必须提醒一句：上九郎山千万不要开车，尤其是周末，堵车堵到怀疑人生。

回望2025年，户外徒步和羽毛球运动，填满了我的业余生活。去年的充实，全是工作赋予的；而今年的充实，是运动和热爱赋予的。2026年，我会继续保持运动的热情，达成更多运动量，成功把体重降下来，争取把湖南周围的山，都爬个遍，解锁更多徒步新路线～

四、旅游：步履所至，皆为风景#

1） 北京｜3月匆忙的出差之旅：新年的第一个出行地点没想到是北京，周末突然接到电话要求到北京出差，一下子就把我可怜的周末给占用了。完成工作后，怎么能错过利用有限时间“公费旅游”的机会呢？毕竟是祖国壮丽的首都呀哈哈～ 上次来北京已经逛过故宫，这次就重点打卡了天坛，感受京城的厚重底蕴，也算不辜负这趟匆忙的出差。

2）武汉｜5月重温旧时光：趁着超哥5月婚礼，我终于回了一趟武汉。再次踏上这片熟悉的土地，心中满是物是人非的感慨——以前住的宿舍，现在居然改成了酒店，周围一圈发展得像CBD一样，我都快认不出，这还是当年那个老破小的鱼区吗？刚提车就开车去了武汉，两天一起开了1000多公里，还在路上就被交警电话警告疲劳驾驶了。

3）宜昌、恩施｜8月高温假，带着爸妈的自驾游：提车后的第二次出省出行，选在了高温假，趁着假期，带着爸妈一起自驾游，主打一个“走到哪玩到哪”，轻松自在，也好好陪了陪爸妈。

我们先去了宜昌：第一天直奔长江边，看看江边的夜景，吹吹宜昌的晚风，第二天上午游清江画廊，绿水如翡翠，下午打卡三峡大瀑布，穿瀑体验超级刺激。宜昌的最后一天，欣赏了震撼的大国工程—两坝一峡。

告别宜昌，我们又去恩施玩了两天：第一天逛了恩施大峡谷，为了照顾爸妈的体力只走了地缝，两边岩壁直直的，还有小瀑布，看着就像原神稻妻的无想仞狭间哈哈哈。第二天去腾龙洞，不愧是亚洲最大溶洞，洞顶高到看不见头，传说能装1000万人，里面的表演也超好看。

这次湖北之行开了两千多公里，回去直接累趴，在家躺了一天才缓过来。

4）桂林｜8月部门团建：刚去了宜昌，隔一周部门又组织去桂林，首先去古东景区爬瀑布，算是一个比较新奇的体验。然后是漓江冠岩，溶洞灯光土得像KTV，10分钟就想溜。漓江竹筏赶上雨天，漓江水浑得不行，让我对此次旅程有点失望。

5）武功山｜9月首次高强度徒步挑战：之前高温假的时候，我已经正穿过一次武功山，而9月，朋友又拉着我去武功山反穿，这也是我的第一次高强度户外徒步挑战。全程爬了整整12个小时，累到怀疑人生，中途无数次想放弃，但当登上山顶，看到连绵起伏的绿色草甸，吹着山间的风，所有的疲惫都烟消云散，那一刻，觉得所有的坚持都值得。

6）佛山、深圳｜9月第二次出差，解锁岭南风味：又是一次突击出差，9月这次来到了祖国的南方，和同学一起逛了佛山的清辉园、渔人码头。然后去了一趟深圳，不仅吃了正宗的广式早茶，粥底火锅、仙庙烧鸡、桑拿鸡，每一样都让人回味无穷，最后还去深圳湾逛了一圈，吹着海风，放松身心，这趟出差，也算吃喝玩乐两不误。

7）天堂在左，雨崩在右 | 国庆徒步之旅：作为一名户外新手，今年国庆被同事“拐”去雨崩，5 天 4 夜的行程，尼农+冰湖+神瀑，一共徒步了50公里，有高反的狼狈、徒步的极限，也有星空下的青旅和冰瀑前的震撼。

8）三清山-10月特种兵一日游，速通大环线：周末朋友拉着去三清山徒步，走的大环线，本来想着预计花两天慢慢爬，整体难度不高，结果我们 6 小时就把大环线刷完了，为了节省时间下山就扛着火车跑回湖南了哈哈哈，纯爬山。

9）白鹤洲｜12月年底观鸟之旅，解锁新体验：年底的时候，鄱阳湖白鹤洲观鸟在小红书上特别火，我也跟着凑了个热闹，拉着朋友一起，开启了一场“高雅”的观鸟之旅。观鸟还是得带专业设备，在场都是超长的”炮筒“，我一个小手机完全拍不清，还在白鹤洲上还给我冻得不轻哈哈哈哈。

2025年去了不少地方，比如美丽的雨崩，艰难的武功山，冻死人的白鹤洲，速通的三清山，还有许多没来得及去的地方，2026年想进一步解锁，比如南太行、麦理浩径，峨眉山、黄山。。。这么多美丽的河山还等着我去探索。

五、工作：慢慢沉淀成长#

今年是我转正后的第二年，已经正式开始主管项目。由于上半年在原部门工作、下半年调整部门，全年仅主管了3个项目，同时参与了多个不同系列的电机设计项目，在实践中慢慢沉淀、逐步成长，也清晰认识到自身的优势与不足，收获满满。

六、全年回望与2026期许#

2025年这一年，过得挺充实，也挺有意义。工作上，从跟着别人做项目，到自己独立管项目，慢慢成长，专业能力也在提升；生活上，简单又自在，提了车、解锁了新生活，运动和旅游填满了业余时间，游戏也玩得开心，整体收获满满。

2026年，希望生活上顺顺利利，坚持运动减体重，多爬几座山、多去几个地方，慢慢变好，不辜负美好时光。

二、开局即 “波折”#

元旦假期的明月山人气爆棚！中午 12 点多赶到景区，停车场入口早已堵成长龙，广播循环播报 “车位已满”。无奈之下，我们只能把车停在景区外临时停车场，顶着零度寒风步行 1 公里冲向游客中心。

刚出发就瞥见山顶雾凇皑皑，没做攻略的特种兵式爬山，竟撞上这般美景，幸运值直接拉满。谁知才爬 2000 级台阶，就被半山腰工作人员拦下 —— 因云谷深处路段结冰，景区禁止步行登山，只能缆车上山且中站不下客。我们和其他游客软磨硬泡，最终录下自愿担责的免责视频，才得以继续进山。

三、爬山初体验#

元旦穿了加绒冲锋衣配秋衣，本以为山里天寒，结果爬山不到二十分钟就浑身发热，后背的汗把衣服浸得透湿。赶到第一个休息平台，我赶紧扒掉加绒内衬，脱衣瞬间，身上的热气撞上冷空气，都开始冒白烟了。

刚收拾好衣服抬头望，瞬间被惊艳到 —— 远处山峰裹着厚厚一层雾凇，阳光穿透云层洒下来，冰棱折射出细碎的光，宛如闯进了童话仙境。此前只在图片里见过雾凇，亲眼所见时，连呼吸都不自觉放轻，生怕惊扰了这片如梦似幻的景致。

四、6381 级台阶#

明月山的登山道全是石阶，全程大概 7000 级，我们最终爬到山顶走了 6381 级，每一步都算数（也都累到算数）！后来才知道，其实明月山有三条路线可选，大家可以按需选择：

• 懒人轻松线（4-5h）：景区大门→观光车（10 元）→缆车上行（80 元）→山顶观光车（15 元）→青云栈道→月亮湖→缆车下行（70 元），全程几乎不用爬，适合家庭和怕累星人，3100 米悬空栈道 + 云海直接打卡。
• 经典徒步线（6-7h）：景区大门→徒步至五叠泉瀑布群（2h）→缆车中站→登顶→青云栈道→返程，能看 119 米云谷飞瀑 + 鱼鳞瀑，层峦叠嶂超治愈，我们走的就是这个路线。
• 硬核穿越线（2 天 1 夜）：明月山→高山小火车（30 元）→羊狮慕→徒步栈道→宿山顶帐篷，能解锁日出星空 + 两景区秘境，户外爱好者可以冲。

我们走的就是经典徒步线的路段，登山初期的路段毫无压力。路面基本没有冰雪覆盖，石阶平整好走，沿途伴着小桥流水，偶尔还能看见山泉从冰缝里汩汩冒出来，清澈得能见底。

越往上走，石阶上的冰雪就越厚，原本轻松的散步模式直接切换成小心翼翼的防滑模式。景区很贴心，在结冰严重的地方铺了麦麸增加摩擦力，但每一步还是得稳着来。行至鱼鳞铺时，因为一路暴走，大脑早就过载，眼镜片上蒙了厚厚一层雾气，眼前一片模糊。不过沿途总能看到工作人员拿着铲子扫雪除冰，零下几度的天气里，真的要给这群守护者狠狠点个赞！

再往后的路段，石阶上的冰雪已经积得有些厚了，只能亦步亦趋慢慢挪。朋友兴致勃勃地想帮我拍张雪地登山照，催着我笑一个，可我累得连嘴角都扯不动，完全笑不出来。

五、登顶：云海 雪山 蓝天#

从山脚到山顶，我们足足走了 3 小时。快到山顶时，余光瞥见缆车从头顶掠过，抬头望去，阳光穿透云雾，天空澄澈得像被水洗过一般，白雪覆盖的群山在阳光下泛着耀眼银光，之前积攒的疲惫瞬间烟消云散。

终于登顶虎背界，站在观景台的那一刻，才算真正读懂 “无限风光在险峰”：远处云海翻涌不息，近处雾凇洁白无瑕，更神奇的是能清晰看到冷空气被明月山阻隔的界限 —— 一边云雾缭绕如仙境，一边晴空万里见苍穹，这般震撼根本无法用语言形容！

山顶的风大得惊人，气温怕是降到了零下，没待多久，头发就结了一层白霜，用手一摸硬邦邦的。山顶还有个人工雪场，不少人在里面滑雪玩闹，可惜我们没带装备，不然真想下场体验一番，有计划来的朋友可别错过这个乐趣！

六、青云栈道 + 明月湖#

到了山顶，后面的路线就是围绕山顶绕一圈，小圈三四公里的样子，大圈就是往明月山庄走，途径青云栈道，最到到达明月湖，回到出发点，全场六七公里的样子。我们选择的是大圈路线。

青云栈道总长约 3 公里，悬在百米悬崖上，走在上面有种 “悬空” 的感觉，给我一种三清山的栈道的即视感。栈道旁的悬崖上挂满了冰挂，脚下是翻滚的云海，偶尔有风吹过，云雾流动的速度肉眼可见，仿佛在仙境中漫步。

从栈道走出来，就能看到山顶的明月湖，高山湖泊超静谧，我们去的时候刚好是晴天，湖面倒映着蓝天白云和雪山，随手一拍都是壁纸级别的照片。

七、下山 “噩梦”#

快乐总是转瞬即逝，下午 5 点赶到索道上站准备下山，一进候车室直接傻眼 —— 小小的空间里挤得水泄不通。

元旦的山里天黑得格外快，气温也越来越低。之前把棉内衬脱了，排队时人挤人根本没空间穿，我们只能在队伍里冻得瑟瑟发抖，靠原地跺脚勉强取暖。

熬到 7 点半终于坐上缆车时，天已经彻底黑透了。下了缆车还得步行 1 公里回停车场，坐进车里的那一刻，全身骨头都在抗议，双腿软得站都站不稳。

八、万载攻略#

5. 万载美食#

（1）花园汤包店#

鱼包哥强推的花园汤包店，真没踩坑！这老店的汤包绝了，皮薄薄的，咬开一口汤汁直接飙出来，肉馅鲜得很，一点不腻。我们一人狂炫两屉，再配一碗本地炒粉，扎粉炒得油滋滋的，酱香十足，嗦起来贼过瘾，最后吃得扶墙出，肚子圆滚滚的才罢休。

（2）百岁我家酸菜鱼#

晚餐冲了百岁我家酸菜鱼，黑鱼是现杀的，片得薄薄的，吃起来又鲜又筋道。牛蹄也炖得烂乎乎的，一抿就脱骨，酸笋贼下饭，凤爪滑溜溜的吸满了汤汁，味道都挺顶。就是这辣度太猛了，辣到头皮发麻（此处无图）。

总结#

这趟元旦之旅，真的把 “惊喜” 拉满了 —— 本来只是冲着朋友的邀请去看烟花，没想到被明星和烟花双重圈粉，还意外解锁了明月山的冬日仙境。有时候旅行的意义，不在于计划多完美，而在于这些不期而遇的美好和波折。

二、WordPress 安装：两种主流方式，按需选择#

（一）Docker 安装：适合技术用户，环境隔离不冲突#

我自己的博客就是用 Docker 搭的，优点是环境隔离，不会和服务器上其他软件冲突，迁移也方便。

1. 准备工作#

先创建一个专属目录，我习惯放在～/docker/wordpress，统一管理配置和数据：

1
work=~/docker/wordpress && mkdir -p $work && cd $work

然后开放端口，我选的是 18080，避免和其他服务冲突，防火墙命令安排上：

1
# Ubuntu/Debian用ufw防火墙
2
sudo ufw allow 18080/tcp comment 'WordPress' && sudo ufw reload
3

4
# CentOS用firewalld
5
# sudo firewall-cmd --add-port=18080/tcp --permanent && sudo firewall-cmd --reload

2. 编写 docker-compose.yml#

新建 docker-compose.yml 文件，直接复制下面的配置，注意两个坑：

• 如果你用的是 arm 架构的服务器，把mysql:5.7改成mysql:oracle，不然会报错；
• 数据库密码和用户密码一定要改复杂点，别用默认的，我这里只是示例。

1
---
2
version: '3.0'
3

4
services:
5
  db:
6
    image: mysql:5.7 # arm架构的机器请将mysql:5.7改为mysql:oracle
7
    container_name: wordpress-db
8
    restart: unless-stopped
9
    # command: --max-binlog-size=200M --expire-logs-days=2 # 使用mysql 8.0的小伙伴建议使用
10
    environment:
11
      MYSQL_ROOT_PASSWORD: rootpassword # 按需修改
12
      MYSQL_DATABASE: wordpress
13
      MYSQL_USER: wordpress
14
      MYSQL_PASSWORD: yourpassword # 按需修改
15
    volumes:
16
      - './db:/var/lib/mysql'
17
    networks:
18
      - default
19

20
  app:
21
    image: wordpress:latest
22
    container_name: wordpress-app
23
    restart: unless-stopped
24
    ports:
25
      - 18080:80  # 按需修改。与防火墙开放端口一致。
26
    environment:
27
      WORDPRESS_DB_HOST: db
28
      WORDPRESS_DB_NAME: wordpress
29
      WORDPRESS_DB_USER: wordpress
30
      WORDPRESS_DB_PASSWORD: yourpassword # 按需修改
31
    volumes:
32
      - './app:/var/www/html'
33
    links:
34
      - db:db
35
    depends_on:
36
      - redis
37
      - db
38
    networks:
39
      - default
40

41
  redis:
42
    image: redis:alpine
43
    container_name: wordpress-redis
44
    restart: unless-stopped
45
    volumes:
46
      - ./redis-data:/data
47
    networks:
48
      - default
49

50
networks:
51
  default:
52
    name: wordpress

展开收起

3. 启动服务，完成初始化#

配置文件写完，直接后台启动就行：

1
# 开启服务
2
cd $work && docker-compose up -d

启动后用docker ps看看状态，只要 db、app、redis 三个容器都是 Up，就说明成功了。接下来访问http://服务器IP:18080，就能进入 WordPress 安装向导：

• 选择简体中文；
• 填写数据库信息（和 docker-compose.yml 里的一致）；
• 设置博客标题、管理员账号密码，完成安装。

最后可以用 Nginx 或 NPM 做反向代理，绑定域名yournewdomain.com并配置 HTTPS，我之前用宝塔面板配置的，步骤很简单，新建站点，反向代理到 127.0.0.1<18080> 就行。

设置完成后直接登陆：https://yournewdomain.com

（二）宝塔一键安装：新手首选，10 分钟搞定#

如果不想折腾 Docker，宝塔面板的一键安装绝对是新手福音，不用写配置文件，点点鼠标就好。

1. 准备工作#

先在服务器上安装宝塔面板，然后登录面板，安装 PHP（推荐 7.4 或 8.0 版本）、MySQL、Nginx 这些环境，面板会自动安装，不用手动操作。

宝塔中集成了不少网站部署的一键脚本，只需要进行简单的设置，就可以完成复杂网页的部署，比如 wordpress 个人博客、discuz 论坛等。

2. 一键部署 WordPress#

1. 点击左侧 “网站”→“添加站点”，输入你的域名，选择 “一键部署”；
2. 在模板里选择 “WordPress”，设置数据库账号密码（自动生成也可以，记得保存好）；
3. 点击 “提交”，宝塔会自动下载 WordPress 源码、创建数据库，全程不用管；
4. 部署完成后，访问你的域名，就能进入安装向导，和 Docker 安装的后续步骤一样。

完成配置后，点击提交，过一会就会自动拉取 wordpress 源代码进行部署，通过点击弹窗中的访问站点即可访问网站服务。

访问网址进入 wordpress 网站页面，开始 wordpress 的初始化配置，选择语言为简体中文

点击继续，下一步进行数据库绑定，将网站创建中一起创建的数据库名、用户名和密码填入栏中，其他的保持默认就行，点击提交。

完成数据库配置，进入网站信息设置页面，标题、用户名、密码、电子邮箱等信息自行修改，然后点击安装 Wordpress 进行部署。

完成部署后，通过上一步自己设置的用户名和密码就可以登录服务器后台，假设博客地址为 https://yournewdomain.com，博客后台的登录网址为 https://yournewdomain.com/wp-admin。

登录后，进入 WordPress 后台界面，如图所示。

搭建成功，可以自定义自己的模块、插件、等等配置了。

宝塔的好处是自动配置了 Nginx 反向代理和 HTTPS，不用自己动手，后期管理文件、数据库也方便，适合不懂技术的新手。

三、WordPress 迁移：四种方法，覆盖不同场景#

博客用久了，难免会遇到换服务器、换域名的情况，迁移就成了刚需。我试过几种迁移方法，各有优劣，大家根据自己的情况选。

2. 宝塔面板迁移：新手友好，可视化操作#

如果用的是宝塔面板，迁移也很简单，还支持定时备份到云存储，比如腾讯云 COS、阿里云 OSS，异地备份更安全。

1. 定时备份（推荐提前设置）#

1. 点击左侧 “计划任务”→“添加任务”，选择 “网站备份”；
2. 选择要备份的网站和数据库，备份周期选每月一次（或每周），远程存储选腾讯云 COS（我用的这个，稳定）；
3. 填写 COS 的 AccessKey、SecretKey、存储桶，保存后就会自动备份，还能保留 3 份历史备份，不怕备份文件丢失。

我同时备份wordpress的目录和数据库，每月执行一次，备份到腾讯云COS，保留3份。

如下图所示，目录和数据库分别备份到相应的文件夹。

2. 还原迁移#

如果你需要还原站点了，使用宝塔面板比较简单，分两步就行了，上传数据库和导入数据库文件即可。

导入数据库#

首先在宝塔面板选择添加数据库，完成命名和密码设置，点击导入备份，从本地上传之前备份的压缩包，导入后就会显示在下方，这样并没有完成，还要点击导入，才会实现解压压缩包数据，完成对新数据库的覆盖，这样就完成数据库的还原了，还是非常简单的。

上传站点文件#

接下来就是上传站点文件，首先通过宝塔面板创建一个新的PHP站点。填入你的站点域名和目录。

来到站点目录，删除默认创建的站点文件，将之前备份的站点压缩包文件上传。

解压到网站目录

将解压的文件移动到站点目录里，这样就完成了站点文件迁移。

注意事项#

修改配置文件#

不过这样还没完成配置，还要更改下博客的数据库和站点配置文件。因为数据库我们是重新创建的，名字和密码可能会不一样（你也可以设置成一样的），所以需要重新配置。

打开目录下解压的wp-config.php的文件，修改这一段代码

1
define( 'DB_NAME', 'yourdbname' );  #修改成你的数据库名字
2

3
/** Database username */
4
define( 'DB_USER', 'yourdbname' );  #修改成你的数据库用户名字
5

6
/** Database password */
7
define( 'DB_PASSWORD', 'yourdbpassword' );  #修改成你的数据库密码
8

9
/** Database hostname */
10
define( 'DB_HOST', 'localhost' );
11

12
/** Database charset to use in creating database tables. */
13
define( 'DB_CHARSET', 'utf8mb4' );
14

15
/** The database collate type. Don't change this if in doubt. */
16
define( 'DB_COLLATE', '' );

展开收起

注意你迁移前后的博客域名注意要一致，否则会无法访问站点，这就是wordpress的痛点了，他要求只能通过一个站点域名访问wordpress站点，如果不一样，就要在配置文件里修改一下。在wp-config.php文件最后加上这一段代码。

1
define('WP_HOME', 'http://yournewdomain.com');    #修改成你的站点域名
2
define('WP_SITEURL', 'http://yournewdomain.com');  #修改成你的站点域名

修改站点地址#

完成这样后，就可以访问你迁移后的wordpress站点了。不过这样简单的修改域名只是让你可以访问站点，还存在一些问题，毕竟WordPress更换域名不是简单把DNS改一下那么轻松，它涉及数据库、缓存、搜索引擎设置、重定向等多个层面。

进入站点后，进入后台的：设置 > 常规 > WordPress地址(URL) & 站点地址(URL)

确保这两个都改为新域名，点击保存后网站会立即跳转。

批量替换数据库中的旧域名#

Better Search Replace 是一个可以对WordPress数据库进行搜索和替换的插件，比如你网站更换域名，或者你需要一次性更换邮箱设置（可能在不同的选项都用到了这个邮箱），等等，通过 Better Search Replace 插件就可以非常方便地实现。

可以在后台 插件 -> 安装插件 界面，搜索 Better Search Replace 进行在线安装，或者到这里下载 Better Search Replace 后手动安装插件。

启用插件以后，就可以在 工具 – Better Search Replace 进入插件界面。

假设原来网址为 http://localhost，线上的网址为 http://yournewdomain.com ，那我们就可以按照下面的步骤操作。

1. 先备份下你的数据库
2. 在 搜索 字段，输入你要查找的内容，这里输入 http://localhost
3. 在 替换为 字段，输入 http://yournewdomain.com
4. 选择数据库表，全选所有数据表
5. 要真正替换数据，就取消“作为尝试运行”那个选项
6. 点击“运行搜索/替换”按钮就开始执行了

如果在运行过程中，提示执行方面的错误，可以尝试切换到下图的设置标签，减少“最大页面大小”的值，保存后再去试试。

这样就完成wordpress站点的迁移了。

1
 services:
2
  db:
3
    ...
4
    volumes:
5
      - './db:/var/lib/mysql'
6
    ...
7
  app:
8
    ...
9
    volumes:
10
      - './app:/var/www/html'
11
    ...
12
  redis:
13
    ...
14
    volumes:
15
      - ./redis-data:/data
16
    ...

4.使用插件迁移#

如果既不用 Docker 也不用宝塔，用插件迁移是最方便的，我推荐 WPvivid Backup，免费功能完全够用，还支持远程存储。

1. 安装插件#

在 WordPress 后台 “插件”→“安装插件”，搜索 “WPvivid Backup”，安装并启用。

2. 备份原站点#

1. 点击左侧 “WPvivid Backup”→“备份与恢复”，选择 “数据库 + 文件”，点击 “立即备份”；
2. 备份完成后，点击 “下载” 把备份文件保存到本地，或者配置远程存储，自动上传备份文件。

计划#

勾选“启用备份计划”，时间为“每天”，文件选择“数据库+文件(WordPress文件)”，保存修改即可。

建议将备份文件发送到远程存储，步骤见下方“远程存储”设置。

远程存储#

远程存储是重点，也是一定要配置的功能！

WPvivid支持使用 Google Drive 、Dropbox 、oneDrive 、Amazon S3 、DigitalOcean Spaces 、 FTP 等方式配置远程存储。

前几种网盘国内的网络都无法访问或者不太稳定，这里推荐自己搭建FTP进行远程存储。

配置远程存储成功后，点击上方“计划”，勾选“启用备份计划”与“发送文件到远程存储”；点击“设置”，勾选“上传到远程存储后，将备份存储在本机”，保存修改即可。

3. 恢复新站点#

1. 在新服务器上搭建好空白的 WordPress（用 Docker 或宝塔都可以）；
2. 同样安装 WPvivid Backup 插件，点击 “备份与恢复”→“上传”，上传之前备份的文件；
3. 点击 “还原”，等待还原完成，新站点就和原站点一模一样了，包括账号密码、主题插件。

这种方法适合新手，不用操作服务器文件，全程在 WordPress 后台完成，缺点是备份文件大的话，上传下载比较慢。

四、WordPress 插件推荐#

安装好 WordPress 后，这些插件一定要装，能提升博客功能和体验：

1. Akismet Anti-Spam：反垃圾评论神器，能自动拦截大部分垃圾评论，不用手动删除；
2. WP Mail SMTP：解决 WordPress 默认邮件发送失败的问题，配置 SMTP 后，评论通知、密码找回邮件都能正常发送；
3. WP Statistics：网站访问统计，能看到访问量、访客来源、热门文章，比第三方统计工具更隐私；
4. Better Search Replace：批量替换数据库内容，换域名、改网站标题都能用；
5. Simple Local Avatars：自定义用户头像，不用依赖 Gravatar，国内访问更快；
6. WP Githuber MD：Markdown 编辑器，写技术博客必备，支持代码高亮、数学公式；
7. Redis Object Cache：Redis 缓存插件，和我们 Docker 配置里的 Redis 配合，能大幅提升博客加载速度。

五、总结#

• 新手入门：优先选宝塔一键安装，简单快捷，后期管理方便；
• 技术用户：选 Docker 安装，环境隔离，迁移方便，适合长期维护；
• 迁移场景：Docker 用户用目录备份迁移，新手用宝塔用户用面板备份，按需选择。

WordPress 搭建和迁移看着复杂，其实实操一遍就会了，我第一次迁移的时候折腾了半天，现在换服务器半小时就能搞定。如果大家在操作过程中遇到问题，比如 Docker 启动失败、迁移后链接失效，可以留言问我，我会尽量帮忙解答～

参考#

1. 如何更换WordPress网站域名 – WordPress大学
2. Docker系列 WordPress系列 搭建WordPress个人博客 - Bensz
3. (19 封私信 / 81 条消息) 零基础WordPress建站教程：WP安装、主题插件、SEO一网打尽 - 知乎

二、准备工作#

Kuma的部署门槛极低，只要服务器能跑Docker，基本零障碍。先确认以下3个条件：：

• 已安装 Docker 和 Docker Compose
• 有公网 IP（或本地服务器用于测试）
• 开放目标端口（默认 13001，可自定义）

为了方便后续管理配置和数据备份，建议创建独立工作目录（我习惯把工具都放~/opt目录下，统一管理）：

1
cd ~
2
mkdir -p ~/opt/uptime-kuma
3
cd ~/opt/uptime-kuma

接下来开放端口，这里分两种场景，根据你的服务器防火墙类型选：

1
# 场景1：用ufw防火墙（Ubuntu/Debian），开放13001端口
2
sudo ufw allow 13001/tcp comment 'Uptime Kuma监控服务' && sudo ufw reload
3

4
# 场景2：用firewalld防火墙（CentOS/RHEL）
5
sudo firewall-cmd --add-port=13001/tcp --permanent && sudo firewall-cmd --reload

注意：如果是云服务器（阿里云/腾讯云），还要在控制台的“安全组”里开放13001端口，否则外部无法访问。

三、Docker Compose部署#

Uptime Kuma的Docker配置极其简洁，核心就是“镜像+数据卷+端口映射”。

在~/opt/uptime-kuma目录下新建docker-compose.yml文件，直接复制以下配置：

1
version: '3.3'
2

3
services:
4
  uptime-kuma:
5
    # 推荐用镜像源，拉取速度快（国外服务器可换louislam/uptime-kuma:2）
6
    image: docker2.leitool.top/louislam/uptime-kuma:2
7
    restart: unless-stopped  # 异常自动重启，保障服务稳定
8
    volumes:
9
      # 数据持久化：将容器内数据映射到宿主机，删除容器也不丢数据
10
      - ./data:/app/data
11
    ports:
12
      # 主机端口:容器端口（容器内默认3001，主机端口可自定义）
13
      - "13001:3001"

配置完成后，执行启动命令，Docker会自动拉取镜像并创建容器：

1
# 后台启动服务（-d表示 detached 模式）
2
docker-compose up -d
3

4
# 查看容器运行状态（出现Up说明启动成功）
5
docker ps
6
# 若启动失败，查看日志排查问题
7
docker-compose logs -f

使用 docker ps 命令检查容器是否创建成功。

四、首次配置：监控项添加#

4.1 配置引导#

打开浏览器访问“服务器IP<13001>”，就能进入Uptime Kuma的安装引导页面，全程可视化操作，非常简单。

Uptime Kuma 2.0版本最大的升级就是支持MariaDB数据库，对比旧版本的SQLite，两者区别很明显，根据需求选。

创建管理员账号：数据库配置后，设置用户名和密码（建议密码包含大小写+数字，避免被暴力破解），点击“Create”完成初始化：

自动跳转进入 Uptime Kuma 仪盘表

4.2 监控项配置#

1. 添加第一个监控项：进入仪表盘后，点击右上角“+ Add Monitor”，重点配置这几个参数： Monitor Type：选“HTTP(s)”（监控网站用这个）；
2. 显示名称：自定义名称（比如“我的个人博客”）；
3. URL：填写网站完整地址（如https://blog.example.com）；
4. Heartbeat Interval：心跳间隔，默认60秒，我建议改成180秒（减少误报，也能降低服务器请求压力）；
5. Max Retries：重试次数，默认3次，保留即可。

4.3 通知方式：宕机报警#

监控的核心是“出问题能及时知道”，Uptime Kuma支持30+通知方式，我推荐使用SMTP邮件（通用）：填写邮箱SMTP服务器信息（比如QQ邮箱用smtp.qq.com，端口465），测试成功后，网站宕机就会收到邮件提醒：

五、状态页面#

正常监控时的响应状态可视化：

状态页面可以把所有监控项整理成一个公开页面，方便访客查看网站状态（比如“status.example.com”）。创建步骤：

1. 点击左侧“Status Pages”→“+ Add Status Page”；
2. 设置页面名称、URL路径（比如“website”，访问地址就是Istatus.example.com/websit）；
3. 保存后就能通过链接访问状态页面了。

我配置的状态页面长这样，能自定义展示顺序和分组：

六、反向代理#

直接通过IP:端口访问不够美观，且缺乏 HTTPS 安全层。我们可以用 Nginx（或 Caddy、Apache）做反向代理，绑定域名并配置 SSL。

与其他 Web 应用程序不同，Uptime Kuma 基于 WebSocket。您需要另外两个标头**“Upgrade”和“Connection”**才能反向代理 WebSocket。

请阅读 wiki 了解更多信息：https://github.com/louislam/uptime-kuma/wiki/Reverse-Proxy

先在域名解析平台（如阿里云、Cloudflare）将域名（如umami.example.com）解析到服务器 IP。

1
  location / {
2
    proxy_set_header   X-Real-IP $remote_addr;
3
    proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
4
    proxy_set_header   Host $host;
5
    proxy_pass         http://localhost:3001/;
6
    proxy_http_version 1.1;
7
    proxy_set_header   Upgrade $http_upgrade;
8
    proxy_set_header   Connection "upgrade";
9
  }

6.3 群晖NAS#

如果把Kuma部署在群晖NAS上，用系统自带的反向代理即可：

1. 打开群晖“控制面板”→“登录门户”→“高级”→“反向代理”；

2. 点击“新增”，填写来源（域名、端口443）和目标（群晖本地IP、端口13001）：

   

3. 切换到“自定义标题”，点击“创建”→选择“Websockets”，自动填充所需头信息：

这样就可以通过域名访问Uptime-kumaf服务了。

七、腾讯云EdgeOne配置#

我把Kuma部署在内网群晖里，没有公网IPv4，所以用腾讯云EdgeOne实现IPv6转IPv4，让纯IPv4环境也能访问，步骤如下：

1. IPv6域名解析：用DDNS-go工具，将域名（如kuma.example.com）解析到群晖的本地IPv6地址。
2. EdgeOne配置：在腾讯云EdgeOne控制台，添加站点并选择“开启IPv6访问”，将加速域名指向刚才的IPv6域名；
3. 验证访问：通过EdgeOne分配的加速域名（如uptime.example.com），纯IPv4网络也能访问内网的Kuma服务了。

#八、小结

作为用了Uptime Robot 免费版2年的老用户，最近用上了Uptime kuma，部署轻量易上手，监控数据实时性和通知可靠性都经得起考验。

如果你有多个网站、服务器或API服务，花10分钟部署Uptime Kuma，就能彻底告别“被动发现故障”的尴尬。

参考#

1. Uptime Kuma的部署与简单使用-腾讯云开发者社区-腾讯云
2. Docker系列 Uptime Kuma监测网站连通性 - Bensz
3. Reverse Proxy · louislam/uptime-kuma Wiki
4. Home · louislam/uptime-kuma Wiki

准备工作#

chevereto部署门槛相较于之前介绍的软件要高一些，其实也没什么复杂的，就是提前把环境弄好，省得等下部署的时候手忙脚乱：

• 已安装 Docker 和 Docker Compose
• 有公网 IP（或本地服务器用于测试）
• 开放目标端口（默认 38080，可自定义）

然后是目录规划，我习惯把所有工具都放在～/opt 目录下，统一管理，找起来方便。这次也不例外，新建了 chevereto 的专属目录，还分了 database（存数据库）、storage（存图片）：

1
cd ~
2
mkdir -p ~/opt/chevereto
3
mkdir -p ~/opt/chevereto/database
4
mkdir -p ~/opt/chevereto/storage
5
cd ~/opt/chevereto

接下来要开放端口，我选的是 38080，避免和其他服务冲突。这里分两种场景，根据你的服务器防火墙类型选：

1
# 场景1：用ufw防火墙（Ubuntu/Debian），开放13001端口
2
sudo ufw allow 38080/tcp comment 'chevereto' && sudo ufw reload
3

4
# 场景2：用firewalld防火墙（CentOS/RHEL）
5
sudo firewall-cmd --add-port=38080/tcp --permanent && sudo firewall-cmd --reload

注意：如果是云服务器（阿里云/腾讯云），还要在控制台的“安全组”里开放38080端口，否则外部无法访问。

docker compose部署#

如果你使用的是付费版本Chevereto图床，需要自己下载付费版本的代码库，然后自己通过docker进行构建，因为我使用的是免费版本（直接在官网下载就行），如果你使用的付费版本可以参考一下官网上介绍的付费版的镜像构建Install Chevereto on Docker | Chevereto V4 Docs。

接着，在~/opt/chevereto文件夹中建立一个文件php.ini：

1
upload_max_filesize = 100M
2
post_max_size = 100M
3
memory_limit = 3072M
4
max_execution_tim = 180

接着，在~/opt/chevereto文件夹中建立一个文件docker-compose.yml：

1
services:
2
  database:
3
    image: docker.m.daocloud.io/mariadb:jammy
4
    networks:
5
      - chevereto
6
    volumes:
7
      - ./database:/var/lib/mysql:rw
8
    restart: always
9
    environment:
10
      MYSQL_ROOT_PASSWORD: password
11
      MYSQL_DATABASE: chevereto
12
      MYSQL_USER: chevereto
13
      MYSQL_PASSWORD: user_database_password
14

15
  php:
16
    image: chevereto/chevereto:latest # tweak with target image to run
17
    networks:
18
      - chevereto
19
    volumes:
20
      - ./storage:/var/www/html/images/:rw
21
      - ./storage/content:/var/www/html/content:rw
22
      - ./storage/routes:/var/www/html/app/routes:rw
23
      - ./storage/php.ini:/usr/local/etc/php/php.ini:ro
24
      # - app:/var/www/html/ # uncomment when using CHEVERETO_SERVICING=server
25
    restart: always
26
    depends_on:
27
      - database
28
    ports:
29
      - 38080:80
30
    environment:
31
      CHEVERETO_DB_HOST: database
32
      CHEVERETO_DB_USER: chevereto
33
      CHEVERETO_DB_PASS: user_database_password
34
      CHEVERETO_DB_PORT: 3306
35
      CHEVERETO_DB_NAME: chevereto
36
      CHEVERETO_HOSTNAME: chevereto.leiting2020.top
37
      CHEVERETO_HOSTNAME_PATH: /
38
      CHEVERETO_HTTPS: 0
39
      CHEVERETO_MAX_POST_SIZE: 2G
40
      CHEVERETO_MAX_UPLOAD_SIZE: 2G
41
      #CHEVERETO_SERVICING: server # uncomment to enable application filesystem upgrades
42

43
networks:
44
  chevereto:

配置完成后，执行启动命令，Docker会自动拉取镜像并创建容器：

1
# 后台启动服务（-d表示 detached 模式）
2
docker-compose up -d
3
# 查看容器运行状态（出现Up说明启动成功）
4
docker ps
5
# 若启动失败，查看日志排查问题
6
docker-compose logs -f

使用 docker ps 命令检查容器是否创建成功。

初始化chevereto#

我是把 Chevereto 部署在群晖 NAS 上的，直接用 IP<38080> 访问太丑了，还没 HTTPS，所以得整个反向代理。群晖用户直接在Web Staion里弄就行。

如果是其他系统可以通过NPM/nginx进行配置。将域名反向代理到docker compose.yml中配置的 CHEVERETO_HOSTNAME域名。

然后就是 EdgeOne 的配置，解决内网没有公网 IPv4 的问题。我用了 DDNS-go 工具，把域名解析到群晖的 IPv6 地址，然后在 EdgeOne 控制台添加站点，源站填解析好的 IPv6 域名，开启 IPv6 回源和 HTTPS 免费证书。这样一来，纯 IPv4 网络也能通过域名访问我的图床了，还能享受 EdgeOne 的加速和防护，关键是免费不限流量，还是挺香的。

完成相关配置后，访问你在docker compose.yml中配置的 CHEVERETO_HOSTNAME域名即可。会自动转到安装界面，会自动跳转到 Chevereto 的安装界面，一步步来就行：

自己填好相关信息就可以完成登陆了。直接登陆，后台就是这样：

登录后台后，第一件事就是把语言改成中文，在 Settings→Language 里选 Chinese (Simplified)，保存后页面就变成中文了，看着舒服多了。

到这里，我们就完成chevereto的安装了。

上传图片#

上传图片很简单，在任意界面都可以看到右上方有一个上传按钮，可以直接浏览本地图片进行上传。

Chevereto 的上传方式特别多，我最常用的是拖拽和剪贴板粘贴：

• 写博客的时候，直接把本地图片拖拽到图床页面，自动上传；
• 微信、QQ 截图后，按 Ctrl+V 就能直接粘贴上传，不用保存本地，太省时间了。

上传完成后，会自动弹出各种格式的链接，我写博客常用 Markdown 格式，直接复制粘贴到 Typora 里就行，不用再手动处理图片路径了。

双击图片还能查看详情，比如上传时间、大小、分辨率，还能生成不同尺寸的链接，功能挺全的。

小结#

用了一段时间，Chevereto 整体挺稳定的，没出什么幺蛾子。搭配 EdgeOne 之后，不仅不用花钱买存储和流量，还解决了公网访问的问题，写博客上传图片的效率也提高了不少。后续我打算研究一下把图片同步到腾讯云 COS 做双备份，这样更安全，到时候再写一篇记录。

如果你也经常写博客，或者需要存很多图片，不想被第三方图床限制，真心推荐试试这个组合，折腾一次，后续能省不少事。

参考#

1. Install Chevereto on Docker | Chevereto V4 Docs
2. (17 封私信 / 80 条消息) 使用Docker安装 Chevereto V4 搭建自己的图床 - 知乎
3. Docker系列 搭建个人图床chevereto - Bensz
4. docker系列 使用docker基于chevereto搭建属于自己的图床 - 无敌的个人博客
5. 调教Chevereto（三）——给Chevereto图床上全套腾讯云服务 – MikuBlog
6. 我的图床解决方案，超详细！ | 老胡的储物柜

准备工作#

在开始部署前，先确认你的服务器满足以下条件：

• 已安装 Docker 和 Docker Compose（如果未安装，可参考文末的补充命令）
• 有公网 IP（或本地服务器用于测试）
• 开放目标端口（默认 3000，可自定义）

为了方便管理 Umami 的配置和数据，我们先创建一个独立的工作目录：

1
cd ~
2
mkdir -p ~/opt/umami
3
cd ~/opt/umami

如果需要通过服务器 IP 直接访问（非反向代理场景），需开放端口（以 3000 为例）：

1
sudo ufw allow 3000/tcp comment 'umami' && sudo ufw reload

配置yml文件#

Umami 需要依赖数据库存储数据（支持 PostgreSQL 或 MySQL，这里以 PostgreSQL 为例），我们用 docker-compose 统一管理应用和数据库容器。

在~/opt/umami目录下，新建docker-compose.yml文件，将以下内容复制到文件中：

1
---
2
version: '3'
3
services:
4
umami:
5
  # 使用Umami官方最新镜像
6
  image: ghcr.io/umami-software/umami:latest
7
  # 端口映射（左侧为服务器端口，右侧为容器内端口，可自定义左侧）
8
  ports:
9
    - "3000:3000"
10
  environment:
11
    # 数据库连接地址（格式：数据库类型://用户名:密码@数据库容器名:端口/数据库名）
12
    DATABASE_URL: postgresql://umami:umamipassword@db:5432/umami
13
    # 数据库类型（postgresql或mysql）
14
    DATABASE_TYPE: postgresql
15
    # 用于加密数据的随机字符串
16
    HASH_SALT: your-random-string-here-123456
17
  # 依赖数据库容器，确保数据库先启动
18
  depends_on:
19
    - db
20
  # 自动重启
21
  restart: always
22
  networks:
23
    - default
24

25
db:
26
  # PostgreSQL镜像（15版本稳定，alpine版本体积更小）
27
  image: ghcr.io/postgres:15-alpine
28
  environment:
29
    # 数据库名（建议保持默认）
30
    POSTGRES_DB: umami
31
    # 数据库用户名（建议保持默认）
32
    POSTGRES_USER: umami
33
    # 数据库密码（按需修改）
34
    POSTGRES_PASSWORD: umamipassword
35
  volumes:
36
    # 映射数据目录到本地（确保数据持久化，重启容器不丢失）
37
    - ./data:/var/lib/postgresql/data
38
  restart: always
39
  networks:
40
    - default
41

42
networks:
43
default:
44
  # 自定义网络名称，避免与其他容器冲突
45
  name: umami

所有配置完成后，启动容器：

1
docker-compose up -d

启动成功后，可检查容器状态：

如果输出中app和db的状态都是Up，说明部署成功！

反向代理#

直接通过IP:端口访问不够美观，且缺乏 HTTPS 安全层。我们可以用 Nginx（或 Caddy、Apache）做反向代理，绑定域名并配置 SSL。

步骤 2：Nginx 反向代理配置#

在 Nginx 配置文件中添加以下内容。反代配置如下图所示：

1
server
2
{
3
    listen 80;
4
  listen 443 ssl http2;
5
    server_name umami.example.com;
6
    root /www/wwwroot/umami.example.com;
7
    if ($server_port !~ 443){
8
        rewrite ^(/.*)$ https://$host$1 permanent;
9
    }
10

11
    ####################
12
    # 其他配置
13
    ####################
14

15
    # 反代配置
16
    location ^~ /   {
17
    proxy_pass http://127.0.0.1:3000;
18
    proxy_set_header Host $host;
19
    proxy_set_header X-Real-IP $remote_addr;
20
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
21
    proxy_set_header X-Forwarded-Proto $scheme;
22
    proxy_set_header REMOTE-HOST $remote_addr;
23
    add_header X-Cache $upstream_cache_status;
24
    # 缓存
25
    add_header Cache-Control no-cache;
26
    expires 12h;
27
  }
28
}

展开收起

如果用宝塔面板，操作更简单：在 “网站” 中添加站点，绑定域名后，在 “反向代理” 中设置目标 URL 为http://127.0.0.1:3000即可：

步骤 3：首次登录：初始化设置#

访问你的域名（如https://umami.example.com），使用默认账号登录：

• 用户名：admin
• 密码：umami

重要！ 登录后第一件事：修改默认密码！进入 “设置”→“个人资料”，更新密码为强密码，避免被他人登录。

使用方法#

步骤 1：添加被统计网站#

进入后台，修改成简体中文后，添加一个网站：

步骤 2：获取跟踪代码#

添加网站后，点击网站右侧的 “编辑”→“跟踪代码”，复制生成的脚本：

1
<script defer src="http://umami.leiting2020.top/script.js" data-website-id="4c3c5b19-7a47-4dd6-ab0f-2542f91fa56a"></script>

步骤 3：安装跟踪代码到网站#

将跟踪代码添加到需要统计的网站中，具体位置因平台而异：

• WordPress：在 “外观”→“主题文件编辑器”→“header.php”，粘贴到<head>标签内
• Hexo：在主题的_config.yml中找到 “自定义脚本” 配置项进行配置即可
• 静态 HTML：直接粘贴到<head>标签内

以 WordPress 为例，添加位置如下：

对于本博客使用的Argon主题来说，在页头或者页尾脚本中，添加这一段跟踪代码即可， 添加后保存Argon设置即可生效。

为什么放<head>里？ 因为<head>是网页加载时优先解析的部分，能确保跟踪代码尽早执行，避免遗漏短时间访问（如用户刚打开页面就关闭）。

Umami 核心功能：能统计哪些数据？#

部署完成后，等待 10-30 分钟（数据有延迟），就能在后台看到详细统计了，核心数据包括：

• 访问概览：访问量（ visitors ）、浏览量（ pageviews ）、平均访问时长、跳出率
• 实时数据：当前在线人数、正在浏览的页面、访客 IP（匿名化）、设备信息
• 页面分析：各页面的访问次数、停留时间、入口 / 出口页面
• 访客分析：设备类型（手机 / 电脑 / 平板）、操作系统、浏览器
• 来源分析：访客从哪个网站 / 搜索引擎跳转而来（支持识别 Google、百度、必应等）
• 地理位置：访客所在国家 / 地区（基于 IP，非精确定位）

小结#

Umami 作为一款轻量、隐私友好的自建统计工具，完美平衡了功能与简洁性。通过本文的 Docker 部署教程，你可以在 10 分钟内搭建一套属于自己的网站分析系统，摆脱对第三方工具的依赖。

参考#

• umami-software/umami: Umami is a modern, privacy-focused alternative to Google Analytics.
• Umami Docker 部署及优化 · eallion’s Blog
• (12 封私信 / 80 条消息) 网站流量分析工具——Umami - 知乎
• Docker系列 通过umami监控网站流量 - Bensz

交通#

我们一行人从湖南株洲出发，实际用时一天，其他更远地方的游客可根据当地车次情况自行考虑一个周末的时间是否足够。

✅ 高铁：快是快，但就是交通费有点肉疼，占了总花费的大头

✅ 卧铺火车：想省点钱的朋友可选这个，能省一半多，穷游党冲

从上饶站下车后，可乘坐班车或者出租车前往三清山，我们下火车是晚上九点半了，这个时候班车已经停运了，只能选择网约车前往，费用为140元（120元+20元高速费），三人出行，均价40+/人，也不算贵，出租车会走一截高速，约1个多小时就能到达目的地，比班车节约很多时间。

路线规划#

三清山的地图如下图所示，一共有三处上山点，分别是金沙、外双溪以及港首。徒步上山必选外双溪，另外即使需要索道上山建议也选择外双溪，当天早上我们到达的时候（7点半）都没什么人，不用排队。而金沙那边旅游团特别多，人满为患。路线一共有三种，分别是小圈、中圈和大圈路线。

小圈（蓝线）：入门版体验小圈路线，也是人最多的路线，特别多的老年团走这条线，人满为患。从金沙索道上山→巨蟒栈道→神陀峰→巨蟒出山→东方女神→女神栈道→金沙索道下山，用时2-3小时，比较轻松，经过核心景点，适合带小孩和老人、时间紧张的家庭。

中圈（蓝线+橙线）：金沙索道上山→巨蟒栈道→神驼峰→巨蟒出山→东方女神→杜鹃谷→玉台→马头石→遥望主峰→玉女开怀→连升三级→生死恋→一线天→神龙戏松→东南沿海栈道→遥望天门群峰→遥望万寿园→金沙索道下山，用时4-5小时。

大圈（蓝线+橙线+红线）：外双溪索道上山→天门山庄→老道拜月→犀牛石→日上山庄→玉兔奔月→福寿门→禹皇顶→秀峰→三龙出海→巨蟒出山→东方女神→杜鹃谷→玉台→马头石→玉女开怀→遥望主峰→连升三级→生死恋→一线天→神龙戏松→摩崖石刻→万寿园→牛背石→蒲牢鸣天→彭祖祝寿→外双溪索道下山。用时5-6小时，适合徒步达人、追求全景的游客，最好带好干粮和登山杖。

如果想要走大环线，推荐从外双溪索道上下，外双溪索道人比较少，旺季都不会排队很久。这个索道附近的景色很美，一下索道就可以看到绝美群峰，最经典的巨蟒出山和女神峰，走到禹皇顶和西海岸、阳光海岸都可以看到，不必执著于金沙索道上下。体力好比较推荐从外双溪上下，走到三清宫往返全程大概五六个小时！

当时做路径规划的时候，考虑一天爬完，大环线全程也有16公里左右，而索道在下午五点就会关，为了防止夜晚下山的风险，选择了索道上下行。结果高估了整体登山的难度，很多人说外双溪费腿要爬山，实际就是索道出来后左拐走西海岸绕大圈，只有30分钟是爬山，剩下的全程都是平路或者下坡路。一点都不累，不要低估自己。

我们算是正常速度，从七点半开始爬，不到六个小时就完成了大环线同时还坐了索道下行。本来预留在山下住一晚的，结果一点多就到山下了，一看时间当天还能坐火车回湖南，就当天买票扛着火车回去了，也算是一次特种兵出行了。PS：如果当时没高估整体的难度，说不定还可以放弃索道上下行，徒步上山，如果采用步行估计用时2小时左右，下山约40分钟，那样更有挑战性一点，估计要多花3-4个小时，应该能在太阳下山前到达山下。

饮食住宿消费#

在美团上看外双溪游客中心那一块的民宿，便宜的民宿卫生条件比较差，都推荐希尔顿，但一个标间就要五六百，太贵了。所以选择住在离游客中心6公里远的一家民宿，一百多一晚上，加卫生条件还不错，民宿老板还提供往返游客中心的接送服务，性价比还不错。

登山过程需要的水和食物最好提前准备。因为我们是坐索道上下行，准备了一些能量胶和士力架、三明治和鸡蛋。整体的体力消耗不算很大，行前准备的能量胶和士力架都没派上用场。

我们早上在民宿老板家里吃的早饭，一碗粉15，虽然说贵了点，但是味道还不错。

中午在山上吃的，因为消耗不大，啃了点三明治和鸡蛋就够了。

因为下山时间比较早，所以晚餐直接选择回长沙吃了。PS：同行伙伴一直念叨着上饶的鸡腿好吃，我们一起在上饶站花15大洋买了个大鸡腿，结果踩了大雷，又辣又难吃，我还被迫在火车站花8块大洋买瓶牛奶来压住辣味。

天气与景观#

1. 必看的景点 & 天气​

• 核心景点：巨蟒出山、女神峰、禹皇顶、西海岸、阳光海岸，从外双溪索道走都能看到

• 最好选晴天去！我们去的时候天气好，能见度高，看山峰超震撼

• 不过有点小遗憾 —— 没碰到云雾绕山的 “仙山” 样子，想蹲云海的朋友可以提前看天气预报

  

1. 这些要注意

• 景区有些岔路口的指示牌不清不楚，我还走错了路，本来应该在玉台那穿过小卖铺网上走，结果没看到岔路，直接往下走了，绕了一大圈。。。在关键路口最好看一下高德地图，免得走冤枉路。

• 一线天那地方游客特别多，容易堵，尽量错峰过去

总结#

EasyTier简介#

在国内复杂的网络环境中，内网穿透和异地组网始终是个棘手问题。之前折腾过 Zerotier、Tailscale 等工具的朋友可能深有体会，网络通畅时，P2P 直连体验流畅。可一旦遇到 NAT 复杂或网络波动，就不得不依赖国外中继服务器 —— 延迟飙升、速度骤降几乎成了常态。

最近接触到了国内的一个开源穿透软件EasyTier ，EasyTier是一个简单、安全、去中心化的内网穿透 SD-WAN 方案，使用 Rust 语言实现。它实现了零拷贝和全链路高性能，性能与主流组网软件相当。EasyTier 支持跨平台运行，包括 MacOS/Linux/Windows/FreeBSD/Android，未来还将支持 iOS。可执行文件静态链接，部署简单。

EasyTier的特点#

• 去中心化：无需依赖中心化服务，节点平等且独立。
• 安全：支持利用 WireGuard 加密通信，也支持 AES-GCM 加密保护中转流量。
• 高性能：全链路零拷贝，性能与主流组网软件相当。
• 跨平台：支持 MacOS/Linux/Windows/FreeBSD/Android，未来将支持 iOS。
• 无公网 IP 组网：支持利用共享的公网节点组网。
• NAT 穿透：支持基于 UDP 的 NAT 穿透，在复杂的网络环境下也能建立稳定的连接。
• 子网代理（点对网）：节点可以将可访问的网段作为虚拟网暴露给其他节点，允许其他节点通过这些节点访问子网。
• 智能路由：根据流量智能选择链路，减少延迟，提高吞吐量。
• TCP 支持：在 UDP 受限的情况下，通过并发 TCP 链接提供可靠的数据传输，优化性能。
• 高可用性：支持多路径和在检测到高丢包率或网络错误时切换到健康路径。
• IPV6 支持：支持利用 IPV6 组网。

安装(docker-compose)#

1
sudo mkdir -p /opt/easytier

1
vim /opt/easytier/docker-compose.yml

1
services:
2
  # 可选：自动更新镜像的watchtower
3
  watchtower:
4
    image: containrrr/watchtower:latest
5
    container_name: easytier-watchtower
6
    restart: unless-stopped
7
    environment:
8
      - TZ=Asia/Shanghai
9
    volumes:
10
      - /var/run/docker.sock:/var/run/docker.sock
11
    command: --interval 3600 --cleanup --label-enable
12

13
  # easytier服务端
14
  easytier-server:
15
    image: easytier/easytier:latest  # 国内：m.daocloud.io/docker.io/easytier/easytier:latest
16
    container_name: easytier-server
17
    hostname: easytier-server  # 与配置文件中hostname一致
18
    labels:
19
      com.centurylinklabs.watchtower.enable: 'true'  # 允许watchtower更新
20
    restart: unless-stopped
21
    network_mode: host  # 必须用host模式，确保端口监听正常
22
    cap_add:
23
      - NET_ADMIN  # 允许网络配置（如创建tun设备）
24
      - NET_RAW
25
    environment:
26
      - TZ=Asia/Shanghai
27
    devices:
28
      - /dev/net/tun:/dev/net/tun  # 提供WireGuard隧道支持
29
    volumes:
30
      - /opt/easytier:/root  # 挂载配置目录到容器内/root
31
      - /etc/machine-id:/etc/machine-id:ro  # 保持机器标识一致
32
    command: --config-file /root/config.yaml  # 加载配置文件

1
# 服务端基础信息（唯一标识）
2
hostname = "easytier-server"  # 服务端主机名（自定义，需唯一）
3
instance_name = "primary-server"  # 实例名称（区分多个服务端）
4
instance_id = "f47ac10b-58cc-4372-a567-0e02b2c3d479"  # 标准UUID（必填，需唯一，生成方法见下方）
5
ipv4 = "10.126.126.1/24"  # 虚拟网络IP（建议用网段首个IP，如.1）
6
dhcp = false  # 服务端固定IP，关闭DHCP
7

8
# 监听端口（客户端通过这些端口连接）
9
listeners = [
10
    "tcp://0.0.0.0:11010",  # TCP协议监听（推荐客户端优先使用）
11
    "udp://0.0.0.0:11010",  # UDP协议监听
12
    "wg://0.0.0.0:11011"    # WireGuard加密协议监听（需tun设备支持）
13
]
14

15
# RPC端口（0表示随机分配，服务端无需固定）
16
rpc_portal = "0.0.0.0:0"
17

18
# 网络标识（客户端必须完全匹配才能加入网络）
19
[network_identity]
20
network_name = "my-easytier-network"  # 网络名称（自定义，如公司/项目名）
21
network_secret = "your-secure-secret-123"  # 网络密钥（类似密码，建议复杂字符串）
22

23
# 服务端无需配置[[peer]]（客户端会主动连接服务端）
24
# 若多服务端集群，可在此添加其他服务端的uri（如"tcp://server2-ip:11010"）

1
# 启动容器
2
docker-compose up -d
3
# 查看日志（确认启动成功）
4
docker logs -f easytier-server

1
# 开放TCP/UDP 11010和WireGuard 11011端口
2
sudo ufw allow 11010/tcp
3
sudo ufw allow 11010/udp
4
sudo ufw allow 11011/udp
5
sudo ufw reload
6
# 若用云服务器（如阿里云/腾讯云），需在安全组中同步开放上述端口

1
# 客户端基础信息（唯一标识）
2
hostname = "client-pc-01"  # 客户端主机名（自定义，需唯一）
3
instance_name = "office-client"  # 实例名称（区分多个客户端）
4
instance_id = "a1b2c3d4-5678-4f5e-8a9b-0c1d2e3f4a5b"  # 客户端唯一UUID（与服务端不同）
5
ipv4 = "10.126.126.2/24"  # 虚拟网络IP（与服务端同一网段，如.2、.3等）
6
dhcp = false  # 客户端固定IP
7

8
# 客户端无需开放监听（若需被其他节点主动连接，可添加监听端口）
9
listeners = []
10

11
# RPC端口（随机分配）
12
rpc_portal = "0.0.0.0:0"
13

14
# 网络标识（必须与服务端完全一致）
15
[network_identity]
16
network_name = "my-easytier-network"  # 与服务端network_name相同
17
network_secret = "your-secure-secret-123"  # 与服务端network_secret相同
18

19
# 需连接的服务端地址（至少填写服务端的TCP/UDP地址）
20
[[peer]]
21
uri = "tcp://服务端公网IP:11010"  # 替换为服务端的公网IP或域名
22

23
[[peer]]
24
uri = "udp://服务端公网IP:11010"  # 可选，提高连接稳定性

客户端验证#

日志中出现以下信息说明连接成功：

1
successfully connected to peer: tcp://服务端IP:11010
2
virtual network ip assigned: 10.126.126.2

测试虚拟网络通信，客户端执行ping 10.126.126.1（服务端虚拟 IP），能 ping 通则说明网络互通。

使用 easytier-cli peer 查看子网中的节点信息：

1
easytier-cli peer

输出示例：

使用 easytier-cli route 查看子网中的路由信息：

1
easytier-cli route

输出示例：

使用 easytier-cli node 查看本节点的信息：

1
easytier-cli node

输出示例：

这是windows下gui的配置情况

关闭转发#

默认情况下，Easytier 的每个节点都允许为其他虚拟网提供转发服务，即使已加入一个虚拟网。若需改变此行为，可通过 --relay-whitelist 参数限定可转发的网络白名单（空格分隔的通配符列表）。当列表为空时，则不会为所有其他网络提供转发服务。例如：

1
easytier-core --relay-whitelist relay-all --relay-all-peer-rpc

只需设置参考白名单为空，同时仅允许转发 RPC 流量即可。

小结#

用了一段时间了，从实际用下来的感受看，EasyTier 最关键的好处就是 ——特别适配咱们国内的网络环境。不管是面对复杂的 NAT 网络，穿透成功率，还是用 WireGuard 加密传输的速度和稳定性，都比那些依赖国外中继服务器的工具稳一些。

而且它是去中心化的 P2P 方案，不用怕单个服务器挂了整个网络就崩了，节点之间直接连接，还能最大程度减少延迟。另外它还支持多平台，不同设备组网特别方便。不管是个人异地办公、家里设备互联，还是小团队做内网穿透，都很合适。

感兴趣的小伙伴不妨来试试 EasyTier。

参考#

1. 快速组网 | EasyTier - 简单、安全、去中心化的异地组网方案

1、伪静态配置问题#

报错现象#

当我迁移完博客时，发现迁移后的博客首页可以访问，但是博客下面的文章，比如/archives/908/这样的链接就会报404错误。

如果我在wordpress固定链接里设置为朴素型链接，比如https://blog.leihub.cn/?p=123这样就没问题

在网上搜了一遍，初步推测是伪静态规则未正确配置 导致的。

因为朴素型链接（?p=123）是 WordPress 默认的「查询字符串形式」，本质是动态 URL。它的结构是 域名/index.php?p=123（浏览器会省略 index.php，直接显示 ?p=123）。服务器收到这种请求时，会默认将 ?p=123 作为参数传递给网站根目录的 index.php 处理（因为 URL 中包含 ? 符号，服务器知道这是动态参数，需要交给 PHP 解析）。所以无论有没有伪静态规则，服务器都能正确找到 index.php 并处理请求，因此不会报错。

因为 WordPress 的 数字型链接（如 /archives/908）属于自定义固定链接，这种格式是「静态化 URL」，服务器收到这种请求时，默认逻辑是：查找是否存在对应的物理文件或目录，但实际上，/archives/908 并不是真实的文件 / 目录，而是 WordPress 为了美观和 SEO 设计的「虚拟路径」，真正处理请求的还是 index.php。需要服务器通过重写规则（Rewrite）将请求转发到 index.php 处理，否则服务器会认为该链接对应的文件不存在，从而返回 「404 Not Found」错误。

解决方法#

解决方法就是按之前提到的步骤，为 Nginx 配置正确的 rewrite 规则，或为 Apache 配置正确的 .htaccess 文件，确保虚拟路径能被转发到 index.php。

Nginx#

因为我使用的是宝塔面板，可以直接使用宝塔的默认模板进行配置，相对简单一点。

手动配置 Nginx 的伪静态规则：

• 登录宝塔面板 → 左侧「网站」→ 找到你的 WordPress 站点，点击「设置」→「伪静态」。
• 在伪静态设置页面，下拉选择「WordPress」模板（宝塔已预设好规则），点击「保存」。

• 若没有「WordPress」模板，手动粘贴以下规则：

1
location / {
2
    try_files $uri $uri/ /index.php?$args;
3
}

• 保存后，重启 Nginx 服务（宝塔「软件商店」→ 找到 Nginx → 点击「重启」）。

设置好伪静态规则后，博客就可以正常访问了。

Apache#

因为我没用Apache，这里就简单贴一下网上描述的解决方法供大家参考。

Apache 依赖网站根目录下的 .htaccess 文件实现重写，若文件缺失或权限不足会导致 404：

• 宝塔面板 →「网站」→ 你的站点 →「文件」，进入网站根目录（如 /www/wwwroot/你的域名）。

• 确认是否存在.htaccess文件。

  • 若不存在：新建一个 .htaccess 文件，粘贴以下内容：

  • 1
    # BEGIN WordPress
    2
    <IfModule mod_rewrite.c>
    3
    RewriteEngine On
    4
    RewriteBase /
    5
    RewriteRule ^index\.php$ - [L]
    6
    RewriteCond %{REQUEST_FILENAME} !-f
    7
    RewriteCond %{REQUEST_FILENAME} !-d
    8
    RewriteRule . /index.php [L]
    9
    </IfModule>
    10
    # END WordPress

  • 若存在：检查内容是否与上面一致，不一致则替换。

  • 设置文件权限：右键 .htaccess →「权限」，设置为 644（所有者读写，其他只读），确保 Apache 能读取该文件。

  • 宝塔「软件商店」→ 找到 Apache → 点击「设置」→「模块」，检查 rewrite 模块是否已勾选（默认已启用，若未勾选则勾选后重启 Apache）。

目录#

1. Day1：株洲→香格里拉｜赶路 + 高反初体验
2. Day2：香格里拉→尼农→雨崩｜14 公里徒步 + 雨夜进山
3. Day3：雨崩冰湖线｜最累的 14 公里
4. Day4：雨崩神瀑线｜最轻松的 “公园级” 徒步
5. Day5：雨崩→株洲｜极限赶车日
6. 全程费用 + 新手必备清单

Day2：香格里拉→尼农→雨崩｜14 公里徒步 + 雨夜进山#

核心行程：香格里拉租车→金沙江打卡→梅里雪山售票→尼农徒步入口→下雨崩→上雨崩

早上 8 点在香格里拉打了个了皮卡上尼龙，把行李箱寄在司机家。

• 香格里拉→尼农：4 小时车程，会经过海拔 4200 米的垭口，我轻微高反（头晕）；中途会路过「金沙江大拐弯观景台」（免费），红军长征途经地，拍照超有意义，建议停留 10 分钟打卡；

  

• 梅里雪山门票：2025 年价格是 55 元 / 人，无需提前预约，但国庆人多，拍照别太久！我们因为在售票处沉迷拍雪山，让同行美女和司机等了 20 分钟，直接导致后续赶夜路；

  

• 尼农→下雨崩徒步：中午 12 点开始，14 公里山路 + 1000 米爬升，刚走 1 小时就下雨（国庆雨崩多雨！必带「防水徒步鞋 + 轻便雨衣」，登山杖能省 30% 体力）。

6 小时后，我们在晚上 6 点终于到下雨崩，又冷又累，随便吃了饭，再往上雨崩时，我体力彻底透支，选了当地皮卡代步（80 元 / 人，单程，晚上只有皮卡能走）。

住宿推荐：「德钦帕萨青旅」（床位 350 元 / 晚），新床位很干净，有公共客厅能烤火，我在雨崩 4 晚里，这晚睡得最香！提醒：刚到雨崩别洗澡，高反会加重，擦身即可。

Day3：雨崩冰湖线｜最累的 14 公里#

核心行程：上雨崩→冰湖观景台→大本营→绝望坡→冰湖→下撤

冰湖线是雨崩经典路线，来回 14 公里 + 800 米爬升，前一天下雨后，山路全是泥（穿「防水徒步鞋」！我看到有人穿运动鞋，鞋底全是泥，走一步滑一步）。作为 “娇弱男孩”，我走 50 米就要停，高反又犯了（头痛 + 喘气），靠「慢慢走」缓解。

• 观景台不是终点：爬 3个小时到冰湖观景台时，别以为快到了！后面还要下陡坡、再爬 “绝望坡” ，全是碎石，建议手脚并用，别抬头看，盯着脚下走）；

  

• 冰湖打卡：终于到冰湖时，我高反加重，只拍了 5 分钟就撤（冰湖海拔 3800 米）；

  

• 下撤选骡子：傍晚 4 点开始下撤，天快黑了，山路更滑，我实在走不动，在大本营租了骡子（555 元 / 人，单程，只能到上雨崩，国庆要排队，建议提前和向导说）。

避坑提醒：冰湖线到了大本营才有补给站，一定要带够水（2L）和干粮（巧克力、能量棒），别指望中途买东西！

Day5：雨崩→株洲｜极限赶车日#

核心行程：下雨崩→尼农（皮卡+步行）→香格里拉→昆明→长沙→株洲

为了保护膝盖，我选了 “皮卡到尼农半程 + 步行下撤”，结果踩了大坑：

• 等皮卡超久：早上 8 点去等皮卡，国庆人太多，半小时只走 20 人，最后被迫坐皮卡后备箱（超颠！同行不高反的朋友都被摇得头晕）；
• 行李寄存问题：之前把行李寄在司机家，到尼农时已经 1 点，司机还想等其他人，我们直接加价 150 元让他先走，又火急火燎让司机家人送行李到尼农；
• 赶车时间卡得死死的：尼农→香格里拉 4 小时，香格里拉→昆明火车 5 小时（无座），昆明→长沙飞机 2.5 小时，最后到株洲已经凌晨 3 点，累到倒头就睡。

赶车攻略：雨崩返程建议预留至少 2 小时缓冲时间，别像我们一样卡着点走，万一堵车就惨了！

🚗 交通攻略#

我们选的周末自驾，9 月 5 日周五下班就走，从株洲到武功山才一百多公里，两个小时就到了，比高铁还灵活。

​ 图：从株洲自驾到武功山的路上，俩小时就到～

因为反穿是从龙山村出发，而下山是下到正面的游客中心，所以我们是选择开车到武功山游客中心，车停在游客中心停车场，然后打车到龙山村。晚上住在龙山村的民宿，价格还算不错。

​ 图：住的龙山村民宿，主打一个便宜～

这是游玩路线，反穿不用买门票！只交 10 块钱卫生费就行，这波血赚

​ 图：我们走的反穿路线，10 块卫生费就能走，标好存图！

🛤️ 徒步全程：20 公里 12 小时#

1. 起点（6<10>）：龙山村→木马坳（开始就上强度）#

上来就是持续爬升！全是山路，没一丁点平路，龙山村（560m）到木马坳（1470m）快 1000 米海拔差。

​ 图：6 点 10 分从龙山村出发，一开始还挺兴奋～

我衣服直接湿透，谁懂啊！路上有人刚爬第一个山头就喊 “10 块钱的山爬够了”，当时还笑人家，爬完才知道人家多明智！

​ 图：爬木马坳的路，全是爬升，腿都在抖～

2. 缓冲段：木马坳→发云界（终于能喘口气）#

这段相对平坦，爬升强度低，能好好恢复体力，建议在这多歇会儿，后面更累。

草甸开始慢慢多起来，随手拍都好看，心情能缓和不少。

​ 图：木马坳到发云界的平路，终于不用一直爬了～

3. 折磨段：发云界→千丈岩（上上下下太搞心态）#

全是 “爬上又爬下”！刚费老劲登上一个山，马上要走下去，循环往复

唯一安慰：武功山的草甸太绝了，连绵一片，看着心情能好点，不然真的想放弃

​ 图：发云界到千丈岩的草甸，美是真的美，累也是真的累～

4. 错觉段：好汉坡（以为快结束？想多了）#

爬完好汉坡，我们还嘻嘻哈哈拍照，觉得 “也就这样”，结果后面才知道，这只是热身！

提醒：别在这浪费太多时间拍照，后面的绝望坡才是真 BOSS

​ 图：爬完好汉坡嘚瑟拍照，现在看太天真了～

5. BOSS 段：绝望坡（名字没骗人，真绝望）#

一堆人在坡下打卡，爬了才懂为啥叫 “绝望”：强度不算最高，但前面体力耗太多了

最搞心态的是：每次以为到顶了，前面又冒一个坡，来来回回两三次，我当时真想坐地上不走了

​ 图：绝望坡下面全是打卡的人，谁知道上去有多虐～

6. 休整段：绝望坡→观音宕（有厕所，能歇脚）#

这段整体平坦，有景区公共厕所，建议在这简单休息，补充点能量

很多人会在这扎帐篷，分两天爬的朋友可以在这住，第二天去金顶看日出

​ 图：观音宕的休息区，有厕所，能好好歇会儿

7. 冲刺前：观音宕→吊马桩（修整！补体力）#

吊马桩是大型休整平台，能在这吃晚饭，我们当时垫了点肚子的，吃完才有力气冲金顶

​ 图：吊马桩休整平台

8. 终段：吊马桩→金顶（最后 1 小时，咬咬牙！）#

还要 1 小时爬升，是对体能和心理的双重考验，当时全靠 “马上到顶” 的信念撑着

​ 图 金顶

9. 下撤：金顶→中庵索道（下撤超伤膝盖）#

到金顶时已经太晚了，金顶索道已经关门，只能去中庵索道，而且夜爬上山的人越来越多，下山只能一步一步挪。

全是台阶，超伤膝盖！我当时腿都软了，全靠扶着栏杆走，还好赶上了最后一班索道

​ 图：下撤的台阶

🍚 食宿#

1. 避坑！老萍巷莲花血鸭（游客中心旁）#

到达武功山游客中心的时候已经是晚上了，当时又累又饿不想再找其他店吃饭了，直接选择在游客中心旁边的老萍巷莲花血鸭吃，看到美团评论最多，好评也不少，然后就踩了个大坑，菜量又少又贵，几个人均价吃了100元/人，还没吃饱，大家可以避雷一下。

​ 图：就是这家老萍巷莲花血鸭，贵还不好吃

2. 推荐！200 元家庭套房#

劳累了一天，腿也软了，不敢开车回株洲，选择在武功山这边休息一个晚上。因为第一天没睡好，我们决定睡一个好一点的民宿，犒劳一下自己。这个民宿还不错，自驾游的朋友可以来着，住的200元一个的家庭套房，有两个一米八的大床，空间有40平，算是住过性价比比较高的民宿了。就是离游客中心有个两公里，得开车前往。

​ 图：住的家庭套房，200 块太值了

3. 必吃！8 号餐厅（花涧里游客中心）#

前一天随便找了个餐厅踩了雷，第二天特意选了个去年吃过的餐厅-8号餐厅，口味很不错，性价比也不错，直接给哥们几个吃撑了。这里比较推荐大家去吃，在武功山花溅里游客中心里。

​ 图：8 号餐厅

总结#

全程耗时#

早上 6 点出发，晚上 6 点多下撤，整整 12 小时，手表还没电了（只记录到观音宕），贴一个同行的伙伴的轨迹做参考。

一、为什么 WPVivid 还原会失败？#

在使用 WPVivid 还原时，“进度卡住”“插件 / 核心文件还原无响应”“数据库导入失败” 是最常见的问题。根据 WPVivid 官方论坛反馈及实战排查，核心原因集中在服务器配置不匹配和备份包处理逻辑冲突，具体包括：

• PHP 执行时间过短（默认 30 秒），无法处理大型备份文件（尤其超过 1GB 的包）
• 服务器内存不足（低于 128M），导致大文件解压 / 传输时中断
• 备份包体积超过服务器 “上传文件大小限制”（常见限制 200MB-500MB）
• 分卷备份包缺失（如 part002.zip 丢失）或备份文件损坏
• 服务器 PHP 版本过低（低于 7.4），与 WPVivid 新功能不兼容

提示：即使你之前用 WPVivid 成功还原过，也可能因 “服务器环境更新（如 PHP 版本升级）”“备份包体积增大（如新增大量图片）” 再次遇到问题。

二、还原前必做：3 项准备工作#

在开始还原操作前，先做好以下检查，可减少 80% 的失败概率：

1. 备份当前站点（关键！） 无论原站点是否能访问，先备份当前的数据库（用 phpMyAdmin 导出）和文件（用 FTP 下载 wp-content 目录），防止还原失误导致现有数据丢失。

2. 验证备份包完整性

   • 若为单文件备份：右键检查文件大小是否与备份时一致，避免下载中断导致文件损坏；
   • 若为分卷备份（如 part001.zip、part002.zip）：确保所有分卷齐全，且文件名连续（无缺号）。

3. 准备工具与确认服务器配置 提前装好必备工具，并检查服务器是否满足最低要求：

   类别	具体要求
   必备工具	7-Zip/WinRAR（解压备份包）、VSCode / 记事本（修改 JSON 文件）、FileZilla（FTP 工具）
   服务器配置	PHP 版本≥7.4、PHP 执行时间≥300 秒、内存限制≥256M、上传文件大小≥备份包单文件体积
   特殊场景处理	若原站点无法访问（如白屏），需先安装全新 WordPress + 激活 WPVivid 插件

   

三、5 步解决 WPVivid 还原失败问题#

步骤二：看懂 WPVivid 备份包结构（手动还原的前提）#

WPVivid 备份包包含多个 “独立组件”，拆分后分别还原可避免 “单包过大导致卡住”。解压备份包后，典型结构如下：

其中wpvivid_package_info.json是核心文件 —— 它记录了备份包的组成的信息，用 VSCode 打开后，可看到备份包含的所有组件（如核心文件、主题、数据库等）：

一个完整的 WPVivid 备份包，通常包含 6 类核心组件：

• backup_core.zip：WordPress 核心文件（wp-admin、wp-includes 目录）；
• backup_themes.zip：主题文件（wp-content/themes）；
• backup_plugins.zip：插件文件（wp-content/plugins）；
• backup_uploads.zip：媒体文件（wp-content/uploads，含图片、视频）；
• backup_content.zip：wp-content 目录下的其他文件（如自定义文件夹）；
• backup_db.zip：数据库备份（内含.sql 或.sql.gz 文件）。

步骤四：修改 JSON 文件（创建组件还原包）#

WPVivid 还原时会读取 JSON 文件识别组件，需为每个拆分的组件创建 “专属 JSON 文件”，确保还原时只加载单个组件：

1. 复制原始的wpvivid_package_info.json文件，为每个组件创建副本 —— 如命名为core_info.json（对应核心文件）、themes_info.json（对应主题）；

2. 用 VSCode 打开副本 JSON 文件，删除child_file数组中 “非当前组件” 的条目，只保留目标组件的记录。

   示例：创建 “主题还原包” 时，JSON 文件只保留主题相关条目：

   1
   {
   2
       "has_child": 1,
   3
       "home_url": "https:\/\/blog.leihub.cn",
   4
       "root_flag": "custom",
   5
       "php_version": "8.2.28",
   6
       "mysql_version": "5.7.44",
   7
       "wp_version": "6.8.2",
   8
       "child_file": {
   9
           "blog.leihub.cn_wpvivid-1bff5dbd0b25b_2025-08-26-20-23_backup_themes.zip": {}
   10
       },
   11
       "file": "blog.leihub.cn_wpvivid-1bff5dbd0b25b_2025-08-26-20-23_backup_all.part001.zip"
   12
   }

3. 将 “修改后的 JSON 文件” 与 “对应的组件 ZIP 包” 选中，压缩为新的 ZIP 包（如themes_restore.zip）—— 还原时上传这个新包即可。

步骤五：按顺序手动还原（关键！避免组件冲突）#

还原顺序直接影响成功率，需按 “从基础到核心” 的逻辑执行 —— 先确保 WordPress 框架正常，再还原数据，具体步骤：

1. 第一步：还原核心文件（core） 进入 WPVivid 后台「还原」→ 上传「core_restore.zip」→ 点击「还原」→ 等待 “还原成功” 提示（核心文件是基础，先确保 wp-admin 能正常访问）。

2. 第二步：还原主题（themes）和插件（plugins） 分别上传「themes_restore.zip」和「plugins_restore.zip」，逐个还原（顺序可互换）。

   注意：若插件数量多（如超过 50 个），还原可能耗时 10-20 分钟，耐心等待，不要刷新页面。

3. 第三步：还原上传文件（uploads）和其他内容（content） 上传「uploads_restore.zip」和「content_restore.zip」，这部分多为图片 / 视频，体积可能较大，需确保服务器内存≥256M。

4. 第四步：还原数据库（database） 最后上传「db_restore.zip」还原数据库（数据库是核心数据，放在最后可避免前期文件操作覆盖数据）。

   必做：还原前先通过 WPVivid「数据库备份」功能，备份目标站点当前数据库，防止数据覆盖错误。

重要提示：每一步还原都要等页面明确显示 “还原成功” 后再进行下一步，中途刷新 / 关闭浏览器会导致文件损坏，甚至站点白屏。

四、还原时的避坑指南（解决 “卡住 / 超时” 问题）#

1. 禁止中途操作 还原时不要：刷新页面、关闭浏览器、点击 “取消”、重启服务器 PHP/MySQL——WPVivid 还原在后台运行，页面仅显示进度，强行中断会导致 “文件残缺”。
2. 判断还原状态的 2 个方法
   • 成功：页面提示 “还原成功”，或收到 WPVivid 邮件通知（需提前在「设置」中开启 “还原通知”）；
   • 失败：页面显示具体错误（如 “PHP 内存溢出”“数据库连接失败”），直接根据错误提示排查（如联系主机商增加内存）。
3. 超时无响应的处理 若进度卡在某百分比（如 83%）超过 30 分钟，且服务器 CPU / 内存已降至正常水平，说明还原已中断：
   • 第一步：联系主机商获取「PHP 错误日志」，查看是否有 “memory_limit exhausted”（内存不足）或 “max_execution_time exceeded”（执行时间不足）；
   • 第二步：通过 FTP 删除 WPVivid 临时文件（路径：wp-content/wpvividbackups/temp/），避免残留文件干扰；
   • 第三步：将组件包再拆分更小（如将 uploads 拆分为 “uploads_2023.zip”“uploads_2024.zip”），重新尝试还原。

总结：WPVivid 手动还原的 3 个关键要点#

1. 环境优先：先优化 WPVivid 设置（延长执行时间、减小分块），再检查服务器配置，避免 “基础问题导致失败”；
2. 拆分核心：遇到大文件卡住时，按 “核心→主题 / 插件→上传文件→数据库” 拆分还原，降低单次处理压力；
3. 日志排查：若还原失败，优先查看 PHP 错误日志 —— 日志中的 “内存 / 时间” 提示，是解决问题的直接线索。

如果按上述步骤仍无法解决，可收集 3 类信息联系官方支持（support@wpvivid.com）：① PHP 错误日志；② 备份包的 JSON 文件内容；③ 还原时的错误截图，官方通常会在 1-2 个工作日内回复。

希望本文能帮你解决 WPVivid 还原难题！如果觉得有用，欢迎分享给需要的 WordPress 用户；若你有其他还原经验，也欢迎在评论区留言交流～

参考资料#

1. WPvivid backup 還原失敗｜非常規處理方式 - SammyStuart
2. Back up is stuck at 83% | WordPress.org

一、湖北自驾：爽到不想走，这些干货必看！#

1. 先薅羊毛！这张年卡能省一大笔#

听我的！去湖北自驾一定要办「湖北省旅游年卡」，官方卖 300 块，闲鱼搜 “湖北旅游年卡”，265 块就能拿下正规的兑换码。100 多个景点免门票，我光玩三峡大瀑布 + 腾龙洞就回本了，后面去的景点全是 “白嫖”，超香！

2. 比亚迪汉 L EV 自驾实测：电车也能放心跑#

我 5 月提的汉 L EV，到出发前都跑 5000 公里了，本来还担心电车自驾麻烦，结果湖北高速充电桩多到离谱！满电开空调 + 导航，跑 500 公里没问题，中途在景区区补电，双枪快充 10 分钟就从 30% 到 80%，上个厕所就充满了，完全没续航焦虑～

二、桂林跟团：有一次踩坑之旅#

隔了一周部门组织去桂林辽阳，我去年去过一次，也踩了不少坑，本不想去，但想着 “不去亏一年” 还是去了，结果还被影响到心情！

• 古东景区：爬瀑布好玩，但草鞋磨脚到哭 第一个去古东景区，爬瀑布挺刺激的，要抓着铁链往上走。但景区给的草鞋硬得像纸板，我走完全程脚磨的够呛！最后还在景区花35买了个洞洞鞋穿。

  

• 漓江冠岩 + 竹筏：溶洞土，江水浑，全是失望 然后去漓江冠岩，那溶洞灯光土得像 KTV，进去逛 10 分钟就想走。从溶洞出来就去漓江坐竹筏，可惜这几天下雨，漓江水很浑浊，一点也不清澈！

  

• 兴坪码头游轮：升级的沙发，救不了套路 游轮确实比去年豪华（沙发软乎），但全程被导游催着 “去甲板拍照”（其实是为了推销 花钱的打印照）。最后去 “少数民族古寨”，实则是银器购物点，不买就被导游甩脸子；返程时推销 “天价特产”，团里花了 1000 多，还被地域黑 “湖南团抠门”…

  

  总结：湖北值得 N 刷，桂林建议自由行#

  湖北的山水是 “野生的治愈”，自驾的自由 + 年卡的实惠，让每一步都很舒服；桂林的山水本是神作，却被跟团套路毁了体验 —— 如果去桂林，一定要选自由行，直奔遇龙河竹筏 + 龙脊梯田，别让导游毁了你的美好心情。

准备工作#

在开始部署前，先确认你的设备满足以下条件：

• 已安装 Docker 和 Docker Compose
• 服务器 / NAS 有足够存储空间（建议至少 10GB，根据存储需求调整）
• 开放目标端口（默认 28080，可自定义）

为了方便管理配置和数据，先创建独立的工作目录：

1
# 自定义路径，可修改为自己习惯的目录
2
mkdir -p ~/docker/nextcloud
3
# 进入目录
4
cd ~/docker/nextcloud

需要开放 Nextcloud 的访问端口（28080）和 Redis 缓存端口（6379）：

1
# 开放28080端口（Nextcloud访问）
2
sudo ufw allow 28080/tcp comment 'nextcloud访问端口' && sudo ufw reload
3
# 开放6379端口（Redis缓存，可选，容器内部通信可省略）
4
sudo ufw allow 6379/tcp comment 'nextcloud Redis缓存' && sudo ufw reload

官方提供两种主流镜像，根据需求选择：

• 基础镜像（nextcloud:latest）：基于 Apache，仅包含核心功能，体积小、部署快，适合普通用户
• 完整镜像（需自行构建）：包含 ffmpeg、ImageMagick 等工具，支持视频预览、图片处理等高级功能，适合有多媒体存储需求的用户

完整镜像构建参考：Nextcloud 官方完整镜像示例，按文档执行docker build即可。

Docker Compose部署服务#

在~/docker/nextcloud目录下创建配置文件：

1
vim docker-compose.yml

以下配置使用 DaoCloud 镜像加速，避免国内拉取镜像缓慢，关键参数已标注说明：

1
services:
2
  # 数据库容器（MariaDB，兼容MySQL）
3
  db:
4
    image: docker.m.daocloud.io/mariadb:latest
5
    restart: always  # 自动重启
6
    # 数据库核心参数，确保Nextcloud兼容
7
    command: --transaction-isolation=READ-COMMITTED --log-bin=binlog --binlog-format=ROW
8
    volumes:
9
      - ./db:/var/lib/mysql  # 数据持久化到本地，容器重启不丢失
10
    environment:
11
      - MYSQL_ROOT_PASSWORD=nextcloud_password_root  # 数据库root密码，需修改（禁止含$字符）
12
      - MYSQL_PASSWORD=nextcloud_password  # Nextcloud数据库用户密码，需修改（禁止含$字符）
13
      - MYSQL_DATABASE=nextcloud  # 数据库名，建议默认
14
      - MYSQL_USER=nextcloud  # 数据库用户，建议默认
15
    networks:
16
      - default
17

18
  # Redis缓存容器（提升Nextcloud访问速度）
19
  cache:
20
    image: docker.m.daocloud.io/redis
21
    restart: unless-stopped
22
    expose:
23
      - "6379"  # 容器内部暴露端口，无需映射到主机
24
    volumes:
25
      - ./cache:/data  # 缓存数据持久化
26
    command: redis-server --requirepass 'redis_password'  # Redis密码，需修改（禁止含$字符）
27
    networks:
28
      - default
29

30
  # Nextcloud应用容器
31
  app:
32
    image: docker.m.daocloud.io/nextcloud
33
    restart: always
34
    ports:
35
      - 28080:80  # 端口映射（主机:容器），28080可自定义
36
    links:
37
      - db  # 关联数据库容器
38
      - cache  # 关联Redis缓存容器
39
    volumes:
40
      - ./app:/var/www/html  # 应用配置和文件存储目录
41
    environment:
42
      - MYSQL_PASSWORD=nextcloud_password  # 与数据库的MYSQL_PASSWORD一致
43
      - MYSQL_DATABASE=nextcloud
44
      - MYSQL_USER=nextcloud
45
      - MYSQL_HOST=db  # 数据库容器名称
46
    networks:
47
      - default
48

49
# 自定义网络，隔离容器环境
50
networks:
51
  default:
52
    name: nextcloud