刚刚好：我的 Atlas Canyon NUC 与低配 "Homelab"

看别人的 Homelab 馋啊，空有需求但没有好的硬件，就买了个 Intel NUC11ATKC4，四核赛扬 N5105 CPU，代号 Atlas Canyon（阿特拉斯峡谷）。有人可能会问，就这么个破赛扬能干啥啊？其实只要摆脱坑比 Windows，能干的事情多着呢。

不过我承认，标题确实是我临时起的，之后性能余量是否够用，那就是以后的事情了。

开箱与拆机

NUC 嘛大家都懂，买回来就是个准系统，没有硬盘没有内存，更别提操作系统了。硬盘买的是血统纯正的国产货，致态（钛）TiPlus 5000 512G，内存则是笔记本换下来的海力士 8G*2。这里吹一波东哥的售后啊，硬盘买回来外包装破了，直接进行了一个上门换新，不到 24 小时搞定。

盒子是一个简洁的纸壳盒子，结合包着每一个部件的塑料袋来看，很难说它是环保还是不环保。包装盒中含有主机、不用看系列（还真得看）、分体式的电源，以及一个灵魂 Celeron Inside logo。

电源来自航嘉，约 65W 功率，三脚插头，考虑到主要部件的功率，余量留得很足。可惜没有做成 PD 充电。

拆装的话需要拧开底下的四个角的螺丝，这之后就可以直接揭开后盖。

前面板接口有两个 USB 3.0 5Gbps，一个 8 针的工控用途 IO，耳机和麦克风各一个；后面板有惊人的两个 USB 3.1 10Gbps、两个 USB 2.0、一个千兆网口、一个 RJ45、一个 HDMI、一个 DP，以及一个供电用的 DC 圆口。这个接口量是超出我预期的，但美中不足的是没有 USB-C。只有一个网口，注定了它不能当作通常的软路由。反正我不是拿来当路由器的，不管它。

卸下底部盖板后就可以看到内部，排列还是比较紧凑的。如图是装好硬盘和内存的样子。网卡型号为 Intel 9462NGW，仅支持 802.11ac，CNViO 协议，被盖在硬盘下面，网卡叠叠乐。

底盖是金属材质，SSD 位置有导热贴。其他地方的导热贴贴得似乎比较散乱。两边具有散热孔，方便空气流通；而散热模组在机身上部，清灰需要将主板拆下来。

如果因清灰等原因需要拆散热模组，需要先拆下固态硬盘，断开硬盘下方网卡上的两根天线，注意（按照网卡贴纸文字方向）左侧为黑线，右侧为白线。如果前侧工控 I/O 的橡胶垫没拔下来，需要先拔下来。因为机身后侧并未使用金属加强，所以可以将撬棒伸入后部 RJ45 接口上方与塑料外壳的缝隙处，轻轻撬开，即可卸下主板。装回时也需先将前侧接口插入机身。

现在就可以看到散热模组和外壳内部的样子了。散热模组包含一个风扇和一条热管，风扇不小，酷冷至尊提供，规模不弱于许多游戏本；孤零零的单热管，看起来也就 6mm，看起来散热能力就不太行，或许配这么大的风扇只是为了静音。

然后断开风扇排线（注意线序，这台蓝色线在左侧），拧松风扇周围三颗防丢螺丝，即可拆下风扇。本人并没有继续拆热管，懒得换硅脂了。

可以看到这颗 N5105 盖着散热模组的样子了。连个铜柱都没有，热管也没有做压扁的处理，很符合这 CPU 低功耗的形象。小小的也很可爱。

操作系统与 BIOS

使用 archinstall 脚本，安装了 Arch Linux。其实在它的加持下，Arch 的安装没有那么难了，也不再需要一点一点的配置，顶多就是 TUI 界面看起来不太友好。

为什么不是 Windows？我可不想让这赛扬整天满载；
为什么不是 TrueNAS？我不会用 FreeBSD；
为什么不是 Unraid？要钱，也对 Slackware 不熟悉；
为什么没有虚拟化（ESXi 之类的）？据传 N5105 跑虚拟化有点问题；
为什么是 Arch Linux？更新快，Wiki 完善，较为轻量，AUR。

装了个 GNOME 桌面环境，不光是因为有领先的 Wayland 支持，而且还有一个原因我们后面会提到。虽然 I 家驱动做得烂，但也不再有 NVIDIA 独显那样烂泥扶不上墙的问题。

BIOS 的设置非常丰富，能够自由调整 CPU 温度墙、PL1/PL2 功耗、风扇转速各方面阈值，也可以自由开关各种接口，可玩性很强。

性能

也不要有什么过高的期望了，N5105 只有四个低功耗 Jasper Lake 核心，总 TDP 才 15W，满载还没一颗骁龙 8 Gen 1 功耗高。但过热应该非常难出现，毕竟就这点功耗还有主动散热加持。事实证明我的猜想是对的，BIOS 风扇设置为 cool 档之后，烤机 CPU 温度维持在 65 度，也比骁龙 8 凉（狗头）。

Geekbench 5 CPU 跑分为单核 699、多核 2286（详见测试记录）；Geekbench 6 单核 557，多核 1646（记录）；Vulkan Compute 跑分为 2313（详见测试记录）。

使用 Firefox 观看 4K YouTube 视频，接 2K 显示器，略有卡顿。2K 分辨率的 CS 能够流畅运行。平常浏览网页等用途则完全未感受到卡顿。

可能由于本身机能限制或文件系统限制，其实是无法完全发挥这块硬盘性能的，标称读 3500 写 2700，在 Btrfs 文件系统下，实际上只能做到读写 1700 左右。

在 KDiskMark 中，跑出了一个更慢的成绩。

内存只能跑在 2933MHz，应该对核显性能有一定程度的影响，不过核显本来就很菜，无所谓了。

互联

网络

要从外网访问内网中的主机，内网穿透是一个很经典的方案，但这需要一台带宽够高、延迟够低、流量足够多的服务器，这在国内成本比较高，将内网服务暴露到外网也让所有人可以访问，有些危险。虚拟局域网方案顾名思义，将在不同内网下的电脑划在同一个 “局域网” 里。在这其中，Tailscale 算是体验最好的之一了。NAT 打洞成功率较高，这意味着大部分时候可以以直连的延迟与带宽在不同设备之间连接。

tailscale/tailscale

Tailscale 的配置非常简单，按照指引配置即可，用起来就知道有多爽了。目前用起来缺点很少，就是不能为同一个机器分配多个域名并签发多个 HTTPS 证书，极限网速也比不了直连（并不是因为性能开销过大，表现见下）。某种程度上，就是这种异地组网程序让下面的许多用途从” 可能” 变为 “好用”。

其他的方案还有 n2n、Netmaker 和 ZeroTier 等，在此不做介绍。

桌面

这样一来桌子上就有两台电脑、两台手机、一台平板了，但外接屏幕只有一块，键鼠也只有一套，笔记本和 NUC 打架是自然而然的事情。

关于这种情况，开源社区已经有多种解决方案，主要分为键鼠漫游和远程桌面两种。

键鼠漫游当然是理想中体验最好的解决方案。NUC 接外部显示器，跑 Linux 程序；笔记本用内置屏幕，跑 Windows 程序。一套键鼠插在某一台设备上，用一个鼠标控制两台设备的桌面。成熟的方案有很多，但统统被我毙掉了，分别由于以下几个理由：

Mouse Without Borders，仅支持 Windows；
Synergy/Barrier，不支持 Wayland；
Waynergy（Synergy 的 Wayland fork），不支持 GNOME 自带 compositor；
rkvm，不支持 Windows。

幸好 GNOME 42 为我留了另一条路，远程桌面。我得以在 NUC 上开一个远程桌面服务端，然后在 Windows 下连接。说起来体验还可以，起码日常使用还是够了的。窗口可以全屏，让 Linux 的桌面铺满整个显示器，局域网内视觉体验非常接近直连；我也可以将远程桌面窗口最小化，从而 Windows 应用（如游戏）也可以使用大尺寸显示器。

更新：后续 GNOME 版本中，远程桌面连接必须在连接显示器的情况下才能工作，且远程分辨率与连接的显示器相同；而在 GNOME 46 中新增了“远程会话”，

我也试过使用 Remmina 连接 Windows 的远程桌面，但结果就是卡顿极其严重，清晰度也很差。当然也可以使用 RustDesk 或 Parsec 等其他远程桌面协议，倒也挺好用。

这里推荐一个 GNOME 插件：Allow Locked Remote Desktop，让锁屏时也可以连接远程桌面，就像 Windows 那样。

而一旦出现了不方便接显示器的情况，可以使用如下的命令启动一个 headless session（来自 Reddit）：

        bash
        
    echo -n "user_password" | /usr/bin/gnome-keyring-daemon --unlock
systemctl --user restart gnome-remote-desktop.service
gnome-shell --wayland --headless --virtual-monitor 1280x720 --no-x11

1
2
3


echo -n "user_password" | /usr/bin/gnome-keyring-daemon --unlock
systemctl --user restart gnome-remote-desktop.service
gnome-shell --wayland --headless --virtual-monitor 1280x720 --no-x11

不过问题在于此时 GNOME 远程桌面连不上。据传，可以使用以下的命令将远程桌面模式设为” 扩展 “，这样它会为你创建一个虚拟显示器（来自 Reddit 和 GNOME GitLab）：

        bash
        
    gsettings set org.gnome.desktop.remote-desktop.rdp screen-share-mode extend

1

gsettings set org.gnome.desktop.remote-desktop.rdp screen-share-mode extend

当不需要用桌面的时候，就用 SSH。尤其是出门后，网络条件难以支持远程桌面，SSH 就显得比较好用了。SSH 比较好配置，此处省略。

文件互传

KDE Connect 完全可以称为最好的跨平台互联工具，通吃所有常见桌面端与移动端环境。GNOME 桌面环境上，可以使用 GSConnect 插件。

文件共享

要将文件暴露到网络上，协议还是很多的。对于公网，一个 Web UI+WebDAV 会很方便；而在内网中，可以选择 SMB。这里与前面 KDE Connect 的区别，则在于前者是 “拉”，而后者是 “推”。

Caddy 带一个文件服务器 Web UI+WebDAV 的功能，但死活没配好，就让它等着做反代吧。作为替代的，我使用了 AList。AUR 有 alist 包，可以直接配好 systemd 服务和配置文件。但在新的 AUR package 中，alist 会作为单独的用户运行，对于共享家目录等需要大规模更改权限的场景则不是非常方便。

alist-org/alist

我是 Cloudreve 的老用户了，它是非常优秀的网盘程序，而它会重新组织上传的文件；相反，AList 能够忠实地将系统文件目录结构呈现出来，既方便远程访问，又方便本地访问。这就是它叫做 “目录程序” 的原因。它也自带一个 WebDAV 服务端，很方便。

通过 AList+Tailscale 下载大文件，约能跑到 160Mbps 左右；通过内网直连下载，则能够达到 720Mbps（路由器硬件所限，非 WiFi 6），不管怎样看 4K HDR 是没有什么压力的，也能喂饱我的百兆小水管外网。

这玩意速度还是有点玄学的，那相较于带加密的 WebDAV，不如直接上 SMB，负担小，对 Windows 的支持也更好。Linux 上 SMB 支持主要由 Samba 软件包提供。

SMB 的配置方法由 ChatGPT 生成。

安装就不用说了。先创建一个 SMB 账户，这里图省事，个人会直接用 Linux 账户。跟 passwd 差不多用法。

bash

1

sudo smbpasswd -a <account_name>

然后编辑配置文件，路径位于 /etc/samba/smb.conf。你可以选择去下载官方模板，但实际上只需要以下的部分：

        ini
        
    [global]
    workgroup = WORKGROUP
    security = user

[homes]
    comment = Home Directories
    browseable = no
    read only = no
    create mask = 0700
    directory mask = 0700
    valid users = %S

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


[global]
    workgroup = WORKGROUP
    security = user

[homes]
    comment = Home Directories
    browseable = no
    read only = no
    create mask = 0700
    directory mask = 0700
    valid users = %S

如果你使用了模板，没连打印机的话，记得把打印机注释掉。

然后把服务启动一下。

        bash
        
    sudo systemctl enable --now smb.service

1

sudo systemctl enable --now smb.service

然后在 Windows 添加 \\<machine-ip>\homes 就能访问了。

更新：Windows 11 24H2 需要启用 SMB 签名，并不支持 guest 账户¹。

那有了这些空间，干点什么呢？比如存个手机备份，这不比某些厂商的 USB 2.0 体验好多了嘛，不一定比无线快，还得时刻连根线。

XayahSuSuSu/Android-DataBackup

笔记

在 Notion-like 的软件中，思源笔记拥有较好的 Markdown 支持，用起来较为舒服，也有自行托管选项（浏览器端），唯一的缺点是 Firefox 支持较差（可惜由于精力原因，开发者不一定会修）。

siyuan-note/siyuan

使用 Podman rootless container + Quadlet，编写 container 文件如下：

        properties
        
    [Unit]
Description=Siyuan Notes container

[Container]
Image=docker.io/b3log/siyuan
ContainerName=siyuan
User=1000
Group=1000
PublishPort=6806:6806
Volume=siyuan:/siyuan/workspace
Exec="--workspace=/siyuan/workspace/" "--accessAuthCode=<your-auth-code>"
AutoUpdate=registry

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


[Unit]
Description=Siyuan Notes container

[Container]
Image=docker.io/b3log/siyuan
ContainerName=siyuan
User=1000
Group=1000
PublishPort=6806:6806
Volume=siyuan:/siyuan/workspace
Exec="--workspace=/siyuan/workspace/" "--accessAuthCode=<your-auth-code>"
AutoUpdate=registry

此处使用 volume 而非本机目录，是因为尝试过多次本机目录，在权限设置应该没什么问题的情况下，容器仍无权限创建文件，使用 volume 则没有这个问题。确实没之前那么方便，但毕竟都是挂载到本地的，也差不太多。

服务的快捷访问

本文早些时候使用了互联网上的常用方式——域名来指代服务，并使用 Caddy 自动进行 HTTPS 加密和多路复用。将域名指向对应主机，因为指向的 IP 都是 Tailnet 中的保留 IP，所以实际上也没什么问题。但是由于主机间连接使用的 Wireguard 本身就带有加密，所以 HTTPS 完全没有必要。如果读者愿意阅读之前的方法，可以点击下方的折叠菜单将其展开。

以前的方法：使用 Caddy+自签证书 HTTPS

到此为止，搭建的服务都是用 IP 地址 + 端口号访问，不太优雅。虽然 Tailscale 提供了 MagicDNS，但也只能为每个设备分配一个域名。既然上有一个自己的域名，就想到配合 Caddy 访问内部服务。

就以上面的 AList 举例，先在 DNS 中将 alist.internal.cyp0633.icu（仅作示例，你当然用这个访问不到）指向 NUC 的 Tailscale IP，然后 Caddyfile 可以这么填写：

        text
        
    alist.internal.cyp0633.icu {
    reverse_proxy :5244
    tls internal
}

1
2
3
4


alist.internal.cyp0633.icu {
    reverse_proxy :5244
    tls internal
}

然后 Caddy 就可以搞定反向代理，甚至包括自签名的 HTTPS 证书。第三行是必不可少的，因为. icu 是公认的 TLD，Caddy 会尝试向公网 CA 申请一个证书，它当然不能接入 Tailscale 局域网；显式指定 tls internal 之后，Caddy 才会自行签名一个证书（见官方论坛帖子）。这样，便可以访问这个域名来获取服务，无需记住端口号，就像是在平常的服务器上一样。类似的，也可以这样配置多个域名指向同一 IP，来让 Caddy 做分流。

思源笔记有 WebSocket 部分，但不需要特别设置。

针对上面 Tailscale 的速度问题，如果想在内网下达到更快的传输速度，可以在路由器上将域名解析至内网 IP，而非 Tailscale IP。这样在内网下就可以直连，无需通过 Tailscale。

Tailscale 开发了一个小工具叫做 golink，能够将 <go/linkname> 重定向至一个自定义的网址，类似于前些年流行的短网址服务。其配置起来并不麻烦，所以个人建议直接用 systemd 管理。先用 go install 安装，然后创建一个systemd user unit，需要的话可以参考我的配置文件。

        properties
        
    [Unit]
Description=Golink service

[Service]
Type=simple
ExecStart=/home/<username>/go/bin/golink --sqlitedb /home/<username>/.config/tsnet-golink/data.db
Environment="TS_AUTHKEY=tskey-auth-yourkey"
Restart=on-failure

[Install]
WantedBy=default.target

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


[Unit]
Description=Golink service

[Service]
Type=simple
ExecStart=/home/<username>/go/bin/golink --sqlitedb /home/<username>/.config/tsnet-golink/data.db
Environment="TS_AUTHKEY=tskey-auth-yourkey"
Restart=on-failure

[Install]
WantedBy=default.target

用浏览器访问 http://go/，新建映射即可以和老方法一样简单易懂的名字访问内部服务。比如我将 go/siyuan 映射到 http://nuc:6806，就可以直接访问思源笔记了。

* 在制定短链接映射时，个人不建议使用形如上文 nuc 的主机名代替 Tailscale IP 地址，因为部分工具不能正确将其识别为内网服务，从而禁用某些功能。比如 Bitwarden 浏览器插件，就会禁用 HTTP 下的自动填充功能，除非访问的是保留 IP。通过跳转到对应 IP 而非主机名，可以启用其自动填充功能。

远程下载

有了这个，就可以远程下片了（逃）。算是用了一种经典方案吧，aria2。pacman 就有打包。

配置文件 aria2.conf 可以参考 P3TERX 的配置文件，但 注意不要照搬，先读完，再使用。

P3TERX/aria2.conf

如果要让 aria2 在后台运行，可以使用 systemd 服务，在 / etc/systemd/system 中编辑 aria2cd.service（改编自 Arch Wiki），然后启用即可：

        properties
        
    [Unit]
Description=aria2 Daemon

[Service]
Type=simple
ExecStart=/usr/bin/aria2c --conf-path = 你的配置文件路径

[Install]
WantedBy=default.target

1
2
3
4
5
6
7
8
9


[Unit]
Description=aria2 Daemon

[Service]
Type=simple
ExecStart=/usr/bin/aria2c --conf-path = 你的配置文件路径

[Install]
WantedBy=default.target

至于 Web 界面，我使用了 AriaNG，也是经典的解决方案。使用 Caddy 反代一下就行了。在 Caddyfile 里限制了 HTTP，否则必须一起反代 HTTPS 的 Aria2 JSON-RPC。

mayswind/AriaNG

开发

只要提到远程开发，必定少不了神通广大的 VS Code。之前写过文章的第三方的 code-server 仍然可用，而且是一个完全开源的版本（基于 code-oss），感兴趣的可以看一下 GitHub 页面，讲得很详细（我写的太久没更新，不推荐阅读）。

coder/code-server

此处要讲的是另外一种途径，来自微软的 VS Code Server，这意味着它可以使用 Copilot 等必须在微软发行的版本才能使用的插件。这项功能已经进入公测，并包含在所有 1.74.0 或更新的 VS Code 版本中。可以使用 vscode.dev 网页或现成的 VS Code 客户端连接，即使不在同一局域网下也可。具体的启用方法可以见这篇 blog post，但长话短说，就是使用 code tunnel 命令。另附内测时期的开启方法如下：

内测时的 VS Code Server 启用方法

VS Code Server 在内测，通过后就可以在 vscode.dev 里直接连接开发机器了，但我并没有通过内测。很幸运的是微软提供了一种不需资格的运行方式，只需加上 --serve-local 参数，就可以在本地机器浏览器中运行，再加一个反代，就可以让 Tailscale 内网中的远程机器连接了。
需要注意：VS Code Server 不是开源 / 自由软件，有自己的协议。将 VS Code Server 暴露到公网上是违反许可协议的。
同样的，也建议创建一个 sysetmd 服务来保持其后台运行。

两个方法都占用很大，占用内存可能达到 2G 左右，CPU 负载也很高，因为所有 language server 的 parsing 等操作都是在这台 NUC 上进行的。但不管是上述两种方法中的哪一种，都可以在平板上码代码了，并且得到很舒服的延迟与比我自己公网上服务器高得多的性能。

照片

请见：

https://cyp0633.icu/archives/2093

数据保护

如果你使用的也是 Btrfs 文件系统，且对数据安全没有那么高的要求，那么可以参考这篇文章。

https://cyp0633.icu/archives/2120

此篇文章首个版本约有四分之三通过 NUC 的远程桌面写成。它作为没那么多预算的我买的入门 Homelab，经过这一段时间的使用，已经证明了能够胜任目前的需求，性价比目前看还算不错。

https://techcommunity.microsoft.com/t5/storage-at-microsoft/accessing-a-third-party-nas-with-smb-in-windows-11-24h2-may-fail/ba-p/4154300 ↩︎