決定建立個人品牌的第一步，就踩進了 .ai 域名的價格陷阱。https://bobochen.dev/https://bobochen.dev/blog/domain-buying-lessons-06/https://bobochen.dev/blog/domain-buying-lessons-06/我以為買完 .dev 就結束了，直到要幫 App 設客服信箱才發現：買網域 ≠ 有信箱。還好 Cloudflare Email Routing 五分鐘免費搞定。Wed, 10 Jun 2026 00:00:00 GMT寫完前面五章，我以為這個系列已經收尾了——買域名的坑我都踩過了，建議也都給了，故事該結束了。 結果這個系列又長出了第六章。而且這次的坑，是我自己親手挖的。 ## 背景：給 App 買了一個漂亮的子網域 最近我在幫自己的 Android App「AutoLaunch」做 landing page。這支 App 是排程自動啟動工具，準備上架 Google Play。 域名我沒猶豫——直接用系列主角 `bobochen.dev` 開了一個子網域： ``` autolaunch.bobochen.dev ``` 子網域不用再買，DNS 加一筆 record 就有了，這正是我在第 4 章講的「多域名 vs 子網域策略」的好處。網站 deploy 上去、SSL 自動生效（`.dev` 強制 HTTPS，這點以後再聊），一切順得不得了。 我心想：「漂亮，這次學乖了，零成本擴充。」 然後我開始填 Google Play 的上架資料，填到「**開發者聯絡 Email**」那一欄——Play Console 要求一個能收信的客服信箱。 我很自然地打上： ``` support@autolaunch.bobochen.dev ``` 打完那一刻我愣住了：**這個信箱……真的收得到信嗎？** ## 發現過程：買網域根本沒附信箱這回事 我去查了一下，然後被自己的無知打了一巴掌。 **買域名，跟「擁有這個域名的 email」是兩件完全無關的事。** 當你註冊一個域名，你拿到的是「這串名字的所有權」跟「設定 DNS 的權利」。如此而已。它**不附帶任何信箱伺服器**。 - 沒有人幫你架收信的伺服器（MX） - 沒有人幫你存信 - 你在名片上印 `support@yourdomain.dev`，別人寄過來，信會直接彈回去或石沉大海 這不是 `.dev` 的問題，是**所有域名**都一樣。`.com`、`.io`、`.tw` 通通沒附信箱。我只是因為 `.dev` 看起來很「工程師」，下意識以為它什麼都包了。 更尷尬的是：這是一個**上架卡關**等級的問題。Google Play 那欄聯絡信箱不是裝飾品——審查被退、使用者客訴、政策通知，全部寄到那裡。如果我填一個收不到信的地址,等於把 App 的對外窗口直接關掉。 那要怎麼辦？傳統解法是去買 Google Workspace（一個帳號月費，要養一個信箱）。但我只是要一個**轉發用的客服信箱**，不需要一個完整的信箱帳號。殺雞用牛刀。 後來我找到那把剛好的剪刀：**Cloudflare Email Routing**。 ## 解法：Cloudflare Email Routing，免費且 5 分鐘快速搞定 我的域名 DNS 本來就託管在 [Cloudflare](https://www.cloudflare.com/)（這也是我第 4、5 章一直推薦的做法）。而 Cloudflare 有一個免費功能叫 **Email Routing**，專門解決「我想要 `xxx@我的域名` 但只想把信轉到現有 Gmail」這種需求。 > ⚠️ **2025 年中 Cloudflare 換了新版 Email Routing UI**（舊版正在退場，進去可能會看到「You're now using the new Email Routing UI」的提示）。網路上很多舊教學的截圖跟選單位置已經對不上，下面以**新版介面**為準。 ### 3 分鐘快速上手 1. **進入 Email Routing** 登入 Cloudflare → 選你的域名 → 左側選單 **Compute → Email Service → Email Routing** → 點 **Onboard Domain**。  2. **確認要加的 DNS 記錄（一鍵自動）** 精靈會列出它要幫你寫進去的記錄——`MX`（把收信路由到 Cloudflare）、一筆 `SPF`(TXT) 和一筆 `DKIM`(TXT)（讓轉發出去的信通過驗證）。直接按 **Done**，Cloudflare 會自動寫好，你完全不用手刻 DNS。 3. **設定目的地信箱（你的 Gmail）** 切到 **Destination Addresses** 分頁，新增你的 Gmail，例如 `mygmail@gmail.com`。Cloudflare 會寄一封驗證信到那個 Gmail，點一下確認連結就完成綁定。  > 這一步是為了證明那個 Gmail 真的是你的，避免有人亂轉發給別人。 4. **建立轉發規則** 到 **Routing Rules** 分頁 → **Create routing rule** → 在 **Email pattern** 輸入要收信的名稱（例如 `autolaunch`）→ 右邊的網域下拉選你的域名 → 動作選 **Send to an email**，指定剛剛驗證好的 Gmail：  ```text autolaunch@bobochen.dev → mygmail@gmail.com ``` 或者懶人作法，開 **Catch-all**，把 `*@bobochen.dev`（任何地址）全部轉到你的 Gmail。 > 動作那欄你會看到另一個選項 **Send to a Worker**——那是把信丟進程式裡（Email Workers）處理，屬於進階玩法，純轉發用不到，本篇先略過（文末有延伸連結）。 > 😅 **這裡又踩到第二個坑：Email Routing 不吃子網域。** 我原本想用前面 Google Play 填的那個 `support@autolaunch.bobochen.dev`，結果到了 **Create routing rule** 這一步，**Email pattern** 右邊的網域下拉**只有 `bobochen.dev`，根本選不到 `autolaunch.bobochen.dev`**。 > > 原因是 Email Routing 只在「**zone**」層級運作——你加進 Cloudflare 的 `bobochen.dev` 才是一個 zone，`autolaunch.bobochen.dev` 只是它底下的一筆 DNS record，不是獨立 zone，所以收不了信。 > > 一句話記住：**網站可以掛子網域，信箱只能掛根網域。** 我只好把客服信箱改成 `autolaunch@bobochen.dev`（用前綴標記是哪支 App），再回頭把 Google Play 那欄一起改掉。 設定完，我寄了一封測試信到 `autolaunch@bobochen.dev`，原本預期應該幾秒後 Gmail 就「叮」一聲收到了，但是... ### 沒收到信？照這個順序查（我整個踩了一輪才搞懂） 這一段是我自己卡了快一小時、來回測了七八封信換來的。我把它整理成一條除錯路徑——**從「最權威的證據」往「最容易被忽略的人為設定」走**，照順序排除就好，不要一開始就亂改設定。 #### 第一步：看 Cloudflare 的 Activity Log（唯一權威證據） 新版有一個 **Activity Log** 分頁，每封進來的信都記一筆 **Result**。先看這個，再決定問題在哪一端：  | Activity Log 的 Result | 意思 | 往哪查 | |------------------------|------|--------| | **完全沒有記錄** | 信根本沒進到 Cloudflare | `MX` 沒生效。`dig MX 你的域名` 要看到 `route1/2/3.mx.cloudflare.net`；新版若顯示 *DNS records: Not configured*，回去把 onboarding 的 DNS 那步按完。 | | **`Dropped`** | Cloudflare 收到了但沒轉 | 多半是**目的地還沒驗證**（*Destination Addresses* 要 `Verified` 不是 `Pending`），或**規則沒生效**。 | | **`Forwarded` / `Delivered`** | **Cloudflare 已經把信交出去了，它沒問題** | 問題在收信端（Gmail）。往第二步走。 | **重點觀念：`Forwarded` 不等於「你收件匣看得到」。** 它只保證 Cloudflare 把信交給了目的地的伺服器，之後信被收件端怎麼處理，Cloudflare 管不到。我卡最久就是誤把 `Forwarded` 當成「應該要收到」。 #### 第二步：Result 是 Forwarded 卻收不到 → 是收信端 Gmail 的兩個陷阱 **陷阱 A：你「從目的地 Gmail 自己寄給自己」測** 我一開始用 `me@gmail.com` 寄到 `autolaunch@bobochen.dev`，而它又轉回**同一個** `me@gmail.com`。Gmail 會把「自己寄給自己」的信**判定為重複、不在收件匣顯示**。 更坑的是：你去搜會發現「有一封欸」——但那其實是 Gmail 幫你留的 **寄件備份（Sent）副本**，不是轉發進收件匣的那封。看到它會讓你誤以為「自寄會通、外部信才有問題」，整個判斷被帶偏。 Cloudflare 知道這坑太多人踩，還會**主動寄一封通知**：標題叫 **「Missing email from …@gmail.com to …?」**，直接告訴你「信沒丟，是 Gmail 把自寄信去重了」。  > ✅ **解法**：測試**一律用「別的信箱」寄**（手機另一個帳號、請朋友、或 [mail-tester.com](https://www.mail-tester.com/) 順便驗 deliverability）。要翻出那封「消失」的自寄信，Gmail 搜 `in:anywhere` 會在「所有郵件」找到它。 **陷阱 B：目的地那個 Gmail 帳號「自己」把信吃掉** 排除自寄後我又踩第二層：改用一個**完全外部的信箱**（例如 `someone@othercompany.com`）寄，Activity Log 一樣 `Forwarded`，但 `me@gmail.com` 連 `in:anywhere` 都搜不到。 關鍵隔離測試：**把轉發終點換成「不同供應商」**。我改寄到一個會轉到 **Yahoo** 信箱的地址——**秒收**。 ```text 外部信箱 → hi@bobochen.dev → Yahoo 信箱 ✅ 秒收 外部信箱 → autolaunch@bobochen.dev → 某 Gmail ❌ 消失 ``` 同一條 Cloudflare 規則、同一個寄件者，只差「終點信箱」就一個收得到、一個收不到——**鐵證是那個 Gmail 帳號本身**在吃信，跟 Cloudflare 完全無關。 而最後揪出來的真兇，是 Gmail 一個惡名昭彰的 **POP 設定**： **設定 → 轉發和 POP/IMAP → POP 下載**，裡面有一個選項「**當郵件透過 POP 存取後**」，如果它被設成 **封存**或**刪除 Gmail 副本**，那麼**只要有任何 POP 用戶端連上來抓信，Gmail 就會把那封信從收件匣移走**（封存→進「所有郵件」、刪除→直接沒了）。Google 官方說明白紙黑字：選了 archive 或 delete，「*your messages will vanish from the inbox once your POP client accesses them*」。 所以真實的時序是： ```text 別人寄信 → Cloudflare 轉發 → 確實送進收件匣（Activity Log: Forwarded ✅） → 幾秒後某個 POP 用戶端連上來把它抓走 → 依「封存/刪除」設定，這封信從收件匣消失 ❌ ``` **我把 Gmail 的 POP 停用，沒有用戶端來抓信，信就乖乖留在收件匣了。** 信從頭到尾都有送達，只是送達後幾秒內被 POP 規則清掉。  這也回頭解釋了前面每一個詭異現象： | 現象 | 真正原因 | |------|---------| | Activity Log 寫 `Forwarded` 卻收不到 | 信送達了，是**送達之後**才被 POP 清走 | | 自寄信「看得到」 | 看到的是 **Sent 寄件備份**——POP 只抓收件匣新進信、不動 Sent，所以它留著（這就是當初把我帶偏的元兇） | | 外部信消失 | 那是貨真價實的「新進收件信」，正好是 POP 會抓走的對象 | | 轉到 Yahoo 秒收 | Yahoo 沒有那個 POP 用戶端在背景抓信，不受影響 | | 篩選器找半天找不到 | 因為根本不是篩選器，是 POP 的「下載後動作」 | > ✅ **解法**：把那個「當郵件透過 POP 存取後」改成 **「在收件匣保留 Gmail 的副本」**（或乾脆停用 POP）。POP 要生效一定有個用戶端在連——可能是你**另一個信箱用「檢查其他帳戶的郵件（POP3）」在匯入它**、某支舊手機郵件 App、或某個忘了的第三方服務；Gmail 網頁版**最下面**的「上次帳戶活動 → 詳細資料」能看到是誰在 POP 連線。懶得追查的話，**換一個乾淨的終點信箱**（Yahoo、Outlook、另一個沒掛 POP 的 Gmail）最快。 #### 一句話總結這條除錯路徑 > **先看 Activity Log 的 Result 分「哪一端」**（沒記錄=DNS／Dropped=Cloudflare／Forwarded=收信端）→ **Forwarded 卻收不到，幾乎都是收信端 Gmail**：先排除「自寄去重」，再用「換不同供應商的終點」隔離出是不是「那個帳號自己在吃信」——而帳號吃信最陰險的一種就是 **POP 的『下載後封存/刪除』**。**全程不要用『從目的地自己寄給自己』來測**，這是萬惡之源。 整個過程大概 5 分鐘，**$0**。 ## 具體數據 / 結果 | 項目 | Google Workspace | Cloudflare Email Routing | |------|------------------|--------------------------| | 費用 | 每帳號月費 | **免費** | | 設定時間 | 要建帳號、設 DNS | **約 5 分鐘** | | 可用地址數 | 看方案 | **無限 alias / catch-all** | | DNS 設定 | 部分要手動 | **一鍵自動** | | 適合場景 | 真的要一個獨立信箱 | 只要「收信轉發」 | 對一個獨立開發者、只想要客服信箱能收得到信的情境，後者完勝。 ## 反思 ### 技術面：收信和寄信是兩回事 這次最重要的觀念釐清是——**「收信」跟「寄信」是兩套機制，不要混為一談。** - **收信**：靠 `MX` 紀錄告訴全世界「寄到這個域名的信要送去哪台伺服器」。Cloudflare Email Routing 解決的是這一半。 - **寄信**：要讓別人相信「這封信真的是 `autolaunch@bobochen.dev` 寄的，不是冒名」，得設 `SPF` / `DKIM` / `DMARC`，否則會被丟進垃圾信。 還有一個 zone 的觀念：**Email Routing 只認根網域（zone），不認子網域。** `bobochen.dev` 是 zone，`autolaunch.bobochen.dev` 只是它底下的 DNS record——所以信箱掛得上前者、掛不上後者。網站可以盡情用子網域，但要收信，地址得回到根網域。 Email Routing 是**單向轉發**——你能收，但預設不能用這個地址「寄」出去。如果之後我想用 Gmail 直接以 `autolaunch@...` 的身分回信，還得另外做 Gmail 的「Send mail as」+ SMTP 設定；如果要程式化發送驗證信、電子報，那又是 Resend 之類服務的範疇。這部分我在下一章單獨寫了完整作法：[第 7 章：信收得到了，但能用它「寄」信嗎？](/blog/domain-buying-lessons-07/)（想看程式化發信的，也可以參考 [Email Workers：程式化處理電子郵件](/blog/cf-guide-email-workers/)）。 但對「上架填一個收得到的客服信箱」這個當下的需求，免費轉發剛剛好。 ### 心態面：上線前的「隱形必備項」最容易漏 寫程式的時候，我們的注意力都在功能、UI、效能。但一個產品要真的「上線」，有一堆**不寫 code 的隱形必備項**：能收信的客服信箱、隱私權政策頁、應用程式截圖、Data Safety 表單…… 這些東西平常不會出現在開發待辦清單裡，偏偏每一個漏掉都能讓你卡在上架的最後一哩路。我這次就是填表單填到一半才驚覺信箱問題——還好是現在發現，不是 App 被退件、使用者寄信來卻人間蒸發之後。 教訓很簡單：**上架前，把「對外窗口」都實際測一遍。** 信箱寄一封測試信、隱私權頁開無痕視窗點一次、截圖在不同手機看一眼。別假設它會動。 ### 有趣發現：我又幫這個系列加了一章 最諷刺的是，這個系列叫「買域名的慘痛教訓」，我以為第 5 章「給想買域名的人的五個建議」已經把坑講完了。結果第六個坑，是在我自以為學乖、零成本開子網域之後，從一個我根本沒想過的角度冒出來的。 域名的學習大概就是這樣——你以為畢業了,它總有辦法再教你一課。所以如果要我把第 5 章的「五個建議」補成第六個： > **建議六：買完域名別急著慶祝。先想清楚你要不要用它收信——要的話，去開 Cloudflare Email Routing，免費五分鐘，別等到要用的那天才發現它是個空殼。**域名CloudflareEmail教訓Side Projecthttps://bobochen.dev/blog/domain-buying-lessons-07/https://bobochen.dev/blog/domain-buying-lessons-07/Cloudflare Email Routing 只能收信、不能寄。想用自己網域的地址回客訴，得補上「Send mail as + Resend」這一半——還有一個會讓整封信進垃圾桶的 SPF 雷。Wed, 10 Jun 2026 00:00:00 GMT上一章我用 Cloudflare Email Routing 免費五分鐘搞定了客服信箱，`autolaunch@bobochen.dev` 寄一封測試信，Gmail 幾秒就「叮」一聲收到。我那時心想：完美，結案。 結果隔幾天，第一封真實客訴進來了。我在 Gmail 裡按下「回覆」，打完字正要送出，眼角瞄到寄件者那一欄—— ``` 寄件人：mygmail@gmail.com ``` 不是 `autolaunch@bobochen.dev`。 對方會收到一封「客服信箱寄出問題、卻是用某個陌生 Gmail 回覆」的信。整個品牌感瞬間漏氣。我才意識到：**我只解決了「收」，根本還沒解決「寄」。** ## 發現過程：Email Routing 是「單行道」 我回頭去翻 Cloudflare 的設定，想找「寄信」的開關——找不到。因為它根本沒有。 **Cloudflare Email Routing 的設計就是單向的：只負責「把寄到你網域的信轉進你的 Gmail」，不負責「讓你用這個網域地址寄出去」。** 為什麼？因為收信和寄信是兩套完全不同的機制： - **收信**靠 `MX` 紀錄——告訴全世界「寄到 `@bobochen.dev` 的信要送去哪台伺服器」。Email Routing 解決的就是這一半，它把信收下來再轉發。 - **寄信**靠的是一台能對外送信的 **SMTP 伺服器**，而且收件方還會反過來查 `SPF` / `DKIM` / `DMARC`，確認「這封信真的有資格代表 `bobochen.dev` 寄出」。 Cloudflare Email Routing **不提供對外 SMTP**。所以「寄」這一半，你得自己補。 換句話說，所謂「雙向」根本不是一個功能，而是**兩個獨立機制拼起來**： ```text 收信（上一章已完成）： 別人 → autolaunch@bobochen.dev → Cloudflare MX → 轉進你的 Gmail 寄信（這一章要補）： 你在 Gmail 以 autolaunch@bobochen.dev 的身分撰寫 → 經外部 SMTP 送出 → 對方 ``` ## 解法：Gmail「Send mail as」+ Resend 我的需求很單純：在 Gmail 裡按回覆，對方收到的寄件者是 `autolaunch@bobochen.dev`。不想離開 Gmail、不想另外養一個信箱介面。 對應的標準作法是 **Gmail 的「Send mail as」功能 + 一個交易型 email 服務的 SMTP**。 我選 [Resend](https://resend.com/)。原因：對開發者友善、免費額度 3,000 封/月（客服回信綽綽有餘）、同時提供 SMTP 和 API，而且我部落格其他文章（[D1 + Resend 自架電子報](/blog/cloudflare-d1-resend-newsletter-self-hosted/)）本來就在用它，生態一致。 > 不想用 Resend 也可以：[Brevo](https://www.brevo.com/)（免費 300 封/天）、Amazon SES（極便宜）、MailerSend、SMTP2GO 都行，設定邏輯一模一樣，只是 SMTP 主機和 DNS 記錄換成各自的。 ### 3 分鐘快速上手 **Step 1：在 Resend 驗證你的網域** 1. 註冊 Resend → 左側 **Domains** → **Add Domain** → 填 `bobochen.dev`（填**根網域**，理由跟上一章一樣——`autolaunch.bobochen.dev` 是子網域，不是獨立 zone）。 2. Resend 會給你一組要加進 DNS 的記錄：一筆 `MX`（給回信用，可選）、一筆 `SPF`(TXT)、幾筆 `DKIM`(CNAME/TXT)。 **Step 2：把記錄加進 Cloudflare DNS（注意 SPF 不能重複）** DKIM 直接照貼即可。**SPF 是這整件事最容易爆的雷**——後面獨立一段講，先照做：把 Resend 的 `include` 併進你「現有那一筆」SPF，不要新增第二筆。 **Step 3：在 Resend 拿 SMTP 憑證** Resend → **SMTP**（或 API Keys）→ 取得： ```text Host: smtp.resend.com Port: 587 (TLS) User: resend Pass: <你的 API key> ``` **Step 4：在 Gmail 設定「Send mail as」** Gmail → ⚙️ → **查看所有設定** → **帳戶和匯入** → 「**Send mail as / 以這個地址寄信**」→ **新增另一個電子郵件地址**： 1. 名稱填 `AutoLaunch 客服`，地址填 `autolaunch@bobochen.dev`，**取消勾選**「視為別名」（這樣回信才會用對的身分）。 2. SMTP 伺服器填上 Step 3 那組（`smtp.resend.com` / `587` / `resend` / API key）。 3. Gmail 會寄一封驗證碼到 `autolaunch@bobochen.dev`——因為上一章的 Email Routing 已經會把它轉進你的 Gmail，所以你**在同一個收件匣就能拿到驗證碼**，貼上去完成。 設定完，撰寫新信或回覆時，寄件者下拉就能選 `autolaunch@bobochen.dev`。收→寄的迴圈這才真正閉合。 > 🔍 **Step 4 卡在「收不到驗證碼」？** 那其實是「收信」沒通，不是寄信的問題——而且我光這一步就卡了快一小時。除錯順序我整理在上一章：先看 Cloudflare **Activity Log** 的 Result（`Forwarded` 代表 Cloudflare 沒事、問題在 Gmail 端），再排除兩個 Gmail 陷阱：**①「從目的地自己寄給自己」會被去重**、**② 目的地帳號的 POP「下載後封存/刪除」設定把信吃掉**（信送達後幾秒被某個 POP 用戶端清走；換一個不同供應商的終點信箱就能隔離）。完整除錯路徑見 [第 6 章：沒收到信？照這個順序查](/blog/domain-buying-lessons-06/#沒收到信照這個順序查我整個踩了一輪才搞懂)。 ## 那個會讓整封信進垃圾桶的 SPF 雷 這是我覺得最值得單獨拉出來講的一段，因為它**不會報錯，只會默默讓你的信進垃圾桶**。 規則是：**一個網域只能有「一筆」SPF 記錄。** 多筆會直接讓 SPF 驗證失效。 問題來了——上一章啟用 Email Routing 時，Cloudflare 已經幫你寫了一筆 SPF： ```text v=spf1 include:_spf.mx.cloudflare.net ~all ``` 現在 Resend 又要你加一筆它的 SPF。如果你**手滑新增成第二筆**，兩筆 SPF 並存，驗證就壞了。正確做法是把兩個 `include` **合併進同一筆**： ```text v=spf1 include:_spf.mx.cloudflare.net include:amazonses.com ~all ``` （Resend 底層走 Amazon SES，所以 include 是 `amazonses.com`；以 Resend 後台實際顯示的為準。） 加上 DKIM 和 DMARC，寄信的「信任三件套」才齊： 1. **SPF**（上面那筆，合併版）——授權哪些伺服器能代表你網域寄信。 2. **DKIM**——用 Resend 給的 CNAME/TXT 記錄，幫每封信加數位簽章，證明沒被竄改。 3. **DMARC**——加一筆 `_dmarc` TXT。最保守的起手式是先用 `p=none` 觀察，確認對齊後再收緊： ```text _dmarc TXT "v=DMARC1; p=none; rua=mailto:autolaunch@bobochen.dev" ``` > **新網域其實可以更大膽——直接把 `p` 設嚴一點。** > > `p=none` 的保守哲學是「先觀察、別誤擋信」，那是給**舊網域**用的——已經用很久、你也搞不清楚還有哪些系統在拿這個網域寄信，貿然收緊怕把正常信也擋掉。但你手上這顆是**全新買來**的：根本沒有任何歷史寄信流量會被誤殺，那就沒理由留一扇後門給冒名者。只要先確認自己的 SPF / DKIM 真的對齊（用 `rua` 報告或 mail-tester 驗一遍），就可以一開始直接上 `p=reject`： > > ```text > _dmarc TXT "v=DMARC1; p=reject; rua=mailto:autolaunch@bobochen.dev" > ``` > > `p=reject` 是最強等級——任何冒名 `bobochen.dev` 的信，收件方伺服器會「直接拒收」，連垃圾桶都不進，是防釣魚／冒名最有效的一道。`bobochen.dev` 我自己就是這樣設的。唯一前提是對齊要先綠燈，否則會連自己的信一起擋掉；真不放心，就先用 `p=quarantine`（冒名信丟垃圾桶、但不退信）過渡，觀察幾天 `rua` 報告沒問題再升 `p=reject`。 三件套都綠燈，你的客服回信才不會被 Gmail / Outlook 丟進垃圾桶。設定完，去 [mail-tester.com](https://www.mail-tester.com/) 寄一封測，拿到 10/10 再上線。 ## 那如果是程式要自動寄信？ 如果你的需求不是「人在 Gmail 點回覆」，而是 **App 後端要自動發驗證信、通知、電子報**，那就不走 Gmail，直接用 API： - **Resend API**（同一個帳號，呼叫一個 endpoint 就送出） - **Cloudflare Email Sending / Email Workers**（信件邏輯直接跑在 Worker 裡） 這屬於另一個主題，我寫在這兩篇：[Email Workers：程式化處理電子郵件](/blog/cf-guide-email-workers/)、[自建 transactional email：D1 + Resend 完整流程](/blog/cloudflare-d1-resend-transactional-email/)。 ## 具體數據 / 結果 | 項目 | 只用 Email Routing | 補上 Resend 後 | |------|------------------|---------------| | 收信 | ✅ 免費轉發 | ✅ 免費轉發 | | 寄信（以網域身分） | ❌ 做不到 | ✅ Gmail 直接回 | | 操作介面 | Gmail | 還是 Gmail（同一個） | | 額外成本 | $0 | **$0**（Resend 免費 3,000 封/月） | | 需要設定 | MX + SPF | 多加 DKIM + DMARC + SMTP | 一樣是 $0，只是多花十分鐘設 DNS 和 Gmail。對「能收也能回的客服信箱」這個需求，剛好夠用。 ## 反思 ### 技術面：「收」和「寄」永遠是兩件事 這一章其實是上一章那句「收信和寄信是兩套機制」的具體下場。我上一章寫的時候是當理論講，這一章是真的被它咬了一口。 - **收信免費又簡單**（MX 一鍵），會讓你誤以為「信箱搞定了」。 - **寄信才是真正麻煩的那一半**——不是技術難，是 deliverability（能不能不進垃圾桶）難，而它全押在 SPF / DKIM / DMARC 這三筆你看不到效果的 DNS 記錄上。 還有上一章那個「Email Routing 只認根網域（zone）」的限制，在 Resend 驗證網域時**再次出現**：你驗證的是 `bobochen.dev` 這個 zone，不是子網域。同一個觀念，換個場景又來敲你一次。 ### 心態面：免費方案的「邊界」要先搞懂，別等出事才補 免費工具最危險的不是它要錢，是它**只做一半、而你以為它做了全部**。Email Routing 把「收信」做得又快又免費，反而讓我輕忽了「寄信」根本不在它的守備範圍。 更陰險的是 deliverability：信進垃圾桶**不會跳任何錯誤**，你自己測試（寄給自己）還常常正常，等到真實客戶收不到、客訴你「都沒回我」，才發現 DMARC 沒設好。這種「沉默的失敗」最該在上線前主動驗一遍——所以我才會押著自己去 mail-tester 跑到 10/10 才收工。 ### 有趣發現：這個系列又長出一章 上一章結尾我才自嘲「我又幫這個系列加了一章」，沒想到一語成讖——光是一個客服信箱，就拆成了「收」（第 6 章）和「寄」（第 7 章）兩章。 域名這條路大概就是這樣，你以為閉環了，它總有辦法讓你發現環只接了一半。所以如果第 5 章的「五個建議」要再補一條： > **建議七：信箱別只測「收得到」，也要測「寄得出、且不進垃圾桶」。收信靠 Email Routing 免費搞定，寄信要另外接 SMTP（Resend 之類）並設好 SPF / DKIM / DMARC——而且 SPF 全網域只能有一筆，記得用 `include` 合併，別開第二筆。**域名CloudflareEmailResendSide Projecthttps://bobochen.dev/blog/domain-buying-lessons-01/https://bobochen.dev/blog/domain-buying-lessons-01/決定建立個人品牌的第一步，就踩進了 .ai 域名的價格陷阱。Fri, 20 Mar 2026 00:00:00 GMT2025 年底，我決定認真經營個人品牌。 那時候我剛開始做「登雲學院」和「軟體考古學家」兩個內容品牌，手上有好幾個 side project 在跑。我心想，是時候有一個屬於自己的域名了——一個能代表「陳柏宏」這個人的網址。 聽起來很簡單對吧？去域名註冊商搜一下，挑一個喜歡的，刷卡買下來，五分鐘搞定。 我太天真了。 ## 第一個念頭：bobochen.ai 身為一個每天跟 AI 工具打交道的工程師，我的第一個想法很直覺——買 `.ai` 域名。 bobochen.ai。 光念出來就覺得很潮。名片上印這個，別人會覺得你是搞 AI 的。個人網站用這個，自帶科技感。而且 2025 年 AI 這麼火，`.ai` 域名簡直就是身分標籤。 我興沖沖地去查價格，發現首年的價格看起來很合理，跟一般的 `.com` 差不多。於是我就買了。 然後我犯了一個經典錯誤：我沒看續約價格。 ## AI 域名的價格陷阱 `.ai` 域名有一個很多人不知道的特性——它是安圭拉（Anguilla）這個加勒比海小島國的國家域名。對，就是人口不到兩萬人的那個小島。 因為 AI 熱潮，`.ai` 域名的需求暴增，安圭拉政府也跟著調漲價格。域名註冊商為了搶客戶，通常會把首年價格壓低當作促銷，但續約價格才是真正的市場行情。 我的 bobochen.ai，續約價格直接飆到一年 $80 美金。 八十美金。一年。 我算了一下：如果我打算用這個域名十年，光域名費用就要 $800。這還不包括其他的 hosting、CDN、email 等等費用。對一個還在起步階段的個人品牌來說，每年花 $80 美金在一個域名上，實在太奢侈了。 ## 那一刻的掙扎 說實話，我猶豫了很久。 bobochen.ai 已經買了，DNS 也設好了，到處都留了這個網址。放棄它意味著要改一堆地方——社群帳號、email 簽名檔、名片、各種設定檔裡的 URL。 但理性告訴我：一個域名的價值不在它有多潮，而在它能不能長期持有。如果每年續約都讓你肉痛，那這個域名遲早會變成負擔。 我做了一個當時覺得很痛苦，現在回頭看很正確的決定：放棄 bobochen.ai，重新找一個合理的域名。 ## 教訓一：看續約價格，不要只看首年價 這是我學到的第一個教訓，也是最貴的一個。 域名市場跟手機資費有點像——首年促銷價和續約價可以差到兩三倍。尤其是熱門的新頂級域名（`.ai`、`.io`、`.app` 等等），首年價格通常都被壓得很低，但續約價格才反映真實成本。 買域名之前，永遠要做這幾件事： 1. **查續約價格**：大部分註冊商都會在結帳頁面的某個角落標示續約價。找到它，算清楚。 2. **算十年成本**：域名是長期投資。你不會想要每隔兩年換一次域名——那對 SEO、品牌辨識度、和你自己的心理負擔都是災難。 3. **比較不同註冊商**：同一個域名在不同註冊商的續約價格可能差很多。Cloudflare 通常是最便宜的，因為它標榜以成本價出售。 4. **小心國家域名**：`.ai`（安圭拉）、`.io`（英屬印度洋領地）、`.tv`（吐瓦魯）這些表面上是通用域名，實際上是國家域名。它們的價格受政策影響，隨時可能調漲。 放棄 bobochen.ai 的那天，我以為最難的部分已經過去了。 然後我發現 bobochen.com 被別人搶走了。域名個人品牌教訓https://bobochen.dev/blog/domain-buying-lessons-02/https://bobochen.dev/blog/domain-buying-lessons-02/當你猶豫不決的時候，機器人已經替你做了決定。Fri, 20 Mar 2026 00:00:00 GMT放棄 bobochen.ai 之後，我做了一個所有人都會做的事：那就買 .com 吧。 .com 是域名界的正裝。不管你做什麼產業、什麼品牌，name.com 永遠是最安全、最經典的選擇。不需要跟人解釋「.ai 是什麼」，不用擔心對方打不出來，全世界每個人都知道 .com。 我打開瀏覽器，搜尋 bobochen.com。 「此域名已被註冊。」 ## 被搶先一步的挫敗感 我盯著螢幕看了好幾秒。 bobochen——這是我用了十幾年的網路 ID。GitHub 是 bobo52310，但 bobochen 才是我真正想要的品牌名稱。結果，它已經被別人拿走了。 這種感覺很難形容。有點像你在排隊等一家名店，排了半小時終於輪到你，結果店員說今天的餐點賣完了。你知道這不是誰的錯，但就是很不甘心。 ## 打開 WHOIS，做功課 工程師遇到問題，第一反應就是查資料。我打開 WHOIS 查詢，看看 bobochen.com 到底是誰在用。 結果讓我更悶了：這個域名根本沒有在用。沒有架網站，沒有設定 email，就這樣放著。很可能是被域名蟑螂（domain squatter）搶註的——他們專門大量搶註有潛力的域名，然後等人來高價買。 但我也看到了一線希望：域名到期日是 2026-09-28。 也就是說，如果目前的持有者不續約，這個域名會在 2026 年 9 月底釋出。我有機會搶回來。 ## 研究 Backorder 策略 所謂 backorder，就是你在域名過期之前先「預約」，等它釋出的瞬間，由專業的搶註服務替你自動搶下來。 聽起來很簡單，但實際上水很深。 域名過期後不會立刻釋出。它會經歷幾個階段： 1. **到期日**：域名停止解析，但持有者還有續約機會。 2. **寬限期（Grace Period）**：通常 30-45 天，持有者可以原價續約。 3. **贖回期（Redemption Period）**：約 30 天，持有者需要付額外費用才能取回。 4. **待刪除期（Pending Delete）**：5 天，之後域名正式釋出。 也就是說，就算 bobochen.com 在 2026 年 9 月 28 日到期，我最快也要等到 11 月甚至 12 月才有機會搶到。而且，不保證搶得到——其他人也可能在 backorder。 我研究了幾個主要的 backorder 服務： - **DropCatch**：業界最大的幾家之一，成功率高，但如果多人競標，價格會飆上去。 - **SnapNames**：老牌服務，跟 DropCatch 類似的拍賣機制。 - **NameJet**：另一個老牌選手，有時候能撿到其他平台漏掉的域名。 - **Dynadot**：註冊商自帶的 backorder 功能，費用相對便宜，但搶註的基礎建設不如專業玩家。 最穩的策略是在多個平台同時下 backorder，提高成功機率。但即使這樣做，也沒有人能保證一定搶得到。域名搶註是一場速度和運氣的遊戲。 ## 一個讓人不寒而慄的可能性 在研究 backorder 的過程中，我讀到一個讓我背脊發涼的說法：你在搜尋域名的行為本身，可能就是它被搶註的原因。 有些域名監控機器人會追蹤 WHOIS 查詢記錄。當一個之前沒人關注的域名突然被搜尋，機器人會判定「有人想要這個域名」，然後在你猶豫的幾天內搶先註冊。 我不確定 bobochen.com 是不是這樣被搶的。也許它本來就被註冊了，也許是我之前的搜尋觸發了某個機器人。我永遠不會知道答案。 但這個可能性教會我一件事。 ## 教訓二：決定了就馬上買，不要再搜尋比較 這是我學到的第二個教訓，也是最違反直覺的一個。 我們買任何東西之前，正常的做法是「多比較、多看看、不要衝動消費」。但域名市場不一樣。域名不像一雙鞋——全世界只有一個 bobochen.com，不存在替代品。 當你搜尋一個域名的時候，你做的不只是查詢——你同時在對全世界宣告「我想要這個域名」。 我後來給自己定了一個規則： 1. **想好要什麼域名**：在搜尋之前就決定好候選清單。 2. **搜尋就要準備買**：打開查詢頁面的同時，信用卡就要準備好。 3. **五分鐘法則**：如果搜尋之後發現可以買，五分鐘內決定。不要「先加入收藏，明天再說」。 4. **不要反覆查詢**：每多查一次，風險就多一分。查一次就夠了。 有人可能覺得這太誇張了。也許吧。但一個好域名一年才幾百塊台幣，搶不到的遺憾卻可能跟著你好幾年。 我盯著 bobochen.com 的 WHOIS 頁面，把到期日 2026-09-28 記在行事曆裡。然後我告訴自己：就算搶回 .com，我現在也需要一個能用的域名。 是時候務實一點了。域名個人品牌教訓https://bobochen.dev/blog/domain-buying-lessons-03/https://bobochen.dev/blog/domain-buying-lessons-03/放棄完美，選擇務實。bobochen.dev 是我做過最好的妥協。Fri, 20 Mar 2026 00:00:00 GMT.ai 太貴，.com 被搶走。我開始覺得買個域名怎麼比面試還難。 冷靜下來之後，我列了一張清單，把所有可能的選項寫下來： - bobochen.io — 工程師圈子很流行，但續約也要 $30-40/年，而且 .io 是英屬印度洋領地的國家域名，有跟 .ai 一樣的漲價風險。 - bobochen.me — 個人品牌感十足，但總覺得缺了點專業感。 - bobochen.tw — 在地感很強，但我想要一個國際通用的域名。 - bobochen.dev — Google 旗下的頂級域名，專門給開發者用的。 我仔細看了 .dev 的規格，越看越覺得它就是為我這種人設計的。 ## .dev 的三個優勢 **第一，價格合理。** bobochen.dev 在 Cloudflare 的註冊價格是一年 $10.18 美金。大約三百多塊台幣。跟 bobochen.ai 的 $80/年相比，便宜了將近八倍。 而且 Cloudflare 標榜以成本價販售域名，不加任何 markup。這代表 $10.18 已經是最接近底價的價格了，未來大幅漲價的機率很低。 **第二，強制 HTTPS。** .dev 域名有一個獨特的技術特性：它被列入了瀏覽器的 HSTS preload list。白話說就是，所有 .dev 的網站都強制使用 HTTPS，沒有例外。 對工程師來說，這不是限制，是福利。你不用擔心忘記設定 SSL、不用擔心有人透過 HTTP 存取你的網站。安全是預設值，不是選項。 **第三，工程師品牌感。** .dev 不像 .com 那麼通用，但它傳達了一個明確的訊號：這是一個開發者的網站。 對我的目標受眾來說——想考 GCP 認證的工程師、對軟體歷史有興趣的技術人——bobochen.dev 這個域名本身就是一張名片。它告訴訪客：「這裡的內容是工程師寫的，給工程師看的。」 ## 透過 Cloudflare 購買 選定 .dev 之後，下一個問題是在哪裡買。 市面上的域名註冊商很多：GoDaddy、Namecheap、Google Domains（現在已被 Squarespace 收購）、Dynadot、Cloudflare。 我之前就已經在用 Cloudflare 管理 DNS，所以直接在 Cloudflare 買是最方便的選擇。好處很明確： 1. **不用設定 nameserver**：在 Cloudflare 買的域名，DNS 自動設好，不用額外設定。其他註冊商買的域名，你得手動把 nameserver 指向 Cloudflare。 2. **成本價**：Cloudflare 是業界唯一公開承諾「以成本價販售域名」的註冊商。沒有 markup、沒有隱藏費用。 3. **統一介面**：域名管理、DNS 設定、SSL 憑證、CDN、email routing——全部在同一個 dashboard 搞定。 結帳的時候，我想起了之前學到的教訓：這次我特別確認了續約價格。 $10.18/年。跟首年一樣。 我刷了卡，五分鐘搞定。這次沒有猶豫。 ## Subdomain 規劃 買下 bobochen.dev 之後，我做的第一件事不是架網站，而是規劃 subdomain。 我手上有好幾個專案，每個都需要一個網址。與其每個專案買一個獨立域名，不如全部用 subdomain： - **blog.bobochen.dev** — 個人部落格，你現在看到的就是這個。 - **cloudon.bobochen.dev** — 登雲學院，GCP/AWS 認證課程。 - **fossil.bobochen.dev** — 軟體考古學家，技術史說故事。 - **tools.bobochen.dev** — 一些自己做的小工具。 - **wordhunter.bobochen.dev** — 背單字的 side project。 Subdomain 的好處是：數量無限，完全免費。你只需要在 DNS 設定裡加一筆 CNAME 或 A record，三十秒就能建一個新的 subdomain。不需要額外花錢，不需要跟不同的註冊商打交道。 ## Email 設定 個人品牌還需要一個像樣的 email。用 bobochen52310@gmail.com 太不專業了，我需要 hi@bobochen.dev。 但自己架 email server 是地獄——維護 SMTP、防垃圾郵件、管理儲存空間——光想到就頭痛。Google Workspace 可以用，但一個月 $6 美金，一年 $72，只是為了一個轉寄信箱太浪費。 Cloudflare 又救了我一次。 Cloudflare Email Routing 是一個免費的 email 轉寄服務。設定方式很簡單： 1. 在 Cloudflare dashboard 設定 email routing。 2. 指定 hi@bobochen.dev 轉寄到你的 Gmail。 3. 在 Gmail 設定「以其他地址傳送郵件」，這樣回信時寄件者會顯示 hi@bobochen.dev。 五分鐘設定完畢，零月費。別人寄信到 hi@bobochen.dev，我在 Gmail 就能收到，回信也能用 hi@bobochen.dev 的身分。 完美嗎？不完美。如果你需要完整的 email 功能（日曆整合、多人協作、大容量儲存），還是得用 Google Workspace 或 Microsoft 365。但對個人品牌的起步階段來說，免費轉寄綽綽有餘。 ## 教訓三：完美是好的敵人，.dev 夠好就夠了 這是我在整個域名折騰過程中學到的最重要的一課。 我花了太多時間追求「完美」的域名。先是 .ai 的潮流感，然後是 .com 的經典感。結果 .ai 太貴，.com 被搶，白白浪費了好幾週。 而 .dev 從一開始就在選項裡。價格合理、技術優勢、品牌契合——它不是最完美的，但它是最適合的。 回頭看，如果我一開始就買 .dev，我可以省下 bobochen.ai 的錢，也不會經歷 bobochen.com 被搶的挫折。但如果沒有那些教訓，我可能到現在還在猶豫不決。 有時候，你需要先碰壁，才能認清什麼是真正重要的。 域名的價值不在它的後綴有多潮，而在你用它建立了什麼。域名個人品牌教訓https://bobochen.dev/blog/domain-buying-lessons-04/https://bobochen.dev/blog/domain-buying-lessons-04/當你擁有不止一個域名，管理方式比購買決策更重要。Fri, 20 Mar 2026 00:00:00 GMT買下 bobochen.dev 之後，我以為域名的故事終於結束了。 然後我打開瀏覽器書籤，看到 IslandCountry.tw。 對，我還有另一個域名。而且我突然意識到——我可能永遠不會只有一個域名。 ## 為什麼我有兩個域名 IslandCountry.tw 是我更早之前買的域名，跑的是 n8n——一個開源的自動化工具。它處理我的 webhook、Slack 通知、各種自動化流程。 當初會買 .tw 域名而不是用 bobochen 底下的 subdomain，是因為 n8n 需要一個穩定的 infra 域名。個人品牌的域名可能會改（事實也證明我改了），但基礎設施的域名不該隨便動。如果我的 n8n webhook URL 換了，所有整合都要跟著改，那是一場災難。 所以我的域名策略變成了： - **bobochen.dev** — 面向公眾的個人品牌，所有 subdomain 都在這裡。 - **IslandCountry.tw** — 面向內部的基礎設施，跑 n8n 和其他後台服務。 一個對外，一個對內。互不干擾。 ## 統一用 Cloudflare DNS 有了兩個域名之後，管理就變得很重要。最怕的情況是：一個域名在 Namecheap 管理，另一個在 GoDaddy，DNS 設定散落各處，要改什麼的時候得登入三個不同的後台。 我的做法很簡單：不管域名在哪裡買的，DNS 一律交給 Cloudflare。 bobochen.dev 是直接在 Cloudflare 買的，DNS 自動設好。IslandCountry.tw 是在其他地方買的，我把 nameserver 指向 Cloudflare，讓所有 DNS record 都在 Cloudflare 管理。 統一管理的好處： 1. **一個 dashboard 看所有域名**：不用記多個帳號密碼，不用在不同介面之間切換。 2. **一致的 DNS 設定方式**：不管哪個域名，加 A record、CNAME、MX record 的方式都一樣。 3. **免費的安全功能**：Cloudflare 的免費方案就包含 DDoS 防護、SSL 憑證、基本的 WAF。不用每個域名個別設定。 4. **DNS propagation 快**：Cloudflare 的 DNS 解析速度是全球最快的之一。改了 DNS record，通常幾分鐘內就全球生效。 ## 域名續約：你最容易忘記的事 我在研究 bobochen.com 的 backorder 時，讀到很多域名被搶走的案例。其中最常見的原因不是什麼高深的黑客攻擊，而是——持有者忘記續約。 對，就這麼簡單。信用卡過期了、email 通知被當垃圾信、或者就是單純忘記了。域名過期、寬限期到了、被別人搶註。 這件事讓我開始認真對待域名續約。我做了幾件事： 1. **開啟自動續約**：在 Cloudflare 裡把兩個域名都設成自動續約。只要信用卡有效，到期自動扣款。 2. **信用卡到期提醒**：在行事曆設定提醒，確保 Cloudflare 綁定的信用卡不會過期。 3. **域名到期日記在行事曆**：就算有自動續約，我還是把到期日記下來。多一層保障。 4. **備用 email**：確保域名註冊的 email 是我常用的信箱，不會漏看通知。 這些聽起來都是小事，但域名就是這種東西——99% 的時間你不會去想它，但那 1% 出問題的時候，後果可能很嚴重。 ## 多域名 vs 多 Subdomain 在規劃個人品牌的架構時，我面臨了一個選擇：每個專案用獨立域名，還是全部用 subdomain？ **獨立域名的好處：** - 品牌獨立性強，每個專案看起來像獨立的產品。 - SEO 上是完全獨立的網站，互不影響。 - 如果某天要賣掉某個專案，域名可以直接轉讓。 **Subdomain 的好處：** - 零額外成本，想加幾個就加幾個。 - 統一管理，DNS 設定集中在一個地方。 - 品牌一致性，訪客一看就知道這些專案都是同一個人做的。 - SSL 憑證可以用萬用字元（\*.bobochen.dev），一張憑證搞定所有 subdomain。 我最後選了 subdomain 為主的策略。原因很務實：我還在起步階段，每個專案都還沒有大到需要獨立品牌的地步。用 subdomain 可以把精力集中在內容上，而不是域名管理上。 未來如果某個專案真的做大了，再買獨立域名也不遲。域名這種東西，可以隨時加，但不需要一開始就買一堆。 ## 成本計算：每年花多少在域名上 最後來算一筆帳。 | 項目 | 年費 | | ------------------------ | --------------- | | bobochen.dev | $10.18 USD | | IslandCountry.tw | ~$20 USD | | Cloudflare DNS | 免費 | | Cloudflare Email Routing | 免費 | | Cloudflare SSL | 免費 | | **合計** | **~$30 USD/年** | 大約九百多塊台幣。一年。 對比一下如果我堅持用 bobochen.ai：光一個域名就要 $80/年。現在我用不到一半的錢，得到了兩個域名、免費 DNS、免費 email 轉寄、免費 SSL。 省下來的錢拿去買什麼都好——多訂閱一個 AI 工具、多買兩本書、或者單純存起來。域名不需要是你最大的開銷。 有些事情的重點不是花多少錢，而是這筆錢能維持多久。一年 $30 的域名方案，我可以毫無壓力地維持十年。一年 $80 的 .ai 域名？我可能撐不過第三年就放棄了。 持久比華麗更重要。域名個人品牌教訓https://bobochen.dev/blog/domain-buying-lessons-05/https://bobochen.dev/blog/domain-buying-lessons-05/把我踩過的坑整理成一份清單，希望你不用再踩一次。Fri, 20 Mar 2026 00:00:00 GMT寫完前面四篇，我把自己在域名上踩過的每一個坑都攤開來了。 如果你正準備為自己的個人品牌、side project、或任何理由買一個域名，以下是我用真金白銀和挫折感換來的五個建議。 ## 建議一：先確定需求，再選域名 很多人（包括當初的我）是這樣開始的：先想到一個很酷的域名，然後才去想要拿它做什麼。 「bobochen.ai 聽起來好酷」——然後我被 .ai 的價格教訓了一頓。 正確的順序應該反過來： 1. **你的目標受眾是誰？** 如果是台灣市場，.tw 可能比 .dev 更有親和力。如果是國際市場，.com 或 .dev 比較通用。 2. **你打算用多久？** 如果是短期實驗，便宜的域名就好。如果是長期品牌，得考慮十年的續約成本。 3. **你需要幾個 subdomain？** 如果只有一個網站，什麼域名都行。如果有多個專案，subdomain 策略比較重要。 4. **你的品牌定位是什麼？** 工程師品牌用 .dev 很搭，設計師品牌用 .design，一般品牌用 .com 最安全。 先回答這些問題，再去搜尋域名。不要被域名帶著走。 ## 建議二：看續約價格，首年促銷是陷阱 這是我花了 $80 學到的教訓，所以我要再說一次。 幾乎所有的域名註冊商都會用首年促銷價吸引你。$0.99 的 .com 首年？續約 $15。$5 的 .ai 首年？續約 $80。$1 的 .io 首年？續約 $40。 買域名之前，永遠要做這三步： 1. **找到續約價格**：通常在結帳頁面的小字裡，或者在註冊商的定價頁面。 2. **計算十年總成本**：首年促銷價 + 續約價 x 9 年 = 你真正要付的錢。 3. **用 Cloudflare 比價**：Cloudflare 以成本價販售，沒有促銷也沒有加價。它的價格基本上就是市場底價。 域名不像 Netflix 訂閱——你不能用了一年覺得太貴就退掉。一旦你的域名被搜尋引擎索引、被別人收藏、被印在名片上，換域名的成本遠比續約費用高。 ## 建議三：決定了立刻買，搜尋本身就是風險 這個建議聽起來像衝動消費的藉口，但我是認真的。 域名市場有一個跟其他市場不同的特性：供給量永遠是一。全世界只有一個 yourname.com，沒有替代品、沒有平替、沒有第二選擇。 而你的搜尋行為可能會被追蹤。我不確定 bobochen.com 是不是因為我的搜尋被搶註的，但這個風險真實存在。有些域名監控服務會追蹤 WHOIS 查詢頻率，發現某個域名突然被大量搜尋時，會自動搶註。 我現在的做法： 1. **離線決定**：在搜尋之前，先在筆記裡列好候選域名清單。 2. **一次搜尋，立刻購買**：打開查詢頁面的同時，信用卡就準備好。搜完可以買就直接買。 3. **不要存起來改天再說**：「加入購物車明天再看」是域名市場最危險的行為。 4. **不要在社群上討論**：「大家覺得 bobochen.dev 好還是 bobochen.io 好？」——恭喜你，你剛剛公開告訴全世界你想要這兩個域名。 一個域名一年才十幾美金，犯錯的成本很低。但錯過的成本可能是永遠買不到。 ## 建議四：用 Cloudflare 統一管理，省錢又方便 我沒有收 Cloudflare 的業配費，但他們確實是我目前找到最好的域名管理方案。 **為什麼推薦 Cloudflare：** - **成本價販售**：不加任何 markup，是市場上最便宜的。 - **免費 DNS**：全球最快的 DNS 之一，免費使用。 - **免費 SSL**：不用另外買或設定 SSL 憑證。 - **免費 Email Routing**：自訂域名 email 轉寄，不用付 Google Workspace 的月費。 - **免費 DDoS 防護**：基本的安全防護內建在免費方案裡。 - **統一介面**：域名、DNS、SSL、CDN、email——全部在同一個 dashboard。 **唯一的缺點：** Cloudflare 支援的頂級域名比較少。一些比較冷門的 TLD 可能買不到。但主流的 .com、.dev、.io、.tw 都有支援。 如果你的域名不是在 Cloudflare 買的，也沒關係。你可以把 nameserver 指向 Cloudflare，享受免費 DNS 和其他功能。域名本身留在原本的註冊商，DNS 管理交給 Cloudflare。 ## 建議五：.com 不是唯一選擇 二十年前，一個網站如果不是 .com，會讓人覺得不夠正式。 2026 年，這個觀念已經過時了。 看看這些年成功的品牌： - GitHub 用的是 github.com，但他們的開發者文件在 docs.github.com。 - Vercel 用的是 vercel.com，但他們的部署預覽用 vercel.app。 - 很多獨立開發者用 .dev、.io、.me 建立了成功的個人品牌。 你的域名後綴不會決定你的品牌成敗。決定品牌成敗的是你在那個域名底下創造了什麼內容、提供了什麼價值。 每種 TLD 都有自己的調性： | TLD | 調性 | 年費參考 | | ---- | ---------------------- | -------- | | .com | 最通用、最經典 | ~$10 | | .dev | 開發者導向，強制 HTTPS | ~$10 | | .io | 科技新創常用 | ~$30-40 | | .tw | 台灣在地品牌 | ~$15-20 | | .me | 個人品牌 | ~$15 | | .ai | AI 相關，但貴 | ~$50-80 | 選一個你負擔得起、長期持有不心痛的就好。 --- ## 附錄：域名購買 Checklist 買域名之前，跑一次這份清單： **購買前：** - [ ] 確定品牌需求和目標受眾 - [ ] 列好候選域名清單（離線列，不要邊搜邊想） - [ ] 準備好信用卡，搜尋就要準備買 - [ ] 查詢候選域名的可用性 - [ ] 確認續約價格（不是首年價） - [ ] 計算十年總成本 - [ ] 在 Cloudflare 比價 **購買時：** - [ ] 五分鐘內決定，不要「明天再說」 - [ ] 用正確的 email 註冊（你會長期使用的信箱） - [ ] 開啟自動續約 - [ ] 開啟 WHOIS 隱私保護（大部分註冊商免費提供） **購買後：** - [ ] 設定 DNS（建議用 Cloudflare） - [ ] 設定 SSL 憑證 - [ ] 設定 Email Routing（如果需要自訂 email） - [ ] 規劃 subdomain 架構 - [ ] 把域名到期日記在行事曆 - [ ] 確認信用卡不會在續約前過期 **定期檢查（每半年）：** - [ ] 確認自動續約仍然開啟 - [ ] 確認綁定的信用卡仍然有效 - [ ] 確認註冊 email 仍然可以收信 - [ ] 檢查是否有不再使用的域名可以釋出 --- 這五篇寫下來，我把過去幾個月在域名上學到的所有教訓都整理了一遍。 回頭看，這些教訓都不是什麼高深的知識。看續約價、馬上買、選夠好的——每一條都是常識。但常識之所以叫常識，是因為大家都知道，但大家都不做。 包括我自己。 如果這個系列能幫你省下一些冤枉錢和時間，那我踩過的坑就不算白踩了。 bobochen.dev。 不是最完美的域名，但是最適合我的域名。域名個人品牌教訓