HomeLab 網路架構迷思：為什麼內網直連沒有想像中美好？
在建立家庭實驗室（HomeLab）時，我們常常會遇到一個直覺的疑問：「既然伺服器跟電視都在客廳，為什麼看影片還要繞去外網（Cloudflare）再回來？這不是很浪費頻寬嗎？」
這個現象被稱為 髮夾彎路由 (Hairpinning)。為了追求極致速度，我們通常會想建立一個「內網走 IP/Local DNS，外網走 Domain」的雙通道架構。但在實際操作後，我們會撞上現代 Web 應用的三座大山。
這份筆記記錄了為什麼有時「接受微小的繞路」反而是最優雅的架構解法。
難題一：行動伺服器的死穴 (Local DNS 劫持)
要讓內網設備自動不走 Cloudflare 而直接找本地機器，最標準的做法是架設 Local DNS（如 AdGuard Home），將 *.3pm.lol 強制解析為內網 IP (192.168.x.x)。
致命傷：如果您的伺服器是一台會帶出門的筆記型電腦 (Mac)，這個架構會瞬間崩潰。 當您把 Mac 帶去上班，家裡的 Router/DNS 依然會把流量導向那個已經不存在的內網 IP。這會導致留在家裡的設備無法連上您的服務，甚至可能因為 DNS 設定而導致全家無法上網。
難題二：應用程式的「單一認同」 (URL 綁定)
既然不能騙過 DNS，那我們直接在瀏覽器輸入內網 IP 總行了吧？這對單純的 API 或影音服務（如 Jellyfin）可行，但對複雜的 Web 應用來說是災難：
- WordPress 的執著：WordPress 的資料庫裡寫死了
site_url。如果您用 IP 登入，它載入 CSS 或圖片時還是會去向 Domain 請求。這會導致嚴重的破圖和跨域錯誤。 - Nextcloud 的分享連結：如果您用 IP 登入 Nextcloud，您產生的分享檔案連結就會是
http://192.168...。當您把這個連結貼給外網的朋友，他們絕對打不開。 - CORS 與安全性：現代網頁架構（如 Immich 的進階上傳）嚴格依賴「來源網址一致性」。混用 IP 和 Domain 會觸發各種不可預期的前端報錯。
難題三：綠色鎖頭的執念 (本地 HTTPS 憑證)
「那我直接輸入 IP，但我不喜歡瀏覽器顯示『不安全』，可以加個 HTTPS 嗎？」
技術限制： 在公開網際網路上，憑證授權中心（如 Let’s Encrypt）絕對不會簽發有效憑證給私有 IP（192.168.x.x）。
如果您硬要在本地端開啟 HTTPS，唯一的解法是「自簽憑證」。但這會讓瀏覽器跳出一個更可怕的紅色警告頁面：「您的連線不是私密連線」，您必須點擊「進階 -> 繼續前往」才能放行。這不僅麻煩，也失去了 HTTPS 建立信任的初衷。
💡 最終結論：擁抱 Cloudflare Tunnel
在考量了「伺服器會移動」、「Web 應用的複雜度」與「HTTPS 的信任感」後，最佳實踐反而是：
全面依賴 Cloudflare Tunnel，統一使用 Domain 存取。
- 無腦的一致性：不管設備在哪、網路環境如何，網址永遠不變，服務永遠不會破圖。
- 合法的綠色鎖頭：Cloudflare 邊緣節點提供世界級的 SSL 憑證。
- 效能妥協：Cloudflare 的節點速度極快。對於 1080p 甚至是高壓縮 4K 的串流，這點延遲通常無感。
唯一的例外： 只有當您在客廳電視盒上，需要觀看數十 GB 的未壓縮藍光原盤原檔，且確定會卡頓時。才在該設備的 Jellyfin App 內，手動將伺服器地址改為 http://192.168.31.123:8096 進行物理直連。其餘的服務，請放心地交給 Domain 吧！