CNAME 偽裝利用一條 DNS 記錄，讓第三方追蹤者看起來像第一方，繞過只認地址列網域的 Cookie 封鎖。
第三方 Cookie 封鎖機制都建立在同一個假設上：只要看一眼網域，就能分辨出它是第三方還是第一方。CNAME 偽裝在 DNS 這一層就打破了這個假設——早在瀏覽器有機會檢查任何 Cookie 之前。網站擁有者用一條 DNS CNAME 記錄，把自己的一個子網域（例如 metrics.example.com）指向某家追蹤公司的基礎設施，此後所有發往這個子網域的請求都會一路解析到追蹤者那邊——但在瀏覽器與任何 Cookie 政策眼中，它看起來仍然和 example.com 本身一模一樣。
重點整理
- CNAME 記錄能讓網站擁有者把自己的一個子網域，別名指向第三方追蹤者的網域，於是發往該子網域的請求由追蹤者處理，瀏覽器看到的卻仍是網站自己的主機名稱。
- 這套手法在設計上就繞過了第三方 Cookie 封鎖：由「子網域」設定的 Cookie，在瀏覽器的同站邏輯看來就是第一方 Cookie，因為你看到的主機名稱根本沒變過。
- 一項已發表的量測研究發現，超過 1,700 個網站用這種方式，總共偽裝了 50 多個不同的追蹤者，說明這是一種真實部署的規避手法，而非理論上的假設。
- 各瀏覽器的因應方式並不一致：Safari 的智慧型追蹤防護會把偵測到透過 CNAME 偽裝之回應所設定的 Cookie，有效期限制在 7 天以內；Brave 會自行解析 CNAME 鏈，拿真正的目的地跟自家的過濾清單比對；Firefox 內建的增強型追蹤保護並不會自行解析 CNAME，因此偽裝過的追蹤者若沒有像 uBlock Origin 這類擴充功能介入，就可能悄悄溜過去。
- 這是彈跳追蹤在 DNS 層面的「表親」：兩者利用的都是「這個網域看起來是誰」和「這個網域實際由誰控制」之間的落差，只是發生在技術堆疊的不同層級。
CNAME 偽裝到底是什麼
DNS 允許任何網域擁有者建立一條 CNAME（規範名稱）記錄，意思是「這個子網域其實只是那個網域的另一個名稱」。這本是一塊再普通不過、支撐日常運作的網際網路基礎設施——CDN、電子郵件服務商與 SaaS 平台一直都在用 CNAME，讓客戶的子網域可以直接指向共享基礎設施，客戶自己不必架設伺服器。
CNAME 偽裝把這套機制原封不動地挪用來做追蹤。某家追蹤服務商會要求客戶（網站擁有者）新建一個子網域——例如 stats.example.com 或 t.example.com——並把它的 CNAME 記錄指向自己的網域。從這一刻起：
- 你的瀏覽器請求
stats.example.com。 - DNS 解析悄悄把這次查詢轉到追蹤者的伺服器上。
- 回應——包括其中任何
Set-Cookie標頭——是從追蹤者那邊回傳的，但就瀏覽器的網址列與同源判斷而言，你自始至終都在跟example.com打交道。
追蹤者在瀏覽器能看到的任何地方都不會以獨立第三方網域的身分現身。它偽裝成了你正在造訪的網站的一個子網域，也就順理成章地繼承了這個網站的第一方信任。
CNAME 背後的 DNS 解析鏈
這套手法之所以能成立，靠的是 DNS 解析一個再平常不過的特性：一條 CNAME 可以指向另一個名稱，而那個名稱又能正常繼續解析下去，瀏覽器自始至終只在意它最初查詢的那個主機名稱。關於這一步解析本身如何進行、又為何自成一道重要的隱私界線，可參見我們關於 DNS 洩漏 的文章——CNAME 偽裝是一個不同的問題，但它利用的正是同一個解析步驟。
你可以親自為任何主機名稱查出這條鏈：
# 追蹤某個主機名稱完整的 CNAME 鏈
dig stats.example.com +trace
# 更簡短的寫法：只顯示規範名稱
dig CNAME stats.example.com +short
如果一個行銷或統計類子網域，透過 CNAME 解析到了一個你不認識的網域——一個屬於廣告技術或分析服務商、而非網站自己的網域——那就是偽裝的典型模式。安全研究人員已經具體記錄過這一點：一項經過同儕審查的量測研究發現，超過 1,700 個網站在用 CNAME 偽裝，把流量導向 50 多家不同的追蹤公司，證實這是一種正在被實際使用的技術，而非邊緣案例。
為什麼它能繞過第三方 Cookie 封鎖
第三方 Cookie 封鎖的原理，是比較瀏覽器網址列裡的網域和試圖設定或讀取 Cookie 的網域——不一致就封鎖。CNAME 偽裝從來不會製造這種不一致。你的瀏覽器解析並連線的主機名稱，不折不扣就是第一方網站的一個子網域，不管背後實際是哪家公司的伺服器在回應。在這個回應裡設定的 Cookie，按瀏覽器執行的每一條同站規則來看，都是第一方 Cookie。
這正是彈跳追蹤所利用的同一個結構性漏洞，只是走了另一條路：彈跳追蹤是透過重新導向，讓追蹤者自己的網域短暫變成第一方；而 CNAME 偽裝則是讓追蹤者以網站自己某個子網域的身分來回應。這兩種手法都完全不需要用到第三方 Cookie，所以一條專門為封鎖第三方 Cookie 而設計的規則，根本沒有能攔下它們的著力點。
瀏覽器與標準層面的因應
由於這種規避發生在 DNS 這一層，要修補它，瀏覽器就必須真的去解析這條鏈、查清楚究竟是誰在回應——而不能只看它拿到的那個主機名稱。
Safari 的智慧型追蹤防護（ITP）是主流瀏覽器中第一個因應方案。正如 WebKit 自己的〈CNAME Cloaking and Bounce Tracking Defense〉一文所述，ITP 能偵測到某個第三方正透過 CNAME 被偽裝，並把該回應中設定的 Cookie 有效期限制在 7 天——這正是 ITP 早已套用在 JavaScript 建立的 Cookie 上的同一道上限，堵上了追蹤者原本藉 CNAME 繞開的那個缺口。
Brave 則更進一步，會在決定是否放行請求之前，自行把這條鏈解析出來。Brave 的〈Fighting CNAME Trickery〉一文描述了它會拿兩個網址去比對自家的過濾清單：一個是原始請求的主機名稱，另一個是把 CNAME 解析出的規範網域代入之後的同一個請求。如果真正的目的地命中了已知追蹤者，Brave 會直接封鎖這個請求——它甚至不需要等到 Cookie 真正被設定。
相較之下，Firefox 的增強型追蹤保護並不會自行解析 CNAME 鏈；它的封鎖邏輯仰賴一份人工維護的追蹤網域清單，比對的是你看得到的那個主機名稱，而一個偽裝過的子網域根本不會出現在這份清單上。實際情況是，Firefox 使用者往往得靠擴充功能才能獲得 CNAME 反偽裝的保護——例如 uBlock Origin 就能自行解析這條鏈，再針對真正的目的地做過濾——而不是靠瀏覽器內建的防護本身。關於這種以清單為基礎的內建防護具體如何運作，可參見 MDN 對 Firefox 追蹤保護 的概述。
CNAME 偽裝與相關技術有何不同
| 技術 | 隱藏的是什麼 | 手法發生在哪個環節 |
|---|---|---|
| CNAME 偽裝 | 追蹤者的真實網域 | 對第一方子網域的 DNS 解析 |
| 彈跳／重新導向追蹤 | 追蹤者自己網域上短暫出現的第一方身分 | 瀏覽器內一次快速的重新導向 |
| DNS 洩漏（隱私問題，非追蹤手法） | 你選用的解析器，而非某個追蹤者的身分 | VPN／DNS 設定不當，導致查詢暴露給你的 ISP |
最後一列值得特別說清楚：DNS 洩漏 是一種把你自己的瀏覽行為暴露給 ISP 的隱私失誤；CNAME 偽裝則恰恰相反——是網站刻意利用 DNS，向你隱藏一個追蹤者的真實身分。兩者都發生在 DNS 這一層，但除此之外沒有任何相似之處。往更廣的範圍看，「單一技術訊號說明不了全部問題，所以系統得綜合多個訊號」這個道理，在網路那一側同樣成立：可參見網站如何偵測 VPN 與代理，了解那邊的偵測系統同樣得綜合多個較弱的訊號，而不是只憑一個主機名稱或 IP 就下結論。
常見問題
CNAME 偽裝違法，或違反瀏覽器政策嗎？
沒有任何法律禁止它，DNS 協定本身也沒有「偽裝」這個概念——CNAME 記錄就是普普通通的基礎設施。這對瀏覽器來說是一個政策與偵測層面的問題，而不是協定層面的違規：Safari 和 Brave 現在一旦偵測到 CNAME 偽裝的 Cookie，都會區別對待，而 DNS 標準本身沒有做出任何變動。
封鎖第三方 Cookie 能阻止 CNAME 偽裝嗎？
不能。這正是這種手法的整個意義所在——被偽裝的追蹤者所設定的 Cookie，按瀏覽器同站邏輯檢查的每一條規則來看都是第一方 Cookie，所以第三方 Cookie 封鎖根本不會被觸發。要擋下它，需要真正解析出 CNAME 鏈、查清楚目的地究竟由誰控制，這正是 Safari 和 Brave 正在做的事。
我怎麼知道自己造訪的網站在用 CNAME 偽裝？
看看頁面的網路請求都用了哪些子網域，然後用 dig CNAME <主機名稱> +short 解析它的 CNAME 鏈。如果一個看起來像行銷或分析用途的子網域，解析出來的卻是某家已知廣告技術或分析公司的網域，而不是網站自己的，那就是這個模式。像 uBlock Origin 這類自帶 DNS 解析能力的擴充功能，會對每個請求自動做這項檢查。
VPN 或 DNS over HTTPS 能防住 CNAME 偽裝嗎？
不能直接防住。加密或改道你自己的 DNS 查詢，保護的是誰能看到你的查詢——參見我們關於 DNS 洩漏防護 的指南——但這並不會改變網站擁有者為自己的子網域設定了什麼。CNAME 偽裝是由網站那一方決定的，不是你的網路路徑決定的，所以只能靠瀏覽器（或擴充功能）去檢查解析鏈本身，而不是靠強化你自己的 DNS。不過，你自己這一側的 DNS 狀況仍然值得單獨查一查——我們的 VPN 與 DNS 洩漏檢測 能看出你的 VPN 是否真的在替你保密 DNS 查詢，而這正是你能掌控的那一部分。
總結
CNAME 偽裝之所以奏效，是因為 DNS 和 Cookie 政策運作在兩個原本就不打算互相核對的層級上：瀏覽器信任自己解析出的主機名稱，而 Cookie 規則又信任瀏覽器對「第一方」的判斷。把追蹤者的回應透過一個別名子網域轉一手，就能讓這兩道檢查都順利通過，實質上卻沒有任何東西真正屬於第一方。Safari 與 Brave 已經透過在做判斷前先解析出真正的目的地，補上了這個缺口；Firefox 則仍仰賴擴充功能來做同樣的事。和本站介紹的每一項技術一樣，誠實的結論是：沒有哪一條單一規則——封鎖第三方 Cookie、加密自己的 DNS，或僅憑主機名稱就下判斷——能擋住追蹤者偽裝自己的每一種方式。
推薦閱讀：
