Day 16〈一個短網址，三種面貌：品牌短連結是被用戶推出來的〉 講第二種面貌的時候，我保留了自己的網域該怎麼接、中間會撞到什麼問題的細節，今天就要針對這個題目展開。

自訂網域，就是讓短連結從你自己的網域出發，形式是 go.yourname.com/abc，而背後的縮短、轉址、統計還是同一套。需要它的理由前面大致提過，名片和簡訊上出現什麼樣的名稱，感受上會有差別，而行銷簡訊要過白名單，實務上就是得用你自己專屬的網域。

設定 CNAME 的挑戰

要在 toui 上用自己原本就有的網域，要做的事比想像中少。先在 toui 後台輸入你要用的子網域，然後到你的網域服務商那裡加一條 CNAME 紀錄，把它指到我們給你的位置，回來按驗證，憑證簽好就生效了。整件事對你來說就是新增一條 DNS 紀錄，快的話幾分鐘就打完收工，我們也有一份五分鐘的設定指南可以照著做。會踩到的坑主要有兩個。一是你的網域如果掛在 Cloudflare 上，那條 CNAME 要設成 DNS only。二是有些 DNS 後台會把沒有結尾點的目標當成自家網域底下的相對名稱，在後面接上多餘的字串，驗證就一直過不了。真的踩到也不用緊張，回到後台按驗證，畫面會把現在查到的狀況和該怎麼改直接寫出來。

設定完成之後，這個網域就被賦予短網址的能力了。新建的短連結從它出發，而網域的根路徑，系統會準備一頁簡單的品牌首頁，讓好奇的訪客或做審核的人直接輸入網域時，知道這個地方是誰的。記得回後台把品牌資訊填好，那一頁就會顯示那些品牌資料。

至於對改 DNS 真的苦手，或本來就沒有自己網域的人，toui 也有完全不用碰 DNS 的做法，把想要的名字填進去送出，剩下的等系統處理，完成就能用，也就是 Day 16 說的第三種面貌。

上線前的兩次 522

你只需要設定 CNAME 就能串好自家網域，是因為其他複雜的工作 toui 都處理掉了。

自己的網域接上之後，有人點下 go.yourname.com/abc，這個請求得先走進 toui 的程式，查出短碼對應的目的地，再把人轉過去。我們要開發的，就是讓別人網域上的流量，正確走進我們的程式。

toui 的這端應用架構在 Cloudflare 之上，它是站在訪客與網站中間的網路，訪客的請求先到它遍布各地的節點，再由節點轉給後面真正提供內容的網站或服務。Cloudflare 把要轉去的目的叫 origin，通常是網站自己的主機；toui 不一樣，我們沒有主機，程式就直接跑在 Cloudflare 的節點上（Worker）。至於哪些網址的流量交給哪支程式，靠的是規則，我們當時寫的是 toui.io/*，意思是 toui.io 底下的所有路徑都歸這支程式。

上線前測試自訂網域，第一次就沒成功，回傳的錯誤碼是 522，意思是「節點連不到 origin」。可是 origin 就是我們的程式，當下覺得大概是程式哪裡出問題，找了半天才發現它根本沒有執行過。真正的問題出在前面那條規則。Cloudflare 把客戶網域的流量轉進來時，會保留客戶原本的網址，於是帶著 go.yourname.com 的請求對不上 toui.io/*，流量就靜默地跳過了程式。往後面找，又沒有任何一台主機對得上，Cloudflare 只能回報連不到 origin。既然從沒到過程式，log 裡自然一句錯誤訊息也沒有，而那個安靜，正是後來除錯時最重要的線索。

第二次我改用 Worker 的 Custom Domain 綁定，等於直接告訴 Cloudflare「這個網域整個交給這支程式」。結果還是 522，而且原因完全不同。這種綁定會自動建一筆 DNS 紀錄，指向 Cloudflare 自家的節點，於是替客戶轉發進來的流量又被指回節點，繞成一個迴圈。同一個錯誤碼，兩個成因，共通點只有一個，我對「流量會怎麼走到程式面前」的想像都是錯的。

後來怎麼解決？答案其實一直在官方文件裡。把 Worker 當 fallback origin，規則要用萬用寫法 */*，把「toui.io 底下的路徑歸我」放寬成「經過這裡的流量都歸我」，替客戶網域轉發進來的請求這才進得了程式。照文件調完就通了。

522 代表的是「邊緣連不到 origin」，當你自己就是 origin，看到 522 該問的不是「我的程式哪裡出錯」，而是「流量為什麼沒有過來」。中介層保留了什麼、轉發了什麼，不能靠假設，要先驗證請求真的有通，之後才是程式的部分。還有，記得好好讀文件。

這些坑踩過清除了，換來優雅的 CNAME 設定，也是值得。