LocalLLM

在低功耗服务器上自托管 Qwen 7B 并通过公网安全访问

随着大模型能力的提升，将语言模型部署到本地服务器（self-hosted）已成为追求数据自治、隐私保护与长期可控性用户的一种现实选择。本文以 Qwen 7B 为例，记录了一种在中低配置服务器上，通过 Docker + Web UI + 公网反向代理 的方式，构建“类似 ChatGPT 的网页使用体验”的完整方案。全文不包含任何真实路径、端口或域名等敏感信息，仅保留通用架构与可复现的工程思路。 一、为什么选择本地部署 Qwen 7B 选择本地部署而非完全依赖云端模型，主要基于以下考虑： 需要明确的是，本地 7B 级模型并非用来“对标”云端超大模型，而是作为一个稳定、可控、随时可用的本地认知工具。 二、硬件与资源需求（现实可行范围） 本文方案基于一台低功耗小型服务器，而非专业 GPU 服务器。 推荐最低配置（CPU-only） 虚拟化场景下的资源分配 在虚拟化环境中（如 PVE / KVM）： 该资源条件下，可长期运行： 三、整体架构设计（不暴露 AI 节点） 核心设计原则 逻辑拓扑（文字描述） 四、容器化部署思路（Docker） 组件拆分 两者均通过 Docker 容器运行，数据通过 volume 持久化。 设计要点 五、公网访问的安全策略 反向代理职责 反向代理服务器承担所有“对外风险”： 必须具备的安全措施 通过该方式，即使域名被扫描，攻击面也仅限于反代层。 六、实际使用体验与定位 …

Proxmox

PVE 宿主网络随机掉线问题的定位与解决（虚拟化宿主通用案例）

适用对象：使用常见集成型以太网控制器的 Proxmox VE 虚拟化宿主机 问题特征：宿主网络随机掉线、时间不固定；重启 networking 后宿主恢复，但虚拟机仍需 stop/start 才能恢复；虚拟机内部 reboot 无效 结论摘要：关闭网卡 offload + 关闭 EEE（Energy Efficient Ethernet），并进行 systemd 永久化，是当前该问题族成功率最高、代价最低、可复现性最强的解决方案之一。 1. 问题现象（行为级描述） 在长期运行的虚拟化环境中，宿主机会出现随机网络中断，具有如下共同特征： 这些现象往往容易被误判为虚拟机、应用或网络配置问题，但多次验证表明：真正进入异常状态的是宿主机网络路径本身。 2. 架构与关键前提 该问题通常出现在如下环境组合中： 与台式机或服务器上常见的独立 PCIe 网卡不同，集成型以太网控制器在电源管理（EEE / ASPM / C-state）与 CPU之间存在更强的耦合，这一差异是问题产生的重要边界条件。 3. 关键认知纠偏 3.1 虚拟机并非问题源头 当宿主网络路径进入异常中间态时，虚拟机只是最先感知失败的一层。 3.2 为什么重启 networking 只能救宿主 networking 服务的重启会： 但它不会销毁或重建已经存在的： 因此，虚拟机仍然绑定在失效的中间层网络对象上。 3.3 为什么必须 …

Server

PVE 网络异常下的工程性止损方案：从虚拟机自愈幻想到宿主机重启策略

一、问题背景 在基于 PVE（Proxmox VE）的单节点虚拟化环境中，宿主机偶发网络异常，表现为： 该现象在家用硬件、非 HA、bridge 网络架构中具有一定普遍性。 二、初始假设与验证路径 1. 虚拟机网卡模型假设 最初怀疑为 VirtIO 在宿主机网络异常时放大问题，因此进行了如下验证： 2. 验证结果 结论： 问题不在虚拟机网卡模型层面 三、systemd + bridge + KVM 的一致性边界 在异常场景下，宿主机通常通过： 恢复网络。 该操作在 systemd + bridge 环境中会导致： 此时虚拟机网络栈处于： 逻辑上未崩溃，但状态不可预测 这是虚拟化架构本身的边界问题，而非配置错误。 四、关键工程结论 经过多轮实测，可得出以下结论： 最终结论： 当宿主机发生网络中断时，最可靠的策略是直接重启宿主机 因为宿主机重启可以同时完成： 五、设计目标的转变 设计目标从： “尽量让虚拟机自己恢复网络” 转变为： “一旦检测到宿主机网络中断，直接重启宿主机，保证整体收敛” 这是典型的工程止损决策，而非妥协。 六、最终方案：宿主机网络监控 + 自动重启 方案原则 七、宿主机网络重启 Watchdog …

Server

通过公网 Pull 模式实现 Raspberry Pi 的长期增量灾备方案

摘要 在 Raspberry Pi 等长期运行设备中，SD 卡依然是最常见、也是最不可靠的存储介质之一。异常断电、磨损老化或 silent corruption 往往在系统仍可运行时悄然发生，一旦彻底失效，恢复成本极高。 本文记录了一套 与设备物理位置无关的 Raspberry Pi 灾备方案：通过公网 SSH，以 备份机主动拉取（pull） 的方式，对远端树莓派的根文件系统进行 持续增量备份，在不影响系统运行的前提下，确保随时具备完整恢复能力。 设计目标 总体设计思路 1. 连接模型：Pull 而非 Push 备份由 备份机主动发起： 该模型符合最小权限原则，也更适合嵌入式设备长期运行。 2. 标识方式：域名而非 IP 使用域名作为唯一入口： 只要 SSH 可达，系统即可被完整拉取。 3. 备份粒度：文件级增量镜像 放弃块级复制（dd），采用 rsync： 核心实现 rsync 参数选择 关键参数说明： 参数 作用 -a 保留权限、时间戳、符号链接 -A 保留 ACL -X …

Network

FRPS 中 QUIC 监听端口的协议类型与配置取舍分析

背景 在使用 FRP（Fast Reverse Proxy）进行内网穿透时，FRPS（服务器端）的通信端口配置直接影响系统的稳定性、安全性以及后续的运维复杂度。 随着 FRP 新版本引入基于 QUIC 的传输方式，配置项中新增了 QUIC 相关监听参数，这使得服务器端可能同时存在多种控制通道实现方式，有必要对其协议属性与实际影响进行明确分析。 QUIC 监听端口的协议属性 结论明确： FRPS 中用于 QUIC 的监听端口基于 UDP 协议 原因在于： 协议层级关系如下： 因此： 传统控制端口与 QUIC 控制端口的差异 FRPS 提供两种功能等价的控制通道实现方式： 项目 传统控制通道 QUIC 控制通道 底层协议 TCP UDP 连接可靠性 由 TCP 提供 由 QUIC 协议实现 网络兼容性 高 依赖 UDP 质量 运维复杂度 较低 …

Selfhost

Nextcloud 中 imagick 无法识别 SVG 的问题排查记录

问题描述 在 Nextcloud 管理后台的 Security & setup warnings 中出现如下提示： The PHP module “imagick” in this instance has no SVG support. 具体表现为： 环境背景（概述） 初步判断 系统层 ImageMagick 验证 通过系统命令确认： 结论： 系统层 ImageMagick 支持 SVG PHP imagick 状态验证 查询 PHP imagick 模块信息，发现： 进一步使用 PHP 接口查询 SVG 支持情况，返回结果为空。 结论： PHP imagick 实际并不支持 SVG 关键分歧点：动态库不一致 …

Docker

Docker 镜像与容器清理实践：以“栈视角”进行安全管理

背景 在长期运行的 Docker 服务器环境中，常见两类资产同时存在： 如果仅依据“容器是否在运行”来判断镜像是否可删除，极易误删冷备镜像，给后续恢复带来额外成本。因此，有必要建立一套以服务栈（stack）为核心的镜像与容器管理方法。 本文记录一次完整的排查与整理过程，目标不是“尽可能删除”，而是确保不误删任何未来仍需使用的镜像。 一、基础原则 在该环境中采用如下原则： 二、列出所有镜像（事实基线） 使用带 digest 的镜像列表作为“真实库存”： 该输出用于确认： 三、列出所有容器（不区分运行/停止） 容器列表是“镜像引用关系”的唯一事实来源： 在该环境中，当前不存在 exited 容器，所有服务均处于运行状态。但这并不改变后续判断逻辑。 四、用“栈（Compose Project）视角”理解容器结构 相比单个容器视角，“栈”更符合真实服务结构。通过 com.docker.compose.project 标签，可将容器按栈分组。 栈视图生成命令 五、当前运行中的服务栈清单（严格脱敏） 为避免暴露具体应用指纹，本节仅以抽象栈类别记录容器结构与数量，不出现任何可被直接识别的服务名称、镜像名或项目名。 该视图仅用于说明“以栈为单位进行管理”的方法论，而非展示具体部署细节。

Docker

Portainer 中删除 Docker 镜像失败的原因分析与处理

问题现象 在使用 Portainer（Community Edition）管理 Docker 环境时，尝试删除标记为 Unused 的镜像失败，界面提示类似以下错误： 即使所选镜像体积较大、状态显示为未使用，删除操作仍无法在 UI 中完成。 初步误判与澄清 误判一：镜像体积过大导致无法删除 该判断并不成立。 Docker 删除镜像的核心操作并非“拷贝或移动大文件”，而是： 镜像体积大小只影响删除耗时，不会导致“无法删除”。 正确原因分析 1. Portainer 报错的本质 504 Gateway Time-out 属于 前端或反向代理超时，而非 Docker Engine 返回的逻辑错误。 Portainer 的工作路径为： 当后端操作耗时过长时： 2. 根本原因：磁盘 I/O 性能不足 在以下场景中，该问题尤为明显： Docker 删除镜像时会触发： 这类操作 高度依赖随机 I/O 性能，在慢盘上可能持续数分钟。 3. 为什么 CLI 删除可以成功 使用命令行执行： 与 Portainer …

Server

在 PVE 单节点环境中正确移除 Ceph 的一次实践记录

背景说明 在一次 Proxmox VE（PVE）节点初始化完成后，Web UI 中出现了 Ceph HEALTH_WARN 提示，提示内容为： OSD count 0 < osd_pool_default_size 3 该告警并非硬件故障或系统异常，而是由于 Ceph 已被初始化，但集群中并未配置任何 OSD（Object Storage Daemon），同时 Ceph 默认要求存储池副本数为 3，从而触发健康警告。 当前环境采用 PVE 单节点 + 独立硬件 PBS（Proxmox Backup Server） 的架构，用于虚拟化运行与备份分离。在该架构下，并不存在分布式存储或在线高可用的需求，因此 Ceph 实际上并不适合该使用场景。 Ceph 的定位与适用场景 Ceph 是一套分布式存储系统，主要目标包括： 其典型使用场景包括： 而在 单节点 PVE 环境中： 因此，在明确不使用 Ceph 的前提下，应当将其从系统角色中移除。 HEALTH_WARN 的根本原因 出现告警的直接原因是： …

Fix

Ubuntu 升级后 Anki Sync Server 虚拟环境断代修复记录

背景 在系统从 Ubuntu 22.04 升级至 24.04 后，一个长期运行的 Anki Sync Server 服务无法启动。该服务基于 Python 虚拟环境（venv）运行，并通过 systemd 管理。升级完成后，systemd 显示服务反复启动失败。 本文记录一次完整的排查与修复过程，重点在于 Python 虚拟环境在系统升级后发生版本断代 的问题，以及如何在不影响业务数据的前提下，安全、可回溯地恢复服务。 本文为工程记录，已严格脱敏，不包含路径、主机名、账号或端口等可识别信息。 一、故障现象 systemd 服务状态显示： 手动执行启动脚本时，出现错误： 这表明 Python 运行环境无法找到 anki 模块。 二、初步检查：虚拟环境异常 检查虚拟环境中的 Python 解释器信息： 进一步检查虚拟环境目录结构后发现： 即： venv 中保留的是 Python 3.10 时期的库，而解释器已经切换到 Python 3.12。 这是一次典型的 虚拟环境断代问题： 三、修复策略选择 核心原则 策略 四、旧虚拟环境归档 原有虚拟环境目录包含： …