18 10 月
簡述
收到 Cloudflare 轉寄的 DMCA 通知，最令人困惑的一點往往不是「我該不該反駁」，而是「反通知到底該寄給誰」。Cloudflare 在多數情境下不是內容的實際託管者，它只是把投訴轉送到真正能刪除內容的一方；只有在極少數內容確實存放在 Cloudflare 自有服務上的情況，Cloudflare 才會以託管服務供應者的身分進入 DMCA 反通知程序。寄錯對象，等於反通知從未在法律上生效，內容也不會進入恢復倒數。以下從 Cloudflare 的角色定位開始，逐層拆解反通知的收件對象、法律要件、實務操作與風險邊界。DMCA 反通知和申訴有什麼不同？選錯方式很慘
Cloudflare 不是主機，是多數 DMCA 混亂的起點
Cloudflare 的核心服務是內容傳遞網路與反向代理。訪客連線到使用 Cloudflare 的網站時，請求先經過 Cloudflare 的全球節點，再轉往由另一家託管商持有的原始伺服器。WHOIS 與 DNS 紀錄中出現 Cloudflare 的 IP，不代表內容存放在 Cloudflare 的硬碟裡。這個架構決定了後續所有反通知的流向：Cloudflare 收到有效的 DMCA 下架通知後，常規做法是將投訴轉寄給網站營運者與原始託管提供者，並向投訴人提供託管商的聯絡資訊，讓投訴人自行向真正有能力移除內容的一方追進。
這也解釋了為什麼許多收到「Cloudflare 轉寄 DMCA」的人會誤以為反通知要寄回 Cloudflare。Cloudflare 確實在某些投訴類別中提供「是否將報告分享給網站營運者、託管提供者或兩者」的選項，但那是投訴端的控制機制，不是反通知端的法定入口。反通知的收件對象，取決於內容的法律上「儲存位置」，而不是取決於誰寄出了那封轉寄郵件。
反通知寄給誰：三種情境的判斷路徑
情境一：Cloudflare 僅為 CDN／反向代理，內容託管於第三方主機
這是絕大多數網站的情況。Cloudflare 在官方說明中反覆強調，它無法移除未經其託管的內容，能做的只是將著作權投訴轉寄給網站營運者與託管提供者。在這種情境下，DMCA 反通知的法定收件對象是原始託管服務提供者的指定代理人，不是 Cloudflare。託管商可能是 AWS、SiteGround、GoDaddy、DigitalOcean、Linode 或區域型主機商，反通知必須寄到該託管商依 17 U.S.C. § 512(c)(2) 指定的代理人窗口。
如果將反通知寄給 Cloudflare，Cloudflare 並沒有法律義務將它當作 § 512(g) 的反通知來處理，因為它在此情境下不是「服務提供者」意義下的託管方。投訴人之所以能讓內容下架，是因為 Cloudflare 將通知轉給了託管商；反通知要逆轉這個效果，就必須回到同一個法律關係中，向託管商發出。換句話說，轉寄鏈的終點才是反通知的起點。
實務上最直接的作法，是從 Cloudflare 轉寄的投訴副本中找出原始託管商的聯絡資訊。Cloudflare 在處理有效通知後，通常會向投訴人提供託管商的聯絡窗口。如果手上只有 Cloudflare 的轉寄信，也可以透過 DNS 歷史紀錄、主機反向查詢或 Cloudflare 濫用表單流程中揭露的資訊，定位真正的託管商。找不到託管商，反通知就沒有合法的投遞對象，這是後續所有步驟的前提。
情境二：內容託管於 Cloudflare 自有基礎設施
Cloudflare 並非完全不可能成為託管方。當內容存放在 Cloudflare Stream、Cloudflare Pages、Cloudflare Workers、Workers KV 或 Cloudflare Images 時，Cloudflare 就該內容而言是實際的服務提供者，必須遵循 DMCA 的通知與取下程序，包含 § 512(g) 的反通知機制。在這種情況下，反通知的收件對象才是 Cloudflare 的指定代理人或法律部門。
Cloudflare 的公司地址與公開聯絡資訊為 101 Townsend Street, San Francisco, CA 94107，電話號碼為 +1-650-319-8930。在司法實務中，與 DMCA 相關的正式通信也曾出現 abuse@cloudflare.com、abusereply@cloudflare.com 與 dmca@cloudflare.com 等信箱。然而，Cloudflare 的主要濫用舉報入口是線上表單 abuse.cloudflare.com/dmca，且官方明確表示以電子郵件提交的投訴通常不會被處理，會收到自動回覆引導至表單。因此，即使對象是 Cloudflare，也不應理所當然地把反通知「寄到某個 email 就結束」，而要先確認 Cloudflare 在該具體服務中是否以託管方身分啟動了 § 512(g) 程序，再依其指定管道遞交。
情境三：Cloudflare 僅清除快取，內容仍存在於原始網站
Cloudflare 也會根據 17 U.S.C. § 512(b) 的有效通知，清除其快取中涉嫌侵權的內容。快取清除與內容下架是兩個不同的動作。快取被清除後，原始網站上的內容仍然存在，只是不再透過 Cloudflare 的快取節點被加速遞送。在這種情境下，反通知的對象依然是原始託管商；Cloudflare 的快取清除本身不是一個可以透過反通知「逆轉」的獨立取下決定，因為它回應的是快取層面的通知，而非 § 512(g) 的內容移除。
以下表格整理三種情境的收件對象與法律依據：
| 情境 | Cloudflare 的角色 | 反通知法定收件對象 | 主要法律條文 |
|---|---|---|---|
| 內容託管於第三方主機，Cloudflare 僅轉發投訴 | CDN／反向代理 | 原始託管服務提供者的指定代理人 | § 512(c)、§ 512(g) |
| 內容存放於 Cloudflare Stream／Pages／Workers／Images | 託管服務提供者 | Cloudflare 指定代理人／法律部門 | § 512(c)、§ 512(g) |
| 僅快取被清除，原始內容仍在第三方主機 | 快取服務提供者 | 原始託管服務提供者的指定代理人（快取清除本身不觸發 § 512(g)） | § 512(b)、§ 512(g) |
反通知的法律要件：寄對人之後，內容必須合格
收件對象正確，反通知還必須符合 17 U.S.C. § 512(g)(3) 的形式與實質要件，否則託管商沒有義務啟動恢復程序。以下是法定核心要素：
- 訂閱者的實體或電子簽名：簽名主體是被指控侵權的用戶或網站營運者，不是代理人隨意代簽。
- 識別被移除或停用的材料，以及其被移除前所在的位置：網址、頁面路徑、檔案名稱，足以讓託管商定位原本的內容。
- 在偽證罪處罰下聲明，有善意確信該材料是因錯誤或誤認而被移除或停用：這是反通知最核心的法律陳述，不是單純的「我覺得我沒有侵權」。
- 提供訂閱者的姓名、地址與電話號碼：使託管商與原投訴人能確認身分與聯繫方式。
- 聲明同意接受管轄：若訂閱者在美國境內，同意其地址所在聯邦地區法院的管轄；若在美國境外，則同意託管商所在地或可得發現託管商之任何司法地區的聯邦地區法院管轄。
上述要件不是建議清單，而是託管商判斷是否進入 § 512(g)(2) 程序的門檻。缺一項，反通知就可能被視為無效，內容不會進入 10 至 14 個工作日的恢復倒數。
從遞交到恢復：10 至 14 天的法律時鐘
有效的反通知遞交後，託管商必須將副本轉發給原投訴人，並告知對方：除非在 10 至 14 個工作日內對被指控的用戶提起訴訟，否則將恢復被移除的內容或停止停用。這個窗口的設計不是為了讓雙方「協商」，而是把舉證責任與行動成本轉回原投訴人身上：投訴人若真心認為內容侵權，必須在此期間向有管轄權的聯邦法院起訴，才能繼續阻止恢復。
對收到 Cloudflare 轉寄通知的網站營運者而言，這個時鐘只有在反通知送達正確的託管商時才開始走。寄給 Cloudflare 而 Cloudflare 不是託管方，時鐘不會啟動；寄給託管商但反通知缺少法定聲明，時鐘同樣不會啟動。這是「寄給誰」與「寄什麼」必須同時滿足的原因。
虛假反通知的代價：不是嚇唬人的條款
§ 512(g) 要求反通知中的陳述在偽證罪處罰下作出，這使虛假反通知同時暴露於刑事與民事風險。18 U.S.C. § 1621 的偽證罪規範的是明知不實而故意陳述；§ 512(f) 則允許因故意不實陳述而受損害的一方請求損害賠償，包含律師費。在台灣地區的法律脈絡中，著作權法第 90-11 條也規定，因故意或過失而不實通知或回復通知，致他人受損害者，負損害賠償責任。
這意味著反通知不是「先寄再說」的戰術工具。如果內容確實使用了他人著作、授權狀態不明，或投訴人並非毫無依據，遞交反通知反而可能把一個單純的下架爭議升級為跨境訴訟風險。特別是網站營運者位於美國境外時，反通知中的同意管轄條款可能被解釋為接受美國聯邦法院的管轄，後續訴訟送達與應訴成本會遠高於內容下架本身。反通知是一把有方向的工具：它保護善意被誤傷的人，但也讓輕率的陳述留下法律紀錄。
實務操作清單：把反通知送到對的地方
以下清單以「Cloudflare 僅轉發、原始託管商為第三方」為預設情境，這是絕大多數網站的真實狀態。
- 先確認 Cloudflare 的角色。檢查內容是否存放在 Cloudflare Stream、Pages、Workers、Workers KV 或 Images；若不是，Cloudflare 不是反通知的法定收件對象。
- 從轉寄通知中找出原始託管商。Cloudflare 轉寄的投訴副本通常包含託管商聯絡資訊，或可透過 DNS 歷史與濫用表單流程反向定位。
- 確認託管商的 DMCA 指定代理人窗口。大型託管商通常在網站底部或法律頁面設有「DMCA Agent」或「Copyright Infringement」入口，不要只寄到一般客服信箱。
- 以書面形式撰寫反通知，逐項對應 § 512(g)(3) 的五個要件，使用英文或託管商指定的語言，附上簽名與日期。
- 保留遞交證明。掛號郵件追蹤碼、電子郵件傳送紀錄、表單提交截圖，都是日後證明反通知已送達的依據。
- 監控 10 至 14 個工作日窗口。若原投訴人在此期間提起訴訟並通知託管商，恢復程序會中止；若沒有，託管商應恢復內容。
- 不要在反通知中承認任何未經確認的事實。反通知的聲明範圍應限於「善意確信移除係因錯誤或誤認」，不需要對著作權歸屬或合理使用做出超出必要的法律論斷。
常見問答
Cloudflare 轉寄的 DMCA 通知，可以直接回覆那封郵件當作反通知嗎？
不建議。Cloudflare 在多數情境下不是託管方，回覆轉寄郵件不會觸發 § 512(g) 的恢復程序。反通知應送達實際託管商的指定代理人；只有當內容託管於 Cloudflare 自有服務時，才依 Cloudflare 的指定管道處理。
把反通知寄到 abuse@cloudflare.com 或 dmca@cloudflare.com 會有效嗎？
這些信箱出現在部分司法文件與公開紀錄中，但 Cloudflare 的正式濫用流程以線上表單為主要入口，電子郵件投訴通常會收到自動回覆引導至表單。更重要的是，即使郵件送達 Cloudflare，若 Cloudflare 不是該內容的託管方，它也沒有法律義務以 § 512(g) 反通知來處理。
Cloudflare 說它「無法移除內容」，那它為什麼還能轉寄 DMCA 通知？
Cloudflare 的轉寄是協助著作權人把投訴送到有能力移除內容的一方，這不是法律義務下的「取下」，而是它所描述的濫用處理流程的一部分。轉寄本身不改變 Cloudflare 作為 CDN／反向代理的角色，也不使 Cloudflare 成為反通知的收件對象。
反通知寄出後，內容一定會在 10 到 14 天後恢復嗎？
不一定。恢復的前提是反通知有效送達託管商，且原投訴人未在期限內提起訴訟並通知託管商。如果託管商認定反通知缺少法定要件，或原投訴人及時起訴，恢復程序不會完成。
網站設在美國境外，反通知中的同意管轄條款會產生什麼後果？
若訂閱者在美國境外，§ 512(g)(3)(D) 要求同意接受「任何可得發現託管商之司法地區」的聯邦地區法院管轄。實務上這可能意味著必須在美國應訴，對境外網站營運者而言是顯著的法律風險，應在遞交前評估。
Cloudflare 的「重複侵權者政策」會因為反通知而改變嗎？
Cloudflare 依 § 512(i) 設有終止重複侵權者服務的政策。反通知處理的是單一內容的恢復，不會直接撤銷帳戶層級的重複侵權紀錄。如果同一個帳戶或網站持續收到投訴，反通知無法取代對重複侵權狀態的處理。
總結
「Cloudflare 收到 DMCA 轉寄，反通知寄給誰」的正確答案，取決於 Cloudflare 在該具體內容上是 CDN／反向代理，還是託管服務提供者。絕大多數情況下，Cloudflare 只是轉送者，反通知必須寄給原始託管商的 DMCA 指定代理人；只有內容存放於 Cloudflare Stream、Pages、Workers、Images 等自有服務時，Cloudflare 才是反通知的法定收件對象。寄對人只是第一步，反通知還必須包含 § 512(g)(3) 的簽名、內容識別、偽證罪聲明、聯絡資訊與同意管轄聲明，才能啟動 10 至 14 個工作日的恢復時鐘。寄錯對象或省略法定要件，反通知在法律上等於沒有發生。反通知的偽證罪與民事賠償風險，則要求每一次遞交都以事實確信為前提，而不是以拖延或戰術對抗為目的。我們何時以及如何使用DMCA 刪除通知來保護您的內容
作者簡介
林誠意，文字工作者與法律內容編輯，長期關注數位平台責任、著作權通知與取下程序，以及跨境內容治理的實務運作。文章以公開法律條文、平台官方文件與司法紀錄為主要依據，致力於把程序性法律問題寫成可操作的判斷路徑。
