Auto-sync: 2026-04-27 00:02

wiki/sources/mac-mini-安装-frp-0-65-0-arm64-操作笔记.md

@@ -1,81 +1,135 @@
----
-title: "Mac Mini 安装 FRP 0.65.0（ARM64）操作笔记"
-type: source
-tags: [frp, frpc, gatekeeper, mac-mini, macos, arm64]
-date: 2026-04-14
----
-
-## Source File
-- [[raw/Home Office/Mac Mini 安装 FRP 0.65.0（ARM64）操作笔记.md]]
-
-## Summary (用中文描述)
-- **核心主题**：在 Apple Silicon（ARM64）Mac Mini M4 上安装配置 FRP 0.65.0 内网穿透客户端，实现通过公网 VPS 远程访问本地服务
-- **问题域**：macOS 服务器化运维、内网穿透、远程访问
-- **方法/机制**：通过 FRP（frpc）客户端连接远程 VPS（frps）建立反向隧道，结合 tmux/nohup/launchd 三种方式实现后台持久运行
-- **结论/价值**：提供完整的 Mac Mini 服务器化运维指南，包含 macOS 特有障碍（Gatekeeper）的解决方案
-
-## Key Claims (用中文描述)
-- macOS 默认 `/opt` 目录需要手动创建并授权才能使用
-- macOS Gatekeeper 会阻止未签名程序运行，必须通过 `xattr -rd com.apple.quarantine .` 解除限制
-- launchd 是 macOS 推荐的开机自启服务管理方式，可通过 `launchctl` 管理生命周期
-- 软链接（symlink）策略可实现 FRP 版本无缝切换
-
-## Key Quotes
-> "macOS 默认 `/opt` 需要手动创建" — 说明了 macOS 与 Linux 目录结构的差异，需手动初始化系统目录
-> "xattr -rd com.apple.quarantine ." — macOS 特有的安全限制解除命令，针对整个目录递归执行
-> "launchd（推荐开机自启）" — macOS 原生服务管理器，是进程持久化的推荐方案
-
-## Key Concepts
-- [[内网穿透]]：通过反向隧道技术，使公网用户能够访问处于 NAT 或防火墙后的内网服务
-- [[frp]]：Fast Reverse Proxy，开源内网穿透工具，包含 frps（服务端）和 frpc（客户端）
-- [[TCP隧道]]：基于 TCP 协议的端口转发机制，将本地端口映射到远程服务器
-- [[launchd]]：macOS 原生服务管理器，用于管理系统级和用户级守护进程
-
-## Key Entities
-- [[Mac Mini M4]]：Apple Silicon Mac Mini，作为家庭服务器运行 FRP 客户端
-- [[VPS]]：公网虚拟专用服务器，运行 frps 作为内网穿透的中转站（IP: 192.227.222.142）
-- [[frpc]]：FRP 客户端程序，运行在 Mac Mini 上，建立与 frps 的连接
-- [[frps]]：FRP 服务端程序，运行在 VPS 上，接收公网请求并转发到 frpc
-- [[Gatekeeper]]：macOS 安全机制，阻止未签名应用运行
-
-## Connections
-- [[Mac Mini M4]] ← runs_on ← [[frpc]]
-- [[VPS]] ← runs_on ← [[frps]]
-- [[frpc]] ← creates_tunnel ← [[frps]]
-- [[内网穿透]] ← enables ← [[远程SSH访问]]
-- [[launchd]] ← manages ← [[frpc]] 进程生命周期
-- [[Gatekeeper]] ← blocks ← [[frpc]] (需解除)
-
-## Contradictions
-- 无已知冲突
-
-## Environment Details
-| 项目 | 内容 |
-|------|------|
-| 系统 | macOS（Mac Mini M4）|
-| 架构 | Apple Silicon (ARM64) |
-| 软件 | FRP 0.65.0 |
-| 安装目录 | `/opt/frp/frp_0.65.0_darwin_arm64` |
-| 客户端程序 | `frpc` |
-| 配置文件 | `frpc.toml` |
-| frps服务器 | 192.227.222.142:7000 |
-| frps映射端口 | 6000（SSH）|
-
-## Installation Steps
-1. 创建安装目录：`sudo mkdir -p /opt/frp && sudo chown -R $(whoami) /opt/frp`
-2. 下载 ARM64 版本：`wget https://github.com/fatedier/frp/releases/download/v0.65.0/frp_0.65.0_darwin_arm64.tar.gz`
-3. 解压：`tar -xzf frp_0.65.0_darwin_arm64.tar.gz`
-4. 解除 Gatekeeper：`xattr -rd com.apple.quarantine .`
-5. 配置 frpc.toml：设置 serverAddr、serverPort、auth.token 和 proxies
-6. 启动 frpc：`./frpc -c frpc.toml`
-
-## Background Running Methods
-1. **tmux**（推荐开发环境）：创建持久会话，断开 SSH 后仍保持运行
-2. **nohup**（简单后台）：重定向输出到日志文件，适合简单部署
-3. **launchd**（生产环境）：系统级服务，开机自启，推荐使用 plist 配置
-
-## Best Practices
-- 统一安装路径：`/opt/frp/<version>` 便于版本管理
-- 创建软链接：`ln -sfn /opt/frp/frp_0.65.0_darwin_arm64 /opt/frp/current` 简化启动命令
-- 日志独立存储：配置 StandardOutPath 和 StandardErrorPath 分离日志
-- 进程守护：使用 launchd KeepAlive=true 确保服务持续运行
+---
+title: "Mac Mini 安装 FRP 0.65.0（ARM64）操作笔记"
+type: source
+tags: [frp, frpc, gatekeeper, mac-mini, macos, arm64]
+date: 2026-04-14
+---
+
+## Source File
+- [[raw/Home Office/Mac Mini 安装 FRP 0.65.0（ARM64）操作笔记.md]]
+
+## Summary (用中文描述)
+- **核心主题**：在 Apple Silicon（ARM64）Mac Mini M4 上安装配置 FRP 0.65.0 内网穿透客户端，实现通过公网 VPS 远程访问本地服务
+- **问题域**：macOS 服务器化运维、内网穿透、远程访问、SSH 安全隧道
+- **方法/机制**：通过 FRP（frpc）客户端连接远程 VPS（frps）建立反向隧道，结合 tmux/nohup/launchd 三种方式实现后台持久运行；通过 SSH 客户端配置简化远程访问
+- **结论/价值**：提供完整的 Mac Mini 服务器化运维指南，包含 macOS 特有障碍（Gatekeeper）的解决方案和 SSH 客户端优化配置
+
+## Key Claims (用中文描述)
+- macOS 默认 `/opt` 目录需要手动创建并授权才能使用
+- macOS Gatekeeper 会阻止未签名程序运行，必须通过 `xattr -rd com.apple.quarantine .` 解除限制
+- launchd 是 macOS 推荐的开机自启服务管理方式，可通过 `launchctl` 管理生命周期
+- 软链接（symlink）策略可实现 FRP 版本无缝切换
+- SSH 客户端配置（`~/.ssh/config`）可简化远程访问命令，只需 `ssh macmini` 即可登录
+
+## Key Quotes
+> "macOS 默认 `/opt` 需要手动创建" — 说明了 macOS 与 Linux 目录结构的差异，需手动初始化系统目录
+> "xattr -rd com.apple.quarantine ." — macOS 特有的安全限制解除命令，针对整个目录递归执行
+> "launchd（推荐开机自启）" — macOS 原生服务管理器，是进程持久化的推荐方案
+> "ssh macmini" — SSH 客户端配置后的简化登录命令，通过 `~/.ssh/config` 定义 Host 别名
+
+## Key Concepts
+- [[内网穿透]]：通过反向隧道技术，使公网用户能够访问处于 NAT 或防火墙后的内网服务
+- [[frp]]：Fast Reverse Proxy，开源内网穿透工具，包含 frps（服务端）和 frpc（客户端）
+- [[TCP隧道]]：基于 TCP 协议的端口转发机制，将本地端口映射到远程服务器
+- [[launchd]]：macOS 原生服务管理器，用于管理系统级和用户级守护进程
+- [[SSH隧道]]：通过 SSH 协议建立的加密隧道，实现安全的远程端口转发
+
+## Key Entities
+- [[Mac Mini M4]]：Apple Silicon Mac Mini，作为家庭服务器运行 FRP 客户端
+- [[VPS]]：公网虚拟专用服务器，运行 frps 作为内网穿透的中转站（IP: 192.227.222.142）
+- [[frpc]]：FRP 客户端程序，运行在 Mac Mini 上，建立与 frps 的连接
+- [[frps]]：FRP 服务端程序，运行在 VPS 上，接收公网请求并转发到 frpc
+- [[Gatekeeper]]：macOS 安全机制，阻止未签名应用运行
+- [[UFW防火墙]]：VPS 上的防火墙，需开放 FRP 映射端口
+
+## Connections
+- [[Mac Mini M4]] ← runs_on ← [[frpc]]
+- [[VPS]] ← runs_on ← [[frps]]
+- [[frpc]] ← creates_tunnel ← [[frps]]
+- [[内网穿透]] ← enables ← [[远程SSH访问]]
+- [[launchd]] ← manages ← [[frpc]] 进程生命周期
+- [[Gatekeeper]] ← blocks ← [[frpc]] (需解除)
+- [[UFW防火墙]] ← controls_access ← [[SSH隧道]]（需开放 remotePort 60026）
+
+## Contradictions
+- 无已知冲突
+
+## Environment Details
+| 项目 | 内容 |
+|------|------|
+| 系统 | macOS（Mac Mini M4）|
+| 架构 | Apple Silicon (ARM64) |
+| 软件 | FRP 0.65.0 |
+| 安装目录 | `/opt/frp/frp_0.65.0_darwin_arm64` |
+| 客户端程序 | `frpc` |
+| 配置文件 | `frpc.toml` |
+| frps服务器 | 192.227.222.142:7000 |
+| frps映射端口 | 6000（SSH），60026（实际案例端口）|
+
+## Installation Steps
+1. 创建安装目录：`sudo mkdir -p /opt/frp && sudo chown -R $(whoami) /opt/frp`
+2. 下载 ARM64 版本：`wget https://github.com/fatedier/frp/releases/download/v0.65.0/frp_0.65.0_darwin_arm64.tar.gz`
+3. 解压：`tar -xzf frp_0.65.0_darwin_arm64.tar.gz`
+4. 解除 Gatekeeper：`xattr -rd com.apple.quarantine .`
+5. 配置 frpc.toml：设置 serverAddr、serverPort、auth.token 和 proxies
+6. 启动 frpc：`./frpc -c frpc.toml`
+
+## Background Running Methods
+1. **tmux**（推荐开发环境）：创建持久会话，断开 SSH 后仍保持运行
+2. **nohup**（简单后台）：重定向输出到日志文件，适合简单部署
+3. **launchd**（生产环境）：系统级服务，开机自启，推荐使用 plist 配置
+
+## Best Practices
+- 统一安装路径：`/opt/frp/<version>` 便于版本管理
+- 创建软链接：`ln -sfn /opt/frp/frp_0.65.0_darwin_arm64 /opt/frp/current` 简化启动命令
+- 日志独立存储：配置 StandardOutPath 和 StandardErrorPath 分离日志
+- 进程守护：使用 launchd KeepAlive=true 确保服务持续运行
+
+## SSH 远程访问案例（完整配置）
+
+### 网络架构
+```
+本地 Mac Mini
+      │  SSH 22
+      │
+frpc 客户端
+      │  FRP 隧道
+      │
+远端 VPS (frps)
+      │  60026
+      │
+公网 SSH 访问：ssh username@VPS_IP -p 60026
+```
+
+### VPS 防火墙配置（UFW）
+```bash
+sudo ufw allow 60026
+sudo ufw status
+# 输出：60026/tcp ALLOW Anywhere
+```
+
+### frpc.toml SSH 代理配置
+```toml
+serverAddr = "VPS_IP"
+serverPort = 7000
+
+auth.method = "token"
+auth.token = "your_token"
+
+[[proxies]]
+name = "macmini-ssh"
+type = "tcp"
+localIP = "127.0.0.1"
+localPort = 22
+remotePort = 60026
+```
+
+### SSH 客户端配置（~/.ssh/config）
+```ssh-config
+Host macmini
+HostName VPS_IP
+Port 60026
+User billy
+```
+
+配置后可直接使用 `ssh macmini` 登录 Mac Mini，无需记忆 IP 和端口。

wiki/sources/macos-创建与解除-symbolic-link-openclaw-目录映射.md

@@ -1,49 +1,41 @@
----
-title: "macOS 创建与解除 Symbolic Link（OpenClaw 目录映射）"
-type: source
-tags: [obsidian, openclaw, symbolic-link, macos]
-date: 2026-04-14
----
-
-## Source File
-- [[raw/Home Office/macOS 创建与解除 Symbolic Link（OpenClaw 目录映射）.md]]
-
-## Summary (用中文描述)
-- **核心主题**：在 macOS 上为 OpenClaw 隐藏目录创建符号链接，使 Finder 和 Obsidian 能够直接访问
-- **问题域**：OpenClaw 默认使用 `~/.openclaw` 隐藏目录，在图形界面中不可见，无法直接作为 Obsidian Vault 使用
-- **方法/机制**：使用 `ln -s` 创建 Symbolic Link，将 `~/.openclaw` 映射为可见的 `~/openclaw` 目录，两个路径指向同一份数据
-- **结论/价值**：符号链接让 Obsidian 可以访问 OpenClaw 的 Markdown 文件，同时保持 OpenClaw 正常工作，是一种零成本、无风险的目录可见性解决方案
-
-## Key Claims (用中文描述)
-- OpenClaw 的默认数据目录 `~/.openclaw` 是隐藏目录，Finder 和 Obsidian 无法直接访问
-- Symbolic Link（符号链接）可以将隐藏目录映射为可见目录，两个路径指向同一份数据
-- 创建符号链接 `ln -s ~/.openclaw ~/openclaw` 不会复制数据，只创建指向关系
-- 删除符号链接 `rm ~/openclaw` 只会删除链接本身，不会影响原始数据
-- 推荐的长期方案是以 `~/openclaw` 为实际目录，再用 `ln -s` 反向链接到 `~/.openclaw`，便于 Git 管理和 Finder 访问
-
-## Key Quotes
-> "该操作**只会删除链接文件，不会删除真实目录**。" — Symbolic Link 删除操作的安全性说明
-
-> "Finder / Obsidian 可直接访问；OpenClaw 兼容原路径；方便 Git 管理与备份。" — 推荐的长期目录结构三优点
-
-## Key Concepts
-- [[Symbolic Link]]：符号链接，Unix/Linux/macOS 文件系统特性，通过 `ln -s` 创建，指向另一个文件或目录的特殊文件类型
-- [[目录映射]]：将一个目录路径指向另一个目录内容的机制，使不同路径访问同一份数据
-- [[隐藏目录]]：以 `.` 开头的目录，macOS Finder 默认不显示，需用 `ls -a` 或 `Cmd+Shift+.` 可见
-
-## Key Entities
-- [[OpenClaw]]：多 Agent 框架，默认数据目录为 `~/.openclaw` 隐藏目录，本笔记的操作对象
-- [[Obsidian]]：本地 Markdown 知识库工具，可通过 Symbolic Link 将 OpenClaw 目录作为 Vault 直接打开
-
-## Connections
-- [[Obsidian]] ← 通过 Symbolic Link 访问 ← [[OpenClaw]]
-- [[OpenClaw]] ← 数据存储于 ← [[Symbolic Link]]
-
-## Contradictions
-- 无已知冲突
-
-## Aliases
-- Symbolic Link
-- 符号链接
-- symlink
-- 软链接
+---
+title: "macOS 创建与解除 Symbolic Link（OpenClaw 目录映射）"
+type: source
+tags: [obsidian, openclaw, symbolic-link, macos]
+date: 
+---
+
+## Source File
+- [[Home Office/macOS 创建与解除 Symbolic Link（OpenClaw 目录映射）.md]]
+
+## Summary（用中文描述）
+- 核心主题：macOS 下为 OpenClaw 隐藏目录创建和解除符号链接，使 Finder / Obsidian 可直接访问
+- 问题域：OpenClaw 默认使用 `~/.openclaw` 隐藏目录，不便于文件管理器直接操作
+- 方法/机制：通过 `ln -s` 创建符号链接，将隐藏目录映射为可见目录 `~/openclaw`；通过 `rm` 删除链接文件而非真实目录
+- 结论/价值：实现 OpenClaw 与 Obsidian 共用同一数据目录，无需复制文件，同时保留原 OpenClaw 的正常功能
+
+## Key Claims（用中文描述）
+- OpenClaw 默认隐藏目录 `~/.openclaw` 不便于 Finder 或 Obsidian 直接访问
+- 使用 `ln -s ~/.openclaw ~/openclaw` 创建符号链接后，Obsidian 可将 `~/openclaw` 作为 Vault 打开
+- 使用 `rm ~/openclaw` 仅删除链接文件，不会影响真实目录 `~/.openclaw` 中的数据
+- 推荐长期方案：建立可见目录 `~/openclaw` 作为实际存储，反向链接 `~/.openclaw -> ~/openclaw`，便于 Git 管理和 Finder 访问
+
+## Key Quotes
+> `ln -s ~/.openclaw ~/openclaw` — 创建符号链接的标准命令，将隐藏目录映射为可见目录
+> `rm ~/openclaw` — 删除符号链接（注意：不会删除真实目录中的数据）
+> `⚠️ 该操作只会删除链接文件，不会删除真实目录` — 强调操作安全性
+
+## Key Concepts
+- [[SymbolicLink]]：Unix/Linux/macOS 中的符号链接（Symlink），是一种特殊类型的文件，指向另一个文件或目录路径
+- [[ObsidianVault]]：Obsidian 知识库的核心概念，以本地文件夹为单位的笔记管理方式
+
+## Key Entities
+- [[OpenClaw]]：AI Agent 管理工具，默认使用隐藏目录存储记忆、Skills、Prompts 等数据
+- [[Obsidian]]：本地 Markdown 笔记应用，支持将任意文件夹作为 Vault 使用
+
+## Connections
+- [[OpenClaw]] ← 使用 ← [[SymbolicLink]]
+- [[Obsidian]] ← 访问 ← [[OpenClaw]]（通过 [[SymbolicLink]] 映射后的可见目录）
+
+## Contradictions
+- 无已知冲突内容

wiki/sources/ubuntu禁用合盖休眠.md

@@ -1,75 +1,45 @@
----
-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
-```
+---
+title: "Ubuntu禁用合盖休眠"
+type: source
+tags: [ubuntu, systemd, 服务器配置]
+date: 2026-04-26
+---
+
+## Source File
+- [[Home Office/Ubuntu禁用合盖休眠]]
+
+## Summary（用中文描述）
+- 核心主题：Ubuntu 24.04 笔记本合盖休眠行为配置
+- 问题域：服务器场景下笔记本合盖后不应进入休眠状态
+- 方法/机制：通过修改 `systemd-logind` 的 `logind.conf` 配置文件，将 `HandleLidSwitch` 系列参数设为 `ignore`；进阶方法通过 `systemctl mask` 彻底禁用所有休眠目标
+- 结论/价值：提供两步完成服务器场景下笔记本合盖持续运行的生产级方案
+
+## Key Claims（用中文描述）
+- systemd-logind 是 Ubuntu 24.04 控制笔记本合盖行为的登录管理器
+- 通过 `HandleLidSwitch`、`HandleLidSwitchExternalPower`、`HandleLidSwitchDocked` 三个配置项可覆盖不同场景
+- 将配置值设为 `ignore` 后系统合盖不执行任何操作，继续运行
+- 修改配置后需执行 `systemctl restart systemd-logind` 重启服务才能生效
+- 可通过 `systemctl mask` 从内核级别彻底禁止待机（sleep/suspend/hibernate/hybrid-sleep）
+- `mask` 与 `unmask` 可逆，恢复时将 mask 改为 unmask 即可
+
+## Key Quotes
+> "在执行此命令时，你的当前会话（包括图形界面或当前的 SSH 连接）可能会短暂断开或重新加载。" — 重启 systemd-logind 服务的注意事项
+
+## Key Concepts
+- [[systemd-logind]]：Linux 系统登录管理器，负责管理用户会话、电源管理和设备访问权限，合盖行为由其控制
+- [[HandleLidSwitch]]：systemd-logind 配置项，定义笔记本合盖时的电源行为
+- [[sleep.target suspend.target hibernate.target hybrid-sleep.target]]：Linux 休眠相关系统目标，通过 `systemctl mask` 可从内核级别彻底禁用
+
+## Key Entities
+- [[Ubuntu 24.04]]：Canonical 发布的长期支持版 Ubuntu，本配置方法的适用系统
+- [[systemd]]：Linux 系统和服务管理器，systemd-logind 为其组件之一
+
+## Connections
+- [[Ubuntu禁用合盖休眠]] ← relates_to ← [[Ubuntu服务器通过rsync实现日常增量备份]]
+- [[Ubuntu禁用合盖休眠]] ← related_topic ← [[Mac Mini 服务器配置：防止自动锁屏与睡眠]]（不同 OS，方法不同，无冲突）
+
+## Contradictions
+- 与 [[Mac Mini 服务器配置：防止自动锁屏与睡眠]] 无冲突：
+  - 冲突点：无（macOS 使用 `pmset` 命令，与 Ubuntu systemd 配置完全不同）
+  - 当前观点：Ubuntu 通过 systemd-logind 配置
+  - 对方观点：macOS 通过 pmset 命令配置

wiki/sources/在synology-nas上安装clouddrive2.md

@@ -1,42 +1,46 @@
----
-title: "在Synology NAS上安装CloudDrive2"
-type: source
-tags: [clouddrive2, nas, synology, 阿里云盘]
-date: 2025-12-29
----
-
-## Source File
-- [[raw/Home Office/在Synology NAS上安装CloudDrive2.md]]
-
-## Summary (用中文描述)
-- 核心主题：在 Synology NAS 上通过 CloudDrive2 将阿里云盘挂载为本地文件系统
-- 问题域：NAS 本地存储与云端存储的融合、家庭多媒体中心的云盘访问
-- 方法/机制：利用矿神源（社群套件源）安装 CloudDrive2，通过阿里云盘 App 扫码授权，实现云盘的本地挂载访问
-- 结论/价值：将阿里云盘无缝接入 NAS 文件系统，无需手动同步即可直接访问云端资源
-
-## Key Claims (用中文描述)
-- 矿神源提供了 CloudDrive2 等第三方套件，扩展了 Synology 官方套件中心的应用生态
-- DSM 7+ 版本要求额外的 Root 权限修复命令，否则 CloudDrive2 可能无法正常运行
-- 阿里云盘授权时应仅授权"资源目录"，避免"备份目录"以控制数据访问范围
-
-## Key Quotes
-> "不要授权备份目录，仅资源目录即可" — 最小权限原则，避免意外访问敏感备份数据
-
-## Key Concepts
-- [[云盘挂载]]：通过 FUSE/虚拟文件系统将云端存储映射为本地目录的技术
-- [[NAS套件管理]]：群晖 NAS 的 Package Center 套件安装与管理机制
-- [[Root权限修复]]：DSM 7+ 系统中第三方套件权限配置的特殊处理方法
-
-## Key Entities
-- [[CloudDrive2]]：云盘挂载工具，支持阿里云盘、Google Drive、OneDrive 等多种云存储服务
-- [[Synology NAS]]（群晖 NAS）：网络附加存储设备，本方案的硬件平台
-- [[矿神源]]：Synology 社群套件源（SPK 社区生态），提供大量官方未收录的第三方应用
-- [[阿里云盘]]：阿里巴巴云盘服务，本方案的挂载目标云存储
-
-## Connections
-- [[群晖NAS科学上网]] ← 关联场景 ← [[在Synology NAS上安装CloudDrive2]]
-- [[Home Server 多服务架构]] ← 扩展 ← [[在Synology NAS上安装CloudDrive2]]
-- [[CloudDrive2]] ← 挂载目标 ← [[阿里云盘]]
-
-## Contradictions
-- 无已知冲突
+---
+title: "在Synology NAS上安装CloudDrive2"
+type: source
+tags: [clouddrive2, nas, synology, 阿里云盘]
+date: 2025-12-29
+---
+
+## Source File
+- [[Home Office/在Synology NAS上安装CloudDrive2.md]]
+
+## Summary（用中文描述）
+- 核心主题：在 Synology NAS（DSM 7+）上安装并配置 CloudDrive2，实现阿里云盘的本地挂载
+- 问题域：群晖 NAS 用户希望将阿里云盘像本地硬盘一样挂载使用，无需手动同步
+- 方法/机制：通过 Synology 社群（矿神源）安装 CloudDrive2 → 执行 root 权限修复命令（DSM 7+ 专用）→ Web UI 配置 → 阿里云盘 App 扫码授权 → 挂载 Aliyun 目录
+- 结论/价值：CloudDrive2 提供了在 NAS 上原生挂载云盘的能力，适合影视、文件等大体积内容管理
+
+## Key Claims（用中文描述）
+- 主体 + 机制 + 结果
+- Synology 社群安装方式：矿神源 → 社群 → CloudDrive2（标准流程）
+- DSM 7+ 特殊处理：需执行 `sed` 命令修改 CloudDrive2 权限文件，将 `package` 替换为 `root`，否则因权限不足无法正常运行
+- Web UI 访问：通过 `http://192.168.3.17:19798/` 访问 CloudDrive2 配置界面
+- 阿里云盘授权：使用阿里云盘 App 扫码授权，仅授权「资源目录」（不要授权「备份目录」）
+
+## Key Quotes
+> "因为我的 DSM 是 7+ 版本，所以需要额外在 root 下执行一条命令" — DSM 7+ 权限修复说明
+> "请主要，不要授权备份目录，仅资源目录即可" — 安全提示，避免备份文件被挂载
+
+## Key Concepts
+- [[CloudDrive2]]：云盘挂载工具，支持阿里云盘、百度网盘等多种云存储，可将云端文件像本地硬盘一样在 NAS 上使用
+- [[Synology NAS]]：群晖网络附加存储设备，运行 DSM 操作系统；通过社群套件源安装第三方应用
+- [[矿神源]]：Synology 社群第三方套件源，提供大量社群维护的应用（如 CloudDrive2）
+
+## Key Entities
+- [[阿里云盘]]：阿里巴巴旗下云盘服务，CloudDrive2 支持挂载的云存储之一；通过 App 扫码授权连接
+- [[CloudDrive2]]：云盘挂载应用，可在 NAS/PC 上将云盘映射为本地文件系统（WebDAV/SMB 等协议）
+
+## Connections
+- [[群晖NAS科学上网方法]] ← related ← [[在Synology NAS上安装CloudDrive2]]（同一设备上的网络配置需求）
+- [[用Docker安装Jellyfin]] ← related ← [[在Synology NAS上安装CloudDrive2]]（Jellyfin 可读取 CloudDrive2 挂载的阿里云盘影视资源）
+
+## Contradictions
+- 无已知冲突
+
+## Related Sources
+- [[群晖NAS科学上网方法]]
+- [[用Docker安装Jellyfin]]

wiki/sources/如何删除旧的废弃的docker-container-volume.md

@@ -1,54 +1,59 @@
----
-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
-- 与其他文档无已知冲突
+---
+title: "如何删除旧的废弃的 Docker Container + Volume"
+type: source
+tags: [docker, container, portainer, volume]
+date: 2026-04-26
+---
+
+## Source File
+- [[Home Office/如何删除旧的废弃的docker container +volume.md]]
+
+## Summary（用中文描述）
+- 核心主题：清理 Docker 环境中废弃的 Portainer 容器、Volume 和 Network 的完整操作流程
+- 问题域：Docker 容器残留导致的端口冲突、卷数据残留、以及重启 Portainer 时出现的 WARN 警告
+- 方法/机制：通过 `docker stop/rm`、`docker volume ls/rm`、`docker network ls/rm` 系列命令手动清理；使用 `docker compose down` 一键清理整个 compose 项目；通过 `external: true` 配置避免 future 部署时的资源冲突
+- 结论/价值：提供了从手动单步清理到一键重装的完整操作链，以及 WARN 原因分析和解决方案
+
+## Key Claims（用中文描述）
+- `docker compose down` 命令可同时删除容器、网络和匿名 Volume，但保留命名 Volume
+- `docker volume rm` 可显式删除指定 Volume（如 `portainer_data`），从而清除 Portainer 所有用户数据和配置
+- Docker WARN "Network already exists" 表示同名 network 由另一个 compose 项目创建，与当前项目冲突
+- Docker WARN "Volume is used by another service" 表示同名 volume 属于另一个 compose 项目的不同 project name
+- 在 compose 文件中设置 `external: true` 可让新项目复用旧 network/volume 而不触发冲突警告
+
+## Key Quotes
+> "⚠️ 注意：这会删除 Portainer 所有数据（用户、配置）。如果你想保留数据，不要删 volume，只需要在 compose 文件里加：`external: true`" — 删除 portainer_data 的重要提示
+
+## Key Concepts
+- [[Docker Container]]：Docker 镜像的运行实例，`docker ps -a` 查看所有容器，`docker rm` 删除已停止容器，`docker rm -f` 强制删除运行中容器
+- [[Docker Volume]]：持久化存储机制，挂载到容器内部用于保存数据；`docker volume ls` 列出所有卷，`docker volume rm` 删除指定卷
+- [[Docker Network]]：容器间通信的虚拟网络；同名 network 冲突是 compose 项目隔离机制导致的警告
+- [[Docker Compose]]：`docker compose down` 停止并删除整个 compose 项目中的容器、网络，以及（非 external 的）命名卷
+- [[Docker Socket]]：Docker 守护进程的 Unix Socket（通常为 `/var/run/docker.sock`），Portainer 通过挂载它实现对本地 Docker 的管理
+
+## Key Entities
+- [[Portainer]]：开源 Docker 容器管理面板，本文档的清理目标；`portainer/portainer-ce` 为其 Community Edition 镜像
+- [[portainer_data]]：Portainer 的命名 Docker Volume，存储用户、配置等持久化数据
+
+## Connections
+- [[用Docker安装Portainer]] ← depends_on ← [[如何删除旧的废弃的 Docker Container + Volume]]
+- [[如何在Ubuntu Server安装 Docker & Docker Compose]] ← related_to ← [[如何删除旧的废弃的 Docker Container + Volume]]
+
+## Contradictions
+- 无已知冲突
+
+## 完整操作流程速查
+
+```bash
+# 最干净的重装流程
+docker stop portainer && docker rm portainer
+docker volume rm portainer_data
+docker network rm portainer_network
+docker compose up -d
+```
+
+```bash
+# 一键清理（compose 部署）
+docker compose down          # 删除容器+网络+匿名卷
+docker compose down -v       # 额外删除命名卷（谨慎！）
+```

wiki/sources/如何在ubuntu-server安装-docker-docker-compose.md

@@ -1,60 +1,54 @@
----
-title: "如何在Ubuntu Server安装 Docker & Docker Compose"
-type: source
-tags: [docker, ubuntu]
-date: 2026-04-14
----
-
-## Source File
-- [[raw/Home Office/如何在Ubuntu Server安装 docker & docker compose.md]]
-
-## Summary (用中文描述)
-- 核心主题：在 Ubuntu Server 上通过官方 apt 仓库安装 Docker Engine 和 Docker Compose V2 的完整流程
-- 问题域：服务器容器化环境搭建
-- 方法/机制：五步标准安装流程——卸载旧版 → 配置官方仓库 → 安装引擎 → 验证安装 → 配置非 root 用户
-- 结论/价值：推荐从 Docker 官方仓库安装以确保获取最新版本；Docker Compose V2 已集成到 docker-compose-plugin，使用 `docker compose` 命令
-
-## Key Claims (用中文描述)
-- Docker 官方仓库安装能确保获取最新版本的 Docker Engine
-- Docker Compose V2 通过 docker-compose-plugin 安装，使用 `docker compose` 命令而非 `docker-compose`
-- 将用户加入 docker 用户组后，可无需 sudo 直接运行 Docker 命令
-- 必须先安装 ca-certificates 和 curl 才能通过 HTTPS 添加 Docker GPG 密钥和仓库
-
-## Key Quotes
-> "It's generally best to install from Docker's official repositories to ensure you have the latest version." — 官方仓库安装的最佳实践理由
-> "The `docker-compose-plugin` installs **Docker Compose V2**, which is used via the command `docker compose` instead of `docker-compose`." — V2 版本命令变化说明
-> "By default, running Docker commands requires `sudo`. To run Docker without `sudo`, you can add your user to the **`docker` group`." — docker 用户组的作用
-
-## Key Concepts
-- [[Docker Engine]]：Docker 核心运行时，包含 dockerd 守护进程、CLI 和 containerd 容器运行时
-- [[Docker Compose]]：多容器 Docker 应用的定义和运行工具，V2 版本集成到 docker CLI（`docker compose`）
-- [[APT 仓库]]：Ubuntu/Debian 的软件包管理仓库，通过 /etc/apt/sources.list.d/ 配置
-- [[GPG 密钥]]：apt 仓库签名验证，确保软件包来源可信
-- [[Docker 用户组]]：Linux 用户组，允许组成员无需 sudo 直接运行 Docker 命令（存在安全风险）
-- [[containerd]]：Docker 的容器运行时底层引擎，独立项目
-
-## Key Entities
-- [[Docker CE]]：Docker Community Edition，Docker Engine 的开源版本
-- [[docker-ce-cli]]：Docker 命令行工具
-- [[docker-buildx-plugin]]：Docker 扩展插件，支持多平台镜像构建
-- [[docker-compose-plugin]]：Docker Compose V2 插件，替代独立的 docker-compose 包
-- [[containerd.io]]：containerd 的 Docker 打包版本
-- [[hello-world]]：Docker 官方测试镜像，用于验证安装是否成功
-
-## Connections
-- [[Docker Engine]] ← installed_by ← [[Docker CE on Ubuntu]]
-- [[Docker Compose]] ← extends ← [[Docker Engine]]
-- [[APT 仓库]] ← provides ← [[Docker CE]]
-- [[GPG 密钥]] ← authenticates ← [[APT 仓库]]
-- [[Ubuntu Server]] ← runs_on ← [[Docker Engine]]
-- [[Docker 用户组]] ← enables ← [[Docker Engine]] (non-root execution)
-- [[containerd]] ← powers ← [[Docker Engine]]
-
-## Contradictions
-- 无已知冲突
-
-## Related Sources
-- [[用docker安装transmission]] — Docker 部署实战
-- [[用docker安装portainer]] — Docker 可视化管理
-- [[用docker安装jellyfin]] — Docker 媒体服务
-- [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]] — Docker 监控堆栈
+---
+title: "如何在Ubuntu Server安装 Docker & Docker Compose"
+type: source
+tags: [Docker, Ubuntu, 容器化, DevOps]
+date: 2026-04-14
+---
+
+## Source File
+- [[Home Office/如何在Ubuntu Server安装 docker & docker compose]]
+
+## Summary（用中文描述）
+- 核心主题：Ubuntu Server 上安装 Docker Engine 和 Docker Compose V2 的完整操作指南
+- 问题域：Ubuntu Server 容器运行时环境搭建，是后续所有 Docker 部署类笔记的前置依赖
+- 方法/机制：通过添加 Docker 官方 APT 仓库（GPG 密钥验证）→ 安装 Docker Engine 核心组件（dockerd、containerd、buildx、compose）→ 验证安装 → 配置非 root 用户权限
+- 结论/价值：官方仓库安装确保版本最新，与 Ubuntu 内置旧版 docker.io 包完全兼容；Docker Compose V2 通过 `docker compose` 调用，与传统 `docker-compose` 命令分离
+
+## Key Claims（用中文描述）
+- Docker 官方 APT 仓库安装比 Ubuntu 默认仓库版本更新、功能更完整
+- 安装 `docker-compose-plugin` 即获得 Docker Compose V2，使用 `docker compose` 而非 `docker-compose` 命令
+- 将用户加入 `docker` 用户组后无需 `sudo` 即可运行 Docker 命令
+- 完整安装包含 5 个组件包：docker-ce、docker-ce-cli、containerd.io、docker-buildx-plugin、docker-compose-plugin
+
+## Key Quotes
+> "The `docker-compose-plugin` installs Docker Compose V2, which is used via the command `docker compose` instead of `docker-compose`." — 源文档 Step 3 安装说明
+> "Log out and log back in (or restart your terminal session, or run `newgrp docker`) for the changes to take effect." — 源文档 Step 5 用户组配置说明
+
+## Key Concepts
+- [[Docker Engine]]：容器运行时核心，包含 dockerd 守护进程、containerd 容器运行时、docker CLI 工具
+- [[Docker Compose]]：多容器应用编排工具，V2 版本通过 `docker compose` 子命令调用
+- [[containerd]]：Docker 的底层容器运行时，本文档安装 `containerd.io` 包
+- [[GPG 密钥验证]]：Docker 官方通过 GPG 密钥（`/etc/apt/keyrings/docker.asc`）验证 APT 包来源真实性
+- [[APT 仓库配置]]：通过在 `/etc/apt/sources.list.d/docker.list` 添加 Docker 官方仓库启用
+- [[Docker 用户组]]：通过 `usermod -aG docker $USER` 将用户加入 docker 组实现免 sudo 运行
+
+## Key Entities
+- [[Docker]]：Docker 公司及其容器平台生态
+- [[Docker-CE]]：Docker Community Edition 开源版本
+- [[hello-world]]：官方验证镜像，用于测试 Docker 安装是否成功
+- [[Docker-Buildx-Plugin]]：Docker 多平台镜像构建插件
+- [[Docker-Compose-Plugin]]：Docker Compose V2 插件形式实现
+
+## Connections
+- [[Docker Engine]] ← 依赖 ← [[containerd]]（安装 containerd.io 包）
+- [[Docker Engine]] ← 依赖 ← [[Docker-Buildx-Plugin]]（安装时一并安装）
+- [[Docker Engine]] ← 依赖 ← [[Docker-Compose-Plugin]]（安装时一并安装）
+- [[Ubuntu Server]] ← 目标平台 ← [[如何在ubuntu-server安装-docker-docker-compose]]（本文档）
+- [[Docker]] ← 官方维护 ← [[Docker-CE]]（上游包来源）
+- [[如何在ubuntu-server安装-docker-docker-compose]] → 前置依赖 → [[用docker安装it-tools]]（it-tools 需 Docker 环境）
+- [[如何在ubuntu-server安装-docker-docker-compose]] → 前置依赖 → [[用docker安装portainer]]（Portainer 需 Docker 环境）
+- [[如何在ubuntu-server安装-docker-docker-compose]] → 前置依赖 → [[用docker安装transmission]]（Transmission 需 Docker 环境）
+- [[如何在ubuntu-server安装-docker-docker-compose]] → 前置依赖 → [[用docker中安装navidrome]]（Navidrome 需 Docker 环境）
+
+## Contradictions
+- 无冲突。文档聚焦 Ubuntu Server 单机安装流程，与企业级 Kubernetes 容器编排（[[Container-Lifecycle-Hardening]]）等来源属不同层次，无内容矛盾。

wiki/sources/安装v2rayn.md

@@ -1,66 +1,48 @@
----
-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 提供图形界面，命令行代理适合服务器/路由器场景
+---
+title: "安装v2rayN"
+type: source
+tags: [linux, v2rayn, windows]
+date: 2026-05-14
+---
+
+## Source File
+- [[Home Office/安装v2rayN.md]]
+
+## Summary（用中文描述）
+- 核心主题：v2rayN 跨平台代理工具的各操作系统安装包说明与安装方法
+- 问题域：用户在不同操作系统（Windows、Linux、macOS）上安装 v2rayN 客户端的需求
+- 方法/机制：通过官方提供的便携版（zip）和安装版（deb/rpm/dmg）两种方式覆盖不同使用场景；内置 Xray、sing-box、mihomo 核心；支持 x64 和 ARM64 架构
+- 结论/价值：提供了清晰的跨平台安装指引，用户可根据系统和架构选择对应包
+
+## Key Claims（用中文描述）
+- v2rayN 发布包内置部分 Core（Xray、sing-box、mihomo），其他 Core 需自行下载
+- zip 格式为便携版，解压即用，文件存储在程序文件夹，可复制多份互相独立
+- Windows 版需要 Windows 10+；x64 版提供 WPF 界面（需 .NET 8.0 Runtime）和 Avalonia UI 界面两种选择
+- Linux 版支持 Debian 12+、Ubuntu 22.04+、Fedora 36+、Redhat 9+；提供 zip 便携版和 deb/rpm 安装版
+- macOS 版支持 macOS 12+；dmg 安装包因无签名会提示"应用已损坏"，需执行 `xattr -cr` 修复
+- ARM64 架构在 Windows、Linux、macOS 上均有对应包
+
+## Key Quotes
+> "zip格式包为便携版，解压缩到文件夹后直接可以运行，存储文件位置为本文件夹；可以复制多份互相独立" — 便携版特性说明
+> "v2rayN-windows-64-desktop.zip Avalonia UI 实现的界面" — WPF vs Avalonia 区别
+> "由于安装包没有签名，会提示应用已损坏；安装后需要运行：xattr -cr /Applications/v2rayN.app" — macOS dmg 安装后必须操作
+
+## Key Concepts
+- [[代理客户端]]：运行代理协议的桌面/服务器端程序，接收本地流量并转发至远程服务器
+- [[代理核心 Core]]：代理客户端的内核引擎，负责实际的协议通信；v2rayN 支持 Xray、sing-box、mihomo 等多种核心
+- [[跨平台兼容]]：同一软件支持 Windows、Linux、macOS 多操作系统
+- [[ARM64 架构支持]]：支持 Apple Silicon、ARM 服务器等 ARM64 硬件平台
+
+## Key Entities
+- [[v2rayN]]：2dust 开发的跨平台代理客户端，支持多种代理协议和多个代理核心
+- [[Xray]]：代理核心之一，内置于 v2rayN 发布包
+- [[sing-box]]：代理核心之一，内置于 v2rayN 发布包
+- [[mihomo]]：代理核心（Clash.Meta）之一，内置于 v2rayN 发布包
+- [[Microsoft .NET 8.0 Desktop Runtime]]：Windows WPF 版 v2rayN 的运行时依赖
+
+## Connections
+- [[3X-UI Xray on BandwagonVPS]] ← relates_to ← [[安装v2rayn]]（均涉及 Xray/代理工具生态）
+- [[Ubuntu Server科学上网]] ← extends ← [[安装v2rayn]]（Linux 服务器端科学上网的客户端安装参考）
+
+## Contradictions
+- 无已知冲突

wiki/sources/家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox.md

@@ -1,101 +1,61 @@
----
-title: "家庭监控方案：Prometheus + Grafana + Node Exporter + cAdvisor + Blackbox"
-type: source
-tags: [grafana, monitoring, prometheus, home-server]
-date: 2025-11-11
----
-
-## Source File
-- [[raw/Home Office/家庭监控方案：Prometheus + Grafana + Node Exporter + cAdvisor +Blackbox.md]]
-
-## Summary (中文描述)
-- 核心主题：家庭/家居服务器（NAS / Ubuntu Server）的一站式开源监控方案，通过 Docker Compose 快速部署完整的 Prometheus 监控栈。
-- 问题域：如何对家庭服务器的主机层、容器层、服务层（HTTP 可用性、TLS 证书）进行全面的指标采集、存储、可视化和告警。
-- 方法/机制：使用 Prometheus 作为时序数据库和告警规则引擎，node_exporter 采集主机指标，cAdvisor 采集容器资源，blackbox_exporter 做 HTTP/TLS 探测，Grafana 做可视化仪表盘，Alertmanager 分发告警到邮件/Slack。配合 Uptime Kuma 做合成可用性监控。
-- 结论/价值：提供可直接拷贝的 docker-compose 模板、prometheus.yml、alerts.yml、alertmanager.yml，8 步落地路径，涵盖 PoC 验证到生产级部署的全流程。
-
-## Key Claims (中文描述)
-- Prometheus 通过 pull 模式定期抓取 node_exporter / cAdvisor / blackbox_exporter 暴露的指标，实现主机/容器/网络探测的统一采集。
-- Grafana 可通过 Dashboard ID（如 Node Exporter Full: 1860）直接导入官方仪表盘，快速搭建可视化界面。
-- Blackbox Exporter 通过 `probe_success == 0` 和 `probe_ssl_earliest_cert_expiry` 等指标实现 HTTP 可用性和 TLS 证书到期监控。
-- node_exporter 以 host network 模式运行，挂载 `/proc`、`/sys`、`/` 为只读卷，实现无代理（agentless）主机指标采集。
-- Docker socket 挂载（如 cAdvisor 中的 `/var/run/docker.sock`）是容器监控的必要条件，但需审慎评估安全风险。
-- Alertmanager 支持邮件/Slack/Teams/Webhook/PagerDuty 等多通道告警路由，并提供告警抑制（inhibition）和分组（grouping）功能。
-
-## Key Quotes
-> "Prometheus 通过 pull 模式定期抓取 exporters 采集指标，支持 PromQL 命名与告警规则。适合做主观测时序库与告警。" — Prometheus 核心机制说明
-
-> "Docker socket 挂载（风险：容器拿到宿主机 root 等同权限）。" — 安全警告
-
-> "把监控流量/端口放在管理 VLAN 或通过防火墙限定访问。" — 网络安全建议
-
-> "Grafana 仪表盘 JSON 导出，Prometheus rule 与配置放在 Git（GitOps）。" — 配置备份最佳实践
-
-## Key Concepts
-- [[Prometheus]]：开源时序数据库和监控告警系统，支持 PromQL 查询语言和告警规则引擎
-- [[Grafana]]：开源可视化平台，支持多数据源仪表盘和告警管理
-- [[node_exporter]]：Prometheus 官方主机指标采集器，采集 CPU/内存/磁盘/网络/I/O 等系统指标
-- [[cAdvisor]]：Google 开源的容器资源监控工具，为 Prometheus 提供容器级别指标
-- [[blackbox_exporter]]：Prometheus 官方黑盒探测 exporter，支持 HTTP/TCP/ICMP/DNS/TLS 探测
-- [[Alertmanager]]：Prometheus 告警分发组件，支持告警分组、抑制、静默和多通道路由
-- [[PromQL]]：Prometheus Query Language，用于查询时序指标和告警条件
-- [[Uptime Kuma]]：自托管 uptime monitoring 工具，支持 HTTP/TCP/DNS/TLS 合成监控
-- [[Netdata]]：开箱即用的实时主机/容器监控面板，默认 19999 端口，适合快速诊断
-- [[VictoriaMetrics]]：Prometheus 时序数据库替代方案，支持长期存储和高效写入
-- [[合成监控]]（Synthetic Monitoring）：通过模拟真实用户请求检测服务可用性和响应时间
-- [[Exporter]]：Prometheus 生态中负责暴露指标数据的组件，通过 HTTP 端点提供 /metrics
-- [[时序数据库]]（Time Series Database）：专门存储带时间戳的指标数据，支持高效的时间范围查询和聚合
-- [[Prometheus告警规则]]：YAML 格式的告警条件定义，基于 PromQL 表达式触发状态变更
-
-## Key Entities
-- [[Prometheus]]（CNCF 项目）：时序数据库 + 监控告警平台核心
-- [[Grafana Labs]]：Grafana 背后的公司和维护组织
-- [[Docker]]：所有组件的部署平台，通过 Docker Compose 实现一键启动
-- [[Uptime Kuma]]（louislam/uptime-kuma）：开源 uptime monitoring 工具
-- [[Portainer]]：Docker 可视化管理工具，不替代 Prometheus 但便于运维快速操作
-
-## Connections
-- [[Prometheus]] ← 数据源 ← [[node_exporter]]
-- [[Prometheus]] ← 数据源 ← [[cAdvisor]]
-- [[Prometheus]] ← 数据源 ← [[blackbox_exporter]]
-- [[Grafana]] ← 可视化 ← [[Prometheus]]
-- [[Alertmanager]] ← 告警接收 ← [[Prometheus]]
-- [[Prometheus]] ← 告警规则 ← [[Prometheus告警规则]]
-- [[Grafana]] ← 仪表盘模板 ← [[Node Exporter Full Dashboard]]
-- [[Docker Compose]] ← 编排 ← 所有组件（Prometheus / Grafana / Alertmanager / node_exporter / cAdvisor / blackbox_exporter）
-
-## Contradictions
-- 与 [[系统监控工具]]（Btop++ / Htop / Glances / Netdata）相比：Netdata 适合实时短期诊断，Prometheus + Grafana 适合长期存储和趋势分析，两者可互补使用而非互斥。
-- 与 [[ctp-topic-42-grafana-observability-dashboard]] 冲突：该来源标注为 expected（source missing），但内容为 Grafana 在 AWS 场景下的企业级应用；本来源侧重家庭服务器轻量部署，场景和规模不同。
-- 与 [[ctp-topic-67-cloud-native-observability-using-opentelemetry]] 冲突：OpenTelemetry 是云原生可观测性新标准（metrics/traces/logs 三合一），Prometheus 生态更成熟但 OpenTelemetry 是未来方向；短期用 Prometheus，长期可考虑 OTel 迁移路径。
-
-## Docker Compose 核心架构
-```yaml
-# 监控栈组件
-services:
-  prometheus:    # 时序数据库 + 告警引擎
-  grafana:       # 可视化仪表盘
-  alertmanager:  # 告警分发
-  node_exporter: # 主机指标（host network）
-  cadvisor:     # 容器指标（挂载 /var/run/docker.sock）
-  blackbox:     # HTTP/TCP 探测
-```
-
-## 关键监控项（PromQL 示例）
-| 指标 | PromQL 表达式 | 阈值 |
-|------|--------------|------|
-| 磁盘空间 | `node_filesystem_avail_bytes / node_filesystem_size_bytes < 0.10` | < 10% |
-| CPU 使用率 | `avg(rate(node_cpu_seconds_total[2m])) * 100 > 85` | > 85% |
-| 内存可用 | `node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes < 0.15` | < 15% |
-| HTTP 可用性 | `probe_success == 0` (持续 2min) | 探测失败 |
-| TLS 证书到期 | `probe_ssl_earliest_cert_expiry - time() < 86400 * 14` | < 14 天 |
-
-## 落地 8 步路径
-1. 用 PoC docker-compose 启动 Netdata + Uptime Kuma（19999 / 3001）验证
-2. 上线 Prometheus + prometheus.yml，配置 scrape_configs
-3. 每台主机部署 node_exporter（host network 模式）
-4. Grafana 导入 Dashboard（1860 / 14282 / 7587）
-5. Alertmanager 配置告警路由（邮件/Slack）
-6. Uptime Kuma 建好所有内外网探测项
-7. GitOps 配置管理（Grafana JSON 导出，Prometheus rules 放 Git）
-8. TLS 证书到期告警（blackbox_exporter 或 Uptime Kuma）
+---
+title: "家庭监控方案：Prometheus + Grafana + Node Exporter + cAdvisor + Blackbox"
+type: source
+tags: [prometheus, grafana, monitoring, docker, home-server]
+date: 2025-11-11
+---
+
+## Source File
+- [[Home Office/家庭监控方案：Prometheus + Grafana + Node Exporter + cAdvisor +Blackbox]]
+
+## Summary（用中文描述）
+- 核心主题：家庭/小型服务器监控的完整 Docker 化解决方案
+- 问题域：主机层、容器层、服务层的可观测性覆盖，以及告警通知渠道
+- 方法/机制：Prometheus 拉取模式采集 + Grafana 可视化 + Alertmanager 告警分发；通过 node_exporter、cAdvisor、blackbox_exporter 三个 exporter 覆盖主机、容器和网络探测；提供可直接拷贝的 docker-compose 完整模板
+- 结论/价值：面向 NAS / Ubuntu Server 用户的零门槛可落地监控栈，含具体 PromQL 告警规则和 Grafana Dashboard ID
+
+## Key Claims（用中文描述）
+- Prometheus + node_exporter + cAdvisor + blackbox_exporter + Grafana + Alertmanager 的组合可覆盖家庭服务器的完整监控面
+- 主机层监控 CPU / 内存 / 磁盘 / 网络 / I/O / inode，容器层监控运行状态、重启次数、资源使用，服务层监控 HTTP 可用性、响应码、延迟、TLS 证书到期、DNS 解析
+- TLS 证书剩余天数 < 14 天应触发告警
+- 黑箱探测 `probe_success == 0` 连续 3 次应触发告警
+- Docker socket 挂载存在宿主机 root 等效权限风险，需审慎处理
+- Grafana 官方 Dashboard ID：Node Exporter Full (`1860`)、cAdvisor Container Metrics (`14282`)、Blackbox Exporter Probe (`7587`)
+
+## Key Quotes
+> "Docker socket 挂载存在宿主机 root 等效权限风险" — 容器安全注意事项
+> "Prometheus 本地磁盘会增长，考虑长期保留要用远端存储或定期 snapshot" — 存储注意事项
+> "Grafana 仪表盘 JSON 导出，Prometheus rule 与配置放在 Git（GitOps）" — 备份最佳实践
+> "把容器/服务启动时打上 service=xxx、env=prod 标签，便于 PromQL 分组和 SLA 报表" — 标签化运维建议
+
+## Key Concepts
+- [[Prometheus]]：开源时序数据库 + 监控系统，采用拉取（pull）模式从 exporters 采集指标
+- [[Grafana]]：跨数据源的可视化与告警平台，支持 Prometheus/Loki/VictoriaMetrics 等
+- [[Observability]]（可观测性）：覆盖指标（Metrics）、日志（Logs）、链路（Traces）三大支柱
+- [[Container Monitoring]]（容器监控）：通过 cAdvisor 采集容器资源使用、重启次数、退出码等指标
+- [[Synthetic Monitoring]]（合成监控）：通过 blackbox_exporter 和 Uptime Kuma 做主动式可用性探测，区别于基于真实用户流量的 RUM
+- [[Alert Management]]（告警管理）：Prometheus 定义告警规则 → Alertmanager 接收 → 抑制/分组/路由到邮件/Slack/Webhook/PagerDuty
+- [[Home Server Automation]]：家庭服务器的运维自动化与监控覆盖
+
+## Key Entities
+- [[Prometheus]]（监控数据采集与告警规则引擎）：负责从各 exporter 拉取指标并执行告警条件判断
+- [[Grafana]]（可视化与告警平台）：展示 Prometheus 时序数据，配置告警规则和通知渠道
+- [[Alertmanager]]（Prometheus 告警分发组件）：负责告警的抑制、分组、向邮件/Slack/Teams 等渠道分发
+- [[Node Exporter]]（主机指标采集器）：Prometheus 官方 exporter，采集 CPU/内存/磁盘/网络/文件系统指标
+- [[cAdvisor]]（Google 容器指标采集器）：采集容器级别的资源使用情况（CPU/内存/网络/磁盘 I/O）
+- [[Blackbox Exporter]]（黑箱探测 exporter）：通过 HTTP/TCP/ICMP/DNS 探测外部或内部服务端点
+- [[Uptime Kuma]]（自托管可用性监控工具）：开源 uptime monitoring，支持 HTTP/TCP/DNS/TLS 探测与历史记录
+- [[Netdata]]（实时监控看板）：开箱即用的详细实时主机/容器监控面板，默认 19999 端口
+- [[Portainer]]（Docker 可视化管理平台）：图形化管理 Docker 主机/Swarm，带监控/日志功能
+
+## Connections
+- [[Prometheus]] ← scrape_configs ← [[Node Exporter]]
+- [[Prometheus]] ← scrape_configs ← [[cAdvisor]]
+- [[Prometheus]] ← scrape_configs ← [[Blackbox Exporter]]
+- [[Prometheus]] ← sends alerts ← [[Alertmanager]]
+- [[Grafana]] ← datasource ← [[Prometheus]]
+- [[Grafana]] ← dashboards ← [[Node Exporter]], [[cAdvisor]], [[Blackbox Exporter]]
+- [[家庭网络环境概览]] ← provides context for ← [[Home Server Automation]]
+
+## Contradictions
+- 与 [[Uptime Kuma]] 描述存在侧重差异：源文档将 Uptime Kuma 定位为"合成监控补充工具"与 blackbox_exporter 并列，实际部署中两者均可独立完成 HTTP/TLS 探测，Uptime Kuma 更适合做外网监控（无公网 IP 时），blackbox_exporter 更适合内网和更细粒度的 PromQL 告警集成

wiki/sources/用docker安装portainer.md

@@ -1,50 +1,34 @@
----
-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 部署系列
+---
+title: "用Docker安装Portainer"
+type: source
+tags: [docker, portainer]
+date: 2026-04-26
+---
+
+## Source File
+- [[Home Office/用Docker安装Portainer]]
+
+## Summary（用中文描述）
+- 核心主题：通过 Docker Compose 方式安装 Portainer 容器管理面板
+- 问题域：家庭服务器或NAS环境下的Docker容器可视化管理工作
+- 方法/机制：使用 docker-compose.yml 配置文件定义 Portainer 服务，通过 `docker-compose run -d` 启动容器
+- 结论/价值：提供图形化界面管理Docker容器、卷、网络等资源，降低命令行操作复杂度
+
+## Key Claims（用中文描述）
+- Portainer 通过挂载 Docker Socket（`/var/run/docker.sock`）实现对本地Docker守护进程的管理
+- 使用 LTS 版本镜像（`portainer/portainer-ce:lts`）确保稳定性和长期支持
+- 容器配置为 `restart: always`，确保服务在系统重启后自动恢复
+- 默认暴露 9443（HTTPS管理界面）和 8000（Edge Agent通信）端口
+
+## Key Quotes
+> "ports: - 9443:9443 - 8000:8000" — Portainer Web界面通过9443端口访问，8000端口用于Edge Agent通信（不使用Edge Agent时可移除）
+
+## Key Concepts
+- [[Docker Compose]]：定义和运行多容器Docker应用的工具，通过YAML配置文件管理服务
+- [[Portainer]]：开源的Docker和Kubernetes图形化管理界面，支持容器、镜像、卷、网络等资源管理
+
+## Key Entities
+- [[Portainer]]：开源容器管理平台，本文档的核心安装目标
+
+## Connections
+- [[如何删除旧的废弃的Docker Container + Volume]] ← related_to ← [[用Docker安装Portainer]]

wiki/sources/群晖nas科学上网方法.md

@@ -1,53 +1,48 @@
----
-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 代理
+---
+title: "群晖NAS科学上网方法"
+type: source
+tags: [docker, nas, synology, v2raya, vpn, 透明代理]
+date: 2025-03-08
+---
+
+## Source File
+- [[Home Office/群晖NAS科学上网方法]]
+
+## Summary（用中文描述）
+- 核心主题：在群晖（Synology）NAS 上通过 Docker 安装 V2RayA，实现透明代理，使 NAS 本机和 Docker Daemon 均能科学上网
+- 问题域：群晖 DSM 环境下，Docker Daemon 网络栈不遵循 V2RayA 的 iptables 规则，导致 `docker pull` 仍无法走代理
+- 方法/机制：
+  - 通过 Docker 部署 V2RayA 容器（Host 网络模式）
+  - 透明代理（transparent proxy）劫持 NAS 本机出站流量
+  - 路由规则选择"大陆白名单（Whitelist of Mainland China）"分流
+  - 备用方案：显式配置 Docker Daemon HTTP 代理环境变量（推荐）
+- 结论/价值：透明代理对 NAS 本机有效，但对 Docker Daemon 无效；Engineering Best Practice 是显式配置 Docker 守护进程代理，而非依赖 Host 透明代理
+
+## Key Claims（用中文描述）
+- V2RayA Docker 容器以 `--network=host` 模式运行，配合 `--restart=always` 确保开机自启
+- V2RayA 透明代理（分流模式"大陆白名单"）可使 NAS 本机流量走代理，验证方法：`curl https://www.google.com`（不加 `-x` 参数）直接返回 HTTP 200
+- DSM 7.x 中，Docker Daemon (`dockerd`) 网络栈不完全遵循 v2rayA 的 iptables 规则，`docker pull` 可能仍然失败
+- 显式配置 Docker Daemon 代理（systemd environment variables）是解决 `docker pull` 科学上网的推荐方案，符合 Engineering Best Practice
+
+## Key Quotes
+> "在群晖 DSM 7.x 中，Docker Daemon (`dockerd`) 的网络栈有时候不会完全遵循 v2rayA 修改的 iptables 规则。如果上面的 `docker pull` 仍然慢或失败，**不要死磕透明代理**，直接配置 Docker 守护进程走 HTTP 代理是最稳妥的方案。" — 核心观点
+> "对于企业级或生产环境（即使是SOHO），我建议**不要**依赖 NAS Host 的透明代理来解决 `docker pull` 问题，因为这修改了系统级路由表，容易影响 NAS 其他服务。**显式配置 Docker Daemon 的 Proxy 环境变量（上面的最后一种方法）是更符合 Engineering Best Practice 的做法。**" — 最佳实践建议
+
+## Key Concepts
+- [[V2RayA]]：基于 V2Ray 的轻量透明代理 Web 管理界面，支持多种分流规则（大陆白名单/GFWList 等）
+- [[透明代理]]（Transparent Proxy）：在网络层劫持并转发流量，无需客户端显式配置代理
+- [[Docker Daemon 代理]]：通过 systemd 环境变量为 Docker 守护进程配置 HTTP/HTTPS 代理，影响所有 `docker pull` 和容器出站流量
+- [[Traffic Splitting]]（流量分流）：V2RayA 的分流模式，根据路由规则决定流量直连或走代理
+
+## Key Entities
+- [[Synology-DSM]]：群晖 NAS 操作系统，DSM 7.x 中 Docker 服务名为 `pkg-ContainerManager-dockerd`
+- [[Docker]]：容器化平台，本文档中作为 V2RayA 的运行环境和需要科学上网的主要场景
+- [[mzz2017/v2raya]]：V2RayA 官方 Docker 镜像，用于在 NAS 上部署代理服务
+
+## Connections
+- [[Ubuntu-Server科学上网]] ← similar_approach ← [[群晖NAS科学上网方法]]（同为 Linux 环境下部署 V2RayA 的实践）
+- [[Synology-NAS上安装CloudDrive2]] ← same_platform ← [[群晖NAS科学上网方法]]（均针对 Synology NAS 环境）
+- [[如何传输Docker-images-并且在另一个Docker安装]] ← referenced_by ← [[群晖NAS科学上网方法]]（文档内引用了镜像传输方法）
+
+## Contradictions
+- 无冲突。与 [[Ubuntu-Server科学上网]] 的方法论一致（均推荐显式配置代理而非依赖透明代理）。