www 的網址和不帶 www 的網址，之所以開啟同一個網站，是因為其中一個名字被一條 CNAME 記錄「轉接」到了另一個名字上——就像來電轉接：你撥打 A 號碼，電話其實被轉到 B 號碼去接聽。把 www、blog.公司.com、shop.公司.com 這些名字都轉接到同一個目標，最實在的好處是：日後換主機、換平台時，你往往只改一個地方，其餘名字自動跟著走，不必逐個去改、也少了「漏改一個、某個網址突然打不開」的風險。
這篇文章適合誰看？ ❓
如果你的公司有網站，又遇過下面任意一種情況，這篇值得花幾分鐘：納悶「www 和不帶 www 怎麼是同一個站」、想加一個 blog. 或 shop. 的子網域卻不知道怎麼指、或者有人要你「加一條 CNAME 記錄」而你不清楚那是什麼、動了會不會出事。如果你完全不碰這些，也不打算碰，可以放心跳過。
先說為什麼會有 CNAME 這種記錄
要明白 CNAME，先看它當初是為了解決什麼麻煩。互聯網上每台伺服器的真實身分，是一串數字位址（IP 位址）；DNS（網域名稱系統）就是互聯網的「電話簿」，專門把你好記的網域名稱翻譯成這串數字，訪客才找得到你的網站。
問題來了：一家公司常常有好幾個名字指向同一個網站或同一項服務——www.公司.com、blog.公司.com、shop.公司.com 等等。如果每一個名字都各自登記一串數字位址，那麼有朝一日這項服務搬了家、數字位址變了，你就得把每一個名字逐條翻出來改一遍，漏了哪一個，對應的網址就打不開。CNAME 記錄就是為了解決這個「改一處要追著改很多處」的麻煩而設計的：它不直接登記數字，而是把一個名字「轉接」到另一個正式名字上，讓這些名字都跟著這一個正式名字走。日後位址變了，只動那個正式名字一處，其餘轉接過來的名字自動跟隨。
把它想成電話裡的「來電轉接」
CNAME 最貼切的比喻是來電轉接：你撥打 A 號碼，電話被自動轉到 B 號碼、由 B 來接聽。CNAME 做的就是這件事——訪客在瀏覽器輸入一個名字，DNS 發現它是一條 CNAME，於是順著它去找被轉接到的那個正式名字，再由那個名字給出真正的位址。訪客全程無感，看到的還是原來那個網址。
一條 CNAME 記錄長什麼樣
在 DNS 後台真正填寫時，一條 CNAME 記錄其實就是簡單的幾欄，對應「哪個名字轉接到哪個目標」：
- 主機／名稱（Host / Name）：你要設定的那個別名，也就是「撥出去的號碼」，比如 www，或是一個子網域如 shop。不同後台這一欄可能叫 Host，也可能叫 Name。
- 值／指向目標（Value / Points to）：轉接到的那個正式名字，也就是「電話真正被接聽的地方」，比如 公司.com，或某個服務商給你的主機名稱如 shops.myshopify.com。這一欄在不同後台叫法不一，可能是 Value、Points to、Alias 或 Canonical name，指的都是同一件事。
- TTL：這條記錄可以被各地伺服器快取多久，以秒計；數字越小，日後改動生效越快，但查詢會略頻繁一些。
以 GoDaddy 後台為例，新增一條 CNAME 大致是這樣：新增記錄 → 類型選 CNAME → 名稱填別名（如 www）→ 值填目標主機（如 公司.com）→ 儲存。各家介面不同，但要填的就是上面這幾欄。還有兩條規則值得記住：主網域本身（很多後台寫成 @，即不帶任何前綴的「光禿禿」網域）一般不能用 CNAME；而且同一個名字上有了 CNAME，就不能再疊加別的記錄——這兩條其實是同一個道理。
www 和不帶 www，為什麼是同一個網站
這就是來電轉接最常見、也最貼近你那個問題的用法。通常的做法是：把 www.公司.com 用一條 CNAME 轉接到不帶 www 的主網域（公司.com）這個正式名字上，於是在瀏覽器輸入哪一個，最終都到同一個網站。反過來則不行：前面說的「主網域（@）一般不能用 CNAME」正是這個原因——這個位置得保留 DNS 運轉所需的基礎記錄，而 CNAME 又不能和別的記錄共存，所以主網域通常改用另一種記錄來指向位址。哪個名字能用 CNAME、哪個不能，正是交給維護方拿捏的地方。
blog.、shop. 這些子網域怎麼「指來指去」
同樣靠來電轉接，而這正是很多第三方服務對接你網域的方式。常見的幾種：商城開在 Shopify 上，它會讓你把 shop.公司.com 用一條 CNAME 轉接到它給的主機名稱（如 shops.myshopify.com）；客服系統、內容傳遞網路（CDN，幫你把圖片、頁面就近快取、加快開啟速度的服務）也大多用同樣的方式，給你一個它那邊的主機名稱讓你轉接過去。還有些服務會讓你加一條 CNAME，用來「驗證這個子網域確實歸你管」或把子網域接到它們的系統上。你只要照著把對應的子網域轉接到平台給的名字，訪客造訪你的子網域，就會被送到平台去接待；哪天平台升級、換了位址，由平台維護那個正式名字即可，你這邊的子網域照常運作，不用跟著改。
一個容易踩空的前提：記錄要填在對的地方
還有一點常被忽略：CNAME 只有填在你網域實際生效的那家 DNS 服務商那裡才管用——也就是你的名稱伺服器（Name Server）目前指向的那一家。如果名稱伺服器早就轉到了別處，你卻在原來的註冊商後台改記錄，改了也不會生效，白忙一場。對沒有專人盯著這些設定的企業來說，光是「知道該在哪兒改」本身就是省下的一份功夫。
A 記錄與 CNAME 的區別，別搞混
這兩種記錄最容易被搞混，但分工很清楚：A 記錄把一個名字直接指向真正的數字位址（名字 → 號碼）；CNAME 把一個名字轉接到另一個名字（名字 → 名字），再由那個名字去給出號碼。也因此同一個名字通常不能既是 A 又是 CNAME。什麼場合該用哪一種，可以看我們另一篇講 A 記錄與 CNAME 區別的文章。
5U Website 怎麼幫客戶管這件事
CNAME 屬於那種「設定對了沒人察覺、設定錯了某個網址或整個子網域打不開」的設定。在過去十多年裡，我們處理過大量搬站、上新子網域、對接第三方部落格與商城平台的場景。我們的做法是：動任何一條記錄前先記錄現狀、想清楚哪個名字應該是「正式名字」、評估改動會影響哪些網址，必要時分步執行，把「主站好好的、某個子網域卻打不開」這類各管一段的事故擋在前面。
把這件事交給我們
你不需要自己研究 CNAME 該怎麼填、哪個名字能用哪個不能——這正好是我們的日常工作。如果你的網站或某個子網域出現「時好時壞」「改了不生效」的怪現象，或者你打算上線一個新的 blog. / shop. 子網域，給 5U Website 寫一封電郵，我們通常會在一到兩個工作天內回覆。
最早發佈於：，最近一次編輯時間：
