<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Mac on Leo's Blog</title><link>https://4ac33ebd.leo-blog.pages.dev/tags/mac/</link><description>Recent content in Mac on Leo's Blog</description><generator>Hugo -- gohugo.io</generator><language>zh-CN</language><lastBuildDate>Sat, 27 Jun 2026 21:56:42 +0800</lastBuildDate><atom:link href="https://4ac33ebd.leo-blog.pages.dev/tags/mac/index.xml" rel="self" type="application/rss+xml"/><item><title>我的HomeLab基础配置</title><link>https://4ac33ebd.leo-blog.pages.dev/p/homelab-base/</link><pubDate>Sat, 27 Jun 2026 21:56:42 +0800</pubDate><guid>https://4ac33ebd.leo-blog.pages.dev/p/homelab-base/</guid><description>&lt;p&gt;不知不觉间，距离我第一次接触 Linux Server 已经过去了六年，而开始折腾自己的 HomeLab 也已经快两年了。这些年踩过不少坑，也积累了一些经验，因此想借这篇文章，把这段折腾历程记录下来，顺便和同样对自托管感兴趣的朋友分享一下。&lt;/p&gt;
&lt;h1 id="硬件与系统"&gt;硬件与系统
&lt;/h1&gt;&lt;p&gt;硬件方面，我选择了一台 Mac mini M1。作为苹果第一代 Apple Silicon 设备，它拥有约 5W 的待机功耗和不错的 CPU 性能，对于个人 HomeLab 来说已经完全够用。&lt;/p&gt;
&lt;p&gt;我使用的是 8GB + 512GB 的版本。最初购买它只是为了看网课和写文档。依稀记得当年正值矿潮，原本计划组装一台台式机，结果预算被显卡价格劝退，只好先买了这台 Mac mini 过渡。大约使用了两年后，我还是换成了组装台式机，而这台 Mac mini 也因此闲置了一段时间。后来想到可以拿它来部署一些自托管服务，也算是让它焕发了第二春。&lt;/p&gt;
&lt;p&gt;当然，如果你手头已经有闲置的低功耗设备或者 VPS，也完全可以直接利用起来。就目前而言，我认为并没有专门为了 HomeLab 再去购买一台 M1 Mac mini 的必要，没有必要为了折腾而创造新的消费需求。&lt;/p&gt;
&lt;p&gt;截至目前，这台机器已经稳定运行了一年左右。硬盘占用约 100GB，在同时运行约 20 个 Podman 容器的情况下，内存占用大约维持在 3.4GB 左右，整体资源利用率让我相当满意。&lt;/p&gt;
&lt;p&gt;系统方面，这台机器最初搭载的是 macOS Big Sur，后来一路升级到了 macOS 15。最开始运行服务时，我依旧选择了原生 macOS，但用久之后便逐渐暴露出不少问题。&lt;/p&gt;
&lt;p&gt;首先，macOS 的许多设置仍然依赖 GUI 完成，在纯 SSH 环境下操作并不方便，很多时候不得不额外开启 VNC。其次，桌面环境本身也会占用不少系统资源，再加上 OrbStack 运行多个容器后，内存压力会明显增大，频繁使用 Swap 对 SSD 也并不友好。此外，使用 macOS 作为服务器本身就是一个相对小众的需求，相关文档和社区资源远不如 Linux 丰富，遇到问题时往往很难找到成熟的解决方案。&lt;/p&gt;
&lt;p&gt;后来，我在刷 B 站时偶然了解到 Asahi Linux 项目。这个项目致力于让 Apple Silicon Mac 原生运行 Linux。目前，它已经能够较好地支持大部分 M1 和 M2 设备。就我这台 Mac mini M1 而言，基本没有遇到什么严重问题，作为服务器使用已经完全足够。&lt;/p&gt;
&lt;p&gt;安装过程直接参考官方文档即可，整个流程基本都是引导式操作，没有太高门槛。分区时建议给 Linux 多预留一些空间，毕竟大概率之后就不会再频繁进入 macOS 了。我个人只给 macOS 保留了约 100GB 的空间。&lt;/p&gt;
&lt;p&gt;发行版方面，Asahi 官方主要支持 Fedora Linux，这也是我目前正在使用的系统。整体使用下来稳定性相当不错，我甚至曾经直接从 Fedora 42 升级到 Fedora 44，也没有出现任何问题。除此之外，Ubuntu、Debian、Arch Linux ARM、Void Linux 以及 Gentoo 等发行版也都有社区贡献者提供支持，这里就不再展开讨论了。&lt;/p&gt;
&lt;h1 id="我部署的服务与部署方式"&gt;我部署的服务与部署方式
&lt;/h1&gt;&lt;p&gt;我目前在这台 HomeLab 上部署了如下服务：&lt;/p&gt;
&lt;table&gt;
	&lt;thead&gt;
			&lt;tr&gt;
					&lt;th&gt;分类&lt;/th&gt;
					&lt;th&gt;服务&lt;/th&gt;
					&lt;th&gt;用途&lt;/th&gt;
			&lt;/tr&gt;
	&lt;/thead&gt;
	&lt;tbody&gt;
			&lt;tr&gt;
					&lt;td&gt;RSS&lt;/td&gt;
					&lt;td&gt;FreshRSS、RSSHub&lt;/td&gt;
					&lt;td&gt;信息聚合&lt;/td&gt;
			&lt;/tr&gt;
			&lt;tr&gt;
					&lt;td&gt;媒体&lt;/td&gt;
					&lt;td&gt;Jellyfin、Stash&lt;/td&gt;
					&lt;td&gt;影视与媒体管理&lt;/td&gt;
			&lt;/tr&gt;
			&lt;tr&gt;
					&lt;td&gt;相册&lt;/td&gt;
					&lt;td&gt;Immich&lt;/td&gt;
					&lt;td&gt;照片备份&lt;/td&gt;
			&lt;/tr&gt;
			&lt;tr&gt;
					&lt;td&gt;财务&lt;/td&gt;
					&lt;td&gt;Wallos&lt;/td&gt;
					&lt;td&gt;订阅管理&lt;/td&gt;
			&lt;/tr&gt;
			&lt;tr&gt;
					&lt;td&gt;存储&lt;/td&gt;
					&lt;td&gt;CloudDrive2、OpenList&lt;/td&gt;
					&lt;td&gt;文件聚合&lt;/td&gt;
			&lt;/tr&gt;
			&lt;tr&gt;
					&lt;td&gt;阅读&lt;/td&gt;
					&lt;td&gt;Calibre-Web、KoSync&lt;/td&gt;
					&lt;td&gt;电子书管理&lt;/td&gt;
			&lt;/tr&gt;
			&lt;tr&gt;
					&lt;td&gt;日历&lt;/td&gt;
					&lt;td&gt;Radicale&lt;/td&gt;
					&lt;td&gt;CalDAV 服务&lt;/td&gt;
			&lt;/tr&gt;
			&lt;tr&gt;
					&lt;td&gt;网络&lt;/td&gt;
					&lt;td&gt;Caddy、Tailscale&lt;/td&gt;
					&lt;td&gt;网络访问与反向代理&lt;/td&gt;
			&lt;/tr&gt;
	&lt;/tbody&gt;
&lt;/table&gt;
&lt;p&gt;我所选用的服务大多都是开源软件。像 CloudDrive2 这种暂时缺乏成熟 FLOSS 替代方案的软件，我则使用了它的免费版本。这里重点聊聊，我为什么会在众多同类项目中选择它们。&lt;/p&gt;
&lt;p&gt;相比 PhotoPrism，Immich 提供了官方的 iOS 和 Android 客户端，手机照片同步体验方便了许多。启用之后，再也不用担心 iCloud 免费版那可怜的 5GB 空间天天弹出容量不足的提醒了。而且，你的照片也不用担心遭到某些网盘平台的和谐。&lt;/p&gt;
&lt;p&gt;我主要使用 Jellyfin 来托管自己的动漫和音乐库，并将资源直接存储在本地，而不是依赖云盘。&lt;/p&gt;
&lt;p&gt;原因主要有两点：首先，Jellyfin 对 CloudDrive2 挂载目录的扫描速度较慢；其次，虽然通过 strm 文件等方式可以显著提升扫库效率，但往往需要额外部署重定向服务，并对 Jellyfin Web Client 进行一些修改。对于我来说，这套方案还是过于折腾了。&lt;/p&gt;
&lt;p&gt;况且，我真正会反复观看和收听的资源其实并不多，因此直接本地存储反而成了一个更简单、也更稳定的选择。&lt;/p&gt;
&lt;p&gt;此外，相比 Emby、Plex 等需要付费才能解锁完整客户端体验的方案，Jellyfin 在客户端生态和功能开放程度上都更加自由，也不需要费心去寻找各种来源不明的破解版。&lt;/p&gt;
&lt;p&gt;FreshRSS 则主要用于同步我的 RSS 订阅和阅读进度，实现手机、台式机以及笔记本之间的无缝衔接。配合 RSSHub，主流网络平台上的大量信息都可以重新以 RSS 这种“旧时代”的方式获取，从而尽可能摆脱算法推荐带来的信息茧房。&lt;/p&gt;
&lt;p&gt;部署方式上，除了 Tailscale 和 CloudDrive2 是直接安装在宿主机上的，其余服务我都通过 Podman Rootless 配合 systemd Quadlet 进行管理。所有数据统一存储在 &lt;code&gt;~/containers&lt;/code&gt; 目录中，方便后续备份与迁移。&lt;/p&gt;
&lt;p&gt;平时登录服务器时，我主要使用 OpenSSH 客户端；如果遇到网络故障，也可以直接切换显示器输入源，接上键盘后在 TTY 环境下进行维护。&lt;/p&gt;
&lt;p&gt;至于远程访问，我选择将一个泛域名通过 CNAME 解析到 Tailnet 提供的 &lt;code&gt;ts.net&lt;/code&gt; 域名，再配合 Caddy 作为反向代理。这样既避免了服务直接暴露在公网环境中，也保证了所有安装了 Tailscale 的设备都能通过统一的域名安全访问这些服务。&lt;/p&gt;
&lt;p&gt;相比 Cloudflare Tunnel 的方案，Tailscale 可以自动选择最优链路，并尽可能建立 P2P 直连。在大多数情况下，我都能够直接通过 IPv6 GUA 使用移动网络访问家中的服务器。此外，我还部署了私有 Derper 服务器，用来保证在 Hard NAT 环境下的连接质量。&lt;/p&gt;
&lt;p&gt;这里放一张简单的域名解析示意图：&lt;/p&gt;
&lt;div class="highlight"&gt;&lt;pre tabindex="0" class="chroma"&gt;&lt;code class="language-text" data-lang="text"&gt;&lt;span class="line"&gt;&lt;span class="cl"&gt;*.example.com
&lt;/span&gt;&lt;/span&gt;&lt;span class="line"&gt;&lt;span class="cl"&gt; │
&lt;/span&gt;&lt;/span&gt;&lt;span class="line"&gt;&lt;span class="cl"&gt; CNAME
&lt;/span&gt;&lt;/span&gt;&lt;span class="line"&gt;&lt;span class="cl"&gt; │
&lt;/span&gt;&lt;/span&gt;&lt;span class="line"&gt;&lt;span class="cl"&gt;xxxxx.ts.net
&lt;/span&gt;&lt;/span&gt;&lt;span class="line"&gt;&lt;span class="cl"&gt; │
&lt;/span&gt;&lt;/span&gt;&lt;span class="line"&gt;&lt;span class="cl"&gt; Tailscale Tailnet
&lt;/span&gt;&lt;/span&gt;&lt;span class="line"&gt;&lt;span class="cl"&gt; │
&lt;/span&gt;&lt;/span&gt;&lt;span class="line"&gt;&lt;span class="cl"&gt; Caddy Reverse Proxy
&lt;/span&gt;&lt;/span&gt;&lt;span class="line"&gt;&lt;span class="cl"&gt; │
&lt;/span&gt;&lt;/span&gt;&lt;span class="line"&gt;&lt;span class="cl"&gt; HomeLab Services
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;p&gt;至于具体每个服务的部署过程，本文就不再详细展开了。实际上，在熟悉 Quadlet 的工作方式之后，大部分容器配置都大同小异，无非是修改几个 Volume 和 Environment 参数而已。后续如果有机会，我可能会单独写几篇文章来记录其中的一些经验。&lt;/p&gt;
&lt;h1 id="聊聊自托管"&gt;聊聊自托管
&lt;/h1&gt;&lt;p&gt;使用这些自托管服务已经有一段时间了。在我看来，自托管最大的价值主要体现在自由和成本两个方面。&lt;/p&gt;
&lt;p&gt;首先，通过上文提到的这些项目，我们可以轻松搭建属于自己的数字资源中心，而不必忍受各种广告、DRM 限制以及越来越高的订阅费用。无论是影音资源、照片管理还是 RSS 阅读，都能够以更加聚合和自主的方式完成。&lt;/p&gt;
&lt;p&gt;其次，你不用担心某个平台突然倒闭、封禁账号，或者悄悄收集和上传你的个人数据；也不会因为过度依赖某家公司的生态而难以迁移。某种意义上，自托管也是重新夺回数字时代数据主权的一种尝试。&lt;/p&gt;
&lt;p&gt;当然，自托管并非只有优点。&lt;/p&gt;
&lt;p&gt;与云服务相比，自托管意味着你需要承担更多维护工作：系统更新、数据备份、故障排查以及安全加固，都需要亲力亲为。很多时候，一个看似简单的问题，可能就会消耗掉整个周末。&lt;/p&gt;
&lt;p&gt;例如，我曾尝试在 Fedora Asahi Remix 上使用 Box64 替代 QEMU，以便在 Podman 中运行某个仅提供 x86_64 版本的闭源容器。折腾了许久，查阅了大量资料，最终还是没能找到可行方案，只能选择放弃。&lt;/p&gt;
&lt;p&gt;此外，我认为，在开始部署某个服务之前，更应该先思考它是否真正解决了自己的某个实际问题，例如数据同步、媒体管理或者订阅成本。&lt;/p&gt;
&lt;p&gt;不少人会不断尝试新的服务，却很少真正使用它们，最终陷入“为了折腾而折腾”的循环。折腾本身固然有趣，但我们也需要时不时停下来问问自己：这个服务，是否真的改善了自己的数字生活？&lt;/p&gt;
&lt;p&gt;希望每个人都能在折腾 HomeLab 的过程中，收获乐趣，也收获便利。&lt;/p&gt;</description></item></channel></rss>