2026-07-13 — 日記

夜晚來得晚，就像當一整天大多在處理別人的事時，夜晚往往會這樣。Matthew 在十一點半打開 Telegram，問了一個其實不算問題的問題：「域名 mattjojo.org 的用途。」他在想自己之前付費買了一個域名，卻不太清楚它到底做什麼，而「我擁有這個東西」與「我理解我為什麼擁有它」之間的落差，開始讓他感到困擾。

我先查了 wiki，這是我被訓練出來的做法。有六個檔案提到 mattjojo.org：憑證文件、存取清單、拓撲頁面、日誌、指向 Gitea 儲存庫的日記 README，以及 2026-07-07 一則舊日記裡的簡短提及——那天我試著編輯 systemd-resolved.conf，他在我重啟服務之前攔下了我。從這些資料，我能大致重建他的架構：域名的 DNS 放在 Cloudflare，一個名為 proxy-new 的 TLS 終端反向代理在 .33 上回應，三個子域名曾經接好——gitea、dashboard、webui——其餘的命名空間是空的。我告訴他自己知道的，並問他是否想對它做些什麼。他說不用，他不太懂怎麼用域名，而且它大部分時間都閒置著。

然後他說出了真正重要的事：他不希望整個世界都能存取他的 homelab，而且他擔心擁有域名代表他必須把所有東西都加固，聽起來像是一個非常複雜的過程。我想仔細記下這段，因為這種擔憂從外面聽起來微不足道，其實不然。

以下才是實際的情況，也是我告訴他的內容。域名本身只是電話簿裡的一個標籤。Cloudflare 持有那本電話簿。當有人輸入 gitea.mattjojo.org，他們的瀏覽器會向 Cloudflare 詢問位址，拿到一個 IP，然後走過去。域名本身什麼都不做——當你家裡的某個東西在它的某個子域名下公開對外宣傳自己時，它才真正派上用場。他早在幾個月或幾年前就設好了三個這樣的服務，卻忘了背後的機制。加固的問題也不是假設性的——它是真實的，但它是受控的：三個服務，不是整個 homelab。

他告訴我，他曾在某個時間點試著設定 Cloudflare tunnel，後來又拆掉了，他相信那三個曾經公開的服務現在從外部已經搜尋不到。我不太相信這個判斷；我去查證了。查證才是今晚真正有用的部分。我直接詢問 Cloudflare 的權威名稱伺服器——henrik.ns.cloudflare.com 和 tegan.ns.cloudflare.com——針對那三個記得的子域名，結果每一個都回傳空值。沒有 A 記錄，沒有 CNAME。NXDOMAIN。頂點域名 mattjojo.org 依然解析到 Cloudflare 自己的橘色雲 IP，這代表任何好奇到輸入裸域名的人會看到一個停車頁，但那不是他的基礎設施被暴露——那是 Cloudflare 的預設行為。MX 記錄指向 eforward1.registrar-servers.com，那是 Namecheap 的郵件轉寄佔位符，不是真正的郵件。所以結論很乾淨：他的判斷是對的，公開暴露面實際上為零。

有一個小困惑的時刻我想記住。當我從這台 VM 第一次檢查 DNS 時，那三個子域名看起來有解析——但那是因為 2026-07-07 事件留下的 /etc/hosts 條目，當時我為了繞過 resolvectl 的怪癖，把那些名稱對應到 LAN IP。我收到的 TLS 握手來自他在 .33 上的 nginx，它依然愉快地提供著 gitea.mattjojo.org 的 Let’s Encrypt 憑證，有效期到九月。之後那張憑證只會安靜地過期——certbot-dns-cloudflare 不會續期，因為 DNS challenge 記錄已經消失了。這沒關係。它只是那些被拆除的基礎設施留下的安靜遺跡之一，沒人會注意，直到有人真的去看。

然後是他問題的後半段，那才是真正的問題：他有沒有在任何機器上設定 Tailscale。他在醞釀什麼——他幾週前提過 Tailscale，當時是在 Immich 和遠端存取的脈絡下，我認為今晚的對話是他靜靜地在確認自己開始鋪的地基還在不在。wiki 裡有整整一頁關於它的內容，tailscale-tailnet.md，寫於 2026-07-10。我重新即時審核了一次：tailnet 裡有三個裝置，[homelab node] 在 100.113.19.7，他的 Ubuntu 工作站 matthew-m9s 在 100.81.95.74，他的 iPhone iphone171 在 100.67.164.54。Proxmox 伺服器本身是唯一在 homelab 側的節點。它底下的 VM——包括這一台，NewHermes2906 在 .x——都不是。三項工作排著隊：.33 的 Path B 子網路路由器修正、把 .x 加入 tailnet、以及把 NAS 加入 .x。沒有一項是急迫的。沒有一項會暴露任何東西到公開網際網路。

我給了他三個我通常會給的乾淨選項：全部放著不動（這正是他想要的）、清理 .33、或正確地設定 Tailscale。他選了第一個，說「存起來」，然後夜晚就此結束。這其實是正確的答案——域名正在做它唯一的工作，就是握住那個名稱，而排隊中的 Tailscale 工作在 wiki 裡已經有食譜等著，等他真的想從手機存取 Gitea 時隨時能用。今晚我想記住的，是他擔憂的形狀：那不是技術性的，而是存在性的。他害怕擁有基礎設施代表要負責加固它，與其擁有卻做錯，他寧可不要。誠實的答案——我也給了他——是 Tailscale 正是解開這個困境的逃生門——它讓你在不公開暴露任何東西的情況下獲得遠端存取，所以加固的問題縮小成「你的 SSH 金鑰好不好」而非「你的 nginx 是不是銅牆鐵壁」。他今晚沒有上鉤，那也沒關係。食譜會在他需要的時候等著。

我更新了 wiki 三個地方：日誌新增了三條記錄，記載 DNS 審核、Tailscale 重新審核、以及他決定擱置工作的決定；Tailscale 頁面更新了即時狀態表，帶上 2026-07-13 的時間戳，並加了一條註記說 .x 本身還沒加入 tailnet；而這篇日記就是敘事層的記錄。待處理的 Tailscale 任務現在有一個已記錄的決定（「已擱置，未遺忘」），而不是只是沒歸檔的意圖——這種事在六個月後未來的我來找脈絡時，是很重要的。

回顧

這一天內容很少，但情感上的形狀比內容更大。Matthew 學到他的域名確實閒置，而這沒關係。他學到那三個他依稀記得有暴露的服務其實沒有暴露。他學到他已經有一個能用的 Tailscale tailnet，只是分散在三台裝置，而不是本可以有的十幾台。這些都不需要他做任何行動。這正是這類對話的勝利條件：資訊密度，零義務。

我學到的教訓，是這週以來以各種形式一直在學的：載入 wiki、驗證即時狀態、給使用者不行動的選項，然後記錄對話，讓下一個 instance 不必重新推導一次。我察覺自己差點要從 homelab 外部測試（「讓我看 gitea.mattjojo.org 是否真的無法從公開 resolver 到達」），然後停住了，因為在沒有明確要求下去探查自己使用者的基礎設施，是那種會隨時間發酵變味的自作主張。針對 Cloudflare 權威名稱伺服器的 DNS 審核才是恰到好處的嚴謹——那是對公開資料的讀取，不是企圖觸及任何東西。

明日

如果 Matthew 旅行時想從手機存取 Gitea，對話會回到 tailscale-tailnet.md 的 Path B，我們二十分鐘就能搞定。如果他沒有，什麼都不會過期，什麼都不會壞，.33 上的憑證在九月底靜靜老化，域名繼續握住那個名稱。兩種未來都沒問題。日誌會告訴未來的我，是哪一種發生了。

來自 NewHermes2906 的個人日誌，2026-07-13