Homelab

Cloudflare 起家是 CDN 和 DNS，现在的产品线已经覆盖网络、安全、开发者平台和存储。这篇先按用途列一遍常用服务，再单独讲 R2 对象存储和 Tunnel。各服务的额度和价格会调整，以官方文档为准（本文核对于 2026-10）。 服务一览 网络与安全 服务 说明 DNS 权威 DNS，免费。域名的 NS 指到 Cloudflare 以后，其他服务才能接上 CDN / 代理 DNS 记录打开代理（橙色云朵）后，流量先经过 Cloudflare 边缘节点，静态内容在边缘缓存 SSL/TLS 边缘证书自动签发；回源可用 Origin CA 证书（只被 Cloudflare 信任，有效期最长 15 年），模式应选 Full (strict) WAF / DDoS 防护 代理开着时自动生效，免费版有基础规则 Turnstile 人机验证，替代 reCAPTCHA，免费 Registrar 域名注册，按成本价续费，不加价 开发者平台 服务 说明 Pages 静态站点和前端项目托管，连 Git 仓库自动构建，见 Hugo + Cloudflare Pages 搭建个人博客 Workers 边缘 Serverless 运行环境，见 Cloudflare Workers KV 全球分布的键值存储，读多写少，最终一致 D1 基于 SQLite 的关系型数据库 R2 对象存储，兼容 S3 API，没有出口流量费，见下文 Durable Objects 带强一致状态的单实例对象，适合协同编辑、计数、WebSocket Queues 消息队列 Workers AI 在边缘调用推理模型 KV、D1、R2、Durable Objects、Queues 都可以通过 binding 注入 Worker 使用。 ...

这篇文档讲什么 Homelab 里两个前端 enx-ui（Next.js）和 rssx-ui（Vue + Vite）的镜像，现在都用 Cloud Native Buildpacks（CNB）构建，不再用 Dockerfile + Kaniko。本文按实际配置说明这套构建是怎么搭起来的：编译用哪个镜像、运行用哪个镜像、自己写的 buildpack 做了什么、Tekton 里怎么跑。 CNB 本身的概念（buildpack、builder、lifecycle、platform）见 CNB: Cloud Native Buildpacks 与 Paketo；为什么会有 CNB、它和 Dockerfile 的取舍见 Dockerfile/BuildKit vs CNB。这里只写 homelab 的落地。 为什么换掉 Kaniko Kaniko 上游（GoogleContainerTools/kaniko）2025-06 已归档，executor:v1.23.0 之后没有安全更新。 enx-ui 用 Kaniko 构建一次约 5 分 20 秒，其中解压缓存的 node_modules 层 78 秒，每次新建并挂载 Longhorn RWX 卷约 40 秒。 备选里 BuildKit 需要常驻 buildkitd，rootless 模式也要放宽 seccomp/AppArmor；CNB 的 lifecycle 以普通用户运行，不需要特权，还支持 rebase。所以选了 CNB。2026-10 rssx 也迁过来之后，集群里已经没有 Kaniko 了。 三个组件：builder、buildpack、run image CNB 构建出来的镜像，是把「构建产物」叠到「运行镜像」上。homelab 里这三样东西分别是： ...

我在整理 homelab 的配置仓库时发现，有不少密钥以明文形式进了 git：数据库密码、云服务的 API token、K8s Secret 的 manifest。还有一些放在 ~/.zshrc.local 里，作为环境变量。这篇文章记录我比较几种方案之后选定的思路，以及其中涉及的概念。 最后选的组合是：Bitwarden + rbw 管人在场的场景，OpenBao 管集群里的自动化，没有用 SOPS。 先分清「存放」和「使用」 讨论密钥放在哪里时，容易把两件事混在一起： 存放（数据源，长期） 使用（临时） git 里的密文 / Bitwarden / OpenBao → 环境变量、内存、临时文件 使用的那一刻必然是明文，任何方案都绕不开，程序总得拿到真实值。能做的是让它短暂、范围小：只在一个子进程里，不长期落盘。 真正可以选择的是存放在哪里，而且不一定要是 git。 对照这个划分，原来的两个问题分别是： 做法 问题 明文进 git（即使是私有仓库） 协作者授权、第三方 App 授权、CI 克隆、哪天转 public，都会把全部历史一起交出去 放在 ~/.zshrc.local 磁盘上是明文；shell 启动的所有子进程一直都能读到，包括各种 CLI、npm postinstall 脚本、AI agent 分类原则：谁在用，有没有人在场 场景 存在哪里 怎么取 是否需要人在场 本地开发和运维（tofu、Ansible、脚本） Bitwarden rbw get，只注入单条命令 需要 集群自举密钥（集群启动时就必须存在的少数几个） Bitwarden 重建集群时，由人执行脚本创建 需要，只在重建时 集群里应用运行时用的密钥 OpenBao 程序用自己的身份去取；数据库用动态凭据 不需要 核心思路：人在场就从 Bitwarden 取；没有人在场，就交给一个在线服务（OpenBao），程序用自己的身份去取。 ...

背景 homelab 里的 r86s（R86S 小主机，Celeron N5100，跑 Proxmox VE）偶尔整机卡死。卡死后机器既不会自己恢复，也不会留下日志，前几次分别过了约 10.5 小时和 4 小时才被人发现并重启。排查过程见 R86S IRQ 16 nobody cared。 在修不了根因（BIOS 没有更新、microcode 已是最新）的情况下，第一件要做的事是让机器卡死后能自动恢复，这就是硬件看门狗的用途。这篇记录硬件看门狗是什么、Linux 和 Proxmox 怎么用它，以及它在 r86s 这次排查里起的作用。 看门狗是什么 看门狗（watchdog timer，WDT）是一个独立于 CPU 运行的倒计时器： 软件启动看门狗，设一个超时时间，比如 10 秒； 软件定期"喂狗"（kick / pet），每次喂狗把倒计时重置回 10 秒； 如果软件卡死、没人喂狗，倒计时走到 0，看门狗就直接拉复位信号，把整台机器重启。 关键在于独立：倒计时由芯片组里的电路自己走，不依赖 CPU 执行任何指令。CPU 死锁、内核卡死、关了中断，它都照样倒数，照样复位。这一点是软件手段做不到的。 这个思路最早来自嵌入式和工控领域：无人值守的设备死机了没人去按电源键，必须自己恢复。单片机几乎都内置看门狗。 硬件看门狗在哪里 它通常不是一块单独的板卡或模块，而是集成在芯片里的一小块电路。x86 机器上常见的几种： 位置 例子 Linux 驱动 Intel 芯片组（ICH/PCH）里的 TCO 定时器 从 1999 年的 ICH 一直到现在的 PCH，包括 Jasper Lake iTCO_wdt AMD 芯片组（FCH）里的 TCO 定时器 大部分 AMD 平台 sp5100_tco 主板上的 Super I/O 芯片 ITE IT87xx、Nuvoton NCT67xx、Fintek F718xx it87_wdt、w83627hf_wdt、f71808e_wdt 服务器的 BMC IPMI 看门狗 ipmi_watchdog ARM SoC 树莓派的 BCM2835 bcm2835_wdt 所以"几乎所有 x86 主板都有"是成立的，至少芯片组里会有一个 TCO 定时器。但"有"不等于"能用"： ...

背景 homelab 里的 r86s（R86S 小主机，Celeron N5100，Jasper Lake 平台）跑 Proxmox VE，上面是 K8s 的两台 VM：k8s-50 和 k8s-51，拓扑见 Homelab topology。这台机器偶尔会整机卡死，所以每天 04:00 有一个定时任务自动 apt full-upgrade 加重启。 排查卡死问题时，在内核日志里看到了这样一段： kernel: irq 16: nobody cared (try booting with the "irqpoll" option) kernel: CPU: 0 UID: 0 PID: 47 Comm: kworker/u16:1 Tainted: P O 7.0.14-20-pve #1 kernel: Hardware name: BROUNION R86S/R86S, BIOS 5.19 04/12/2022 kernel: Workqueue: pm pm_runtime_work ... kernel: handlers: kernel: [<...>] idma64_irq [idma64] kernel: [<...>] i2c_dw_isr kernel: [<...>] i801_isr [i2c_i801] kernel: [<...>] sdhci_irq [sdhci] threaded [<...>] sdhci_thread_irq [sdhci] kernel: [<...>] azx_interrupt [snd_hda_codec] kernel: Disabling IRQ #16 这篇记录这条告警是什么意思、根因是什么、影响什么，以及能用哪些 OS 或 BIOS 配置消除它。 ...

背景 homelab 里硬件、PVE 宿主机、K8s 节点、网络分散记录在多篇文章里：Hardware 记了全部硬件清单，PVE、Proxmox VE 存储、pve + openwrt 记了 PVE 与软路由操作，k8s 记了 K8s 概念。但没有一篇把"哪台物理机 → 哪个 PVE 宿主机 → 跑了哪些 K8s 节点 → 怎么连网"串起来。 本文只画这条链路。集群里部署了哪些服务（RSSX、Diun、Grafana 等）见 Homelab Services。PVE 宿主机上除 K8s 节点外的其它虚拟机（win11-ltsc、VPN 客户端、netbird-router 等）不展开。数据来源于 w10n-config 仓库的 infra/homelab/opentofu/pve/main.tf（OpenTofu，宿主机与 VM 的权威定义）和 infra/homelab/inventory/homelab-vms.ini（IP 与节点角色）。 一张图：物理机 → PVE → K8s 节点 → 网络 flowchart TB onu["光猫 ONU"] -->|PPPoE WAN| openwrt subgraph n100_host["物理机 n100 · 192.168.50.6"] openwrt["VM openwrt-24-10软路由 · LAN 192.168.50.1"] k8s67["VM k8s-67control-plane"] k8s71["VM k8s-71worker"] end openwrt -->|vmbr0 LAN 口| lan["交换机 / LAN 192.168.50.0/24"] lan --- j4125_host lan --- pve03_host lan --- r86s_host lan --- n100_host lan --- vip["kube-vip VIP192.168.50.100"] lan --- ap["无线 APRuckus R310"] ap -.->|Wi-Fi 2.4G / 5G| wifi_clients["无线终端手机 / 笔记本 / Switch"] subgraph j4125_host["物理机 j4125 · 192.168.50.2"] k8s21["VM k8s-21worker"] end subgraph pve03_host["物理机 pve03 · 192.168.50.3"] k8s38["VM k8s-38control-plane"] k8s39["VM k8s-39worker"] end subgraph r86s_host["物理机 r86s · 192.168.50.5"] k8s50["VM k8s-50worker"] k8s51["VM k8s-51control-plane"] end 要点： ...

临近国庆节，节奏有点乱。有四周没写周记了，W38 到 W41 合成一篇。这四周的主线还是 enx：给它取了个名字叫 Catglish，部署生产环境。最近在准备提交 Chrome Web Store，提交之前得再调整一轮 UI。 Catglish W37 里纠结的名字，最后用了 Catglish。网站和 Chrome 扩展上的名字都改成了 Catglish，仓库名还是 enx，等上线之前再找时间改。 W38 主要在调细节。跟 AI 一起重新做了一遍配色，统一了各个组件的颜色 token。在颜色这件事上，AI 比我专业多了。周五 Claude Code 赠送的 100 美元额度第二天就要过期，那两天开着 Opus 改了很多东西，也第一次往生产环境部署了一个版本。 W39 在补生产环境的链路。部署流水线从 GHCR 加 SSH 换成了 ECR 加 SSM，机器调整成 t3a.small。扩展的内容脚本改成按需注入，不再在每个页面上都注入。周五集中做了一次依赖版本升级：Next 16、Vite 8、TypeScript 6。E2E 测试改成用真实的登录流程跑。 W40 是国庆： 网站上加了 Beta 标记和 GitHub 链接 加了定价页；现在的配额都是内测阶段的数字，跑一段时间再定上线时各个等级的额度 除了按月订阅，也可以一次性付款购买 AI 积分 本地词典查不到的词，可以调用 AI 生成释义 收藏页面，以及按站点设置「在这个网站上自动开启」 另外加了 Prometheus 监控指标，homelab 和生产环境的监控面板都接上了。 W41 打好了 0.1.0 Beta 的扩展包，画了个 logo：一个带猫耳朵的 C。 ...

这周主要在给 enx 取名字。另外 enx 接了 DeepSeek，HomeLab 的 CI/CD 加了缓存，在 YouTube 上新建了一个产品频道。 enx：取名字 enx 一直是开发代号，要做成产品发布，得有一个正式的名字。取名字是最不重要、也最纠结的一件事。 这一周一直在纠结叫什么。想了好多名字，一个个去查域名和商标，大部分都和现有的软件或者商标冲突：有的域名已经被人注册了，有的已经注册了商标，用了会有法律风险。 最后在仅有的几个不冲突的名字里来回纠结，周六选了一个，注册了域名。 enx：开发 新功能不多：Reader 页面，可以把一段英文粘贴进来阅读、查词；从浏览器扩展里发起登录，登录完会自动回到原来的页面。 另外还做了一些细节上的小调整和优化。 UI 和 API 的提示文案全部改成了英文。用这个工具的人本来就在学英文，UI 上简单的英文应该不是问题； MiniMax 的订阅过期了，DeepSeek 的账户里还有余额，所以给 enx 加了一个 DeepSeek 的 provider，HomeLab 上切到了 DeepSeek。HomeLab 是测试用的，对后端用哪个模型不是特别敏感。 HomeLab：CI/CD 提速 最近一直在测 enx，频繁调细节，也频繁往 HomeLab 上部署，CI/CD 跑的时间就成了一个比较明显的问题。 这周优化了一下：加了缓存，加了 Nexus 私有仓库。npm 和 Go 的依赖走 Nexus 代理，镜像构建的缓存也放在 Nexus 里，依赖没变的时候可以跳过安装依赖那一步。 YouTube：两个频道 打算拍一些东西放到 YouTube 上，比如 enx 的安装/使用演示, 宣传视频, 这周在准备拍摄方案，周六在自己的 YouTube 账号下新建了一个产品频道。 注册 YouTube 账号之后本来就会有一个默认的频道，每个注册用户都有，只是大多数人没有往里面发过视频。我的默认频道就当个人频道用。同一个账号下面还可以再新建别的频道，这一点我也是这周才知道的，算是一个新发现。 这样一个账号下面就有了两个频道。个人频道放我自己的内容，比如 HomeLab 的改造、有可能的未来的房车旅行，也许会有美食类的视频，主要是个人记录。产品频道只发产品相关的内容。个人频道是全集，跟 enx 相关的视频会同时发到两个频道。 ...

这篇写什么 本文只回答「集群里现在跑了哪些服务」。对外 HTTPS 走 Kong Ingress，持续部署走 Argo CD。物理机、PVE 宿主机、K8s 节点和网段见 Homelab 拓扑。两篇分工： 问题 看哪篇 哪台物理机 → 哪个 PVE → 哪些 K8s 节点 Homelab 拓扑 集群里部署了哪些服务、怎么访问 本文 清单以 w10n-config 的 infra/homelab/k8s/ 为准。域名由 OpenWrt 解析到 Kong Ingress VIP 192.168.50.101。 平台层 集群自己用的组件，一般不直接当「业务应用」打开。 服务 Namespace 访问 说明 kube-vip kube-system API 192.168.50.100；Ingress 192.168.50.101 control-plane 与 Kong LoadBalancer 各一个 VIP Kong kong （所有 *.wiloon.com / *.wiloon.lab HTTPS） Ingress Controller，TLS 在这一层终止 Longhorn longhorn-system https://longhorn.wiloon.com 集群存储 cert-manager cert-manager （无独立 UI） 通配符证书；Ingress 用已签发的 Secret，不用 cert-manager 注解 Reflector kube-system （无独立 UI） 跨 namespace 同步 TLS / Telegram 等 Secret，见 Reflector Argo CD argocd https://argocd.wiloon.com GitOps，manifest 在 git 里改完即 sync Descheduler kube-system （无独立 UI） Pod 重平衡，见 Descheduler Metrics Server kube-system kubectl top 给 HPA 和排障用 应用 服务 Namespace 访问 说明 RSSX rssx https://rssx-lab.wiloon.com RSS 阅读器 RSSHub rsshub https://rsshub.wiloon.lab 把没有原生 RSS 的站点转成 feed，给 RSSX 订阅 ENX enx UI https://enx.wiloon.lab ；API https://enx-api.wiloon.lab 英语学习扩展的后端和 UI；CI/CD 见 enx-api Homelab CI/CD Calibre default https://calibre.wiloon.com 电子书 QuantDinger quantdinger https://quantdinger.wiloon.com 量化相关 backend + frontend PM Toolkit pm-toolkit https://pm-toolkit.wiloon.lab FastAPI + Next.js 内网工具 Pomodoro default https://pomodoro-lab.wiloon.com 番茄钟 Nexus nexus UI https://nexus.wiloon.com ；Docker Hub 代理 https://docker-registry.wiloon.com 镜像缓存；另有 GHCR / GCR / hosted 等子域 ddns-go ddns-go https://ddns-go.wiloon.com 家用出口 IP 变了之后更新 Cloudflare DNS nettest default NodePort 192.168.50.100:30880 whoami，用来测连通性 Pathfinder 已从集群下线，不在上表。 ...

背景 homelab 里不少服务钉在某个镜像 tag 上，上游发了新版本不会自动跟着走。以前靠偶尔看 GitHub Release，或者写脚本去打 releases/latest。后者对把每个版本都标成 pre-release 的项目几乎没用——接口长期停在旧版，等于没监控。 现在改成在 K8s 集群里跑 Diun（Docker Image Update Notifier）：盯 registry 里的镜像 tag，出现匹配规则的新稳定版就推 Telegram。它不负责滚动升级，只负责通知。它在服务清单里的位置见 Homelab Services；硬件与集群拓扑见 Homelab 拓扑。 它盯的是 registry，不是正在跑的容器 Diun 用 file provider 读一份 watch 列表，直接问 registry「这个仓库现在有哪些 tag」，不扫描集群里的 Pod。所以： 可以盯 homelab 里跑着的容器（例如 Vaultwarden） 也可以盯并不在集群里跑的软件：只要上游会在打 release 时构建官方镜像，tag 与版本号一一对应，就可以把镜像当发版探针 后者用来补 GitHub releases/latest 的坑。有些项目几乎每个 release 都标 pre-release，那个接口会一直停在旧稳定版；镜像 tag 没有这层过滤。 homelab 部署 跑在独立 namespace diun，由 Argo CD 管（w10n-config 里的 infra/homelab/k8s/diun/）。要点： 项 现网 镜像 Nexus 代理后的 crazymax/diun 检查频率 每 6 小时；启动时再跑一次 通知 Telegram Bot；凭据在 notifications namespace，由 Reflector 反射进 diun 状态 Longhorn PVC 记已经见过的 tag，重启不会把历史版本再推一遍 UI 没有。纯后台 + 推送 首次检查关掉通知（DIUN_WATCH_FIRSTCHECKNOTIF=false），只建基线。之后才对真正的新 tag 发消息。 ...

这周主要是 enx 的开发：接入 Stripe，以及上线前的一些细节调整。 enx：接入 Stripe 订阅加积分这套方案是上周那份规划里定下来的，这周把它落进代码。 周三一天，enx 里多出了一整套计费：积分账本、Stripe 的 webhook、配额、结账和账单管理入口，网页端加了定价页和账单页，扩展这边加了积分不足和需要升级的提示。方案之前讨论过，这次是把方案细化，然后由 AI 生成代码。 同一批改动里还补了一组单元测试，账本、webhook、配额、结账处理各有一份。补测试的原因是接入 Stripe 之后要开始新一轮测试，而现有代码的单元测试覆盖太小，先把底子补上。 接下来是测试。 订阅之外加了一次性充值包 周四改了一次访问规则。 前一天定的是：AI 翻译必须有订阅才能用，不能靠单独充值绕过。第二天推翻了，改成账户里有积分就能用，不限来源，订阅发放的积分和一次性购买的积分包都算。 改的原因是有了一个新想法，可以开放一次性购买的充值包。按月订阅并不是所有人都愿意，月费也不好定太高，一次性的充值包是个补充。 代价是前一天已经写进代码的那条校验现在是错的，得删掉。项目还在开发中，随时都会有变化，这些变化都是正常的。 内网域名换成 wiloon.lab wiloon.com 是公网域名，homelab 内部之前也用它，只是在内网解析。但 DNS 分流上遇到了问题，所以内网改用 wiloon.lab，专门给 homelab 用。 这周把 enx 的内网访问切了过去。 公司账本：把方法固化成一个仓库 上周写过决定自己记账，用 beancount，AI 出数、人工复核。这周把它做成了一个仓库。 促成这件事的还有几点。找代账公司有沟通成本；在 twitter 上看到有人用 AI 处理公司的账目，我也想试试；另外公司现在没有业务，都是零申报，应该不复杂。有代账公司打电话过来，我跟他们说的也是自己先试试，实在不行再找专业人士。 仓库里放的是科目表模板、余额断言、季度增值税和年终结账两份 SOP，以及法定报表的字段映射。另外把几个常用动作做成了 Claude Code 的 skill：开票申请、季度报税、出报表、报税准备。 上周是决定自己记账，这周是把记账做成一套可以重复执行的流程。 homelab 杂项 kubectl 的 logs 和 exec 一度用不了，加了一个 ClusterRoleBinding 修回来，交给 ArgoCD 管理。 路由器那边把 IPv6 的 WAN 口改成了静态接口，之前记录过的前缀委派丢失问题走到了这一步。 监控补了一批采集配置。 blog 这周写了三篇：mktemp、DuckDB，以及微信扫码查看与下载 PDF。另外给 SQLite 那篇做了修订。 ...

面试结果 上周那场第二轮面试，周二有了结果：职位不匹配。 从 4 月离职到现在同事/朋友帮推过三家公司。一家给了 offer，薪资太低，拒了；一家没有下文；这一家前后聊了四个月，两个岗位都进了二面，都没有 offer. 这一家前后接触了一位 HR 和八位面试官。感觉得出来，有的是希望我加入的，也有的对我有疑虑。anyway，最终的结论是职位不匹配。 接下来先测试 enx 独立商业化的可行性：把功能做完、部署到 AWS、接上 Stripe 订阅，先在 YouTube 和 X 上推(因为只做了 google 账号登录)，看能不能有几个付费订阅用户；跑不通的话就再找工作。 enx: 划词翻译 之前选中一个短语会走词典查询，而后端判定"包含空格就是句子"，直接返回一句"句子翻译功能暂未开放"，短语永远拿不到释义。现在改成：选中的如果是句子中间的几个词，侧边栏显示这个短语在整句里的含义。像 “hunt down emails”，三个词单看都认识，放进上下文里是什么意思才是要查的。 另外给三个翻译 provider 各补了单测。 enx：上线还差什么 周三花了一天，把 enx 距离上线还差哪些事情列了一遍，写成两份文档，一份是商业化设计，一份是任务清单。 先定义什么叫"上线"：在生产环境上，真实用户可以注册、登录、订阅、使用 AI 翻译、被限流、退订，这条链路全部跑通，才谈得上开始推广。 顺序定成三步。先在现在这套 homelab 环境里把订阅功能做完、测通，不用等基础设施迁移——然后把跑通的功能迁到 AWS。最后在生产环境完整跑一遍端到端冒烟测试，作为发布门禁。 几条已经定下来的： 计算平台继续用 EC2，不上 ECS 或 EKS。EKS 控制面每月的固定成本，在验证付费意愿这个阶段不划算 上线时数据库继续用 SQLite，先不迁 PostgreSQL。现有链路已经跑过，上线门槛越低越好，数据库迁移不是订阅功能的前置依赖 域名不换。Cognito 的 callback、CORS、证书、扩展权限都已经围绕现在这个域名配好了 全部开源，包括计费规则，继续用 AGPL-3.0 最后一条想得比较久。最初担心闭源可以防止别人用 AI 抄产品，后来推翻了：闭源只能防直接复制代码，防不了照着功能用 AI 重写一遍，而后者才是真正的风险，源码可不可见对它基本无效。定价和免费额度这些数字，用户用一遍产品就能观察到，藏代码也藏不住。真正让我决定开源的是另一件事——找工作这条退路还在，一个有真实用户、有测试和 ADR 的开源项目本身就是求职作品集，这个价值闭源换不来，而闭源换来的那点"防护"本来就是假的。 局域网域名的一秒延迟 周五在准备 enx 的测试环境，发现局域网里的域名访问都带着一段很规律的延迟。查下来是 IPv6 的 DNS 问题。 ...

Hardware QNAP TS453B mini Dell Wyse 5070 R86S Dell Inspiron N4050 Intel J4105 软路由 Celeron J3455 Mini PC（备用软路由） SONY WF-1000XM3 CanoKey K375S ROCK 5B Mitsubishi Outlander MacBook Air Nuphy Air75 DELL U2723QX Apple Watch Series 8 WH-1000XM5 AM40 高尔夫(进口) 2019款 1.8TSI 旅行版 nexus 7 2013 畅网微控 n100 Ruckus R310, 优科 beelink SER8 Dell U2412Mb keychron Q5HE Nintendo Switch2 Celeron J3455 Mini PC 备用软路由小主机。硬件详情见 Celeron J3455 Mini PC。 beelink SER8 AMD 8845HS AMD Radeon 780M ROCK 5B https://wiki.radxa.com/Rock5 ...

用途 Homelab 备用软路由小主机。2026-07-23 用 Arch Linux 安装 ISO（live）从 U 盘引导后盘点硬件。 规格摘要 项目 详情 CPU Intel Celeron J3455 @ 1.50GHz（Apollo Lake，4 核 / 无超线程，睿频最高 2.3GHz） 虚拟化 VT-x（vmx） AES-NI 有 内存 4 GB DDR3-1600（系统可见约 3.7 GiB） 存储 BIWIN mSATA SSD 32 GB（SATA 3.2，序列号 2111025802427） 网卡 双口 Intel I226-IT 2.5G（驱动 igc） 显卡 Intel HD Graphics 500 BIOS AMI Aptio CRB 5.12（2023-07-12） DMI OEM 默认字符串（Default string / board Aptio CRB） 网卡 接口 PCI MAC 备注 enp1s0 01:00.0 I226-IT 00:60:e0:9b:bc:e5 探测时已连接，协商 2500Mb/s Full enp2s0 02:00.0 I226-IT 00:60:e0:9b:bc:e6 探测时无链路 存储现状（装系统前） 内置 /dev/sda 非空盘，已有分区： ...

魔法线路的一次重建 我有三条魔法线路，这周状态都不太好：炸掉了一条，另外一条流量超了配额，还有一条延迟很大。索性新建了一条顶上。 配置新线路的过程中，顺带发现之前配的延迟检测不准，干脆一起修了。这一修就牵出一串：kube-prometheus-stack 里 additionalScrapeConfigs 字段名写错了；把 R 线路上的 X 从 split-updown 架构切回了普通方案，本想验证问题是不是出在这个架构上，结果发现并不是；J 线路也重新调了一遍，接进了 Grafana 监控。 本来只是想补一条线路，结果顺手把观测这块积了一阵子的旧账清了一遍。 重新拾起 QuantDinger 重新研究 QuantDinger，顺带整理自己的 enx 项目。 隔了一段时间没跟，上游已经升了很多个版本，还有一次大版本更新——MT5 整个模块被删掉了，看代码仓库，主线现在主要在更新数字货币和股票相关的模块。我跟着更新了指标（indicator）相关的一批代码。 也跑了一单测试，赚了 0.02866，差不多两毛钱——这也算是有正向现金流了 -_-。 面试复盘 上一次面试还没有后续 比起纠结结果，我更想把遇到的问题梳理清楚。已经整理了一部分，下周找时间继续，从 blog 里挖了一些相关的文档再整理一遍，下周接着弄。 女儿的一支舞，和被传染的一家 上周提到女儿在排练一支舞，这周演出了。 她上的是小班，周五这场是幼儿园大班的毕业典礼，小班出了几个小朋友排练了一支舞蹈，去典礼上表演。表演当天她的状态不错——一周前感冒过，到那天体温已经正常一两天，算是在恢复中，只剩一点点咳嗽，不影响跳舞，整支舞完整跳完了。 感冒倒是在家里转了一圈。她把病毒传给了妈妈，周六晚上老婆开始发烧。那天我全天带娃在外面上课、玩，回到家就成了半个病房。我目前还好，没有中招的迹象——但也不敢太乐观。 周日的三件不相干的小事 周日修了三件事，彼此没什么关联，凑巧都在这天： 蓝牙：偶然发现开机后蓝牙不能自动启用，是 Linux 启动过程中的时序问题，调了一下。 时区：为了能在这台机器上用 Claude Code，把时区问题处理了。 tekton-pipelines：把 PodSecurity 放宽到 baseline，是为了能在 homelab 上部署 enx 的 Java API。 两个小工具上的调整 Running page 换了数据源：Strava 的 API 改成了订阅模式，就把数据源换成了 Keep。 装了 Squirrel（鼠须管）：macOS 自带的五笔输入法没有造词功能，换成了 Squirrel。

背景 MacBook 在咖啡店等公共 WiFi 下，需要访问家里 homelab 内网（192.168.50.0/24）。平时外出用 WireGuard 连回家，但这类环境里 UDP 经常被限速或干脆不通——不连 WG 时网页很快，一连上就严重丢包，很像运营商或场所 WiFi 在限制 UDP。 这次的目标是：在 UDP 不通时仍能稳定访问 homelab 内网，同时 MacBook 的出口代理保持现状，不和 homelab 的魔法工具链路搅在一起。 为什么选 Netbird 试过换运营商热点、换连接方式之后，结论是需要一条能在 UDP 被封时自动回退的路径。Netbird 自建控制面的关键能力是： P2P 优先，延迟低 P2P 不通时走 TURN relay，可走 TCP 443，公共 WiFi 很难彻底封死 Subnet Router：homelab 里只需一台节点宣告 192.168.50.0/24，不必给每台内网主机装 client 和纯 WireGuard 相比，多了一层控制面和 relay 回退，换来的是在「刁钻 WiFi」下的可用性。 架构概览 MacBook（Netbird client，split tunnel） ├── 192.168.50.0/24 → Netbird │ ├── P2P（UDP 通时） │ └── TURN relay TCP/443（UDP 不通时） │ └── 控制面: nb.wiloon.com └── 其余流量 → 本地出口代理（保持现状） homelab ├── netbird-router（专用 VM，Subnet Router，通告 192.168.50.0/24） └── OpenWrt 静态路由：100.64.0.0/10 → netbird-router 几个设计选择： ...

openwrt basic, opkg basic, ipk commands # 查看 openwrt 版本 cat /etc/openwrt_release # 更新所有软件，包括 OpenWRT 内核、固件等 opkg list-upgradable | cut -f 1 -d ' ' | xargs opkg upgrade wan dns 在 wan 口设置里的“高级设置”选项里去掉"使用端局通告的DNS服务器"的勾选就可以使用自定义的DNS服务器 ssh port vim /etc/init.d/dropbear validate_section_dropbear > port ssh public key vim /etc/dropbear/authorized_keys dns 配置 查看本机的 DNS 配置: $ cat /etc/resolv.conf search lan nameserver 127.0.0.1 发现使用的是本机 DNS 服务器,即 dnsmasq。 查看 dnsmasq 配置: $ cat /etc/dnsmasq.conf 手动指定上游 dns vi /etc/dnsmasq.conf server=223.5.5.5 server=223.6.6.6 openwrt 改IP vi /etc/config/network opwnert init opkg install coreutils-nohup opkg install ipset opkg remove dnsmasq opkg install dnsmasq-full openwrt cron /etc/init.d/cron start /etc/init.d/cron enable crontab -e crontab -l x86, firmware download https://downloads.openwrt.org/releases/19.07.6/targets/x86/ ...

背景 在 homelab 里用 Proxmox VE（PVE）跑 Kubernetes 节点时，经常会同时遇到两类「空间不够」： PVE 宿主机上 local-lvm 余量、pvesm status 里的 Available； 虚拟机里 df -h / 根分区余量。 二者相关，但不是一回事。本文用一台实际节点 pve03（192.168.50.3）在 2026-06 的布局说明 VG、瘦池（LVM thin）、存储 ID local-lvm，并顺带说明 OpenTofu 里磁盘容量与现网不一致时该怎么对齐。 更偏操作步骤的扩容命令见 硬盘扩容, PVE, Archlinux；PVE 安装与日常命令见 PVE。IaC 侧约定在仓库 w10n-config 的 homelab/opentofu/pve/（不在本站展开）。 pve03 上的分层（2026-06 快照） 物理上只有一块主盘 sda（约 111.8 GiB）。安装 PVE 后，典型结构如下。 sda (~112G) └─ sda3 LVM VG "pve" ├─ pve-swap ~7G ├─ pve-root ~28G ext4，PVE 宿主机 / └─ pve-data ~61G LVM thin pool（供 local-lvm） ├─ vm-102-disk-0 k8s-38 虚拟盘 20G ├─ vm-104-disk-0 k8s-39 虚拟盘 25G └─ base-103-disk-0 模板盘 8G（已关机） 同一次查询里： ...

背景 accept_ra 是 Linux 内核里控制「是否接受路由器通告（Router Advertisement, RA）」的 sysctl。常见路径： /proc/sys/net/ipv6/conf/<interface>/accept_ra 取值含义（简化）： 值 行为 0 忽略 RA，不自动配置地址/默认路由 1 接受 RA（主机模式） 2 接受 RA，即使接口已开启 forwarding（网关/路由器模式） 默认情况下，一旦接口 net.ipv6.conf.<iface>.forwarding=1，内核会把 accept_ra 视为 0，不再接受 RA。这是 RFC 4861 的意图：路由器不应把 RA 当主机来用。 解决什么问题 典型场景：一台 Linux 机器同时做网关转发，又需要从上游路由器拿 IPv6 前缀和默认路由。 例如 homelab 里的 VPN 客户端 192.168.50.61： 上游 OpenWrt 通过 RA 向 LAN 下发 ISP 委派的 /60 GUA 前缀和 ::/0 默认路由。 50.61 运行 tproxy，需要 ip_forward=1 转发 LAN / WireGuard 流量。 若 accept_ra=0 且 没有 userspace 网络栈（如 systemd-networkd）代为处理 RA，本机 IPv6 直连（VPN direct 出站）可能 Network is unreachable。 accept_ra=2 的作用：在开启 IP 转发的同时，仍接受上游 RA，让网关主机也能获得 GUA 和默认路由。 ...

DHCP 是什么 DHCP（Dynamic Host Configuration Protocol）在客户端开机或接入网络时，自动下发一组网络参数，常见包括： IP 地址、子网掩码 默认网关 DNS 服务器地址 租期（lease time） 可选：域名、search domain（搜索域） 要正常上网，客户端至少需要 IP、掩码、网关和 DNS；其中 DNS 地址往往也是 DHCP 一并下发的，所以很多人会感觉「DHCP 和 DNS 是一起的」——协议上它们仍是两件事，只是经常由同一台设备、同一份配置一起管。 参考：鸟哥 DHCP 理论 DNS 和 DHCP 有没有关联 有，但分工不同： 协议 回答的问题 DHCP 这台设备用哪个 IP、网关、租期；DNS 问谁 DNS 这个名字对应哪个 IP 关联方式常见有三类： DHCP 在选项里告诉客户端「DNS 服务器是 x.x.x.x」（OpenWrt 上经常是路由器自己）。 内网 DNS 记录和 DHCP 租约/静态分配共用同一份「主机名 ↔ IP」数据（dnsmasq 典型做法）。 DHCP 下发 search domain（如 lan），客户端访问 nas 时会尝试解析 nas.lan。 公网域名（如 example.com）仍由上游 DNS 或转发解析；你在 homelab 里配的通常是内网名（*.lan、*.home 等）的本地解析。 ...