Auto-sync: 2026-04-22 08:02

2026-04-22 08:02:59 +08:00
parent de096f2f88
commit 143d1fd105
62 changed files with 5232 additions and 1268 deletions
--- a/wiki/sources/install-apache-superset-in-docker.md
+++ b/wiki/sources/install-apache-superset-in-docker.md
@@ -0,0 +1,82 @@
+---
+title: "Install Apache Superset in Docker"
+type: source
+tags: [apache, bi, docker, mysql, superset]
+date: 2026-04-14
+---
+
+## Source File
+- [[raw/Home Office/Install Apache Superset in Docker.md]]
+
+## Summary (中文)
+- **核心主题**：通过 Docker 容器快速部署 Apache Superset BI 平台
+- **问题域**：数据可视化与 BI 工具的本地化安装
+- **方法/机制**：使用 Docker Hub 官方镜像 `apache/superset`，通过 docker exec 进入容器执行初始化命令
+- **结论/价值**：提供一套标准化、可复现的 Superset 部署流程，适合开发测试环境快速搭建
+
+## Key Claims (中文)
+- Docker 容器化部署可将 Superset 安装时间压缩至分钟级别
+- 通过 `superset fab create-admin` 命令创建管理员账户是初始化第一步
+- `superset db upgrade` 确保数据库 Schema 与当前版本同步
+- `superset load_examples` 加载示例数据集，便于新用户快速上手
+- `superset init` 完成权限和缓存的初始化
+
+## Key Quotes
+> `docker run -d -p 8777:8088 -e "SUPERSET_SECRET_KEY=*** --name superset apache/superset:GHA-19524015706"` — 容器启动命令，将宿主机的 8777 端口映射到容器的 8088 端口（Superset 默认 Web UI 端口）
+>
+> `docker exec -it superset superset fab create-admin --username admin --firstname Superset --lastname Admin --email admin@superset.com --password admin` — 管理员账户创建命令，用于首次登录
+
+## Key Concepts
+- [[Docker]]：容器化平台，Superset 的部署底座
+- [[Docker-Image]]：`apache/superset` 官方镜像
+- [[容器初始化]]：docker exec 进入运行中的容器执行初始化命令的流程
+- [[BI平台]]：Business Intelligence 平台，Superset 属于开源 BI 工具
+- [[数据可视化]]：将数据库数据转化为图表/仪表盘的技术
+
+## Key Entities
+- [[Apache Superset]]：开源 BI 和数据探索平台，由 Apache 软件基金会维护，支持 SQL 查询、可视化仪表盘和数据源连接
+- [[MySQL]]：关系型数据库，在 Superset 中作为默认元数据存储（SQLite 也可使用）
+- [[Docker Hub]]：官方镜像仓库，`apache/superset` 的托管位置
+
+## Connections
+- [[Docker]] ← uses ← [[Apache Superset]]
+- [[MySQL]] ← stores ← [[Apache Superset 元数据]]
+- [[Docker]] ← extends ← [[Docker Compose]]（生产环境推荐）
+- [[Apache Superset]] ← depends_on ← [[Flask]]（Web 框架）
+- [[Apache Superset]] ← depends_on ← [[SQLAlchemy]]（数据库 ORM）
+
+## Contradictions
+- 与 [[用docker安装apache-superset]] 可能的冲突：
+  - 冲突点：两篇文档可能描述不同的安装方式（Docker Run vs Docker Compose）
+  - 当前观点：本篇使用 `docker run` 单容器模式，适合快速尝鲜
+  - 对方观点：Docker Compose 模式便于多容器协同（Redis + PostgreSQL + Superset），更适合生产环境
+
+## 安装步骤速查
+
+```bash
+# 1. 拉取镜像
+docker pull apache/superset:GHA-19524015706
+
+# 2. 运行容器
+docker run -d -p 8777:8088 -e "SUPERSET_SECRET_KEY=*** --name superset apache/superset:GHA-19524015706
+
+# 3. 创建管理员账户
+docker exec -it superset superset fab create-admin \
+  --username admin \
+  --firstname Superset \
+  --lastname Admin \
+  --email admin@superset.com \
+  --password admin
+
+# 4. 数据库迁移
+docker exec -it superset superset db upgrade
+
+# 5. 加载示例数据
+docker exec -it superset superset load_examples
+
+# 6. 初始化
+docker exec -it superset superset init
+```
+
+访问地址：`http://localhost:8777`
+默认凭据：`admin / admin`
--- a/wiki/sources/mac-mini-服务器配置-防止自动锁屏与睡眠.md
+++ b/wiki/sources/mac-mini-服务器配置-防止自动锁屏与睡眠.md
@@ -0,0 +1,53 @@
+---
+title: "Mac Mini 服务器配置：防止自动锁屏与睡眠"
+type: source
+tags: []
+date: 2026-03-15
+---
+
+## Source File
+- [[raw/Home Office/Mac-Mini-服务器配置-防止自动锁屏与睡眠.md]]
+
+## Summary (用中文描述)
+- **核心主题**：Mac Mini 作为无显示器 Home Server 时，防止 macOS 自动锁屏、睡眠、待机和休眠的完整解决方案
+- **问题域**：macOS 电源管理在 Headless（无显示器）场景下的行为导致远程访问中断
+- **方法/机制**：
+  - 永久方案：通过 `pmset` 命令永久关闭所有睡眠/锁屏机制
+  - 临时方案：通过 `caffeinate` 命令临时保持唤醒
+  - 验证：通过 `pmset -g` 系列命令确认电源设置状态
+- **结论/价值**：仅需一行 sudo 命令即可将 Mac Mini 转化为 7×24 可靠运行的 Headless 服务器，支持 RustDesk/VNC 等远程访问工具持续连接
+
+## Key Claims (用中文描述)
+- Mac Mini 关闭显示器后会自动锁屏或进入睡眠，导致 RustDesk/VNC 无法连接
+- `sudo pmset -a sleep 0 displaysleep 0 standby 0 hibernatemode 0` 可永久禁止所有睡眠行为
+- `pmset -a womp 1` 启用 Wake-on-LAN，可远程唤醒 Mac Mini
+- `-a` 参数表示同时应用于电池模式和电源适配器模式
+- `caffeinate -d -i -s` 可临时防止睡眠，不修改系统设置
+- 关闭睡眠会增加功耗，适合始终接电的服务器场景
+
+## Key Quotes
+> "Mac Mini 作为服务器使用时，关闭显示器后会自动锁屏或进入睡眠状态，导致远程访问软件（如 RustDesk、VNC）无法连接，需要物理到主机上输入密码解锁。" — 问题描述
+
+## Key Concepts
+- [[pmset]]：macOS 系统电源管理命令行工具，用于查询和修改电源设置（sleep/displaysleep/standby/hibernatemode/womp）
+- [[caffeinate]]：macOS 临时防止睡眠的工具，不修改系统持久设置，按 Ctrl+C 停止
+- [[Wake-on-LAN]]：网络唤醒协议，通过网卡接收特定魔法包（Magic Packet）远程唤醒关机状态的设备；`pmset -a womp 1` 启用
+- [[Headless 服务器]]：无本地显示器/键盘的服务器，通过网络远程管理，依赖稳定的电源管理配置
+- [[系统睡眠管理]]：操作系统在空闲时降低功耗的机制，包含系统睡眠（sleep）、显示器睡眠（displaysleep）、待机（standby）、休眠（hibernatemode）四种层级
+
+## Key Entities
+- [[Mac Mini M4]]：Apple Silicon Mac Mini，作为家庭服务器运行 Home Office 服务，防止自动睡眠是其服务器化的关键配置之一
+- [[RustDesk]]：开源远程桌面软件，Home Server 场景下需要 Mac Mini 不进入睡眠才能持续接受连接
+
+## Connections
+- [[Mac Mini M4]] ← 电源配置 ← [[pmset]]（防止睡眠的命令）
+- [[pmset]] ← 对应关系 ← [[HandleLidSwitch]]（Linux/Ubuntu 等效配置）
+- [[caffeinate]] ← 临时替代 ← [[pmset]]（临时 vs 永久）
+- [[Wake-on-LAN]] ← 相关 ← [[Mac Mini M4]]（网络唤醒启用后可通过其他设备远程唤醒）
+
+## Contradictions
+- 与 [[ubuntu禁用合盖休眠]] 冲突：
+  - **冲突点**：macOS vs Linux 的睡眠管理机制和命令工具完全不同
+  - **当前观点**：macOS 使用 `pmset` 命令配置电源管理，设置 `sleep 0/displaysleep 0/standby 0/hibernatemode 0`
+  - **对方观点**：Linux/Ubuntu 使用 `systemd-logind` 的 `HandleLidSwitch=ignore` 配置合盖行为，进阶方案用 `systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target`
+  - **解决说明**：两者目标相同（防止服务器睡眠），但平台不同，方法论不可互换，均为正确方案
--- a/wiki/sources/minio-zipline-自托管图床应用安装教程.md
+++ b/wiki/sources/minio-zipline-自托管图床应用安装教程.md
@@ -0,0 +1,165 @@
+---
+title: "MinIO + Zipline 自托管图床应用安装教程"
+type: source
+tags: [docker, image, minio, n8n, nas, synology, zipline]
+date: 2025-12-29
+---
+
+## Source File
+- [[raw/Home Office/MinIO + Zipline 自托管图床应用安装教程.md]]
+
+## Summary (用中文描述)
+- **核心主题**：在 Synology NAS 上通过 Docker Compose 部署 MinIO + Zipline 自托管图床解决方案
+- **问题域**：家庭/小型办公环境需要自托管的图片存储服务，替代云服务（图床）
+- **方法/机制**：
+  - MinIO 作为 S3 兼容对象存储后端，提供高性价比的本地存储
+  - Zipline 作为图片上传 UI 和 API 服务层，支持 n8n 工作流集成
+  - PostgreSQL 作为 Zipline 的元数据存储
+  - 使用 `mc` 命令行工具设置 Public Bucket 匿名访问
+  - pg_dump 实现 PostgreSQL 逻辑备份脚本
+  - Synology Hyper Backup 配合定时任务实现增量归档
+- **结论/价值**：零成本、完全自控的图床方案，适合技术用户家庭部署
+
+## Key Claims (用中文描述)
+- MinIO + Zipline 架构将存储性能与元数据管理分离，MinIO 存储性能仅受 NAS 硬盘/SSD 限制，Zipline 仅处理 metadata
+- Docker Compose `depends_on` + `condition: service_healthy` 实现服务启动顺序保障，避免竞态条件
+- pg_dump 逻辑备份是 Synology NAS 环境的标准热备份方案，零停机、迁移能力强
+- "脑体分离"（PostgreSQL 元数据 + MinIO 文件实体）是图床系统的核心架构特征，备份必须同时覆盖两者
+
+## Key Quotes
+> "Zipline 将元数据存在 Postgres，将文件实体存在 MinIO，你的备份方案必须确保这两者在时间点上是（尽可能）一致的。" — 备份策略核心挑战
+
+> "docker exec $PG_CONTAINER pg_dump -U $PG_USER -d $PG_DB | gzip > $BACKUP_DIR/db_$DATE.sql.gz" — 热备份标准命令
+
+## Key Concepts
+- [[图床]]：托管图片/媒体文件的服务，通过 URL 直接访问
+- [[S3-兼容对象存储]]：MinIO 实现的 S3 API 兼容对象存储
+- [[Docker堆栈]]：多容器 Docker Compose 编排，多服务依赖管理
+- [[逻辑备份]]：通过 pg_dump 导出 SQL，而非物理文件备份
+- [[数据一致性]]：分布式存储系统中元数据与文件实体的时间点一致性
+- [[匿名访问策略]]：MinIO mc anonymous 命令设置 bucket 公共读写权限
+
+## Key Entities
+- [[MinIO]]：开源 S3 兼容对象存储，MinIO + Zipline 架构的存储后端
+- [[Zipline]]：开源图床应用，提供前端上传 UI 和 REST API
+- [[PostgreSQL]]：Zipline 的元数据数据库
+- [[群晖 NAS]]（Synology NAS）：部署 Docker 的硬件平台
+- [[n8n]]：工作流自动化工具，通过 Zipline API 实现图片上传
+- [[Synology Hyper Backup]]：群晖备份套件
+- [[pg_dump]]：PostgreSQL 逻辑备份工具
+
+## Connections
+- [[Zipline]] ← depends_on ← [[MinIO]]（S3 存储）
+- [[Zipline]] ← depends_on ← [[PostgreSQL]]（元数据）
+- [[n8n]] ← calls ← [[Zipline API]]（图片上传）
+- [[pg_dump]] ← backup ← [[PostgreSQL]]
+- [[Synology Hyper Backup]] ← backup ← [[MinIO 数据目录]]
+- [[Docker堆栈]] ← orchestrates ← [[MinIO]] + [[Zipline]] + [[PostgreSQL]]
+
+## Contradictions
+- 与 [[rsync增量备份]] 冲突：
+  - 冲突点：数据库备份方式
+  - 当前观点：pg_dump 逻辑备份（SQL 文件，可跨平台迁移）
+  - 对方观点：rsync 增量备份（文件级同步，适合 Docker 卷）
+  - 协调：两者互补——pg_dump 备份元数据，rsync/Hyper Backup 备份文件实体
+
+## Architecture
+
+```
+[DSM Docker UI]
+     │
+     ├── MinIO (9000 API, 9001 Console)
+     │       └── /volume1/docker/zipline-stack/minio/minio_data
+     │
+     ├── PostgreSQL (Zipline DB)
+     │       └── /volume1/docker/zipline-stack/zipline/pg_data
+     │
+     └── Zipline (暴露 3333)
+             ├── 前端上传 UI
+             └── n8n API 上传
+
+Zipline → MinIO（S3） → NAS 存储
+```
+
+## Docker Compose Key Config
+
+```yaml
+services:
+  minio:
+    image: minio/minio:latest
+    command: server /data --console-address ":9001"
+    ports:
+      - "9000:9000"   # API
+      - "9001:9001"   # Console
+    environment:
+      MINIO_ROOT_USER: admin
+      MINIO_ROOT_PASSWORD: Abcd_1234
+
+  postgres:
+    image: postgres:16
+    environment:
+      POSTGRES_USER: zipline
+      POSTGRES_PASSWORD: zipline
+      POSTGRES_DB: zipline
+
+  zipline:
+    image: ghcr.io/diced/zipline:latest
+    depends_on:
+      minio:
+        condition: service_healthy
+      postgres:
+        condition: service_healthy
+    environment:
+      DATABASE_URL: postgres://zipline:***@postgres:5432/zipline
+      STORAGE_ENGINE: s3
+      S3_BUCKET: zipline-bucket
+      S3_ENDPOINT: http://minio:9000
+      S3_ACCESS_KEY: admin
+      S3_SECRET_KEY: Abcd_1234
+      S3_FORCE_PATH_STYLE: "true"
+```
+
+## mc (MinIO Client) Anonymous Access Commands
+
+```bash
+# 设置别名
+mc alias set local http://192.168.3.17:9000 admin StrongPasswordHere
+
+# 创建 bucket
+mc mb local/zipline-bucket
+
+# 设置公共读写权限
+mc anonymous set public local/zipline-bucket
+
+# 匿名权限类型
+# - download: 仅下载（GET）
+# - upload: 仅上传（PUT）
+# - public: 读写
+# - none: 禁用匿名访问
+```
+
+## Backup Script
+
+```bash
+#!/bin/bash
+BACKUP_DIR="/volume1/docker/zipline-stack/backups"
+PG_CONTAINER="zipline_postgres"
+PG_USER="zipline"
+PG_DB="zipline"
+RETENTION_DAYS=30
+DATE=$(date +%Y%m%d_%H%M%S)
+
+mkdir -p "$BACKUP_DIR"
+
+# pg_dump 逻辑备份（热备份）
+docker exec "$PG_CONTAINER" pg_dump -U "$PG_USER" -d "$PG_DB" | gzip > "$BACKUP_DIR/db_$DATE.sql.gz"
+
+# 清理旧备份
+find "$BACKUP_DIR" -name "db_*.sql.gz" -mtime +$RETENTION_DAYS -delete
+```
+
+## Reference URLs
+- [Docker Volume Documentation](https://docs.docker.com/storage/volumes/)
+- [MinIO Docker Persistence](https://min.io/docs/minio/linux/operations/install-deploy-manage/deploy-minio-single-node-single-drive.html)
+- [Synology ACL Settings](https://kb.synology.com/en-global/DSM/tutorial/How_to_manage_ACL_settings_on_your_Synology_NAS)
+- [MinIO mc anonymous](https://min.io/docs/enterprise/aistor-object-store/reference/cli/mc-anonymous/)
--- a/wiki/sources/ubuntu-server科学上网.md
+++ b/wiki/sources/ubuntu-server科学上网.md
@@ -0,0 +1,60 @@
+---
+title: "Ubuntu Server科学上网"
+type: source
+tags: [docker, proxychains, ubuntu, v2rayn]
+date: 2025-12-29
+---
+
+## Source File
+- [[raw/Home Office/Ubuntu Server科学上网.md]]
+
+## Summary (用中文描述)
+- **核心主题**：Ubuntu Server 终端场景下的科学上网多方案配置，涵盖 ProxyChains、Git 全局代理、Docker Daemon 代理、Docker 容器内代理四种场景
+- **问题域**：如何让 Ubuntu Server 上的各种命令行工具（git clone、docker pull、apt-get）和容器内应用通过代理访问国外资源
+- **方法/机制**：按场景分：① ProxyChains 劫持任意命令 ② Git 全局配置 ③ Docker Daemon systemd 注入 ④ Docker 容器环境变量注入
+- **结论/价值**：提供了完整的"Ubuntu Server 终端代理"工具箱，针对不同工具有不同最优方案
+
+## Key Claims (用中文描述)
+- ProxyChains 通过 LD_PRELOAD 劫持动态链接库的 socket 调用，使原本不支持代理的终端命令（如 curl、wget、git clone）自动走 SOCKS5 代理
+- Git 不读取系统环境变量 http_proxy/HTTP_PROXY，必须通过 `git config --global` 设置 socks5:// 代理
+- Docker Daemon（dockerd）以 systemd 服务运行，不读取普通用户环境变量，必须通过 systemd drop-in 文件注入 HTTP_PROXY 环境变量
+- Docker 容器默认 bridge 网络模式下，127.0.0.1 指向容器内部而非宿主机，需使用 Docker 网络网关 IP（通常是 172.17.0.1 或 172.24.0.1）
+- Docker 客户端配置文件 `~/.docker/config.json` 的 proxies.default 字段仅影响 `docker run` 新启动的容器，不影响已运行的容器
+
+## Key Quotes
+> "curl -x socks5h://127.0.0.1:10808 -v https://www.google.com" — 推荐的最快最直接的代理验证方法，socks5h 的 h 表示让代理服务器解析 DNS 避免本地 DNS 污染
+> "proxychains4 git clone https://github.com/..." — ProxyChains 使用方法，在任意命令前加前缀即可
+> "git config --global http.proxy 'socks5://127.0.0.1:10808'" — Git 全局代理配置，必须显式设置
+> "Environment=\"HTTP_PROXY=http://127.0.0.1:10808/\"" — Docker Daemon systemd drop-in 配置格式
+> "ALL_PROXY=socks5://172.24.0.1:10808" — Docker 容器内应用代理，使用 Docker 网络网关 IP 而非 127.0.0.1
+
+## Key Concepts
+- [[ProxyChains]]：通过 LD_PRELOAD 技术劫持动态链接库的 socket 函数，使终端命令自动走代理的工具，支持 socks4/socks5/HTTP 代理类型
+- [[Git 全局代理]]：Git 不读取系统环境变量，必须通过 `git config --global` 设置代理配置，支持 socks5 和 HTTP 代理
+- [[Docker Daemon Proxy]]：通过 systemd drop-in 文件注入环境变量使 dockerd 走代理的配置方式，配置文件位于 /etc/systemd/system/docker.service.d/http-proxy.conf
+- [[Docker 网络网关 IP]]：Docker bridge 网络模式下容器访问宿主机的 IP 地址，通常为 172.17.0.1（默认 bridge）或 172.24.0.1（自定义网络），不能用 127.0.0.1
+- [[SOCKS5h 代理]]：SOCKS5 协议的 h 变体（socks5h），表示 DNS 解析由代理服务器完成，防止本地 DNS 污染导致的连接失败
+- [[环境变量代理]]：通过 HTTP_PROXY/HTTPS_PROXY/ALL_PROXY 环境变量让应用走代理的配置方式，适用于 Docker 容器场景
+
+## Key Entities
+- [[v2rayN]]：提供 SOCKS5 和 HTTP 代理端口（默认 10808）的跨平台代理客户端，本文档所有场景的代理来源，Ubuntu Server 上通过 v2rayN 提供代理服务
+- [[代理客户端]]：运行在终端设备上提供本地代理服务的软件，v2rayN 是典型产品
+- [[SOCKS5 协议]]：一种代理协议，相比 HTTP 代理更通用，可代理任意 TCP 连接
+- [[Docker]]：容器化平台，dockerd 守护进程本身需要代理配置才能 pull 国外镜像
+
+## Connections
+- [[v2rayN]] ← 提供代理 ← [[ProxyChains]]
+- [[v2rayN]] ← 提供代理 ← [[Git 全局代理]]
+- [[v2rayN]] ← 提供代理 ← [[Docker Daemon Proxy]]
+- [[v2rayN]] ← 提供代理 ← [[Docker 网络网关 IP]]
+- [[Docker Daemon Proxy]] ← 依赖 ← [[systemd]]
+- [[ProxyChains]] ← 底层机制 ← [[LD_PRELOAD 劫持]]
+- [[ubuntu-server科学上网]] ← 与 ← [[群晖nas科学上网方法]] ← 相关但场景不同（终端 vs NAS GUI）
+- [[ubuntu-server科学上网]] ← 与 ← [[网件rax50路由器刷梅林固件与科学上网插件安装教程]] ← 互补（终端代理 vs 路由网关代理）
+- [[ubuntu-server科学上网]] ← 与 ← [[3x-ui-xray-on-bandwagonvps]] ← 互补（客户端配置 vs 服务端配置）
+
+## Contradictions
+- 与 [[群晖nas科学上网方法]] 差异：
+  - 冲突点：群晖方案强调透明代理（V2RayA iptables 分流），本方案强调显式终端代理（ProxyChains/Git/Docker Daemon 配置）
+  - 当前观点：Ubuntu Server 终端场景下，显式配置代理比透明代理更可控、更可预测
+  - 对方观点：群晖 NAS 场景下，透明代理可以一次性解决所有应用的科学上网问题，无需逐个配置
--- a/wiki/sources/ubuntu用rustdesk远程登录出现不能使用wayland登录的错误.md
+++ b/wiki/sources/ubuntu用rustdesk远程登录出现不能使用wayland登录的错误.md
@@ -0,0 +1,48 @@
+---
+title: "Ubuntu用RustDesk远程登录出现不能使用Wayland登录的错误"
+type: source
+tags: [rustdesk, ubuntu, wayland, x11, gdm3]
+date: 2026-04-14
+---
+
+## Source File
+- [[Home Office/Ubuntu用RustDesk远程登录出现不能使用Wayland登录的错误]]
+
+## Summary（用中文描述）
+- 核心主题：Ubuntu 24.04 下 RustDesk 无法在 Wayland 会话中使用/登录的故障排查与解决
+- 问题域：Linux 远程桌面协议兼容性、Wayland vs X11 显示协议
+- 方法/机制：修改 GDM3 配置文件，注释掉 `WaylandEnable=false` 以强制使用 X11 协议
+- 结论/价值：通过禁用 Wayland 强制 X11，使 RustDesk 能够在系统登录前（Login Screen）和登录后（Post-Login）正常工作
+
+## Key Claims（用中文描述）
+- Ubuntu 24.04 默认使用 Wayland 显示协议，Wayland 基于安全设计严格限制外部程序在未登录状态下获取屏幕控制权
+- 修改 `/etc/gdm3/custom.conf` 文件中 `WaylandEnable=false`（取消注释）后，登录界面强制使用 X11，RustDesk 后台服务可识别 X11 窗口并与之交互
+- X11 的稳定性与权限开放度目前仍优于 Wayland，适合需要频繁远程桌面运维的场景
+
+## Key Quotes
+> "Ubuntu 24.04 默认使用了 Wayland 显示协议，而 Wayland 出于安全设计，严格限制了外部程序在用户未登录状态下（即 GDM 登录界面）获取屏幕控制权" — 问题根因说明
+
+> "# Uncoment the line below to force the login screen to use Xorg" — GDM3 配置文件注释原文
+
+## Key Concepts
+- [[Wayland]]：Linux 新一代显示协议，基于安全设计，限制未授权程序获取屏幕控制权
+- [[X11]]：经典显示协议，兼容性更好，权限开放度更高，适合远程桌面场景
+- [[GDM3]]：GNOME Display Manager，Ubuntu 默认登录管理器，控制用户会话初始化
+
+## Key Entities
+- [[RustDesk]]：开源远程桌面软件，支持自建中继服务器
+- [[Ubuntu]]：Linux 发行版，本文档针对 24.04 LTS 版本
+- [[GNOME]]：Ubuntu 24.04 默认桌面环境，使用 GDM3 作为显示管理器
+
+## Connections
+- [[Ubuntu]] ← uses ← [[GDM3]]
+- [[GDM3]] ← can_run_on ← [[X11]]
+- [[GDM3]] ← can_run_on ← [[Wayland]]
+- [[RustDesk]] ← requires ← [[X11]] ← (在 GDM3 Login Screen 场景下)
+
+## Contradictions
+- 与 [[Ubuntu]] Wayland 趋势：
+  - 冲突点：Ubuntu 24.04 推动 Wayland 替代 X11，而本文档建议禁用 Wayland 回退到 X11
+  - 当前观点：对于 RustDesk 远程桌面运维场景，X11 的稳定性和兼容性优于 Wayland
+  - 对方观点：Wayland 是未来方向，应尽量保持默认配置
+  - 备注：此为务实方案，非长期理想状态
--- a/wiki/sources/ubuntu禁用合盖休眠.md
+++ b/wiki/sources/ubuntu禁用合盖休眠.md
@@ -0,0 +1,75 @@
+---
+title: "Ubuntu禁用合盖休眠"
+type: source
+tags: [ubuntu, systemd, 服务器配置]
+date: 2026-04-14
+---
+
+## Source File
+- [[raw/Home Office/Ubuntu禁用合盖休眠.md]]
+
+## Summary (用中文描述)
+- 核心主题：Ubuntu Server 合盖不休眠的完整操作指南
+- 问题域：Ubuntu 笔记本作为服务器运行时，合盖触发系统休眠/待机导致服务中断的问题
+- 方法/机制：通过修改 systemd-logind 的 logind.conf 配置文件，设置 HandleLidSwitch 系列参数为 ignore，并重启服务生效；进阶方案是通过 systemctl mask 彻底禁用内核级休眠目标
+- 结论/价值：让 Ubuntu 笔记本在无外接显示器的情况下作为稳定服务器运行
+
+## Key Claims (用中文描述)
+- systemd-logind 是 Ubuntu 24.04 控制笔记本合盖行为的系统服务
+- 修改 /etc/systemd/logind.conf 中的 HandleLidSwitch* 系列配置项并重启服务即可生效
+- HandleLidSwitch=ignore 使系统合盖后继续运行
+- systemctl mask 可从内核级别彻底禁用 sleep/suspend/hibernate/hybrid-sleep 四个休眠目标
+
+## Key Quotes
+> "HandleLidSwitch：合盖时的动作（通常指用电池时）" — Ubuntu logind.conf 配置项说明
+> "HandleLidSwitchExternalPower：连接外接电源合盖时的动作" — Ubuntu logind.conf 配置项说明
+> "HandleLidSwitchDocked：连接扩展坞合盖时的动作" — Ubuntu logind.conf 配置项说明
+> "在执行此命令时，你的当前会话（包括图形界面或当前的 SSH 连接）可能会短暂断开或重新加载。" — 重启 systemd-logind 的注意事项
+
+## Key Concepts
+- [[systemd-logind]]：Linux 系统登录管理器，负责管理用户会话、电源事件和系统休眠行为
+- [[HandleLidSwitch]]：systemd-logind 的合盖动作配置项，支持 ignore/suspend/hibernate/poweroff/lock 等值
+- [[休眠目标]]：Linux 内核的电源管理目标，包括 sleep.target / suspend.target / hibernate.target / hybrid-sleep.target
+
+## Key Entities
+- [[Ubuntu Server]]：Canonical 维护的 Linux 服务器操作系统，默认使用 systemd 作为初始化系统
+- [[systemd]]：Linux 系统和服务管理器，通过 logind 管理笔记本电源事件
+
+## Connections
+- [[Ubuntu Server]] ← 使用 ← [[systemd-logind]]（电源管理机制）
+- [[systemd-logind]] ← 配置项 ← [[HandleLidSwitch]]（合盖行为控制）
+- [[休眠目标]] ← 进阶禁用 ← systemd（通过 systemctl mask）
+
+## Contradictions
+- 无已知冲突页面
+
+## Related Sources
+- [[mac-mini服务器配置-防止自动锁屏与睡眠]] — macOS 等效配置（防止 Mac Mini 服务器自动睡眠）
+- [[ubuntu服务器通过rsync实现日常增量备份]] — Ubuntu 服务器备份方案
+- [[安装ubuntu-24-04-2在hp-zbook工作站笔记本上]] — HP ZBook Ubuntu 安装记录
+
+## Operations (操作步骤)
+
+### 基础方案：修改 logind.conf
+```bash
+# 1. 编辑配置文件
+sudo nano /etc/systemd/logind.conf
+
+# 2. 修改/添加以下配置（删除行首 #）
+[Login]
+HandleLidSwitch=ignore
+HandleLidSwitchExternalPower=ignore
+HandleLidSwitchDocked=ignore
+
+# 3. 重启服务使配置生效
+sudo systemctl restart systemd-logind
+```
+
+### 进阶方案：禁用内核级休眠功能
+```bash
+# 彻底禁用所有休眠目标
+sudo systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target
+
+# 恢复（如需）
+sudo systemctl unmask sleep.target suspend.target hibernate.target hybrid-sleep.target
+```
--- a/wiki/sources/在ubuntu上通过vps-内网反向代理实现域名访问内网穿透.md
+++ b/wiki/sources/在ubuntu上通过vps-内网反向代理实现域名访问内网穿透.md
@@ -0,0 +1,58 @@
+---
+title: "在Ubuntu上通过VPS+内网反向代理实现域名访问内网穿透"
+type: source
+tags: [vps, caddy, frp, reverse-proxy, troubleshooting, cloudflare, ubuntu, 内网穿透]
+date: 2026-04-14
+---
+
+## Source File
+- [[Home Office/在Ubuntu上通过VPS+内网反向代理实现域名访问内网穿透.md]]
+
+## Summary（用中文描述）
+- 核心主题：通过 VPS（公网服务器）+ frp（反向隧道）+ Caddy（自动 HTTPS 反向代理）实现家庭内网服务的公网域名访问
+- 问题域：家庭/办公内网中的 NAS、Ubuntu 服务器运行的服务（如 n8n、Grafana、Transmission 等）如何通过自定义域名从公网安全访问
+- 方法/机制：Cloudflare DNS A 记录指向 VPS 公网 IP → VPS 运行 frps（frp 服务端）和 Caddy → 内网主机运行 frpc（frp 客户端）将本地端口映射到 VPS → Caddy 反向代理到 frp 映射端口，自动申请 Let's Encrypt 证书提供 HTTPS
+- 结论/价值：完整梳理了从 DNS 配置、frps/frpc 安装配置、Caddy 反向代理到 SSH 穿透的全套流程，并提供了 7 步系统化故障排查指南
+
+## Key Claims（用中文描述）
+- frp 内网穿透工具包含 frps（服务端）和 frpc（客户端），通过 TCP 反向隧道将内网端口暴露到公网 VPS
+- Caddy 自动管理 HTTPS 证书（Let's Encrypt），无需手动配置 SSL，通过 reverse_proxy 指令将请求转发到 frp 映射的本地端口
+- Cloudflare DNS 仅负责将子域名 A 记录指向 VPS 公网 IP，不影响 TCP 流量的直接路由
+- SSH 穿透不同于 HTTP/HTTPS，不经过 Caddy，仅通过 frps + frpc 的 TCP 映射实现
+- 内网 NAS 上的 V2RayA 透明代理可能干扰 frp 连接，需要停止代理后重启 frpc
+
+## Key Quotes
+> "思路：Cloudflare DNS 指向 公网上的一台VPS，VPS 上运行 Caddy；内网主机通过 frp 将服务暴露到 VPS（本地 127.0.0.1 或某个端口），VPS 反向代理到该端口。" — 整体方案架构描述
+
+> "Caddy 会自动申请并更新 Let's Encrypt 证书，提供 HTTPS 访问。" — Caddy 自动 HTTPS 特性
+
+> "⚠️ **重点提醒（安全性）**：SSH 穿透与 HTTP 不同，它是纯 TCP 流量，不经 Caddy（Caddy 只处理 HTTP/HTTPS），所以：Caddy 不参与 SSH 的代理，只用 frps + frpc 配置即可完成。" — SSH 与 HTTP 代理架构差异
+
+> "authentication failed token mismatch invalid login → 那肯定是 token 和 frpc 不一致。" — frp 连接失败的核心原因之一
+
+## Key Concepts
+- [[内网穿透]]：通过公网服务器中转，使 NAT/防火墙后的内网服务可被外部访问的技术，本方案使用 frp 反向隧道实现
+- [[反向代理]]：Caddy 作为反向代理，将公网 HTTPS 请求转发到本地 frp 映射端口，提供统一的 HTTPS 入口
+- [[TCP隧道]]：frp 通过 TCP 协议在 frpc 客户端和 frps 服务端之间建立持久隧道，支持非 HTTP 协议（如 SSH、MySQL）
+- [[自动HTTPS]]：Caddy 内置 Let's Encrypt 证书自动申请和续期，无需手动管理 SSL 证书
+- [[DNS A记录]]：Cloudflare DNS 配置，将子域名（如 nas.ishenwei.online）指向 VPS 公网 IP
+
+## Key Entities
+- [[RackNerd VPS]]：VPS 提供商（192.227.222.142），托管 frps 服务端和 Caddy 反向代理，作为内网穿透的公网中转站
+- [[Synology NAS DS718]]：内网 NAS 设备（192.168.3.17），运行 frpc 客户端，通过 frp 暴露 NAS 服务（5000端口 → VPS 15000）
+- [[frp]]：开源内网穿透工具，本方案的核心，包含 frps（服务端，监听 7000 端口）和 frpc（客户端），版本 0.65.0
+- [[Caddy]]：Go 语言编写的自动 HTTPS 反向代理服务器，与 frp 配合为内网服务提供 HTTPS 域名访问
+- [[Cloudflare]]：域名 DNS 托管服务商，通过 A 记录将 ishenwei.online 子域名指向 VPS 公网 IP
+
+## Connections
+- [[家庭网络环境概览_2026-04-03]] ← extends ← [[在Ubuntu上通过VPS+内网反向代理实现域名访问内网穿透]]（本文是该概览中内网穿透架构的详细展开）
+- [[ubuntu-安装-frp-0-65-0-x86_64-操作笔记]] ← depends_on ← [[在Ubuntu上通过VPS+内网反向代理实现域名访问内网穿透]]（FRP 安装是该方案的前置步骤）
+- [[mac-mini-安装-frp-0-65-0-arm64-操作笔记]] ← depends_on ← [[在Ubuntu上通过VPS+内网反向代理实现域名访问内网穿透]]（Mac Mini FRP 客户端配置参考）
+- [[Ubuntu Server]] ← hosts ← [[在Ubuntu上通过VPS+内网反向代理实现域名访问内网穿透]]（Ubuntu Server 24.04 是本方案的目标操作系统）
+
+## Contradictions
+- 与 [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]] 可能的差异点：
+  - 冲突点：监控方案中是否包含完整的公网访问配置
+  - 当前观点：本文提供完整公网域名访问方案，包含 HTTPS 和 SSH 穿透的详细配置
+  - 对方观点：监控方案侧重于 Prometheus + Grafana + exporters 的部署和告警配置，未展开公网访问细节
+  - 建议：在监控方案中补充指向本文内网穿透配置的外链，实现监控方案 + 公网访问的完整闭环
--- a/wiki/sources/如何删除旧的废弃的docker-container-volume.md
+++ b/wiki/sources/如何删除旧的废弃的docker-container-volume.md
@@ -0,0 +1,54 @@
+---
+title: "如何删除旧的废弃的Docker Container + Volume"
+type: source
+tags: [container, docker, portainer, volume]
+date: 2026-04-14
+---
+
+## Source File
+- [[raw/Home Office/如何删除旧的废弃的docker container +volume.md]]
+
+## Summary (用中文描述)
+- 核心主题：Docker 容器生命周期管理——如何彻底清理旧的废弃 Portainer 容器、Volume 和 Network，并安全重装
+- 问题域：Home Server 运维中常见的 Docker 残留资源清理问题，尤其是 Portainer 重装时遇到的警告和报错
+- 方法/机制：通过 `docker stop` / `docker rm` 删除容器 → `docker volume rm` 删除数据卷 → `docker network rm` 删除网络 → `docker compose down` 清理 Compose 堆栈；对于遗留资源通过 `external: true` 配置复用或直接重建
+- 结论/价值：提供了从发现到彻底重装的完整操作流程，以及对两类常见 WARN 警告的根因分析和解决方案
+
+## Key Claims (用中文描述)
+- 运维人员可通过 `docker ps -a | grep portainer` 快速定位 Portainer 容器
+- 容器删除前必须先停止，否则需使用 `docker rm -f` 强制删除
+- 删除 `portainer_data` Volume 会永久丢失 Portainer 所有数据（用户、配置）
+- `docker compose down` 可一键清理整个 Compose 堆栈的容器、网络和（可选）卷
+- WARN 1 根因：之前的 compose 文件创建了 network，但新 compose 文件试图重建同名网络
+- WARN 2 根因：之前的 compose 项目使用了不同 project name，遗留了 Volume
+- 解决方案：在 compose 文件中声明 `external: true` 以复用旧网络/卷，或删除旧资源后重建
+
+## Key Quotes
+> "⚠️ 注意：这会删除 Portainer 所有数据（用户、配置）。如果你想保留数据，不要删 volume，只需要在 compose 文件里加：`external: true`" — 删除 Volume 前的警告，区分数据保留策略
+
+> "说明你之前用了别的 compose 文件部署过 Portainer" — WARN 1 的根因解释，network 冲突的场景
+
+> "说明你以前用不同 project 名字做过 Portainer" — WARN 2 的根因解释，Volume 隔离的项目命名机制
+
+## Key Concepts
+- [[Docker容器生命周期管理]]：容器的创建( create ) → 启动( start ) → 停止( stop ) → 删除( rm ) 完整流程管理
+- [[Docker Volume]]：容器持久化数据存储卷，通过 `docker volume ls` 查看，`docker volume rm` 删除
+- [[Docker Network]]：容器网络连接，通过 `docker network ls` 查看，`docker network rm` 删除
+- [[Docker Compose堆栈管理]]：通过 `docker compose down` 一次性清理整个堆栈的容器、网络和卷
+- [[external配置]]：compose 文件中 `external: true` 声明让 Docker 复用已存在的 Volume 或 Network 而非创建新的
+- [[Docker警告处理]]：Network 已存在警告和 Volume 属于其他项目的警告的标准排查思路
+
+## Key Entities
+- [[Portainer]]：Docker 可视化管理工具（portainer/portainer-ce），通过 Web UI 管理容器/卷/网络，支持 Edge Agent 集群管理
+- [[Docker]]：容器化平台，本文档所有操作的底层系统
+- [[Docker Compose]]：多容器应用的定义和编排工具，`docker compose down` 提供堆栈级清理能力
+
+## Connections
+- [[Portainer]] ← 部署于 ← [[Docker]]
+- [[Docker Compose]] ← 管理 ← [[Docker容器生命周期管理]]
+- [[Docker Volume]] ← 依赖 ← [[Docker]]
+- [[Docker Network]] ← 连接 ← [[Docker]]
+- [[external配置]] ← 解决 ← [[Docker警告处理]]
+
+## Contradictions
+- 与其他文档无已知冲突
--- a/wiki/sources/如何在ubuntu-server上通过nfs挂载synology-nas上的共享文件夹.md
+++ b/wiki/sources/如何在ubuntu-server上通过nfs挂载synology-nas上的共享文件夹.md
@@ -0,0 +1,59 @@
+---
+title: "如何在Ubuntu Server上通过NFS挂载Synology NAS上的共享文件夹"
+type: source
+tags: [nas, nfs, synology, ubuntu]
+date: 2025-12-29
+---
+
+## Source File
+- [[raw/Home Office/如何在Ubuntu Server上通过NFS挂载Synology NAS上的共享文件夹.md]]
+
+## Summary (用中文描述)
+- 核心主题：在 Ubuntu Server 上通过 NFS 协议挂载 Synology NAS 共享文件夹，实现服务器到 NAS 的自动化备份存储
+- 问题域：Samba 挂载丢失 Linux 文件权限信息导致 Docker 卷恢复失败；NFS 相比 Samba 完美保留文件所有权、性能更强
+- 方法/机制：
+  1. Synology NAS DSM 控制面板 → 共享文件夹 → NFS 权限配置（关键：Squash 设为"映射所有用户为 admin"）
+  2. Ubuntu 安装 nfs-common，mount -t nfs 挂载
+  3. /etc/fstab 写入永久挂载配置（关键参数：_netdev、timeo=900、retrans=5）
+  4. sudo mount -a 测试后再重启
+  5. 备份脚本前加挂载点检查防止数据写入本地磁盘
+  6. systemctl enable remote-fs.target 解决 nfs-common 启动慢问题
+- 结论/价值：NFS 是 Linux 服务器备份到 NAS 的最佳方案，配合 rsync + Cron 实现全自动化备份
+
+## Key Claims (用中文描述)
+- **NFS 相比 Samba 的核心优势**：NFS 原生保留 Linux 文件所有权信息，避免 Docker 卷恢复时的权限报错
+- **Synology NFS Squash 关键配置**：必须选择"映射所有用户为 admin"，否则 Ubuntu 端 root 发起的备份请求会在 NAS 端遭遇权限校验失败
+- **fstab _netdev 参数的作用**：告知系统这是网络设备，等网络服务完全启动后再尝试挂载，防止开机卡死
+- **永远不要直接重启测试**：/etc/fstab 写错会导致系统无法正常启动，必须先用 sudo mount -a 验证
+
+## Key Quotes
+> "NFS 会完美保留文件所有权信息，Samba 则会丢失 Linux 的文件所有权，导致恢复 Docker 卷时权限报错。" — NFS 相比 Samba 的优势说明
+
+> "_netdev: **关键参数**。告诉系统这是一个网络设备，务必等到网络服务完全启动后再尝试挂载，防止开机过程因找不到网络而卡死。" — fstab 参数解析
+
+> "千万不要直接重启！如果 `/etc/fstab` 写错了，系统可能无法正常启动。" — 配置验证警告
+
+> "如果在执行了上述操作后重启依然不生效，通常是因为 Ubuntu 的 `nfs-common` 服务启动慢于 `mount -a` 的执行。" — nfs-common 启动时序问题
+
+## Key Concepts
+- [[NFS]]：Network File System，Linux/Unix 系统的网络文件系统协议，Ubuntu 备份到 NAS 的推荐协议
+- [[永久挂载]]：通过 /etc/fstab 配置实现开机自动挂载，配合 _netdev 参数确保网络设备就绪后再挂载
+- [[挂载点检查]]：备份脚本执行前的安全验证，使用 mountpoint -q 命令检查挂载点有效性
+- [[NFS网络备份]]：通过 NFS 协议将备份数据存储到网络存储设备（与本文 Ubuntu rsync 备份场景互补）
+
+## Key Entities
+- [[Synology NAS DS718]]：群晖 NAS 设备（192.168.3.17），通过 DSM 控制面板配置 NFS 权限，作为 Ubuntu Server 的备份存储目标
+- [[Ubuntu Server]]：Linux 服务器发行版，运行 rsync 备份脚本，将数据写入 NAS 的 NFS 挂载点
+- [[rsync]]：增量文件同步工具，与 NFS 永久挂载配合实现 Ubuntu Server 到 NAS 的自动化日常备份
+
+## Connections
+- [[Ubuntu Server]] ← runs ← [[rsync]] (备份工具)
+- [[rsync]] ← writes to ← [[永久挂载]] (NFS 挂载点 /mnt/nas_backup)
+- [[永久挂载]] ← depends on ← [[NFS]] (NFS 协议)
+- [[Synology NAS DS718]] ← serves ← [[NFS]] (NFS 服务端)
+- [[挂载点检查]] ← guards ← [[rsync]] (备份安全前置检查)
+- [[Cron定时任务]] ← schedules ← [[rsync]] (定时触发备份)
+- [[NFS网络备份]] ← uses ← [[NFS]] (两者同属 NFS 存储应用场景)
+
+## Contradictions
+- 无冲突
--- a/wiki/sources/安装v2rayn.md
+++ b/wiki/sources/安装v2rayn.md
@@ -0,0 +1,66 @@
+---
+title: "安装v2rayN"
+type: source
+tags: [linux, v2rayn, windows, macos]
+date: 2026-04-14
+---
+
+## Source File
+- [[raw/Home Office/安装v2rayN.md]]
+
+## Summary (中文)
+- **核心主题**：v2rayN 跨平台代理客户端的官方发布包详解，涵盖 Windows/Linux/macOS 各平台下载选项、安装方式与依赖要求
+- **问题域**：如何为不同操作系统选择正确的 v2rayN 版本，以及各平台安装注意事项
+- **方法/机制**：
+  - zip 便携版：解压即用，数据存储在同目录，多份独立运行
+  - deb/rpm 安装版：存储在系统用户文件目录，通过 apt/dnf 安装
+  - WPF 版需额外安装 .NET 8 Desktop Runtime；Avalonia UI 版为自包含
+  - macOS DMG 版因无签名需执行 `xattr -cr` 修复
+  - 支持多核心：Xray、sing-box、mihomo
+- **结论/价值**：v2rayN 是支持 Windows/Linux/macOS 的可视化代理客户端，Windows 推荐 WPF 版，跨平台推荐 Avalonia UI 版；核心文件需单独下载
+
+## Key Claims (中文)
+- v2rayN 跨平台支持 Windows 10+、Linux（Debian 12+/Ubuntu 22.04+/Fedora 36+/RHEL 9+）、macOS 12+
+- zip 便携版解压后直接运行 `./v2rayN`，数据存放在程序同目录，可多份独立使用
+- deb/rpm 安装版存储位置为系统规定的用户文件目录
+- Windows x64 WPF 版需预装 Microsoft .NET 8.0 Desktop Runtime，Avalonia UI 版为自包含无需额外依赖
+- macOS DMG 版因应用无签名会提示"已损坏"，安装后需执行 `xattr -cr /Applications/v2rayN.app` 修复
+- 发布包内含部分 Core（Xray/sing-box/mihomo），其他 Core 需从 v2rayN-core-bin 仓库单独下载
+
+## Key Quotes
+> "zip 格式包为便携版，解压缩到文件夹后直接可以运行，存储文件位置为本文件夹；可以复制多份互相独立" — 官方说明
+> "v2rayN-windows-64.zip WPF实现的界面，需要安装 Microsoft .NET 8.0 Desktop Runtime" — Windows x64 WPF版依赖说明
+> "v2rayN-macos-64.dmg 由于安装包没有签名，会提示应用已损坏；安装后需要运行：xattr -cr /Applications/v2rayN.app" — macOS签名问题解决方案
+
+## Key Concepts
+- [[代理客户端]]：运行在终端设备上，通过代理协议连接远程节点的软件
+- [[代理协议]]：v2rayN 支持 VLESS/VMess/Trojan/SS 等协议
+- [[Reality]]：Xray 的流量伪装方案，v2rayN 可配合 Reality 节点使用
+- [[Avalonia UI]]：跨平台 .NET UI 框架，v2rayN Avalonia 版可运行在 Windows/Linux/macOS，无需额外运行时依赖
+- [[WPF]]：Windows Presentation Foundation，Windows 原生 UI 框架，.NET 桌面应用首选
+- [[.NET Desktop Runtime]]：.NET 桌面运行时环境，WPF 应用必需依赖
+- [[便携版]] vs [[安装版]]：便携版数据自包含、安装版数据放系统目录
+- [[代理核心]]：代理客户端的底层引擎，如 Xray、sing-box、mihomo
+
+## Key Entities
+- [[v2rayN]]：主产品，GitHub 2dust 维护的跨平台代理客户端，支持多种协议和核心
+- [[Xray]]：v2rayN 支持的代理核心之一，Reality 流量伪装方案的内核
+- [[sing-box]]：v2rayN 支持的代理核心，支持多协议
+- [[mihomo]]：v2rayN 支持的代理核心，mihomo 协议实现
+- [[2dust]]：v2rayN GitHub 仓库维护者
+- [[Microsoft .NET 8.0 Desktop Runtime]]：Windows WPF 版的必需运行时环境
+- [[Avalonia UI]]：跨平台 UI 框架，v2rayN desktop 版基于此构建
+
+## Connections
+- [[v2rayN]] ← 使用 ← [[Xray]]
+- [[v2rayN]] ← 使用 ← [[sing-box]]
+- [[v2rayN]] ← 使用 ← [[mihomo]]
+- [[v2rayN]] ← 依赖 ← [[Microsoft .NET 8.0 Desktop Runtime]]（WPF 版）
+- [[v2rayN]] ← 基于 ← [[Avalonia UI]]（desktop 版）
+- [[3X-UI]] ← 服务端 ← [[Xray]]（v2rayN 的服务端 counterpart）
+- [[v2rayNG]] ← 移动版 ← [[v2rayN]]（Android 版）
+- [[Bandwagon VPS]] ← 托管 ← [[3X-UI]] + [[Xray]]（服务端节点）
+
+## Contradictions
+- 与 [[3x-ui-xray-on-bandwagonvps]] 互补而非冲突：v2rayN 是客户端，3X-UI 是服务端管理面板，共同构成完整代理链路（服务端 Xray ←→ 客户端 v2rayN）
+- 与 [[ubuntu-server科学上网]] 各有侧重：v2rayN 提供图形界面，命令行代理适合服务器/路由器场景
--- a/wiki/sources/家庭网络环境概览_2026-04-03.md
+++ b/wiki/sources/家庭网络环境概览_2026-04-03.md
@@ -0,0 +1,101 @@
+---
+title: "家庭网络环境概览"
+type: source
+tags: [home-office, nas, synology, ubuntu, vps]
+date: 2026-04-03
+---
+
+## Source File
+- [[raw/Home Office/家庭网络环境概览_2026-04-03.md]]
+
+## Summary (用中文描述)
+- **核心主题**：星曜家庭网络基础设施的完整架构图谱，涵盖5大节点（1个公网VPS + 1个Mac Mini + 1个Synology NAS + 2个Ubuntu Server），近50个Docker应用服务的部署现状、端口映射与公网访问方案。
+- **问题域**：如何将分散在多个物理位置和内网的服务，通过FRP内网穿透 + Caddy反向代理 + Cloudflare DNS，实现统一的HTTPS公网访问？
+- **方法/机制**：
+  - **FRP**（frps/frpc）：在内网各节点部署frpc客户端，公网VPS运行frps服务端，通过TCP隧道将内网端口映射到公网；
+  - **Caddy**：在公网VPS上运行，自动申请Let's Encrypt证书，根据域名将请求反向代理到对应的FRP映射端口；
+  - **Cloudflare**：托管 ishenwei.online 域名的DNS解析，将子域名A记录指向VPS公网IP；
+  - **Docker Compose**：各节点上的服务通过Docker Compose管理，独立部署、版本隔离。
+- **结论/价值**：该架构实现了"零静态IP依赖"的公网访问方案，所有内网服务均可通过 *.ishenwei.online 子域名从公网访问，同时保持了内网服务的隐私性和低带宽成本。
+
+## Key Claims (用中文描述)
+- VPS（192.227.222.142）通过FRP Server（端口7000）+ Caddy Web服务器，为全网内网服务提供统一的HTTPS公网入口。
+- Mac Mini M4（192.168.3.189）作为主控节点，运行OpenClaw AI助手框架、vaultwarden密码管理器及STQ项目管理系统。
+- Synology NAS DS718（192.168.3.17）托管了媒体服务（Jellyfin/Navidrome）、监控栈（Prometheus/Alertmanager/node_exporter）、密码管理（vaultwarden）、云盘挂载（CloudDrive2）等核心应用。
+- Ubuntu Server 1（192.168.3.47）承担监控可视化（Grafana/Superset）、个人导航（Homarr）、BT下载（Transmission）等面向公网的服务。
+- Ubuntu Server 2（192.168.3.45）运行n8n工作流自动化、Gitea自建Git服务及TikTok项目管理系统（DEV环境）。
+- 科学上网代理（SOCKS5: 10808）在Mac mini、ubuntu1、ubuntu2上均正常，仅NAS（端口20170）仅本机监听。
+
+## Key Quotes
+> "Caddy — 现代化 Web 服务器，自带 HTTPS 自动化证书申请，常作为前置反向代理处理业务流量。" — 域名映射表说明
+
+> "FRP Server — 高性能内网穿透服务端（frps），负责将内网 NAS 或本地开发环境的服务暴露至公网访问。端口 7000" — VPS应用说明
+
+> "n8n 已迁移至 Ubuntu2，Mac Mini 不再暴露 n8n 端口" — Mac Mini FRP配置说明
+
+## Key Concepts
+- [[内网穿透]]：通过FRP反向隧道将内网服务暴露至公网访问的完整方案，包含frps（服务端）和frpc（客户端）两个组件。
+- [[反向代理]]：通过Caddy根据域名将公网HTTPS请求反向代理到内网FRP映射端口的机制。
+- [[HTTPS自动化证书]]：Caddy自动申请和管理Let's Encrypt SSL证书的机制。
+- [[Docker Compose]]：各节点服务通过YAML文件声明式定义和管理的多容器编排工具。
+- [[时序数据库]]：Prometheus作为监控数据的时序数据库，用于采集和存储node_exporter/cAdvisor/blackbox_exporter的指标。
+- [[告警管理]]：Alertmanager处理Prometheus告警的分组、抑制、静默和多通道路由。
+- [[SOCKS5代理]]：本地科学上网代理协议，监听127.0.0.1:10808。
+- [[DNS托管]]：Cloudflare免费提供域名DNS解析服务，含CDN和SSL。
+
+## Key Entities
+- [[RackNerd]]：VPS提供商，托管公网VPS1（192.227.222.142），提供frps和Caddy服务。
+- [[Mac Mini M4]]：Apple Silicon Mac Mini作为家庭服务器主控节点（192.168.3.189），运行OpenClaw、vaultwarden、STQ项目等应用。
+- [[Synology NAS DS718]]：群晖NAS设备（192.168.3.17），运行DSM管理界面及Calibre/MinIO/Zipline/Navidrome/Jellyfin等Docker应用。
+- [[Ubuntu Server]]：两个内网Ubuntu服务器节点（Ubuntu1: 192.168.3.47, Ubuntu2: 192.168.3.45），承担监控/导航/下载/工作流/Git等服务。
+- [[Caddy]]：公网VPS上的自动HTTPS反向代理服务器，绑定*.ishenwei.online域名。
+- [[FRP]]：内网穿透工具（frps/frpc v0.65.0），实现内网端口到公网端口的TCP隧道映射。
+- [[Prometheus]]：时序数据库监控系统，在NAS和Ubuntu1上运行，采集node_exporter/cAdvisor/blackbox_exporter指标。
+- [[Grafana]]：监控可视化平台（Ubuntu1:13000），通过Dashboard ID导入官方模板。
+- [[vaultwarden]]：轻量级Bitwarden密码管理器服务端，在Mac Mini和NAS上均有部署。
+- [[Jellyfin]]：开源媒体服务器，在NAS上运行（端口8096），公网通过FRP+Caddy访问。
+- [[Navidrome]]：开源音乐流媒体服务器，Subsonic API兼容，在NAS上运行（端口4533）。
+- [[Transmission]]：BT下载客户端，在Ubuntu1上运行（端口9091），公网通过FRP+Caddy访问。
+- [[n8n]]：工作流自动化平台，已从Mac Mini迁移至Ubuntu2（端口5678），公网通过FRP+Caddy访问。
+- [[Portainer]]：Docker容器可视化管理界面，在NAS、Ubuntu1、Ubuntu2上均有部署。
+- [[Homarr]]：个人导航页面/仪表板，在Ubuntu1上运行（端口7575），公网通过FRP+Caddy访问。
+- [[Apache Superset]]：开源BI平台，在Ubuntu1上运行（端口8777），公网通过FRP+Caddy访问。
+- [[Zipline]]：自托管图床应用，在NAS上运行（端口3333），后端为PostgreSQL。
+- [[MinIO]]：S3兼容对象存储，在NAS上运行（端口9001），作为Zipline的存储后端。
+- [[Cloudflare]]：DNS托管服务商，免费提供CDN和SSL证书，托管ishenwei.online域名。
+- [[OpenClaw]]：AI助手框架，在Mac Mini上运行（端口8080），星曜的主要运行环境。
+- [[Calibre]]：电子书库管理工具，在NAS上运行（端口8083），公网通过FRP+Caddy访问。
+- [[v2rayA]]：V2Ray图形化代理客户端，在NAS上运行（端口2017），SOCKS5仅本机监听。
+- [[CloudDrive2]]：多云盘挂载工具，在NAS上运行（端口19798），支持阿里云盘等。
+- [[Alertmanager]]：Prometheus告警分发组件，在NAS和Ubuntu1上运行（端口9093）。
+- [[node_exporter]]：Prometheus官方主机指标采集器，以host network模式运行。
+- [[cAdvisor]]：Google开源容器资源监控工具，挂载Docker socket采集容器级指标。
+- [[blackbox_exporter]]：Prometheus官方黑盒探测exporter，支持HTTP/TCP/ICMP/DNS/TLS探测。
+- [[nginx-proxy-manager]]：反向代理管理工具，在Ubuntu1上运行（端口81）。
+- [[Gitea]]：自建Git服务，在Ubuntu2上运行（端口3000）。
+- [[Draw.io]]：在线图表编辑器，在Ubuntu2上运行（端口8085），公网通过FRP+Caddy访问。
+- [[it-tools]]：开源开发者工具集合，在Ubuntu1和Ubuntu2上运行（端口8999），提供URL编解码、UUID生成、哈希计算等100+工具。
+
+## Connections
+- [[Caddy]] ← 反向代理 ← [[FRP]]（Caddy将HTTPS请求代理到FRP映射端口）
+- [[Cloudflare]] ← DNS托管 ← [[Caddy]]（DNS A记录指向VPS公网IP）
+- [[Prometheus]] ← 指标采集 ← [[node_exporter]] + [[cAdvisor]] + [[blackbox_exporter]]
+- [[Grafana]] ← 数据源 ← [[Prometheus]]（Grafana消费Prometheus指标）
+- [[Alertmanager]] ← 告警路由 ← [[Prometheus]]（Prometheus触发告警后发送至Alertmanager）
+- [[Zipline]] ← 存储后端 ← [[MinIO]]（Zipline使用MinIO存储图片）
+- [[Zipline]] ← 数据库 ← [[PostgreSQL]]（NAS上zipline_postgres容器）
+- [[Jellyfin]] ← 下载来源 ← [[Transmission]]（下载→整理→播放工作流）
+- [[Navidrome]] ← 同 ← [[Jellyfin]]（均为媒体服务，下载→播放工作流）
+- [[OpenClaw]] ← 运行平台 ← [[Mac Mini M4]]（OpenClaw的主要运行环境）
+- [[n8n]] ← 数据存储 ← [[PostgreSQL]]（Ubuntu2上n8n_postgres容器）
+- [[Cloudflare]] ← DNS ← [[RackNerd]]（VPS IP: 192.227.222.142）
+- [[FRP]] ← 客户端节点 ← [[Mac Mini M4]] + [[Synology NAS DS718]] + [[Ubuntu Server 1]] + [[Ubuntu Server 2]]（4个frpc客户端）
+- [[FRP]] ← 服务端 ← [[RackNerd]]（VPS运行frps服务端）
+- [[Docker Compose]] ← 部署载体 ← [[Prometheus]] + [[Grafana]] + [[Jellyfin]] + [[Navidrome]] + [[n8n]] + [[Zipline]] + [[MinIO]] + [[v2rayA]] + [[vaultwarden]] + [[Portainer]] + [[Homarr]] + [[Apache Superset]] + [[Gitea]] + [[it-tools]]（所有Docker应用均通过Docker Compose部署）
+
+## Contradictions
+- 与 [[ubuntu-server科学上网]] 冲突：
+  - **冲突点**：NAS上v2rayA的SOCKS5代理（端口20170）状态为"仅本机监听"，而ubuntu-server科学上网方案强调Docker Daemon也需要代理配置。
+  - **当前观点**：v2rayA在NAS上运行但仅本机监听，Docker pull仍可能受限。
+  - **对方观点**：Ubuntu Server可通过ProxyChains/Docker Daemon Proxy显式配置代理，覆盖终端和Docker Daemon两层。
+  - **Resolution**：v2rayA仅覆盖NAS本身，NAS上Docker pull可能还需配置Docker Daemon Proxy（参考[[群晖NAS科学上网]]方案）。
--- a/wiki/sources/用docker安装apache-superset.md
+++ b/wiki/sources/用docker安装apache-superset.md
@@ -0,0 +1,49 @@
+---
+title: "用Docker安装Apache Superset"
+type: source
+tags: [apache, bi, docker, mysql, superset]
+date: 2026-04-14
+---
+
+## Source File
+- [[raw/Home Office/用Docker安装Apache Superset.md]]
+
+## Summary (用中文描述)
+- 核心主题：通过 Docker 快速部署 Apache Superset 开源 BI 平台，包含镜像拉取、容器启动、管理员账户创建、数据库迁移、示例数据加载等完整 6 步初始化流程
+- 问题域：Home Server 场景下自托管 BI 可视化平台的 Docker 容器化部署
+- 方法/机制：使用 Docker Hub 官方镜像 `apache/superset:GHA-19524015706`（GHA 构建版本），通过 `docker pull` + `docker run` + `docker exec` 初始化三步骤完成部署，端口映射 8777:8088，数据库使用内置 SQLite
+- 结论/价值：提供一套可快速落地的自托管 BI 平台部署方案，适合家庭服务器场景的轻量级数据可视化
+
+## Key Claims (用中文描述)
+- Apache Superset 通过 Docker 容器化部署可实现一键启动，是 Home Server 场景下的轻量级 BI 可视化方案
+- 通过 `superset fab create-admin` 命令行交互式创建首个管理员账户（用户名/邮箱/密码）
+- 通过 `superset db upgrade` 执行数据库迁移，确保 Superset 元数据存储就绪
+- 通过 `superset load_examples` 加载示例数据集，新用户可快速熟悉 BI 平台功能
+- 通过 `superset init` 完成初始化，使平台进入可用状态
+
+## Key Quotes
+> "docker run -d -p 8777:8088 -e \"SUPERSET_SECRET_KEY=*** --name superset apache/superset:GHA-19524015706"
+> — 容器启动命令，8777 映射到容器内 8088，设置了安全密钥环境变量
+
+> "docker exec -it superset superset fab create-admin --username admin --firstname Superset --lastname Admin --email admin@superset.com --password admin"
+> — 管理员账户创建命令，通过 flask-appbuilder (fab) CLI 创建首个 admin 用户
+
+## Key Concepts
+- [[BI平台]]：Business Intelligence 平台，提供数据可视化、仪表盘构建、SQL 查询等功能
+- [[Docker容器化部署]]：通过 Docker 镜像封装应用依赖，实现环境一致性和快速部署
+- [[Flask-AppBuilder]]：Superset 的 Web 框架，基于 Flask 的认证和权限管理组件
+- [[数据库迁移]]：通过 `db upgrade` 命令初始化或升级 Superset 元数据数据库
+
+## Key Entities
+- [[Apache Superset]]：Apache 软件基金会旗下的开源 BI 平台，支持多样化图表和仪表盘构建
+- [[Docker]]：容器化平台，Superset 的部署底座
+- [[MySQL]]：Superset 支持的外部数据库后端（标签提及），默认使用 SQLite
+
+## Connections
+- [[Apache Superset]] ← deployed_by ← [[Docker]]
+- [[Home Server Automation]] ← part_of ← [[家庭网络环境概览]]
+- [[Apache Superset]] ← use_case ← [[数据可视化]]
+- [[Portainer]] ← alternative_admin_ui ← [[Docker]]
+
+## Contradictions
+- 无冲突
--- a/wiki/sources/用docker安装homarr.md
+++ b/wiki/sources/用docker安装homarr.md
@@ -0,0 +1,47 @@
+---
+title: "用Docker安装Homarr"
+type: source
+tags: [docker, homarr]
+date: 2026-04-14
+---
+
+## Source File
+- [[Home Office/用Docker安装Homarr.md]]
+
+## Summary（用中文描述）
+- 核心主题：通过 Docker Compose 在 Home Server 上部署 Homarr 个人导航仪表盘
+- 问题域：Homarr 是一款开源服务器/服务仪表盘工具，用于集中展示和管理家庭网络中的各类自托管服务
+- 方法/机制：使用 docker-compose.yml 定义 Homarr 容器，通过卷挂载持久化配置数据，通过环境变量配置加密密钥和代理
+- 结论/价值：提供统一的 Web UI 入口，方便查看和管理 Jellyfin、n8n、Prometheus 等多个自托管服务
+
+## Key Claims（用中文描述）
+- Homarr 官方通过 GitHub Container Registry 发布 Docker 镜像（ghcr.io/homarr-labs/homarr）
+- Homarr 支持挂载 /var/run/docker.sock 以直接集成 Docker 容器状态监控
+- Homarr 依赖 SECRET_ENCRYPTION_KEY 环境变量进行数据加密
+
+## Key Quotes
+> "image: ghcr.io/homarr-labs/homarr" — 官方镜像来源为 GitHub Container Registry
+> "ports: - '7575:7575'" — Homarr 默认 Web UI 端口为 7575
+> "- /var/run/docker.sock:/var/run/docker.sock" — 挂载 Docker Socket 以获取容器信息
+> "- ALL_PROXY=socks5://172.24.0.1:10808" — 通过宿主机 SOCKS5 代理访问外网
+
+## Key Concepts
+- [[Docker Compose]]：通过 YAML 配置文件声明式定义 Homarr 服务
+- [[Docker卷]]：/appdata 卷挂载用于持久化 Homarr 的配置数据
+- [[Homarr]]：开源自托管服务仪表盘（Home Server Dashboard）
+- [[环境变量代理]]：通过 ALL_PROXY 环境变量配置容器级代理
+- [[SOCKS5代理]]：Homarr 容器通过 socks5://172.24.0.1:10808 访问外部网络
+
+## Key Entities
+- [[Homarr]]：开源服务器仪表盘项目，提供 Homarr Labs 维护的官方 Docker 镜像
+
+## Connections
+- [[用docker安装jellyfin]] ← related_service ← [[用docker安装homarr]]
+- [[用docker安装n8n]] ← related_service ← [[用docker安装homarr]]
+- [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]] ← related_service ← [[用docker安装homarr]]
+
+## Contradictions
+- 与 [[用docker安装portainer]] 冲突：
+  - 冲突点：两者都提供 Docker 容器管理能力
+  - 当前观点：Homarr 提供服务层面的统一导航仪表盘，整合多个服务状态；Portainer 提供专业的 Docker 运维 Web UI
+  - 对方观点：Portainer 功能更全面，可管理容器/网络/卷/镜像等底层资源
--- a/wiki/sources/用docker安装jellyfin.md
+++ b/wiki/sources/用docker安装jellyfin.md
@@ -0,0 +1,48 @@
+---
+title: "用Docker安装Jellyfin"
+type: source
+tags: [docker, jellyfin, movie, nas, synology, tv-show]
+date: 2026-04-14
+---
+
+## Source File
+- [[raw/Home Office/用Docker安装Jellyfin.md]]
+
+## Summary (用中文描述)
+- 核心主题：通过 Docker Compose 在群晖 NAS 上部署 Jellyfin 视频媒体服务器，实现家庭媒体中心
+- 问题域：家庭影院、个人媒体库、NAS 多媒体服务
+- 方法/机制：使用 nyanmisaka/jellyfin 镜像（预装硬件转码优化），通过 Docker Compose YAML 配置服务，启用 Intel QuickSync 硬件加速转码（/dev/dri 设备直通），配置多目录媒体挂载、群晖 UID/GID 用户权限、自定义字体、时区和外网发布 URL
+- 结论/价值：构建完整的"Transmission 下载 → Jellyfin 播放"家庭媒体工作流，支持视频转码以适配不同客户端
+
+## Key Claims (用中文描述)
+- nyanmisaka/jellyfin 镜像通过预装 FFmpeg 和硬件转码依赖，提供开箱即用的 Intel QuickSync 加速能力
+- 群晖 NAS 使用 `user: "1026:100"` 固定 UID:GID，可避免容器内文件权限问题
+- `/dev/dri` 设备直通使容器内 Jellyfin 可调用宿主机的 GPU 进行硬件视频转码
+- Jellyfin 默认端口 8096，UDP 端口 7359 用于自动发现
+
+## Key Quotes
+> "核心优化：挂载硬件渲染设备以实现 Intel QuickSync 转码" — 硬件加速转码是 Jellyfin 在 NAS 上的性能关键
+
+## Key Concepts
+- [[硬件转码]]：通过 Intel QuickSync / NVIDIA GPU / VA-API 等硬件加速视频编解码，相比软件转码大幅降低 CPU 占用
+- [[媒体服务器]]：提供视频/音乐流媒体播放服务的自托管应用，Jellyfin 属于此类
+- [[Docker 用户权限映射]]：通过 PUID/PGID 或 user 字段将容器内用户映射到宿主机特定用户，解决文件读写权限问题
+- [[设备直通]]：通过 Docker devices 参数将宿主机设备（如 GPU、硬件编码器）映射到容器内使用
+
+## Key Entities
+- [[Jellyfin]]：开源视频媒体服务器，本文部署的目标服务，提供网页端播放和管理界面
+- [[nyanmisaka/jellyfin]]：社区维护的 Jellyfin Docker 镜像，预装优化版 FFmpeg 和硬件转码支持
+- [[群晖 NAS]]（Synology NAS）：NAS 设备类型，本文 Jellyfin 的宿主机，提供 /volume1/docker 存储路径
+- [[Intel QuickSync]]：Intel CPU 集成视频编码/解码硬件单元，通过 /dev/dri 接口访问
+- [[LinuxServer.io]]：开源 Docker 镜像维护组织，Jellyfin 官方镜像由其维护，nyanmisaka 是社区优化分支
+
+## Connections
+- [[Transmission]] ← 下载端 ← [[Jellyfin]]（播放端）— "下载→整理→播放" 家庭媒体工作流
+- [[Navidrome]] ← 对标竞品 ← [[Jellyfin]] — Navidrome 服务音乐，Jellyfin 服务视频
+- [[用docker安装transmission]] ← 共用宿主机 ← [[用docker安装jellyfin]] — 共用 Docker 环境和 NAS 存储
+- [[群晖 NAS]] ← 宿主机 ← [[用docker安装jellyfin]] — NAS 提供 Docker 环境和存储卷
+- [[Intel QuickSync]] ← 依赖 ← [[Jellyfin]] — QuickSync 提供硬件转码加速
+- [[Docker卷]] ← 数据存储 ← [[Jellyfin]] — config 和 cache 目录持久化
+
+## Contradictions
+- 无已知冲突
--- a/wiki/sources/用docker安装portainer.md
+++ b/wiki/sources/用docker安装portainer.md
@@ -0,0 +1,50 @@
+---
+title: "用Docker安装Portainer"
+type: source
+tags: [docker, portainer]
+date: 2026-04-14
+---
+
+## Source File
+- [[raw/Home Office/用Docker安装Portainer.md]]
+
+## Summary (用中文描述)
+- **核心主题**：通过 Docker Compose 在 Home Server 上部署 Portainer 容器管理 Web UI
+- **问题域**：家庭服务器 Docker 容器运维管理
+- **方法/机制**：使用 docker-compose.yml 定义 Portainer 服务，通过 Docker socket 直通实现宿主机 Docker 守护进程的 Web 可视化管理
+- **结论/价值**：提供图形化界面管理 Docker 容器/镜像/卷/网络，降低命令行运维门槛
+
+## Key Claims (用中文描述)
+- **Portainer** 通过 `docker.sock` 挂载实现对宿主机 Docker 守护进程的完整访问控制
+- 使用 **portainer/portainer-ce:lts** 镜像部署 Portainer Community Edition 长期支持版
+- 配置 `restart: always` 确保容器在宿主机重启后自动恢复
+- 映射端口 `9443:9443` 提供 HTTPS API Web 界面，`8000:8000` 支持 Edge Agent 通信
+- 持久化数据存储在 Docker 卷 `portainer_data:/data`
+
+## Key Quotes
+> "create docker-compose.yml" — 部署起点，docker-compose 是 Portainer 部署的标准方式
+
+> "`docker-compose run -d`" — 容器启动命令，后台守护模式运行
+
+## Key Concepts
+- [[Docker可视化管理工具]]：提供 Web UI 替代命令行管理 Docker 容器、镜像、卷、网络
+- [[Docker Socket]]：`/var/run/docker.sock` 是 Docker 守护进程的 Unix socket，挂载到容器内实现特权访问
+- [[Docker卷]]：`portainer_data` Docker 卷用于持久化 Portainer 自身数据（配置、密码等）
+
+## Key Entities
+- [[Portainer]]：开源 Docker 可视化管理工具，提供 Web UI 管理容器/镜像/卷/网络
+- [[Portainer CE LTS]]：Portainer Community Edition 长期支持版本
+
+## Connections
+- [[Portainer]] ← 依赖 ← [[Docker Engine]]（宿主机 Docker 守护进程）
+- [[Portainer]] ← 使用 ← [[Docker Socket]]（socket 直通实现特权访问）
+- [[Portainer]] ← 存储数据在 ← [[Docker卷]]（portainer_data 卷）
+- [[Portainer]] ← 属于 ← [[Docker可视化管理工具]]（替代命令行运维）
+
+## Contradictions
+- 无冲突
+
+## Related Sources
+- [[用docker安装transmission]] — 同属 Home Office Docker 部署系列
+- [[用docker安装jellyfin]] — 同属 Home Office Docker 部署系列
+- [[用docker安装navidrome]] — 同属 Home Office Docker 部署系列
--- a/wiki/sources/群晖nas科学上网方法.md
+++ b/wiki/sources/群晖nas科学上网方法.md
@@ -0,0 +1,53 @@
+---
+title: "群晖NAS科学上网方法"
+type: source
+tags: [docker, nas, synology, v2raya, vpn]
+date: 2025-03-08
+---
+
+## Source File
+- [[raw/Home Office/群晖NAS科学上网方法.md]]
+
+## Summary (用中文描述)
+- **核心主题：** 在群晖 NAS（Synology DSM）上通过 V2RayA 代理实现 Docker 容器透明代理，使 NAS 上的 Docker 可以访问 Docker Hub 等被墙的国外资源
+- **问题域：** 国内网络环境下 NAS Docker pull/pull image 困难；V2RayA 透明代理对 Docker Daemon 网络栈的兼容性挑战
+- **方法/机制：** 两层方案——① V2RayA Docker 容器 + 透明代理（分流模式：大陆白名单）；② Docker Daemon HTTP Proxy 配置（兜底方案）
+- **结论/价值：** 透明代理在群晖 DSM 7.x 中对 Docker Daemon 网络栈不一定生效；显式配置 Docker Daemon Proxy 环境变量是更可靠的 Engineering Best Practice
+
+## Key Claims (用中文描述)
+- V2RayA 在群晖 DSM 7.x 环境下透明代理不一定对 Host（NAS 本机）生效，可能与 DSM 防火墙或路由表冲突
+- Docker Daemon (dockerd) 的网络栈在群晖 DSM 7.x 中不完全遵循 v2rayA 修改的 iptables 规则
+- 显式配置 Docker Daemon 的 HTTP Proxy 环境变量（`/etc/systemd/system/`）比依赖 NAS Host 透明代理更符合工程最佳实践
+- 验证流程：`curl -x` 测端口 → `curl` 直连测透明代理 → `docker pull` 实战验证
+
+## Key Quotes
+> "对于企业级或生产环境（即使是 SOHO），我建议**不要**依赖 NAS Host 的透明代理来解决 `docker pull` 问题，因为这修改了系统级路由表，容易影响 NAS 其他服务。**显式配置 Docker Daemon 的 Proxy 环境变量（上面的最后一种方法）是更符合 Engineering Best Practice 的做法。**" — 经验总结
+
+> "⚠️ 风险提示：在 NAS 上开启透明代理（尤其是 Host 模式）有极小概率会导致局域网连接中断。如果你正在远程操作，请确保有备用连接方案（如 QuickConnect 或同局域网设备）。" — 操作警告
+
+## Key Concepts
+- [[透明代理]]：V2RayA 通过修改 iptables 规则劫持系统出站流量，国内流量直连、国外流量走代理的分流模式
+- [[Docker Daemon Proxy]]：Docker 守护进程的 HTTP/HTTPS 代理配置，通过 systemd 环境变量注入，使 `docker pull` 显式走代理而非依赖系统透明代理
+- [[分流模式]]：V2RayA 路由策略，"大陆白名单"模式下仅代理非中国大陆流量，减少不必要的代理开销
+- [[iptables]]：Linux 内核防火墙，V2RayA 通过修改 iptables 规则实现透明代理
+
+## Key Entities
+- [[V2RayA]]：V2Ray 的 Web 可视化管理界面，基于 V2Ray 内核，支持透明代理和多种分流策略
+- [[群晖 NAS]]：Synology NAS 设备，运行 DSM 操作系统，Docker 环境为 ContainerManager (DSM 7.x)
+- [[Docker]]：容器化平台，群晖通过 ContainerManager 套件提供 Docker 支持
+- [[Docker Hub]]：Docker 官方镜像仓库，国内访问受限，是科学上网的主要需求驱动
+- [[DSM 7.x]]：群晖 DiskStation Manager 7.x 版本，Docker 服务名为 ContainerManager（旧版叫 Docker）
+
+## Connections
+- [[V2RayA]] ← 部署于 ← [[群晖 NAS]]
+- [[透明代理]] ← 依赖 ← [[iptables]]
+- [[Docker Daemon Proxy]] ← 解决 ← 透明代理对 Docker 无效的场景
+- [[分流模式]] ← 配置于 ← [[V2RayA]]
+- [[群晖NAS科学上网]] ← 扩展 ← [[ubuntu-server科学上网]]（终端代理场景）
+
+## Contradictions
+- 与"路由器科学上网"方案（[[MerlinClash插件]]）对比：
+  - **冲突点：** 路由器作为全屋透明网关 vs NAS 终端代理
+  - **当前观点（本文）：** NAS 终端配置 Docker Daemon Proxy 是针对 Docker 场景的精确解决方案
+  - **对方观点（路由方案）：** 路由器透明代理覆盖所有设备，无需逐设备配置
+  - **结论：** 两者互补，路由器作为主网关，NAS 按需单独配置 Docker 代理