🏠 **初期建设与需求明确 (2023年)**：作者在新家入住后，基于对全屋透明代理、内网2.5G速率、内网穿透等核心需求的考量，开始构建家庭网络。初期采用OpenWrt作为软路由系统，并在ESXi上虚拟化部署。服务器方面，选择了支持多盘位、ECC内存、核显的配置，并最终部署了TrueNAS系统，以实现数据存储、虚拟机和容器运行。智能家居方面，选择了HomeKit生态，并通过Aqara网关及HomeAssistant进行设备接入。

⚠️ **问题浮现与架构优化 (2024年)**：随着网络使用，单点故障（网管交换机）和OpenClash的性能问题逐渐暴露，导致网络不稳定和故障恢复困难。作者通过链路可用性分析，调整了物理拓扑，将路由器移回弱电箱，减少了强依赖项。系统架构上，将OpenClash剥离出主路由，并在ESXi中单独运行，以隔离资源消耗，同时优化了服务器应用和服务，并引入了基于Shell脚本的初步监控体系。

📈 **体系化建设与稳定性提升 (2025年)**：面对瞬时异常难以捕捉和监控盲区等问题，作者将重点放在建设体系化监控和设备职责单一化上。引入了Prometheus+Grafana进行系统监控，以及Alloy+Loki组合进行日志采集与分析，实现了对各关键节点更精细化的观测。同时，精简了软路由功能，将HomeAssistant迁移至服务器，并考虑未来增加专用计算设备，以遵循KISS原则，进一步提升系统的稳定性和可维护性。

原文发布在我的博客

前言

早在毕业后的租房时期，我就时常期待拥有自己的家后要如何改造家庭网络。每次看到网上博主分享内网万兆传输、服务器机柜、NAS 阵列等内容，都不禁心生羡慕。2023 年新家入住后，我对家庭网络的改造断断续续持续了两年。到了 2025 年，终于是时候对这段历程做一些总结了。

这篇文章将重点回顾这两年来家庭网络结构的演进过程及背后的思考。

房屋结构和网络需求

房屋为精装交付，出于成本考虑，入住时未对结构进行大幅改造。简略结构如下：

入住前暴露的主要问题有以下几点：

弱电箱嵌入在进门鞋柜内，空间非常有限，难以容纳较多设备，散热也较差。网口数量不足，无线 AP 只能放置在客厅，书房存在 WiFi 死角。预埋网线为超五类，虽然短距离可支持万兆，但稳定性不佳。

我对家庭网络能力的主要需求如下：

基于以上的需求，得到以下的初步结论

由于需要全屋透明代理，故需要使用软路由做主路由的方案，这里我选用 OpenWrt 作为我的软路由系统。由于需要全屋 2.5G 速率，硬件上交换机/AP/设备网口均需要支持 2.5G 协商速率。（被只支持 1G 和 10G 的万兆卡坑过）由于需要内网穿透+私有域名等需求，需要软路由系统有相关的功能支持.(关注版本功能)由于需要智能家居内网部署，购买设备时需要关注是否支持 Zigbee / Matter 等协议。

2023 年：从零搭建，先跑起来

物理拓扑

2023 年的主题是建设，在入住后不久，我便设计了如下的网络拓扑：

可以看到这里用了不太常见的单臂路由作为主路由连接方案，并不是因为软路由只有一个网口，纯粹是当时考虑如果软路由放在弱电箱内散热不太好。

我的主要网络设备如下：

软路由：零刻 EQ12(n100/16G)交换机：TP-LINK 网管交换机 + 水星非网管交换机无线 ap：小米 AX7000服务器：X11SCA-F + E2144G + 64G ECC

硬件配置上普普通通，甚至有些富裕。当然，在闲鱼淘的交换机还是带起了后续的一些变化（笑

系统架构

系统架构如下图所示

软路由

我在 ESXi 上虚拟化运行 OpenWrt ，主要出于以下考虑：

部署便利：套一层虚拟机便于在更改网络配置时不需要进行物理空间内的布线调整。容灾能力：ESXi 有完善的备份还原机制，通过备份可以快速恢复网络配置。性能考虑：觉得软路由性能过剩，除了 OpenWrt 还可以安装其他的系统（这点后来证明并不现实）。熟悉程度：相比 PVE 来说对 ESXi 更熟悉一些

OpenWrt 使用了来自恩山的“高大全”版本，后来发现其中大部分功能并未用到，反而偶尔引发卡顿。

HomeAssistant 直接部署在软路由中，主要原因一是软路由设备先于服务器购买，出于调教智能家居设备的原因先安装在软路由内。二是 HA 需要安装 HAOS 才能安装插件（即必须是虚拟机版本，不能部署在容器内），当时认为 TrueNAS 的虚拟机能力并没有 ESXi 好，所以服务器买来后也没有进行迁移（后来发现 N100 性能根本无法与 E-2144G 相比😅）

服务器

2023 年 618 ，我筹备组建第一台服务器，当时我对服务器的主要需求是以下几点：

是一台偏存储的服务器，多盘位存储且支持 SAS 硬盘。支持 ecc 内存。带核显，支持视频硬解。支持 RAID 。可以装虚拟机/容器。

在淘了比较久的垃圾后，最终选用的配置如下：

主板: 超微 X11SCA-FCPU: Intel E-2144G内存: 三星 DDR4 2666 ECC 32G*2 硬盘: 希捷酷鹰 4T*4网卡: 迈络思 MCX311A机箱: 半人马座电源: 海韵 SGX500

这套配置里，最先选择的是机箱，因为家里没有位置放置机柜，想要多盘位又不想装较大的塔式机箱，最终入了半人马的机箱，颜值和扩展相对不错。

CPU 上，2144g 的性能和能耗较为平衡，且核显有 QSV 能力，能加速视频编解码，主频 3.6 睿频 4.5 也能较好的应付日常的计算工作。

内存上由于心心念念一直想要搞一套 ecc 内存，这次选用了三星的 ddr4 2666 的纯 ecc 内存条(24 年还坏了一根😭)。

这套配置有几个小插曲，一是网卡一开始买的浪潮电口 X540, 没想到居然不支持 2.5G 协商速率，害的我又重新买了一块。二是由于机箱比较小，虽然能装 atx 板，但硬盘接口的位置都被挡住了，没办法后续加装了一块 SAS 直通卡解决。

在系统上，由于是偏存储的服务器，系统更偏向选择一些具备 nas 功能的系统，在 Unraid/TrueNAS 等一众 nas 系统及 linux 原生/虚拟机系统的抉择下，我最终选择了以 TrueNAS 作为我的服务器系统，理由主要是以下几点:

相比 Unraid 等 NAS 系统，TrueNAS 使用 ZFS 文件系统，有完善的数据验证、快照、恢复等机制。相比直接部署 linux 系统, TrueNAS 上有更易上手的 RAID 管理/监控等能力。相比部署虚拟机系统，如 ESXi 或 proxmox ，由于 TrueNAS scale 已经支持了虚拟机和容器，我不需要再加一层套娃。

RAID 方面，我的 4 块 4T 酷鹰组了 RAIDZ1(类似 RAID5)，实际容量在 10T 左右，确保在一块坏了的时候能够不丢失数据恢复。

软件服务方面，我部署了以下的服务：

qBittorrent：PT 下载。Homepage: 家庭服务仪表盘。icloudpd: 同步 iCloud 照片Jellyfin: 媒体服务器。TinyMediaManager: 影视元数据刮削。PhotoPrism: 照片管理

智能家居

作为 ios 用户，加上购买了 AppleTv 、HomePod 等一些设备，智能家居生态自然选择了 Apple 的 HomeKit 。主要设备有:

网关: Aqara M1S/HomePod开关: Aqara D1空调控制: 郎宁 VRF窗帘电机: Aqara传感器: 小米人体传感器门锁: 小米智能门锁电视: AppleTv

Aqara 设备通过网关直接接入 HomeKit ，小米设备则通过 HomeAssistant 桥接接入。

2024 年: 问题浮现与系统优化

遇到的问题

2023 年的架构基本稳定运行至 2024 上半年，期间虽然偶尔出现 PT 流量误走代理、OpenClash 卡死等问题，但尚可接受。

然而以上的拓扑存在一个致命的缺陷: 弱电箱中的网管交换机成为单点故障。一旦损坏，替换过程极为繁琐，需重新配置 VLAN ，且端口顺序必须与原配置一致。

而就在 2024 年的 5 月某天，那台网管交换机突然宕机了，我在重新下单等了 2 天收到货后开始配置，才发现完全不记得之前的 VLAN 设置了。当时正值 618 之际，在每天晚上下班仅有的 2 个小时内，花了 2 天才将家庭网络恢复如初。这促使我决心进行网络改造，重点是稳定性和容灾能力

链路可用性分析

既然要增强系统稳定性及容灾能力，那么首先需要梳理一下目前的网络链路以及相关的可用性需求。

其次，需要梳理一下网络中可能故障的节点以及其挂了后的影响面。对影响面的评估我分了以下几级：

致命: 对网络可用性或完整性产生重大影响，且无法通过备用设备进行快恢。严重: 对网络可用性或完整性产生较大影响，但可以通过备用设备或降级部分功能完成核心功能恢复。一般: 对网络可用性或完整性产生影响，但有备用链路可以使用，或允许接受功能降级的情况。轻微: 有轻微体验影响的情况

先列举一下物理设备可能的故障:

然后是系统组件的可能的故障:

物理拓扑的调整

根据上述的可用性优先级，我将物理拓扑图变成了这样:

从物理拓扑上来看，改变不算特别大，仅是将路由器从书房移回了弱电箱，但从稳定性的角度考虑，这一项调整让家庭减少了 2 个强依赖项，一个就是网管交换机，就算挂了我也可以替换为普通交换机，甚至不用交换机直连客厅 AP,也能保证局部的网络可用。另一个就是去除了弱电箱到书房的网线这个强依赖，一旦网线出问题，仅需降级书房的有线网络即可保障部分可用性。

至于软路由的散热问题，一来在这一年的使用过程中，温度还算可控。二来我买了一个 usb 温控风扇贴着吹进行散热，整体评估放在弱电箱内问题不大。（是吗=。=）

系统架构的升级

在系统拓扑方面，改造的东西就相对较多一些了，在聊改造细节之前，我们还是先来看看当下遇到的问题有哪些：

由于 OpenClash 的性能问题，导致间歇性的断网。当 OpenClash 的目标节点异常时没有主动感知，在连不上外网或者速度很慢时才能发现进行切换。PT 流量会经过代理服务器导致流量耗尽。所有数据共用一个磁盘组，PT 和重要数据的区分不够，有数据丢失风险，重要数据没有备份机制。网络的整体监控能力较弱，出现问题无法溯源。缺少各关键节点的容灾能力。

为了解决以上的问题，系统的拓扑变成了这样：

软路由内的调整

由上图所示，软路由内最大的一个改变，就是将 OpenClash 从拨号的 OpenWrt 内剥离了出去，并将拨号用的 OpenWrt 更改为了自编译的精简版本，插件只包含了阿里 ddns 和 mosdns ，其中阿里 ddns 用于内网穿透，而 mosdns 用做代理分流使用。

首先需要说明一下这样调整后的网络请求顺序，为方便说明，拨号用的 OpenWrt 简称为 A ，OpenClash 所在的 OpenWrt 简称 B：

如图所示，在这种网络链路下，国内请求不会经过 OpenClash ，同时为了控制 OpenClash 影响的 CPU 和内存范围，我选择在 ESXi 内单独起了一个虚拟机，用 ESXi 进行最大 CPU 和内存的限制，尽可能做到在 OpenClash 异常时不会耗尽整个路由器资源。至于为什么要再套一层 OpenWrt 而不是直接部署 OpenClash ，那是为了后续有其他插件需要安装时也可以从主链路中剥离开。

而在 2024 年，为什么我还将 HomeAssistant 部署在软路由内，原因是当时高估了软路由的性能，并且因为担心服务器挂了可能会影响智能家居设备=.=

服务器的调整

首先提一下硬件上的调整(上图中没展示出来)，由于需要按资料重要性进行资源隔离，我新增了 2 块二手 12T 的氦气盘组了 RAID 1 阵列，高频读写的 PT 、影音等数据存在这个阵列内，原先的阵列用来存放家庭照片、数据备份、文档备份等。

然后是服务器内部署的一些应用进行了调整:

移除 Jellyfin：由于我没有在外看视频的需求，在家的话不需要在服务器上进行解码，直接传流手机解码即可，最终方案是在手机和电视上安装了 infuse 作为媒体观看软件。PhotoPrism 替换为 MTPhotos: PhotoPrism 属实难用。新增 Alist （网盘管理）、Calibre （电子书管理）。部署 Ubuntu 虚拟机: 用来部署相关的监控脚本。计划上会添加上 prometheus+grafana 作为监控套件，但实际 2024 年并未添加

在增强稳定性方面，服务器上的脚本担任了绝大多数的任务需求，整个监控体系如下图所示:

其中的脚本都是非常简单的 shell 脚本，通过 http 请求对应服务的管理接口，有数据就当有心跳。这里可以看出当时的一个观点：只要不挂都不是大问题（笑）。但这套体系还是有不少的监控盲区和问题，最显而易见的，就是当 OpenWrt 或者 ESXi 挂了的时候，push 消息根本发不出来（这个问题居然一直到了 25 年才被反应过来）

2025 年: 体系化与稳定性建设

发现问题

上述调整后的架构完美运行了很长时间，期间没有发生任何大问题，偶尔的 clash 异常也能在重启后恢复。但没出大问题也就意味着上述的降级容灾措施并没有被实际验证过。

时间来到 2025 年的夏天，某个周末开始网络会时不时出现卡顿，一开始还以为是 PT 下载的缘故，由于持续时间不长就没太关注。但慢慢的卡顿频率越来越多，有时候 OpenWrt 的 CPU 占用会飙升到 100%，排查发现 OpenWrt 内 CPU 占用最高的线程是 ksoftirqd ，ksoftirqd 是一个处理软中断的线程，它占 CPU 高往往是结果而不是原因。深入排查发现在弱电箱内的软路由在正常情况下就烫的厉害，那会不会是因为软路由散热不好导致 CPU 降频或网卡异常进而触发了软中断爆炸呢，在换了一个更大的散热风扇后，这个情况再没有发生。

这个事件让我看到了 2 个问题：

现有监控无法捕捉瞬时异常，缺乏历史数据追踪。软路由的负载过高，需进一步划清设备职责。

这样下来，2025 年的改造目标，重点就是：

建设体系化监控+设备能力单一化

监控体系升级

其实在 2024 年的规划中，就已经画出了 grafana+prometheus 的套件组合，但由于 prometheus 过于原始的配置方式，加上当时认为脚本探活就可以完成家庭网络的监控工作，这 2 者并没有被使用起来。

回到现在，监控体系还是选择使用 grafana+prometheus 的组合，毕竟开源解决方案很多。安装后的效果如下。

关于 prometheus exporter 的选择，目前是这样的:

需要提的是为什么没有 ESXi 的 exporter ，原因是不想为了监控再装一个 vCenter 了=。=

日志

日志及下述单一化的部分在这篇文章写作之时并没有完全调整完成，这里主要说一下我的方案。

既然监控使用了 grafana ，日志当然使用 promtail+loki 的配套搭配，但看了文档发现 promtail 目前已经被弃用了，替代者是 alloy ，所以整个的日志方案就变成了 alloy(日志采集)+loki(日志存储)+grafana(日志看板)的组合拳。

TrueNAS 内的日志采集直接部署 alloy 应用即可，日志基本集中在/var/log 目录下，我目前是采集了/var/log/containers/*和/var/log/syslog.log 用以监控应用和系统的关键日志。

OpenWrt 的日志采集，我决定参考 github 的方案在 OpenWrt 内直接部署日志上报的功能。

ESXi 和 HomeAssistant 暂不接入。

设备职责单一化

在软件工程里，KISS 原则是一个非常重要的工程实践方法。回看前两年迭代的结构演进，有哪些地方违法了 KISS 原则呢？

为了减少 OpenClash 对系统的影响，引入了 mosdns 进入主链路。软路由内部署了 HomeAssistant 。存储服务器承担了越来越多的计算工作。

要如何解决这 3 个问题呢，我目前的方案如下：

关于问题 1, 当我在 2025 年再次审视 clash 的配置时，发现其实 clash 本身就支持 dns 分流及按配置绕过内核，引入 mosdns 似乎并不需要，于是我将 2 个 OpenWrt 再次删减为一个，仅使用 OpenClash 的规则配置进行流量分流，这个方案带来的唯一问题可能 CPU 会被 clash 吃满，但这通过监控也可以完成 clash 自动启停。关于 clash 的配置，github 上的这个仓库有非常详尽的教学，可以参考。

关于问题 2, 很好解决，我将 HomeAssistant 从软路由迁移至服务器。

关于问题 3 ，这实际是个成本问题（哈哈）。随着监控和日志系统的完善，我计划观察一段时间服务器使用，如果确实日常计算量很高，可能会考虑增加一台专用计算的设备保障存储设备的稳定性。（比如 mac mini ）

最后

家庭网络的建设是一个持续迭代的过程，从最初的“能用到”到“稳定用”，再到“高效与可观测”，每一个阶段都伴随着新的挑战与解决方案。本文重点分享了设计思路与架构演进，具体技术细节将在后续文章展开。如果你也正在构建家庭网络，希望本文能为你提供一些参考。