Cloudflare 防護 WordPress | 桃園小聚 WP 安全性設定實戰心得

今天我去了桃園 WordPress 小聚，現場四位講者輪流上台，分別談用 Cloudflare 保護 WordPress、404 垃圾外鏈攻擊救援、惡意內部搜尋 SEO 防禦，最後我自己也上去分享一場 Astro × WordPress 的多人共管方案——這幾個議題加起來，幾乎涵蓋了一個 WordPress 站長最容易踩到的安全坑和維運痛點。

回程的路上整理筆記，發現前三場分享其實在講同一件事：WordPress 的安全不能只靠外掛，必須在外圍多疊一層。這篇就把現場聽到的內容和事後反思的細節寫下來。

從去年的海纜斷裂事件開始

第一位上台的是 科比主機的科比，他一開場就聊到去年 10 月 17 日的海纜斷裂事件。他說當天晚上開始陸續接到幾通電話，全部都是把網站放在海外主機的客戶——海纜一斷，他們的網站從台灣連線時整個卡住，只好緊急問他能不能搬到台灣主機。

數發部隔天澄清「對外連線正常」，但實際監控數據看起來不太一樣，晚上尖峰時段海外主機的 TTFB 拉到平常的好幾倍。這件事後來幫他爭取了不少新客戶，也把一個老問題重新攤開來：主機放台灣還是海外，要看你的客群在哪。客群在台灣，海纜斷裂時你還活著；客群在海外，台灣主機反而是受害者。

這個小故事其實帶出了當天分享的共同主題——既然這些站長服務的客戶大多在台灣，主機在台灣已經處理掉了「連線可用性」這一層，那後臺安全就是下一個必須補上的洞。

科比示範把網站從 A2 Hosting 搬回自家主機

科比現場直接示範整個搬遷流程，把自己一個示範用的網站從 A2 Hosting 搬到他們公司的代管平台。流程有一套標準做法：

1. 在原主機用 UpdraftPlus 打包整個站
2. 在新主機 cPanel 開一個全新的 WordPress，再用 UpdraftPlus 還原
3. 改本機的 hosts 檔，把網域指向新主機 IP 做測試

這邊有個小細節值得提：他特別說測試新主機時建議用 Firefox。因為新主機還沒設定 SSL 憑證，每次點擊不同頁面 Chrome 都會跳「不安全」警告，必須一直按確認；Firefox 在第一次允許之後就不會再煩你，整個測試流程順很多。

確認搬遷沒問題後，把 DNS 切到新主機，搬遷完成。科比接著進入真正想講的重點：保護後臺。

用 Cloudflare Zero Trust 鎖住 wp-admin

科比提到，WordPress 兩步驗證最常見的做法是裝外掛，但這做法有個結構問題——驗證邏輯跑在 WordPress 本身。萬一外掛本身有漏洞，或攻擊者找到方式繞過外掛載入流程，兩步驗證就形同虛設，從外部做驗證才是比較穩的方向。

Cloudflare Zero Trust 的 Access 服務剛好可以做這件事。

設定流程簡述如下：

1. 在 Cloudflare Dashboard 進入 Zero Trust → Access → Applications
2. 新增一個 Self-hosted application，網域填 yourdomain.com/wp-admin
3. 建立一條 Policy，設定允許的 Email 清單（要登入後臺的人）
4. 驗證方式選 Email OTP（一次性密碼會寄到指定信箱）

設定完之後，任何人想打開 wp-admin，都會先看到 Cloudflare 的 Email 驗證畫面。輸入信箱、收驗證碼、輸入驗證碼，才會看到 WordPress 的登入頁。對攻擊者來說，連 WordPress 的登入頁長什麼樣子都看不到，更別提暴力破解。

關於 Cloudflare Zero Trust 的詳細配置與權限規則，我之前在 Cloudflare Pages 預覽環境設定教學 那篇文章裡有完整說明，差別只是這次保護的對象從 Pages 預覽網址換成了 wp-admin。

但 Zero Trust 有個盲點：原始 IP 暴露時可以被繞過

到這邊看起來很完美，但科比特別停下來強調一個盲點：Cloudflare Zero Trust 只能保護「經過 Cloudflare」的流量。

如果攻擊者透過某種方式知道了你原始虛擬主機的 IP（這比想像中容易，例如歷史 DNS 紀錄、SSL 憑證透明日誌、舊的 mail server 紀錄都可能洩漏），他可以直接連到主機 IP，完全跳過 Cloudflare 這層。一連上去，wp-admin 直接顯示，Email OTP 那層根本沒啟動。

科比現場示範了一次：把 hosts 檔指向原主機 IP，瀏覽器直接打開後臺登入頁。Cloudflare 的保護完全沒在運作。

解法：用自訂 Header 鎖死「只接受來自 Cloudflare 的流量」

這是科比今天特別想分享的小技巧——在 Cloudflare 設一個自訂 Header，原主機只接受帶這個 Header 的請求。

做法是兩步：

第一步：在 Cloudflare 設 Transform Rule

進入網站設定的 Rules → Transform Rules → Modify Request Header，套用範圍選「所有傳入要求」，新增一條規則對所有請求加上一個自訂 Header。科比現場示範用的是：

標頭名稱：X-My-Secret
值：abc123xyz

實務上 值 要換成只有自己知道的長字串。

第二步：在原主機設 .htaccess

只放行帶這個 Header 的請求，其他全部 403。以 Apache 為例，在 .htaccess 開頭加上：

RewriteEngine On
RewriteCond %{HTTP:X-My-Secret} !^abc123xyz$
RewriteRule ^ - [F,L]

這樣即使攻擊者知道你的原始 IP、繞過 Cloudflare 直接連線，請求裡沒有那個 Header，主機會直接回 403——他連 WordPress 首頁都看不到，更別提繞過 Zero Trust。

當然這也不是 100% 安全的，世界上沒有絕對安全。如果攻擊者連 Cloudflare 帳號都拿到、能讀到 Transform Rule 設定，這層也守不住。但對於 99% 的自動化掃描和暴力嘗試，這已經把門檻拉得夠高。

勇哥分享：404 垃圾外鏈攻擊，排名一夕歸零

第二位上台的勇哥分享了一個我從沒看過的攻擊方式。他的客戶 3 月 28 日開始遭遇大量 404 請求——但這不是傳統的 DDoS，Apache 日誌裡看到的全是正常的 Googlebot、FB 爬蟲、AI 爬蟲。

攻擊者本身根本沒進到網站。他做的事情是：

1. 用「蜘蛛池」（黑帽 SEO 圈養 2000+ 個自有網站、用 AI 產生 10 萬篇文章的池子）大量產生指向受害網站的垃圾外連
2. 把連結到處灑——FB 社群、論壇、其他蜘蛛池網站
3. 連結指向的 URL 路徑是隨機產生的（26 字母 + 4 數字組合，可生成 20 幾萬條）
4. Google、Bing、AI 爬蟲跟著去爬這些連結，受害網站全部回 404

結果：Google Search Console 的「網頁未編入索引」數字從 4 萬條飆到 24 萬條，網站關鍵字排名直接歸零。

為什麼這種攻擊這麼難擋

從伺服器角度看，這些都是合法的搜尋引擎爬蟲，封掉它們等於把自己 SEO 也封了。從 Cloudflare 角度看，這也不是 DDoS，連請求量都沒爆。勇哥試過寫 .htaccess 規則對特定關鍵字（例如夾帶簡體字的 URL）回 410 Gone，告訴 Google 這頁永久消失別再來爬，但攻擊者用隨機字母組合可以產出 20 幾萬條 URL，根本寫不完規則。

勇哥的救援方式：放棄舊網域，301 全站搬家

勇哥試了快一個月才接受現實——舊網域已經被 Google 標記為低品質網站，救不回來了。他最後的處理是：

1. 把舊網站完整複製到新網域
2. 舊網域所有 URL 全部 301 轉址到新網域對應頁面
3. 等 Google 重新建立索引

從 4 月 18 日換網域，到 4 月 25 日今天，新網域的曝光數字已經慢慢回來了。客戶在崩潰 20 幾天之後，總算接受了這個方案。

一個重要提醒：不要做 404 → 301 轉首頁

勇哥提到客戶問過他能不能把所有 404 都 301 轉到首頁，「這樣 Google 不就看不到 404 了嗎？」這是錯的，Google 會把這種行為判定為 Soft 404，違反站長規範，反而拖累整站評分。404 就讓它好好回 404，這是正常的網路行為。

商業面：攻擊也要花錢

勇哥順便講了一個有趣的點。蜘蛛池本身要養 2000+ 網站、每天用 AI 產 10 萬篇文章、買全美 IP 段，成本很高；對你打 24 萬條連結也是要花錢。所以會被這種方式打的，通常都是仇家行業——博弈、貸款、當鋪這類，他們的對手會直接準備十個域名輪換，反正燒錢比賽看誰先撐不住。

Leo 分享：惡意內部搜尋 SEO 與 robots.txt 防禦

第三位 Leo 接著勇哥的話題，講了另一種更早出現、但同樣陰險的攻擊。

攻擊方式是針對 WordPress 的內部搜尋 URL（?s=xxx）。攻擊者在外部論壇、社群放大量連結，URL 結構是：

https://yourdomain.com/?s=賭博平台推薦
https://yourdomain.com/?s=色情主播直播
https://yourdomain.com/?s=網路博弈娛樂城

雖然搜尋結果頁通常設了 noindex，但 Google 還是要先把頁面爬過一次才知道。這會發生兩件事：

1. 浪費 Crawl Budget：Google 給每個網站每天的爬蟲配額有限，全被這些垃圾 URL 吃掉，正規文章反而沒被爬到
2. Google Search Console 的「未編入索引」報表異常飆高，看起來像被攻擊但又找不到原因

解法：直接在 robots.txt 擋下

Leo 示範的解法走 Yoast SEO 後臺：進階設定 → 檢索最佳化 → 啟用「防止檢索網站內部搜尋結果網址」。

Yoast 會自動在 robots.txt 加一條：

Disallow: /*?*s=*
Disallow: /search/*

爬蟲讀完 robots.txt 就不會再去爬這些 URL，從源頭斷掉問題；如果你的 Yoast 是從很舊版本升級上來的，這條規則可能不會自動寫入，這時候就直接編輯 robots.txt 手動加上去。

怎麼發現自己中招

定期看 Google Search Console 的「網頁未編入索引」報表。如果某天突然飆出一堆莫名其妙的關鍵字 URL，跟你的網站主題完全無關，幾乎可以確定是這種攻擊。

我的分享：用 astro-wp 做多人共同管理的 Astro × WordPress

第四場輪到我上台，主題接續這幾天在研究 Astro 改造的進度，講多人共同管理的 Astro × WordPress 方案——把 WordPress 留下來當後臺給非工程師同事上稿，前臺用 Astro 重建，省下 Docker、終端機這些對編輯不友善的環境。完整內容和簡報都收在那篇文章裡，這裡就不重複展開。

三場分享連起來看

回家路上想了一下，前三場安全主題其實有個共同的底層邏輯：

攻擊面	防禦做法	不能單靠的東西
後臺登入暴力破解	Cloudflare Zero Trust + 自訂 Header	WordPress 安全外掛
垃圾外鏈攻擊（外部到 404）	robots.txt + 410 規則 + 換網域	Cloudflare WAF
惡意內部搜尋（吃 Crawl Budget）	Yoast 設定 + robots.txt Disallow	noindex

每一招要有效，都得在 WordPress 之外多疊一層——Cloudflare、robots.txt、DNS 層面的設定。光靠外掛或 noindex 這種 WordPress 內部機制，碰到稍微有點手段的攻擊就破功。

另外勇哥提到的那個 AI 農場網站讓人印象很深：一天發 50+ 篇 AI 垃圾文，Google 還是穩穩收錄、文章一小時就上排名，能養四個整理草稿的員工。勇哥自己也說從頭到尾都認為那是垃圾內容，但它就是賺錢——SEO 圈的真實樣貌跟一般人想像的「優質內容自然會贏」差很遠。

---

有 WordPress 後臺保護或 SEO 攻擊救援的需求，歡迎聯絡我，或加入我的 LINE 官方帳號聊聊你的狀況。