release: v1.2.2 — 双域名配置与 Host 隔离修复

修复设置页误清空管理域、配置与生效 URL 混淆及第三 Host 绕过隔离；加固 Settings API 与中间件，并更新文档站。

docs-site/guide/changelog.md

@@ -0,0 +1,113 @@
+# 更新日志
+
+PicHost 版本历史与重要变更说明。完整记录亦见仓库根目录 [CHANGELOG.md](https://github.com/O96u/PicHost/blob/main/CHANGELOG.md)。
+
+---
+
+## [1.2.2] — 2026-08-30
+
+> 升级后请**重启服务**使中间件与 API 生效。
+
+### 双域名配置与 Host 隔离
+
+#### 修复
+
+| 问题 | 说明 |
+| ---- | ---- |
+| 管理域被误清空 | 设置页保存时，关闭双域名或仅改图片域可能把 `site_base_url` 写成空字符串，导致 UI 切回单域、管理域「消失」 |
+| 配置与生效 URL 混淆 | `GET /api/settings` 的 `siteBaseUrl` / `imageBaseUrl` 曾混入当前请求的 `origin`，设置页「当前生效」与数据库配置难以区分 |
+| 第三 Host 绕过隔离 | `pages.dev`、裸 IP、旧图片域等未纳入配置的 Host 此前不被中间件拦截，后台/API 可能仍可访问 |
+
+#### 改进
+
+**设置 API（`GET /api/settings`）**
+
+| 字段 | 含义 |
+| ---- | ---- |
+| `siteBaseUrl` / `imageBaseUrl` | **配置值**（DB → 环境变量），不含 request fallback |
+| `effectiveSiteBaseUrl` / `effectiveImageBaseUrl` | **直链生成用**，未配置时回退到当前请求 origin |
+| `runtime.currentOrigin` | 检测到的当前访问地址（仅展示，不写入配置） |
+| `runtime.hostRole` | `site` / `image` / `unknown` / `single` |
+
+**保存 API（`PATCH /api/settings`）**
+
+- 新增 body 字段 `domainSeparation`（`true` / `false`），显式表达是否启用双域名
+- `domainSeparation: true` 时网站域与图片域**均必填**，且主机名不能相同
+- `domainSeparation: false` 时允许清空网站域
+- 未传 `domainSeparation` 且双域名已配置时，**禁止**单独把 `siteBaseUrl` 置空
+
+**设置页 / 首次设置**
+
+- 表单回填配置值；「当前生效」显示 `effective*` 字段
+- 展示「检测到当前访问」地址，**不再**自动写入 `window.location.origin`
+- 提供「填入检测地址」按钮（用户主动点击才填）
+- 关闭双域名需确认弹窗
+- 双域名开启且 `hostRole === 'unknown'` 时显示反代绕过警告
+
+**Host 中间件**
+
+- 双域名开启时，非 site/image 的 Host **应用层一律 404**（所有 HTTP 方法）
+- 开发环境 `localhost` / `127.0.0.1` 例外，便于 `npm run dev`
+- 与 Nginx `default_server` **互补**，建议两层都配置
+
+#### 文档
+
+- 重写 [Cloudflare / CF 优选部署](./cloudflare-deployment.md)（精简结构、检查清单、双层防护）
+- 更新 [双域名分离](./domain-separation.md) 第三 Host 与应用层拦截说明
+- 新增本页 **更新日志**
+
+#### 升级说明
+
+- **无需**数据库迁移或 CLI 操作
+- 若管理域此前已被误清空：在 **设置** 中重新填写网站域，或设置环境变量 `SITE_BASE_URL` 后重启
+- 生产双域名部署：确认反代 `server_name` 与设置一致；建议保留 Nginx default server
+
+---
+
+## [1.2.1] — 2026-08-29
+
+### 新增
+
+- 登录滑动拼图验证（缺口对齐）；验证与登录分两步
+- VitePress 文档站（`docs-site/`），部署至 GitHub Pages
+- `npm run docs:dev` / `docs:build` / `docs:preview`
+
+### 修复
+
+- 统计页删除图片后图库不刷新
+- 分页跳转输入框在 `type="number"` 下无法跳转
+- 非首页路由下复制链接格式偏好不持久化
+- 滑动验证 UI：滑块垂直居中、缺口尺寸与滑块一致
+
+### 改进
+
+- README 精简，详细说明迁入文档站
+- 双域名文档补充未知 Host 风险与 Cloudflare 部署说明
+
+---
+
+## [1.2.0] — 2026-08-28
+
+### 变更
+
+- 图片统一存放在 `data/images/`；遗留 `blog/`、`twikoo/` 等并列目录需迁移
+
+### 新增
+
+- CLI：`docker exec pichost migrate` / `migrate --apply`
+- 启动时自动同步图片索引（扫描磁盘、归一化遗留 key、清理孤儿记录）
+
+详见 [v1.2 迁移](./migration.md)。
+
+---
+
+## [1.1.x] 摘要
+
+| 版本 | 要点 |
+| ---- | ---- |
+| 1.1.5 | API 上传后预览偶发失败修复；出图前校验文件存在 |
+| 1.1.4 | 按年/月分组存储；网站域禁止直链出图 |
+| 1.1.3 | 双域名分离（`SITE_BASE_URL` / `IMAGE_BASE_URL`）；Host 中间件 |
+| 1.1.0 | 多存储后端（S3 / R2 等） |
+
+更早版本见 [GitHub CHANGELOG](https://github.com/O96u/PicHost/blob/main/CHANGELOG.md)。

docs-site/guide/cloudflare-deployment.md

@@ -0,0 +1,240 @@
+# Cloudflare / CF 优选部署说明
+
+PicHost 双域名模式下，应用根据请求 **Host**（及可信反代转发的 `X-Forwarded-Host`）区分**管理域**与**图片域**。使用 Cloudflare 橙云、优选线路、Workers 或 Pages 时，只要最终到达 PicHost 的 Host 身份不变，即可正常工作。
+
+> **一句话原则：** 网络线路可以改变，请求的域名身份不能改变 — `admin → admin`，`img → img`，不要 `img → admin`。
+
+基础概念见 [双域名分离](./domain-separation.md)；反代通用要求见 [反向代理](./reverse-proxy.md)。
+
+---
+
+## 快速检查清单
+
+部署或排错时，按顺序确认：
+
+| # | 检查项 | 期望 |
+| - | ------ | ---- |
+| 1 | 浏览器地址栏域名 | `admin.*` 或 `img.*`，不要用 IP / `pages.dev` 混用 |
+| 2 | 中间是否经过 Pages / Worker | 图片域**不得** `fetch(admin…)` |
+| 3 | 反代 upstream | 两个域名均指向 `http://127.0.0.1:6892` |
+| 4 | Nginx `proxy_set_header Host` | `$host`（保持客户端域名） |
+| 5 | PicHost 设置 | `SITE_BASE_URL` / `IMAGE_BASE_URL` 与 `server_name` 一致 |
+| 6 | 端口 `6892` | 仅本机或内网反代可达，不对公网裸露 |
+
+---
+
+## 推荐拓扑
+
+两个域名经 Cloudflare（橙云）后，**各自独立**反代到同一 PicHost 实例：
+
+```mermaid
+flowchart TB
+  internet[Internet]
+  cf[Cloudflare 橙云]
+  admin[admin.example.com]
+  img[img.example.com]
+  panel[1Panel / Nginx]
+  app[PicHost :6892]
+
+  internet --> cf
+  cf --> admin
+  cf --> img
+  admin --> panel
+  img --> panel
+  panel --> app
+```
+
+```env
+SITE_BASE_URL=https://admin.example.com
+IMAGE_BASE_URL=https://img.example.com
+```
+
+```text
+admin.example.com → http://127.0.0.1:6892
+img.example.com   → http://127.0.0.1:6892
+```
+
+不需要为「前端 / 后端 / 图片」开不同端口；一个 PicHost 实例、一个内部端口（默认 `6892`）即可。
+
+### 管理域 ≠ 前端域名
+
+| 域名 | 用途 |
+| ---- | ---- |
+| `admin.example.com` | 后台、登录、设置、图库、API、上传 |
+| `img.example.com` | 图片直链、外链、CDN 分发 |
+
+更准确的说法是**管理域 / 图片域**，而非「前端 / 后端」。PicHost 生产环境也**不需要** `前端 :3000 + 后端 :6892` 这种拆分。
+
+---
+
+## Cloudflare 橙云与 CF 优选
+
+**橙云（DNS Proxied）** 是正常且推荐的方式：
+
+```text
+admin.example.com、img.example.com
+  A / CNAME → 源站 → Proxied
+```
+
+用户访问 `admin.example.com` 时，PicHost 应收到 `Host: admin.example.com`；访问 `img.example.com` 时应收到 `Host: img.example.com`。
+
+**CF 优选**（优选 IP、优选域名、边缘入口）同样可用。优选可以改变用户到 Cloudflare 边缘的路径，但**不能**把图片域的回源身份变成管理域。两个域名应保持平行、独立的回源链：
+
+```text
+admin → CF → admin.example.com → 源站 → PicHost
+img   → CF → img.example.com   → 源站 → PicHost
+```
+
+---
+
+## 六、典型错误拓扑
+
+以下方案会破坏 Host 隔离，即使浏览器地址栏仍显示图片域：
+
+### ❌ 错误 1：图片域 fetch 到管理域
+
+```mermaid
+flowchart LR
+  user[用户 img.example.com]
+  worker[Pages / Worker]
+  admin[fetch admin.example.com]
+  app[PicHost]
+
+  user --> worker --> admin --> app
+```
+
+最后一跳 Host 变成 `admin.example.com`，PicHost 会认为这是管理域 — `https://img.example.com/` 可能看到后台。这是 **Host 被改写**，不是缓存问题。
+
+### ❌ 错误 2：优选回源到管理域
+
+```text
+img.example.com → 优选域名 → admin.example.com → 源站
+```
+
+即使只为改善线路，只要 upstream 使用管理域，图片域隔离即失效。
+
+### ❌ 错误 3：公网直接暴露 6892
+
+```text
+任意域名 / IP:6892 → PicHost
+```
+
+用户可绕开 Cloudflare 与 Nginx 的 `server_name` 限制。`6892` 应仅允许 `127.0.0.1` 或内网反代访问。
+
+### ✅ 正确做法
+
+```text
+admin → admin → PicHost
+img   → img   → PicHost
+```
+
+**不要** Pages / Workers **整站反代** PicHost（会多出 `pages.dev` / `workers.dev` 等第三入口）。PicHost 依赖 `node-server`、SQLite、`sharp` 与本地 `data/`，**不能**作为 Node 应用直接部署到 Pages/Workers；应用本体继续 Docker/VPS 部署，CF 侧用橙云 DNS + 可选 R2 即可。
+
+---
+
+## Workers / Pages 使用建议
+
+若只需改响应头、鉴权、防盗链、日志或缓存，且源站仍是自己的 PicHost：
+
+| 推荐 | 不推荐 |
+| ---- | ------ |
+| `img.example.com` → **Worker Route** → 原 `img` 源站 | `img` → Worker → `fetch(admin.example.com)` |
+
+Cloudflare 对已有外部源站的场景更推荐 [Routes](https://developers.cloudflare.com/workers/configuration/routing/routes/)（在现有 proxied 域名与源站之前运行），而非用 [Custom Domain](https://developers.cloudflare.com/workers/configuration/routing/custom-domains/) 把 Worker 当作跨域 fetch 的中转。
+
+Worker 中若出现：
+
+```js
+fetch(`https://admin.example.com${url.pathname}`)
+```
+
+即基本可确定隔离被破坏。
+
+---
+
+## Nginx / 1Panel 配置
+
+两个 `server` 块，upstream 相同，**关键行**是 `proxy_set_header Host $host;`：
+
+```nginx
+server {
+    server_name admin.example.com;
+    location / {
+        proxy_pass http://127.0.0.1:6892;
+        proxy_set_header Host $host;
+        proxy_set_header X-Forwarded-Proto $scheme;
+        proxy_set_header X-Real-IP $remote_addr;
+        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
+        client_max_body_size 12m;
+    }
+}
+
+server {
+    server_name img.example.com;
+    location / {
+        proxy_pass http://127.0.0.1:6892;
+        proxy_set_header Host $host;
+        proxy_set_header X-Forwarded-Proto $scheme;
+        proxy_set_header X-Real-IP $remote_addr;
+        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
+    }
+}
+
+# 拒绝裸 IP 与未配置域名（强烈建议）
+server {
+    listen 80 default_server;
+    listen 443 ssl default_server;
+    server_name _;
+    return 444;
+}
+```
+
+橙云部署时，源站防火墙建议**仅放行 [Cloudflare IP 段](https://www.cloudflare.com/ips/)**，避免绕过 CDN 直连。
+
+---
+
+## 双层 Host 防护
+
+生产环境建议反代层与应用层**互补**，而非二选一：
+
+| 层级 | 作用 |
+| ---- | ---- |
+| **Nginx default server** | 拒绝裸 IP、`pages.dev` 等未在 `server_name` 中声明的 Host |
+| **PicHost 中间件（v1.2.x+）** | 双域名开启时，非 site/image 的 Host 应用层返回 404（开发环境 `localhost` / `127.0.0.1` 例外） |
+
+即使应用层已拦截第三 Host，仍建议在反代配置 default server — 减少无效流量到达 PicHost。
+
+---
+
+## X-Forwarded-Host 说明
+
+PicHost 在反代场景会参考 `X-Forwarded-Host` 识别请求域名，但**不能无条件信任**该 Header（客户端可伪造）。因此：
+
+- 不要让 `6892` 对公网裸露
+- 确保只有可信反代能到达应用
+- 首选方案仍是让 `Host` 从第一跳起就保持正确
+
+---
+
+## 排查：图片域能看到后台？
+
+**先查反代链，不要先清 CF 缓存。**
+
+缓存问题通常表现为旧 JS/CSS/图片或偶发 404；若图片域能**稳定**访问 `/`、`/login`、`/settings`，几乎都是 Host 被改写。
+
+```text
+① 浏览器实际域名？
+② 是否经过 Pages / Worker / 优选反代？
+③ 代理最终 fetch 的 URL？
+④ 是否 fetch 到 admin.example.com？
+⑤ 1Panel / PicHost 最终收到的 Host？
+```
+
+---
+
+## 相关
+
+- [双域名分离](./domain-separation.md) — 中间件行为与本地测试
+- [反向代理](./reverse-proxy.md) — 单域名与源站加固
+- [环境变量](./configuration.md) — `SITE_BASE_URL`、`IMAGE_BASE_URL`
+- [常见问题](./faq.md) — Pages / Workers 与第三 Host

docs-site/guide/configuration.md

@@ -9,8 +9,8 @@ PicHost 支持通过环境变量（Docker / `.env`）与后台 **设置** 页配
 | API 上传 Token | 环境变量 → SQLite | **是**（设了则后台无法重新生成） |
 | WebP 质量 | SQLite → 环境变量 → 默认 80 | 否（未在 DB 存时读 env） |
 | 防盗链白名单 | SQLite → 环境变量 | 否 |
-| 网站 / 图片域名 | SQLite → 环境变量 → 当前请求 | 否 |
-| 隐藏 `images/` 前缀 | SQLite → 环境变量 → 默认 false | 否 |
+| 网站 / 图片域名 | SQLite → 环境变量（设置 API 配置值）；直链生成另用 `effective*` 或请求 origin | 否 |
+| 简短图片链接 | SQLite → 环境变量 → 默认 false | 否 |
 | 按年/月分组存储 | SQLite → 环境变量 → 默认 true | 否 |
 | 全局自动删除天数 | SQLite → 环境变量 → 默认 0 | 否 |
 
@@ -33,11 +33,13 @@ PicHost 支持通过环境变量（Docker / `.env`）与后台 **设置** 页配
 - **网站域名**：管理后台、API、Twikoo 上传入口
 - **图片域名**：复制链接与直链使用的公网地址
 
-双域名分离需两者主机名不同，详见 [双域名分离](./domain-separation.md)。填写后须与反代 `server_name` 一致；**勿**通过 `localhost`、IP 或未配置的域名访问生产后台。
+双域名分离需两者主机名不同，详见 [双域名分离](./domain-separation.md) 与 [Cloudflare / CF 优选部署](./cloudflare-deployment.md)。填写后须与反代 `server_name` 一致；**勿**通过 `localhost`、IP 或未配置的域名访问生产后台。
+
+在后台 **设置** 中保存时须显式勾选「启用后台与图片域名分离」，并同时填写两个域名；关闭双域名会清除网站域配置（需确认）。设置 API 返回的配置值与「当前生效」直链地址已分离，详见 [更新日志](./changelog.md#1-2-2-2026-08-30)。
 
 ### `HIDE_FOLDER_IN_URL`
 
-`true` 时直链隐藏 `images/` 前缀（如 `images/2026/08/a.webp` → `/2026/08/a.webp` 或仅文件名，取决于路径模式）。
+`true` 时使用简短图片链接（仅域名 + 文件名，如 `img.example.com/a8K3xP.webp`）；`false` 时保留日期或自定义目录（如 `img.example.com/2026/08/a8K3xP.webp`）。对外 URL **不会** 暴露内部 `images/` 前缀；旧版含 `images/` 的直链仍兼容。
 
 ### `STORAGE_USE_DATE_PATH` / `STORAGE_LAYOUT`
 

docs-site/guide/domain-separation.md

@@ -19,6 +19,8 @@
 - **网站域名**：`https://admin.example.com`
 - **图片域名**：`https://pic.example.com`
 
+首次设置与系统设置**不会**自动把当前浏览器地址写入网站域；可手动填写或点击「填入检测地址」。关闭双域名需确认，且会清除网站域配置。保存时 API 会收到 `domainSeparation: true/false` 字段。详见 [更新日志](./changelog.md#1-2-2-2026-08-30)。
+
 ## Nginx 示例
 
 ```nginx
@@ -56,36 +58,42 @@ server {
 
 ## 安全与注意事项
 
-### 中间件只隔离「已配置的两个域名」
+### 中间件隔离与第三 Host
 
 PicHost 根据请求 **Host**（反代会转发为 `X-Forwarded-Host`，应用会一并识别）判断当前是网站域还是图片域：
 
 - **图片域**：非图片路径（如 `/`、`/settings`）→ 404
 - **网站域**：图片直链路径（如 `/images/...`）→ 404
+- **未配置的第三 Host**（如 `*.pages.dev`、裸 IP、旧图片域）：**v1.2.x 起应用层一律 404**（开发环境 `localhost` / `127.0.0.1` 例外，便于 `npm run dev`）
 
-若 Host **既不是网站域也不是图片域**（例如 `localhost`、服务器 **公网 IP**、Cloudflare **Pages** 的 `*.pages.dev`、**Workers** 的 `*.workers.dev`、或其它未在设置里填写的域名），**当前版本不会拦截**，后台与 API 仍可能被访问。这与域名是否带 `-`、长短无关，而是多了一条未纳入双域名配置的入口。
+这与域名是否带 `-`、长短无关；此前版本对第三 Host 不拦截，需依赖反代 default server 封堵。
 
 **生产环境建议：**
 
-1. 反代层仅为网站域、图片域配置 `server_name`，并增加 **default server** 拒绝其它 Host 与裸 IP（见上方 Nginx 示例）
+1. 反代层仅为网站域、图片域配置 `server_name`，并增加 **default server** 拒绝其它 Host 与裸 IP（见上方 Nginx 示例，与应用层拦截互补）
 2. 使用 Cloudflare **橙云** 时，源站防火墙 **仅放行 [Cloudflare IP 段](https://www.cloudflare.com/ips/)**，避免绕过 CDN 直连源站
 3. **仅使用** 设置中的网站域名登录后台，不要用 `localhost`、IP 或未配置的域名混用
-4. **不要** 用 Cloudflare Pages / Workers 对 PicHost **整站反代**（会多出 `pages.dev` / `workers.dev` 等第三入口，且易出现上述绕过）
-5. PicHost **不能** 作为 Node 应用直接部署到 Pages/Workers（依赖 `node-server`、SQLite、`sharp` 与本地 `data/`）；应用请继续 Docker/VPS 部署，CF 侧用橙云 DNS + 可选 R2 存储即可
+4. **不要** 用 Cloudflare Pages / Workers 对 PicHost **整站反代**（会多出 `pages.dev` / `workers.dev` 等第三入口；`IMAGE_BASE_URL` 可填 CDN 公网地址，但应用本体应 Docker/VPS 部署）
+5. 若必须在边缘做反代，须保留客户端 **`Host` 或 `X-Forwarded-Host`**，否则 Host 隔离会失效
+6. PicHost **不能** 作为 Node 应用直接部署到 Pages/Workers（依赖 `node-server`、SQLite、`sharp` 与本地 `data/`）；应用请继续 Docker/VPS 部署，CF 侧用橙云 DNS + 可选 R2 存储即可
 
 ### Cloudflare 橙云（含 DNS 优选）
 
-**推荐架构：** `admin.example.com` 与 `pic.example.com` 均 **DNS Proxied（橙云）** → 源站 Nginx / 1Panel 反代 `6892`，SSL 模式 **Full (strict)**（源站可用 Cloudflare Origin Certificate）。
+完整说明见专章：[Cloudflare / CF 优选部署](./cloudflare-deployment.md)。
+
+**推荐：** `admin.example.com` 与 `pic.example.com` 均 **DNS Proxied（橙云）** → 源站 Nginx / 1Panel 反代 `6892`，SSL 模式 **Full (strict)**。
 
 | 能力 | 说明 |
 | ---- | ---- |
 | 橙云 CDN | 与 PicHost 双域名兼容；回源须保留 `Host`、`X-Forwarded-Proto` |
-| DNS 优选 | 仅改变用户连到 CF 边缘的 IP，Host 仍为正式域名，无额外配置 |
+| DNS 优选 | 仅改变用户连到 CF 边缘的 IP；**admin → admin、img → img** 的回源身份不能变 |
 | R2 对象存储 | 在 **存储** 页添加 R2 后端即可，与是否橙云无关 |
 | `cloudflare` Git 分支 | R2 专用部署线，仍是 Docker 运行，**不是** Workers 托管 |
 
 **勿混淆：** CF 控制台「创建 Worker」并连接本仓库 **无法** 直接部署 PicHost；`npm run build` + `wrangler deploy` 与当前 `node-server` 预设不兼容。
 
+**勿用 Pages/Worker 把图片域 `fetch` 到管理域** — 会破坏 Host 隔离（详见 [Cloudflare 部署说明 · 典型错误拓扑](./cloudflare-deployment.md#六典型错误拓扑)）。
+
 反代与源站加固详见 [反向代理](./reverse-proxy.md#cloudflare-橙云)。
 
 ## 飞牛 NAS · Lucky 反向代理
@@ -157,7 +165,7 @@ npm run dev
 | `http://admin.pichost.test:3000/images/...` 或 `/2026/08/xxx.webp` | **404**（请用图片域直链） |
 | `http://pic.pichost.test:3000/` | **404**（正常，图片域不提供后台） |
 | `http://pic.pichost.test:3000/images/...` | 能出图 |
-| `http://localhost:3000/` 或 `http://127.0.0.1:3000/` | **能打开后台**（第三 Host，隔离不生效；仅开发可接受，生产须用反代封禁） |
+| `http://localhost:3000/` 或 `http://127.0.0.1:3000/` | **能打开后台**（开发环境例外；生产须用反代封禁未配置 Host） |
 
 上传一张图后，复制链接应指向 `pic.pichost.test` 域名；在后台图库中缩略图也应能正常显示。
 
@@ -169,4 +177,4 @@ npm run dev
 - 单域名部署可不启用分离，仅配置 `IMAGE_BASE_URL` 或使用默认当前访问域名
 - 配置了 Referer 防盗链时，网站域与图片域会自动加入白名单，无需手写两个域名
 
-单域名反代要点见 [反向代理](./reverse-proxy.md)。英文版：[Dual-domain separation](/en/guide/domain-separation)
+单域名反代要点见 [反向代理](./reverse-proxy.md)。

docs-site/guide/faq.md

@@ -22,11 +22,15 @@ docker exec pichost reset-password 用户名
 
 ## 双域名下为什么用 pages.dev / workers.dev / IP 也能进后台？
 
-PicHost 双域名隔离**只对已配置的网站域、图片域做路径分流**；其它 Host（`localhost`、公网 IP、Cloudflare Pages 的 `*.pages.dev`、Workers 的 `*.workers.dev` 等）**当前不会拦截**，因此可能出现「奇怪地址也能开后台」。
+**v1.2.2 起：** 双域名开启时，PicHost 中间件会对**未配置的网站域、图片域之外**的 Host 返回 **404**（开发环境 `localhost` / `127.0.0.1` 例外）。详见 [更新日志](./changelog.md#1-2-2-2026-08-30)。
 
-常见原因：在橙云之外又用 **Pages/Workers 整站反代** 到源站，或源站未限制 `server_name` / 允许裸 IP 访问。
+若仍能访问，常见原因：
 
-处理：仅用正式两个域名访问；反代加 default server；橙云时源站只放行 CF IP。详见 [双域名分离 · 安全与注意事项](./domain-separation.md#安全与注意事项)。
+1. **未启用双域名**（仅配置了图片域、网站域为空）— 隔离与第三 Host 拦截均不生效
+2. **反代把 Host 改成管理域** — 例如 Pages/Worker 对图片域 `fetch(admin…)`，PicHost 看到的是管理域
+3. **源站裸暴露 `6892`** — 绕过 Cloudflare 与 Nginx `server_name`
+
+处理：在设置中正确配置双域名；反代加 default server；橙云时源站只放行 CF IP；勿用 Pages/Workers 整站反代。详见 [双域名分离](./domain-separation.md#中间件隔离与第三-host)、[Cloudflare 部署](./cloudflare-deployment.md) 与 [更新日志](./changelog.md#1-2-2-2026-08-30)。
 
 ## 能把 PicHost 部署到 Cloudflare Workers / Pages 吗？
 
@@ -64,8 +68,6 @@ PicHost 双域名隔离**只对已配置的网站域、图片域做路径分流*
 
 **本 VitePress 文档站** 为完整用户指南；README 保留摘要与快速开始。在线地址：<https://o96u.github.io/PicHost/>
 
-若访问 404，说明 GitHub Pages 尚未部署成功：请在仓库 **Settings → Pages** 将 Source 设为 **GitHub Actions**，并确认 `docs` workflow 的 deploy 步骤已通过。详见 [本地开发 · 发布到 GitHub Pages](./local-dev.md#发布到-github-pages)。
-
 ## GitHub 仓库 About 怎么写？
 
 **main** 分支建议：

docs-site/guide/index.md

@@ -6,8 +6,9 @@
 
 1. [快速开始](./getting-started.md) — Docker 部署与首次设置
 2. [环境变量](./configuration.md) — 生产环境配置与后台设置对照
-3. [存储](./storage.md) — 多后端与直链模式
-4. [API](./api.md) — REST 接口与 Token
+3. [更新日志](./changelog.md) — 版本变更与升级说明
+4. [存储](./storage.md) — 多后端与直链模式
+5. [API](./api.md) — REST 接口与 Token
 
 ## 截图预览
 

docs-site/guide/local-dev.md

@@ -51,16 +51,4 @@ npm run docs:build    # 构建静态站点
 npm run docs:preview  # 预览构建结果
 ```
 
-文档源码在 `docs-site/`；截图源文件在 `docs/screenshots/`（含 `login.png` 登录页），构建前会复制到 `docs-site/public/screenshots/`。
-
-## 发布到 GitHub Pages
-
-在线文档地址：<https://o96u.github.io/PicHost/>
-
-**首次启用**（部署 job 失败、访问 404 时检查）：
-
-1. 仓库 **Settings → Pages**
-2. **Build and deployment → Source** 选择 **GitHub Actions**（不要选 Deploy from a branch）
-3. 推送 `main` 触发 `docs` workflow，或在 Actions 页手动 **Run workflow**
-
-构建成功后约 1–2 分钟可访问。`docs` workflow 的 `deploy` 步骤失败且日志提示 Pages 未启用时，多为未完成上述设置。
+文档源码在 `docs-site/`；截图源文件在 `docs/screenshots/`（含 `login.png` 登录页），构建前会复制到 `docs-site/public/screenshots/`。在线文档：<https://o96u.github.io/PicHost/>

docs-site/guide/migration.md

@@ -174,5 +174,3 @@ CLI 只负责**搬文件**；索引对齐、遗留 key、孤儿记录由启动
 | `docker exec pichost migrate` | 预览磁盘迁移 |
 | `docker exec pichost migrate --apply` | 执行磁盘迁移 |
 | `docker exec pichost reset-password` | 重置密码（与迁移无关） |
-
-英文版：[v1.2 migration guide](/en/guide/migration)

docs-site/guide/reverse-proxy.md

@@ -41,18 +41,18 @@ IMAGE_BASE_URL=https://pic.example.com
 
 ## Cloudflare 橙云
 
-PicHost 应用运行在 **自有服务器 / Docker**（端口 `6892`），Cloudflare 侧推荐：
+详见专章：[Cloudflare / CF 优选部署](./cloudflare-deployment.md)。
 
 | 做法 | 说明 |
 | ---- | ---- |
-| **DNS 橙云** | `admin` / `pic` 两个子域 Proxied → 源站反代 `6892`，SSL **Full (strict)** |
-| **DNS 优选** | 与 PicHost 兼容；Host 仍为正式域名 |
+| **DNS 橙云** | `admin` / `img` 两个子域 Proxied → 源站反代 `6892`，SSL **Full (strict)** |
+| **DNS 优选** | 与 PicHost 兼容；须保持 **admin → admin、img → img** 回源 |
 | **R2** | 在存储页作对象后端，非 Pages 托管应用 |
 | **源站防火墙** | 仅放行 [Cloudflare IP](https://www.cloudflare.com/ips/)，禁止公网直连 `6892` |
 
 **不建议：**
 
-- 用 **Cloudflare Pages**（`*.pages.dev`）或 **Workers**（`*.workers.dev`）对 PicHost **整站反代** — 会多出第三 Host，且可能绕过双域名隔离（见 [双域名分离 · 安全与注意事项](./domain-separation.md#安全与注意事项)）
+- 用 **Cloudflare Pages**（`*.pages.dev`）或 **Workers**（`*.workers.dev`）对 PicHost **整站反代**，或让图片域 **fetch 到管理域** — 会改写 Host、绕过双域名隔离（见 [Cloudflare 部署说明](./cloudflare-deployment.md)）
 - 在 CF 控制台「从 Git 创建 Worker」部署本仓库 — 当前为 `node-server` 预设，无法直接 `wrangler deploy`
 
 ## 源站安全（双域名推荐）