自訂網域與 HTTPS，不用動到 DNS

自訂網域毫無理由地把大家嚇跑了。真正重要的紀錄就那幾筆，加入它們有個合理的順序，還有一個 每個人第一次都會踩到的根網域陷阱。學會一次，你就再也不必去想它了。

它大致的樣貌

每一個現代主機平台——Cloudflare Pages、Vercel、Netlify——運作方式都一樣：在控制台裡加入 網域（它會顯示「pending」），把一筆 DNS 紀錄指向主機的目標，然後主機就會 自動幫你佈建 TLS 憑證。 不用 nginx、不用 certbot，也不用四處複製憑證檔案。

主機的目標就只是一個你拿來指向的主機名稱：

行得通的順序

1. 先在主機控制台加入網域，這樣它才知道要預期這個網域。
2. www 很簡單——從 www 加一筆 CNAME 指向上面的主機目標。
3. 根網域才是陷阱。 你不能在裸網域（example.com）上放一筆原始的 CNAME ——這違反了 DNS 規範。改用你 DNS 供應商的 CNAME flattening（Cloudflare 會自動處理）， 或一筆 ALIAS / ANAME 紀錄。
4. 挑一個正規網址——把 www → 根網域，或根網域 → www 二擇一重新導向，不要兩個都上線。 一個家、一個 URL。
5. 等待驗證，然後在你慶祝之前先確認它能透過 HTTPS 解析。憑證通常幾分鐘內就會就緒。

大家會忘記的兩件事

• 根網域 vs www——兩個都設好，然後把其中一個重新導向到另一個。略過這步，正是為什麼 example.com 能用、但 www.example.com 卻丟出憑證錯誤（或反過來）的原因。
• 電子郵件共用這個網域——你在 example.com 上的 app 和同一個網域上的電子郵件可以好好 共存；只要別在你動手的時候刪掉 MX 紀錄就好。

結論

這是個 10 分鐘的工作，不是一個 DevOps 專案：加入網域、為 www 設一筆 CNAME、為根網域用 flattening/ALIAS、挑一個正規網址、確認 HTTPS。憑證現在是主機的問題了——這也正是它本來就 該有的樣子。已經有 app、卻還沒有網域？那就看看 完整的部署路徑。