Linux

虚拟机强制关机后 ext4 文件系统 fsck 卡顿问题分析与结论

背景说明 在一次 Linux 虚拟机运行过程中，由于操作需要，对虚拟机执行了强制关机（相当于物理断电）。随后再次启动虚拟机时，系统在引导阶段进入了 ext4 文件系统自动检查（fsck），并在控制台输出大量类似以下信息： 同时，系统在该阶段停留时间较长，给人以“卡住”的直观感觉。 现象描述 引导过程中，fsck.ext4 输出了大量 orphaned inode（孤儿 inode） 清理信息，持续时间明显长于平时正常启动。 但在日志中可以观察到： 原因分析 1. 强制关机导致文件系统处于未一致状态 ext4 是日志文件系统，但在以下情况下仍会留下不完整状态： 虚拟机被强制关机时，这些操作会被中断。 2. orphaned inode 的来源 orphaned inode 是指： 在包含 Web 服务、数据库、同步程序（如文件同步系统）等场景下，这类 inode 数量可能较多。 3. fsck 运行缓慢的技术原因 fsck.ext4 运行缓慢并不意味着异常，主要原因包括： fsck 在修复过程中几乎不会提供进度指示，因此容易被误认为“卡死”。 预计耗时范围 在类似环境下，fsck 的常见耗时如下： 场景 耗时范围 数据量较小 5–15 分钟 普通服务器虚拟机 10–30 …

Linux

Proxmox VE 中虚拟机「带内存快照」日志解析与行为说明

背景说明 在 Proxmox VE（PVE）环境中，对虚拟机执行某些操作（如带内存的快照、暂停或状态保存）时，系统会输出一段看起来较长的日志。本文对一次完整的日志输出进行拆解说明，明确其含义、触发条件以及是否属于异常行为。 一、日志原文（已脱敏） 说明： 二、日志整体结论 该日志并非报错，而是一次“包含内存的虚拟机快照”或“虚拟机状态保存”的正常过程输出。 日志清晰地展示了以下两个阶段： 三、日志逐段解析 1️⃣ 创建虚拟机状态文件 含义： 该文件并非虚拟磁盘，而是“内存快照容器”。 2️⃣ 保存内存与运行状态 说明： 3️⃣ 内存写入进度输出 这是内存写入过程的实时进度信息： 关于“保存内存小于分配内存”的说明 在该环境中： 这是完全正常的行为，原因包括： 该结果表明虚拟机内存处于正常、稳定使用状态。 4️⃣ 日志输出频率降低说明 该提示仅表示： 5️⃣ 内存保存完成，开始磁盘快照 该行表明： 这一步明确说明：此次快照为“包含内存的快照（snapshot with RAM）” 四、该日志通常由哪些操作触发？ 常见触发场景包括： 如果仅执行普通磁盘快照，不会出现内存保存相关日志。 五、是否属于异常？是否需要处理？ ✔️ 正常情况 ➡ 无需任何处理 ⚠️ 需要注意的点（非故障） 六、运维建议（通用） 七、总结 本文所示日志为 Proxmox VE 在执行“虚拟机带内存快照”或“状态保存”时的标准输出。整个过程完整、连续、无异常，属于正常系统行为，不应被误判为错误或性能问题。

Linux

自建邮件服务器半年回顾：为什么最终选择并坚持使用 Mailcow

在自建服务体系中，电子邮件服务器是最基础、也最容易踩坑的一类服务。要求往往非常苛刻： 经过方案调研与实际部署，最终选择了 Mailcow（Dockerized），并已经稳定运行超过半年。 这篇文章对这段使用经历做一次阶段性技术复盘。 可选方案简要回顾 在选择 Mailcow 之前，常见的自建邮件方案主要包括： 如果仅从功能完整度出发，这些方案的差异非常明显。 内存需求排序（从低到高） 从实际运行经验和社区共识来看，内存需求大致如下： 结论很直接：Mailcow 不是最轻量，但是功能最完整的方案。 为什么最终选择 Mailcow Mailcow 的定位非常明确： 完整邮件系统，而不仅仅是“能收发邮件” 其优势主要体现在： 本质上，它更接近 “企业邮件系统的自建实现”。 半年稳定运行意味着什么 连续运行半年，且未出现结构性问题，本身已经说明： 这也是 Mailcow 相比轻量方案的重要优势：不是实验性质，而是长期可运行的基础设施。 半年节点的关键检查项 在运行半年后，有必要对以下几个关键点进行一次确认，而不是盲目“继续堆功能”。 1. DKIM / SPF / DMARC 状态 这直接决定邮件是否进垃圾箱。至少需要确认： 2. Rspamd 是否真正参与了“学习” 如果半年内： 那么反垃圾系统只是“存在”，而不是“被使用”。 3. ClamAV 是否仍然值得开启 现实结论往往是： 在这种情况下，ClamAV 的收益往往低于其内存成本。关闭后可显著降低整体内存占用，而不影响核心邮件功能。 4. 备份是否“可恢复” 关键问题只有一个： …

Docker

使用 Docker 自建 RustDesk 服务器：host 网络模式下的完整实践

摘要 本文记录了一次 RustDesk 自托管服务器 的完整部署实践，采用 Docker + host 网络模式，并结合 宿主机防火墙 与 边界路由器端口转发，在家庭网络环境中实现了稳定可用的远程桌面服务。 出于安全考虑，本文 对所有本地路径、端口号与网络细节进行抽象处理，仅保留架构思路、配置原则与验证方法，确保内容可理解、可复现，但不暴露任何可被直接利用的信息。 一、整体架构思路 RustDesk 官方在 Docker 场景中推荐使用 host 网络模式运行服务，其核心特征包括： 因此，网络安全边界主要由两部分构成： 二、Docker 服务的统一目录管理（路径脱敏） 所有 Docker 服务均集中放置在一个 统一的服务根目录 下，每个应用使用独立子目录管理自身配置与数据，例如： 这种结构的优点在于： 三、Docker Compose 配置（原则级描述） RustDesk 由两个核心组件组成： 二者均以 Docker 容器形式运行，并共享数据目录。 配置原则如下： 示意结构（非可直接复制配置）： 上述示例为结构示意，刻意省略所有具体参数与数值。 四、端口设计原则（不公开端口号） RustDesk 服务需要若干 固定职责端口，但在公开文档中应避免直接暴露数值。 其功能层级可抽象为： 核心通信端口 可选功能端口 在实际部署中应遵循： 五、宿主机防火墙配置原则（以 …

Fix

一次 v2rayA 部署失败的完整排障记录

摘要 在一次服务器环境部署过程中，使用 v2rayA 管理代理服务时，先后遇到了两个相互叠加的问题： 这两个问题在受限网络环境下相互影响，导致服务反复启动失败。本文完整记录了问题出现、逐步排查、原因定位以及最终解决的全过程，并总结出一套在类似环境中稳定、可复现的处理方案。 全文已严格脱敏，仅保留必要的技术事实与因果关系。 一、问题背景 在该前提下进行常规部署，出现了一系列连锁问题。 二、问题一：geoip.dat / geosite.dat 缺失 1. 现象 服务层日志提示： geoip.dat or geosite.dat file does not exists 2. 初步判断 根据 v2ray 的运行机制： 因此，问题并非配置错误，而是 资产文件获取失败。 3. 自动下载失败的真实原因 进一步结合环境特征分析后，可以确认： 由此形成典型的“鸡生蛋”死循环： 在该环境下，自动修复机制在理论上无法成功。 4. 解决方式：手动上传 geo 文件 在可访问 GitHub 的环境中下载： 上传并放置到 v2ray 默认资产目录： 重启服务（关键）： 此时： 问题一解决。 三、问题二：软件源安装的 v2ray-core 版本过低 …

SSH

OpenWrt 配置 SSH 使用密钥登录（关闭密码认证）

在 OpenWrt 路由系统中，SSH 默认使用 Dropbear 作为服务端，并允许密码登录。在具备公网访问、端口转发或远程运维场景下，切换为仅密钥登录可以显著降低暴力破解与误入侵风险。 本文记录 OpenWrt 中将 SSH 登录方式由“密码 + 密钥”调整为“仅密钥”的完整过程，并附带常见注意事项。 一、OpenWrt 中 SSH 的配置位置 OpenWrt 提供两种主要配置方式： 底层服务均由 Dropbear 控制。 二、通过 LuCI Web 界面配置（直观方式） 配置路径 关键设置项 保存并应用即可生效。 三、通过命令行配置（可控性更高） 1️⃣ 准备 SSH 公钥（客户端） 在客户端生成或查看公钥，例如： 复制输出的整行内容。 2️⃣ 写入 OpenWrt 的 authorized_keys 登录 OpenWrt（此阶段仍保留密码登录）： 创建并编辑公钥文件： 示例内容： 设置正确权限（非常重要）： 3️⃣ 禁用 SSH 密码认证 …

Network

家庭网络自建邮件服务器：关于是否需要固定 IP 的一次完整评估

一、场景说明 在一个典型的家庭自托管环境中，网络结构通常具备以下特征： 邮件服务器并非面向公众提供邮箱服务，而是用于： 是否接收来自互联网的外部邮件，并非初始刚性需求。 二、最初遇到的现实限制 1. VPS 方案的端口问题 常见的做法是使用一台低成本 VPS 作为公网入口或中转节点。然而在实践中发现： 即便 VPS 成本低廉，只要 25 端口被封禁，在邮件接收场景下就会出现功能性不可用的问题。 2. 家庭宽带（MAP-E / IPv4 over IPv6）的天然约束 在未申请固定 IPv4 的家庭宽带环境中，常见网络形态包括： 在这种情况下： 因此，“直接在家庭网络中接收外部邮件”在默认条件下并不可行。 三、被认真评估的解决方案：家庭固定 IPv4 为了解决端口受限问题，评估了运营商提供的固定 IPv4 服务。该方案在技术层面具有明确优势： 成本结构（已脱敏） 与现有 VPS（月费约 500 日元）相比，固定 IP 带来了额外且长期的成本。 四、关键转折：重新界定真实需求 在进一步分析后，一个核心问题被重新提出： 邮件服务器当前是否真的需要接收来自外部的邮件？ 对邮件系统的实际用途进行梳理后，可以明确： 由此可以得出一个重要结论： “无法接收外部邮件”并不会影响当前系统的实际功能价值。 五、工程视角下的理性判断 1. 固定 IP 的技术价值是确定的 …

Network

公网端口转发与 VPS + FRP：谁能看到真实访客 IP？

在自建服务（如 Web、SSH、邮件、游戏服务器等）的过程中，是否能够识别真实访客 IP 是一个非常关键、但常被忽略的问题。本文对两种常见方案进行对比分析： 重点讨论：后端服务究竟能看到什么来源 IP。 一、问题背景 常见的家庭或个人服务器部署方式主要有两类： 两种方案在“能否访问服务”上都可行，但在访问者 IP 可见性上存在本质差异。 二、结论先行 使用公网 IPv4 + 路由器端口转发时，局域网服务通常可以直接看到访问者的真实公网 IP。 使用 VPS + FRP 时，局域网服务只能看到 VPS 的 IP，无法直接获得真实访客 IP。 这是由网络连接模型决定的，而非配置错误。 三、公网 IP + 端口转发的工作机制 端口转发的本质是 DNAT（Destination NAT，目标地址转换）： 关键点： 因此： 四、实际表现 在这种架构下： 这是网络层原生行为，无需额外配置。 五、VPS + FRP 的连接模型 FRP 属于反向隧道工具，其连接关系为： 在该模型中： 因此在内核层面： 这是设计决定的，无法通过简单配置绕过。 六、FRP 是否能“传递”真实 …

Network

OpenWrt 公网端口转发 + Nginx 子域名反向代理完整实践与故障排查记录

一、背景与目标 在家庭网络环境中，已获得 公网 IPv4，并希望实现以下目标： 这是一个典型、标准、可长期维护的公网自建服务架构。 二、目标架构设计 最终期望的网络拓扑如下： 设计原则： 三、初始异常现象 在配置完成后，出现以下问题： 四、问题一：OpenWrt 抢占 80 / 443 1. 关键证据 使用 curl -vk 访问子域名，发现： 这说明： 2. 根因定位 检查 OpenWrt 的 uhttpd 配置： 含义： 3. 修复方式（关键一步） 将 OpenWrt 的 Web 管理界面 限制为仅监听 LAN IP： 或直接将管理端口改为 8443。 重启服务： 验证监听状态： 确认 不再存在 0.0.0.0:80/443。 五、问题二：DNAT 规则缺失 在释放 …

Network

家庭网络架构选择：固定 IP 还是 VPS + FRP？

在家庭宽带环境中，如果希望实现远程访问、自建服务或长期运行的后台系统，通常会面临一个关键选择： 使用家庭宽带固定公网 IP，还是使用 VPS + FRP 的反向穿透架构？ 这并不是一个“哪个更高级”的问题，而是一个工程取舍问题。本文从安全性、可控性、稳定性和长期维护角度，对两种方案进行系统对比。 一、家庭宽带使用固定 IP 的核心价值 固定公网 IP（静态 IP）最大的优势，在于地址稳定、访问路径直观。 固定 IP 的主要优势 从功能角度看，固定 IP 的确“简单直接”。 二、固定 IP 在家庭场景下的现实问题 在真实环境中，家庭固定 IP 往往伴随一些结构性问题： 1️⃣ 家庭网络被永久暴露 即便配置防火墙，暴露本身就是风险源。 2️⃣ ISP 合规与稳定性不确定 3️⃣ 故障与迁移成本高 三、VPS + FRP：反向穿透的工程逻辑 相比之下，VPS + FRP 并不是“权宜之计”，而是一种明确的工程设计选择。 FRP 的本质 FRP 并非传统意义上的“穿透工具”，而是： 由内向外建立的长期反向连接隧道 家庭网络主动连接 VPS，不接受任何外部入站请求。 四、VPS + …