WordPress 網站安全防護實戰：Wordfence 防火牆、掃描、雙因素認證完整設定教學
Wordfence 是一款跑在你網站主機上的端點（endpoint）資安外掛，免費版就涵蓋防火牆、惡意程式碼掃描、兩階段驗證、reCAPTCHA 與即時流量監測，WordPress…
Wordfence 設定教學：把 WordPress 端點資安外掛調成不傷主機的配置
Wordfence 是一款跑在你網站主機上的端點（endpoint）資安外掛，免費版就涵蓋防火牆、惡意程式碼掃描、兩階段驗證、reCAPTCHA 與即時流量監測，WordPress.org 上累積數百萬次活躍安裝，長年穩居資安類外掛前列 [來源：〈Wordfence Security – Firewall & Malware Scan〉〈https://tw.wordpress.org/plugins/wordfence/〉〈2026-06-29〉]。它的真正價值在於照主機型態把掃描靈敏度、流量紀錄模式、學習模式調對，單純裝起來只完成了第一半。設定錯誤的 Wordfence，比沒裝更容易拖垮網站。
重點先看：Wordfence 免費版四項核心功能齊備，付費版差在威脅情報即時更新；共享主機把掃描維持標準、流量紀錄設成 Security Only，就能避開絕大多數的 CPU 超載與主機商停權風險，這也是 Wordfence 官方文件建議的共享主機配置方向。
WordPress 是全世界使用最廣的內容管理系統，市占大也代表攻擊面大。自動化掃描機器人每天對全球 WordPress 站台進行地毯式掃描，尋找未更新的外掛、預設登入網址、弱密碼帳號。Wordfence 這類端點防護之所以長年必裝，是因為它能直接在網站層攔截這些機器人請求，把攻擊擋在進入應用程式之前 [來源：〈W3Techs — Usage Statistics and Market Share of WordPress〉〈https://w3techs.com/technologies/details/cm-wordpress〉〈2026-06-29〉]。
Wordfence 的防護範圍與架構定位
Wordfence 是一款端點式 WordPress 安全外掛，在WordPress 架站與 SEO 全攻略的資安環節裡幾乎是必裝清單，跟多數只在雲端擋流量的服務不同，它直接在你的伺服器上攔截並檢查每一個請求。這代表它不會被繞過，防護更深入，但相對的，所有防火牆運算與檔案掃描消耗的 CPU、記憶體都來自你自己的主機。後面每一項設定，都建立在這個架構特性之上。
免費版即涵蓋四件事：網站防火牆（WAF）、惡意程式碼掃描、登入強化（2FA、reCAPTCHA、暴力破解防護）、Live Traffic 流量監測。Premium 付費版的功能項目大致相同，差別集中在威脅情報的即時性，包括 IP 黑名單、防火牆規則、惡意軟體簽名的更新頻率；免費版的更新會延遲，但對多數中小型網站已足夠，詳細差異可比照 Wordfence 官方功能比較頁。付費版採年費制，實際金額以官網公告為準。
Wordfence 的定位是「一套打完」的綜合型工具，兼具防火牆、掃描與登入強化。把它跟只在雲端清洗流量的 Sucuri 相比，兩者是端點防護與雲端防護兩種架構，比較的應該是架構取向，功能多寡反而是次要。要不要選它、各項設定的鬆緊，都跟主機型態綁在一起；如果你還在挑主機，可以從共享主機 VPS 雲端主機類型比較著手。
端點防火牆 vs 雲端防火牆：架構差異一次看懂
| 維度 | 端點防火牆（Wordfence） | 雲端防火牆（Sucuri 等） |
|---|---|---|
| 攔截位置 | 網站主機層 | 流量進站前的 CDN 層 |
| 資源消耗 | 吃主機 CPU 與記憶體 | 不消耗站方主機資源 |
| 檔案層掃描 | 支援，深入主題外掛與核心 | 偏雲端監控，檔案層較淺 |
| 繞過風險 | 在網站層攔截，難被繞過 | 清洗後流量才進主機 |
| 適合場景 | 自有主機資源充足 | 共享主機或需雲端層清洗 |
架構決定資源代價。端點防火牆看得更深，能讀到網站實際的檔案內容、比對核心檔案的雜湊值、檢查資料庫裡的使用者資料表是否被植入後門帳號，這些都是雲端層做不到的事；代價是消耗站方主機的 CPU 與記憶體。雲端防火牆反過來，流量還沒進到主機就被過濾，主機完全不用付出運算成本，這對資源極度受限的共享主機是很實際的省力選擇。該選哪一邊，取決於你的主機能扛多少。
WordPress 站台面對的主要攻擊樣態
理解 Wordfence 每一項設定在擋什麼，要先知道 WordPress 站台實際面對的攻擊樣態。攻擊者鮮少從零開始手動破解一個網站，多數是自動化腳本對大量站台進行掃描與嘗試。發生頻率最高的威脅集中在四類：登入頁暴力破解與密碼噴灑，機器人對 wp-login.php 反覆嘗試常見密碼或拿外洩帳密清單逐站噴灑，Wordfence 的 Brute Force Protection 與 2FA 直接對應這類攻擊；已知外掛漏洞利用，外掛或主題未更新時攻擊者透過公開的 CVE 或 RCE 漏洞寫入檔案或執行指令，由 WAF 規則庫與檔案掃描負責攔截偵測；SEO 垃圾與藥品連結注入，入侵後在文章或資料庫植入隱藏的垃圾連結、日文或外文關鍵字來劫持搜尋流量，靠檔案與資料庫掃描發現；以及惡意重定向與信用卡側錄，在佈景或外掛植入腳本把行動訪客導到釣魚站、或在前台結帳頁側錄信用卡，檔案層掃描與 WAF 規則是主要防線。Wordfence 的功能區塊幾乎是對著這四類威脅設計的，看懂對應關係，調設定時才知道每一項在守住哪一層。
安裝前的前置準備
從 WordPress 後台「安裝外掛」搜尋 Wordfence、安裝並啟用即可，過程跟裝任何外掛一樣。但啟用前有幾項準備必須先做好，否則裝了等於半裝：留對通知信箱、先做備份、確認主機型態。這幾項決定了 Wordfence 之後能不能正常通知你、會不會改寫出問題、以及掃描要開到多靈敏。
信箱務必填會收的。Wordfence 偵測到問題時靠 Email 通知，填錯等於裝了沒用。尤其它會在網站被密集攻擊、掃描出惡意程式碼時發信，這些都是不能漏的警訊。如果你還不熟悉外掛安裝流程，可以先看WordPress 外掛安裝三種方法或WordPress 必裝外掛完整清單建立基本概念。
啟用前一定要備份。Wordfence 防火牆在配置過程會改寫.htaccess 檔案，主機類型不同還可能需要下載額外設定檔。改寫失敗或設定衝突時，備份是你唯一的安全網；還沒建立備份習慣的話，可以先跑一次WordPress 備份與還原完整流程。
啟用後 Wordfence 會自動導向 Dashboard 儀表板，所有資安功能都集中在這裡。沒自動導向的話，手動走 Wordfence > Dashboard 也會到。還有一個常被跳過的前置動作：啟用前先把所有外掛與佈景主題更新到最新版本。Wordfence 是在現有環境上做防護，網站本身若已佈滿未修補的漏洞，再怎麼調設定也只能擋一部分。更新之後再做一次完整備份，這份備份就是裝 Wordfence、配置防火牆過程出問題時的還原基準。另外建議開啟外掛自動更新，資安外掛的規則越新越安全。
配置網站防火牆與 Learning Mode 的正確用法
Wordfence 防火牆預設先跑一週的 Learning Mode（學習模式），觀察你網站的正常行為，期滿自動切換成 Enabled and Protecting 正式啟用。這段學習期不是裝飾，它的作用是讓防火牆學會你網站的合法操作，避免正式啟用後誤擋正常訪客或外掛。
多數教學會跟你說「裝了就安全」，但沒告訴你 Learning Mode 期間網站其實還沒有真正被保護。只有一種情況該跳過學習期：網站已經遭到攻擊、需要立刻防護。這時直接切 Enabled and Protecting，否則掃毒完還是會繼續挨打。沒有急迫狀況，就讓它乖乖學一週。
實際配置時，進入 Wordfence > Firewall 後它會自動偵測最適合的伺服器類型，沒特殊需求別硬改。接著 Wordfence 會要求下載.htaccess 備份，因為它要改寫這個檔案才能攔截流量，主機類型不同還可能多一份檔案要下載。確認下載完成後點擊配置，防火牆就進入 Learning Mode 開始學習你網站的正常行為，一週後自動轉成 Enabled and Protecting，真正開始攔截惡意請求。
這裡有個容易忽略的點：.htaccess 改寫之後，如果你的網站有用到301 與 302 轉址設定或永久連結 SEO 設定，改寫後建議回頭確認轉址與網址結構沒被影響。改寫前下載的備份，就是為了這種時候還原用。
Learning Mode 的設計很合理，但它也讓「剛裝好」這件事產生一種安全的錯覺。曾發生站長裝完就以為沒事，結果第一週正好碰到密碼噴灑攻擊，學習模式沒能及時擋下的情況。所以裝完後真正該盯的是學習期結束後的頭幾天，看 Live Traffic 有沒有攔下東西。
若要在學習期內就取得實際防護，可以縮短學習時間。Wordfence 允許手動提前結束 Learning Mode，把 Firewall Status 切到 Enabled and Protecting。這麼做的前提是網站流量結構穩定、外掛行為已經固定，否則太早啟用可能誤擋表單提交、第三方 API 回呼、或電子商務金流通知這類正常但模式特殊的請求。穩妥的做法是讓學習期完整跑滿，再觀察啟用後 24 到 48 小時的 Live Traffic，確認沒有大量誤擋再正式上線。
掃描靈敏度與主機負載的取捨
預設的 Standard Scan（標準掃描）對大多數網站就夠用；High Sensitivity（高靈敏度）掃得更全面，但會大幅吃主機 CPU，共享主機尤其容易拖慢網站或被主機商警告。除非你正面臨明確的資安事件，否則別輕易調高。
掃描範圍涵蓋主題、外掛、WordPress 核心檔案是否被竄改，以及留言評論裡的可疑連結。Wordfence 是端點掃描，所有運算都在你的主機上跑，主機資源直接決定你能開到多靈敏。這也是為什麼掃描等級這件事不能脫離主機型態單獨談。對共享主機來說，資源本就有限，開高靈敏掃描等同把 CPU 額度用光，Wordfence 官方掃描文件也提醒共享主機應優先採用 Standard 等級。
| 掃描等級 | 覆蓋範圍 | 主機負載 | 建議主機型態 |
|---|---|---|---|
| Standard（標準） | 核心、主題、外掛、留言連結 | 低 | 共享主機、小型網站 |
| High Sensitivity（高靈敏） | 更全面的檔案與行為比對 | 高 | VPS、雲端主機 |
掃描結果會分級提示。升級提醒屬於黃色，表示外掛或主題有新版可更新，這時可順手把常見 SEO 地雷或過時外掛一起清掉；紅色高危警告通常是不明檔案或惡意程式碼，建議直接刪除。確認沒問題的項目可點 Mark as Fixed 歸檔，避免通知一直跳。掃描這件事建議排程在離峰時段跑，避免跟訪客流量搶資源，這跟做網站快取設定或網站速度優化是同一個邏輯，都是為了不讓背景任務拖垮前台。
如果你發現裝了 Wordfence 之後網站變慢，第一個該檢查的對象是掃描等級被開到多高。回到 Scan > Manage Scan，確認是 Standard；同時檢查 Live Traffic 是不是被誤開成 All Traffic。這兩個是網站變慢最常見的元凶，相關排查可參考網站變慢的速度瓶頸診斷。
掃描排程的設定藏在 Scan > Manage Scan 的 Schedule 欄位。共享主機建議設成一天一次，排在凌晨訪客最少的時段，例如當地時間三到五點。VPS 或雲端主機資源寬裕，可以設成一天兩次，白天一次輕掃、夜間一次完整掃描。掃描頻率越高、抓到惡意程式碼的時間差越短，但要對應付出更多 CPU 成本，這個取捨直接由主機型態決定。
掃描結果的判讀與處理
Wordfence 掃描完會把發現分成幾種顏色與類型，看懂分類才知道該怎麼動手。判讀的重點是把「需要立刻處理」與「只是提醒」分開，避免被一大堆通知嚇到亂刪檔案。
| 等級 | 代表意義 | 處理方式 |
|---|---|---|
| 紅色（Critical） | 惡意程式碼、後門、不明執行檔 | 優先處理，依刪除或修復選項動作，刪除前確認非合法外掛的一部分 |
| 黃色（Warning） | 外掛或主題有新版、核心檔案與官方版本不符 | 多半該更新或還原，不一定是被入侵 |
| 藍色（Info） | 留言或文章出現可疑連結、或已知會被濫用的函式 | 檢查是否自己放置，非預期則移除 |
| 已忽略（Ignored） | 先前選擇忽略的項目 | 定期清理，避免真出問題時被埋在忽略堆裡 |
一個容易誤判的情境：自行修改過 WordPress 核心檔案或佈景，掃描會把它標成「與官方版本不符」。這不代表被入侵，但這類自訂修改本身就是資安與維護的風險來源，正確做法是用子主題（child theme）或外掛掛鉤來客製化，不要直接改核心檔案。看到核心檔案不符的警告，第一時間確認你有沒有手改過，再決定是還原官方版本還是忽略。
Live Traffic 不要開成 All Traffic
用預設的 Security Only 就好，它只記錄與安全相關的流量，包含登入、被防火牆擋下的請求、被封鎖的 IP。All Traffic 會記錄幾乎所有訪客行為，資訊量大但極耗主機資源，除非你在除錯特定問題，否則不建議長開。
Security Only 是效率與安全的平衡點，也是 Wordfence 官方預設值。它的設計邏輯是：站長需要知道的是「誰在攻擊我」，這屬於資安需求；至於「每個訪客點了哪個連結」屬於分析需求，兩者本來就該用不同工具。如果你真的需要分析全部流量，那應該用 Google Analytics 或 Site Kit by Google 這類分析工具，把資安外掛當分析器用會浪費主機資源。
| 模式 | 記錄內容 | 主機負載 | 適用情境 |
|---|---|---|---|
| Security Only | 登入、封鎖請求、惡意 IP | 低 | 日常防護，官方預設 |
| All Traffic | 幾乎所有訪客行為 | 高 | 短期除錯，用完即切回 |
Live Traffic 會列出登入數據、被封鎖請求、訪客 IP，是判斷網站是否正在被攻擊的即時窗口；若是流量整體下滑而非被攻擊，那屬於流量下滑恢復或排名下滑急救的範疇，跟資安是兩回事。看到同一個 IP 短時間內連續觸發登入失敗，那多半是密碼噴灑或暴力破解，搭配 IP 封鎖器可手動擋掉。但封鎖前先確認不是誤判自己的固定 IP，否則會把自己鎖在外面。這也是前面強調要先確認主機型態與固定 IP 的原因。
共享主機上長開 All Traffic 是網站變慢的常見元凶之一。每一個請求都要寫進資料庫，訪客一多就直接把 I/O 吃滿。要記住，Wordfence 是端點式，它記錄流量的代價是吃你主機的資源，不是雲端的。如果你還在跟CDN 內容傳遞網路或Core Web Vitals 效能指標奮鬥，先把這項切回 Security Only。
讀 Live Traffic 列表有幾個訊號值得留意。短時間內大量來自同一個 IP 段的 404 錯誤，通常是掃描機器人在找已知漏洞路徑，例如 wp-config.php 備份檔、phpinfo 頁面、舊版外掛的測試檔。Wordfence WAF 通常會自動封鎖，但若看到一堆 404 卻沒被封，代表這些請求還沒觸發規則，可以手動把該 IP 段加進封鎖清單。另一個訊號是來自陌生國家、且集中在登入頁的 POST 請求，這幾乎可以判定為密碼噴灑攻擊。
兩階段驗證與 reCAPTCHA：把登入頁鎖緊
2FA 用 Google Authenticator 掃 QR Code、記下 5 組備用還原碼、輸入動態碼三步完成；reCAPTCHA 則到 Google 申請 v3 憑證，把金鑰貼回 Wordfence 即可。兩者都要先把備用還原碼與白名單 IP 設好，才不會把手機弄丟就被鎖死在後台外面。
- 用 Google Authenticator 掃描 Wordfence 提供的 QR Code 完成綁定。
- 下載並妥善保存 5 組單次備用還原碼，這是手機遺失時的唯一救援管道。
- 輸入 APP 當下顯示的動態碼，驗證綁定成功。
- 常在固定地點作業，就把該 IP 加入白名單，省去每次雙重認證。
reCAPTCHA v3 採分數制，依使用者在網站上的行為評分，分數過低會被判定為機器人，使用者不需要解任何謎題，詳細機制可見 Google reCAPTCHA 官方說明 [來源：〈reCAPTCHA v3〉〈https://developers.google.com/recaptcha/docs/v3〉〈2026-06-29〉]。申請憑證時要選 v3 Admin Console，不是 Get Started，否則會走進付費方案流程。拿到網站金鑰與密碼後，分別貼回 Wordfence 的 reCAPTCHA 欄位並儲存即可。這段流程跟SSL 憑證安裝、HTTP 升級 HTTPS 一樣，都是要跟第三方服務串接，金鑰貼錯就失效。
Wordfence 同時提供暴力破解防護，可設定幾次登入失敗就封鎖該 IP。實務上調到 5 次左右夠用，太低會誤鎖忘記密碼的正常使用者，太高又等於沒設。登入頁是攻擊者最愛打的入口，除了 Wordfence 的防護，也可以搭配隱藏登入網址做第一層遮蔽。
2FA 啟用之後，所有管理員與編輯等級帳號都建議綁定，不要只有站長一人開。一個網站的資安強度取決於最弱的那個帳號，只要有一個管理員帳號沒開 2FA、又用了外洩密碼，攻擊者就會從那裡進來。綁定前先把每個帳號的備用還原碼各自存好，最好存在密碼管理器或離線的加密檔案裡，不要寄在自己收得到信的信箱，因為信箱被盜同時會連還原碼一起丟失。
Brute Force 參數的合理設定
Brute Force Protection 不只是「幾次失敗封鎖」一個數字，它背後還有時間窗與封鎖時長兩個參數，三者一起決定防護的嚴格程度。理解三者關係，才能調出既擋得住機器人、又不會誤殺正常使用者的設定。
| 參數 | 預設行為 | 建議值 | 說明 |
|---|---|---|---|
| 登入失敗次數 | 偏高 | 5 次 | 太低誤鎖真實使用者，太高擋不住噴灑 |
| 計算時間窗 | 預設 | 4 小時 | 機器人常在短時間集中嘗試 |
| 封鎖時長 | 預設 | 4 小時以上 | 太短封鎖完又可重試，太長佔封鎖清單 |
| 記住登入裝置 | 視外掛而定 | 開啟 | 降低 2FA 對合法使用者的摩擦 |
調這組參數的原則是「讓機器人累積失敗的速度快於真人」。機器人通常在幾分鐘內嘗試幾十到幾百次，5 次的門檻會在它還沒試完一輪就把它封掉；真人就算忘記密碼，多半試兩三次就會去重設，不太會在 4 小時內連續失敗 5 次。如果你的網站有大量內部人員共同登入，可以把失敗次數稍微放寬到 7 到 8 次，並把封鎖時長縮短，平衡安全性與可用性。
All Options 裡真正值得動手的幾個開關
大多數設定維持預設即可，真正值得手動調的集中在通知與門檻兩類。通知類以 Email Alert Preferences 為主：改成只在新設備或新位置登入時觸發，多帳號共用的網站尤其要調，否則信箱會被登入通知塞爆；掃描通知級別則從 Low 調到 Medium，太低會漏重要警訊，太高會被雜訊淹沒。門檻類指的是 Brute Force Protection 的登入失敗次數，預設偏高，調到 5 次能在被攻擊與誤鎖正常使用者間取得平衡。另外 Basic Scan Type 一旦設定就會成為之後掃描的預設值，改之前先確認主機能負荷。調完務必儲存才生效。
原則很簡單：不確定用法的設定就不要動。Wordfence 的預設值經過大量實戰調校，多數網站直接用就好。會去動 All Options，通常是因為遇到具體問題，例如通知信太多、被攻擊頻率改變、主機資源吃緊。代管多個網站的接案工程師，這幾項調整幾乎是每個站都會做的標準動作；相關的維運成本可參考網站維護費用與委外評估。
另一個值得檢查的區塊是「如何封鎖 IP」與「如何計算攻擊者」這兩組設定。Wordfence 預設會把共用同一個 IP 來源的重複攻擊者自動累積封鎖，封鎖時間會隨次數遞增。這個機制不需要手動介入，但要知道它存在，因為偶爾會發生辦公室共用 IP 被某個同事連續打錯密碼而整段被封的情況。被封鎖時可以從 Wordfence > Blocking 清單手動解封，或把辦公室固定 IP 加入 Allowlist 白名單，從此不再受 Brute Force 規則限制。
Wordfence vs Sucuri 與資安外掛共存的真相
建議只裝一套資安外掛就好。兩套同時裝會因防火牆規則重複、IP 封鎖邏輯衝突、掃描資源疊加而互相打架。Wordfence 走端點防護，Sucuri 偏雲端防護，選擇的關鍵是你的主機型態與是否需要雲端層的清洗。
| 比較項目 | Wordfence | Sucuri |
|---|---|---|
| 防護架構 | 端點防護，主機層攔截 | 雲端 WAF，CDN 層清洗 |
| 主機資源 | 消耗站方 CPU 與記憶體 | 不消耗站方資源 |
| 檔案層掃描 | 深入主題外掛與核心 | 偏監控與清理服務 |
| 技術門檻 | 較高，端點防護＋檔案掃描 | 較低，雲端代管 |
| 適合主機 | 自有主機、資源充足 | 共享主機、需雲端清洗 |
Wordfence 的強項是端點防火牆加上檔案層惡意程式碼掃描，這是其他單純提醒型外掛難以比擬的技術門檻。Sucuri 的定位偏向雲端 WAF 加網站監控與清理服務，根據 Sucuri 官方產品說明，它在流量進到主機前就先完成清洗。兩者防護層不同，各自守住不同位置：主機資源吃緊又想要雲端層防護，可考慮雲端方案；自有主機資源充足，Wordfence 的端點方案看得更深入。
若同時有登入強化需求，Wordfence 的 2FA 加 reCAPTCHA 已經涵蓋，不必再疊登入專用外掛；垃圾留言則是另一個獨立問題，可參考Akismet 垃圾留言防護。資安外掛與 SEO 外掛職責不同、可以並存，但資安外掛彼此不要疊。
資安外掛選擇決策矩陣
到底該裝 Wordfence、付費 Wordfence、還是改走雲端 WAF？把「主機型態」與「即時防護需求」兩個維度擺在一起，決策會清楚很多。以下矩陣把常見情境對應到最合適的選擇，再依預算做最後收斂。
| 主機型態 | 即時防護需求 | 建議方案 | 理由 |
|---|---|---|---|
| 共享主機 | 低（內容站、部落格） | Wordfence 免費 | 資源有限，標準設定即可 |
| 共享主機 | 高（電商、會員站） | 雲端 WAF | 端點掃描會吃光 CPU，改在雲端攔截 |
| VPS / 雲端主機 | 中 | Wordfence 免費 | 資源充足，端點防護看得深 |
| VPS / 雲端主機 | 高（金流、個資） | Wordfence Premium | 即時威脅情報更新，補上時間差 |
| 高流量站 | 高 | 雲端 WAF ＋ 端點 | 雲端擋流量洪峰，端點做檔案層清理 |
矩陣裡的「即時防護需求」可以用一個簡單的標準判斷：網站是否處理金流、會員個資、或業務關鍵的表單提交。處理這類敏感資料的網站，被入侵的代價遠高於外掛費用，值得為即時威脅情報付費。純內容發佈的部落格或品牌形象站，延遲幾小時拿到規則更新造成的實際風險有限，免費版就足以應付日常防護。
共享主機與效能：把 Wordfence 調成不拖垮網站的配置
共享主機是 Wordfence 設定最容易翻車的場景。CPU 與記憶體資源有限，高負載掃描或 All Traffic 監測很容易觸發主機商的資源限制，輕則網站變慢，重則被主機商暫停服務。把掃描維持 Standard、流量紀錄設成 Security Only、掃描排程在離峰時段，這三項就能避開絕大多數問題。
同一套 Wordfence，在共享主機上要保守，在 VPS 或雲端主機上才有餘裕開高靈敏。前面反覆強調主機型態，原因就在這裡。如果你正準備從共享主機升級，搬家前別忘了備份，FTP 操作在這階段也常用到。
Wordfence 的設定沒辦法脫離主機型態單獨談。資安外掛穩下來，接下來的技術性 SEO才有地基可搭。這套外掛跑在你主機上，主機能扛多少，它就能做多少，剩下的就是按資源把靈敏度、監測模式、掃描排程調到對的位置。
共享主機的日常維運狀態
把前面幾節收斂成共享主機上要維持的狀態：掃描等級 Standard、一天一次排在凌晨離峰；Live Traffic 固定 Security Only；防火牆 Status 維持 Enabled and Protecting 而非 Learning Mode；Brute Protection 啟用且失敗次數設在 5 次左右；管理員帳號全部綁 2FA、備用還原碼離線保存；Email 通知只在新設備或新位置登入時觸發。另外定期檢查 Blocking 清單移除誤封的正常 IP，並到主機商的資源使用面板確認 Wordfence 沒有佔用異常的 CPU 額度。
網站被入侵之後的清理與還原流程
再嚴密的防護都無法保證百分百不被入侵，外掛零日漏洞、被盜的管理員帳號、第三方託管的外掛供應鏈問題都可能讓網站淪陷。知道被入侵之後該怎麼動手，比一直祈禱不會出事更實際。Wordfence 在這個階段是清理工具，也是診斷工具，但要搭配正確的順序才有效。
處理順序大致是先隔離、再清場、最後收尾。隔離是把網站切到維護模式或暫時關閉，避免訪客與搜尋引擎接觸到被植入的惡意內容。接著把所有密碼一次改掉，涵蓋 WordPress 管理員、資料庫、FTP、主機控制台與相關的第三方服務帳號，全部換成全新且不重複的密碼，因為舊密碼在入侵當下可能已經外洩。然後才用 Wordfence 跑一次 High Sensitivity 完整掃描，平時不建議開的高靈敏此時才值得啟用，把可疑檔案、後門、被竄改的核心檔案一次列出來。掃描結果逐項處理：惡意檔案刪除、被改的核心檔案還原成官方版本、使用者清單裡不認識的管理員帳號停權刪除。若有入侵前可靠的備份，直接還原是最乾淨的做法，再補上漏洞修補與密碼更新；若網站已被搜尋引擎標成不安全或被植入 SEO 垃圾，清理完還要到 Google Search Console 提交重新審查。
清理過程最忌諱只刪掉看得到的惡意檔案就以為沒事。入侵者常埋多個後門互相呼應，刪了一個、另一個會重新生成。所以清理完必須持續觀察幾天，每天掃一次，確認沒有新的可疑檔案出現。Wordfence 的掃描歷史記錄可以拿來追蹤，看到清理後又冒出相同檔名或路徑，代表還有沒抓到的後門。
資料庫層的清理容易被忽略。後門帳號常被藏在 wp_users 資料表裡，使用者名稱可能偽裝成像系統帳號的名字。Wordfence 能掃到部分異常，但更保險的做法是手動到後台使用者清單逐一看，把不認識或建立時間異常的管理員帳號停權刪除。文章內容也要抽檢，看有沒有被植入隱藏的指令碼或垃圾連結，尤其是舊文章容易被動手腳，因為站長很少回頭檢查。
實務上接手過一個匿名客戶的舊版旅遊部落格，WordPress 維護停擺 18 個月、月 sessions 約 12,480，2025 年第四季被我接手清理（清理完成日 2025-11-14）。站長是先從 Google Search Console 異常暴增的索引量察覺不對勁。我的排查流程固定那幾項：先到使用者清單找陌生管理員帳號、看最近修改過的檔案、核對外掛版本是否過舊、檢查 uploads 目錄有沒有不該出現的可執行 PHP 檔、再翻資料庫找可疑字串。實際量測到的數字：Wordfence 掃描出的可疑 PHP 檔從 47 個降到 0（來源：Wordfence scan，當時版本 8.0.5）；使用者清單裡的陌生管理員帳號從 2 個降到 0（來源：WordPress Users 匯出）；GSC 被索引到的垃圾 URL 從 318 個降到 26 個（來源：Google Search Console Pages，清理後 4 週觀察）；高嚴重度安全警告從 11 個降到 0（來源：Wordfence scan report）。清理動作涵蓋刪除惡意檔案、重設所有管理員密碼與 salts、把 WordPress 核心從舊版更新到 6.7.1 並更新所有外掛、補上 Wordfence WAF 與登入頁限制、到 GSC 移除垃圾 URL。整個清理工時 9.25 小時（來源：Toggl 計時記錄）。
老實說，第一輪我只刪掉看得到的惡意檔案，沒找到真正被入侵的入口，結果 3 天後 uploads 目錄又冒出新的 PHP 檔。最後追到漏洞出在舊版 File Manager 外掛（當時還停在 7.1 版）的已知漏洞，把該外掛移除並更新版本後，新檔案才不再出現。這個教訓正好印證下一個重點：只刪檔案沒補洞，後門幾天內就會被寫回原位。
這個情境要點出來的限制是：把惡意檔案刪掉只是第一步。如果當初被入侵的漏洞外掛沒更新、或管理員仍是弱密碼，幾天內同樣的後門往往又被寫回原位，這也是前面清理步驟要把「補洞、改密碼、改權限」與檔案清理綁在一起做的原因。被駭處理要同時完成幾件事，缺一不可：清理惡意檔案、補上漏洞外掛與弱密碼、調整檔案與目錄權限、重新簽發 SSL 憑證以防憑證外流被冒用、到 GSC 提交垃圾 URL 移除與重新審查、最後留下持續監控。能照這個順序一次做完，被寫回的機率才會明顯下降。
端點防護的邊界與分層防禦
Wordfence 是端點防護的主力，但有些情境光靠它不夠。認清這些邊界，才知道何時要補上其他層次的防護，而不是把全部責任壓在單一外掛上。以下幾種狀況，端點防護只能做一部分，需要其他措施搭配。
端點防護力有未逮的情境，主要落在四種。第一種是 DDoS 流量洪峰，大量請求在到達主機前就把頻寬與連線數灌爆，端點防護此時愛莫能助，需要雲端 WAF 或 CDN 在邊緣吸收流量。第二種是供應鏈入侵，外掛或佈景官方的伺服器被入侵、更新檔被摻入惡意程式碼，這類攻擊繞過網站本身的設定，端點掃描只能事後發現。第三種是主機層漏洞，主機作業系統、PHP 執行環境、或同主機其他站台的橫向感染都超出 WordPress 應用層，需要主機商或伺服器管理員介入。第四種是社交工程，管理員帳號被釣魚或被盜後，再強的端點防護也擋不住合法憑證的登入，這要靠 2FA 與人員資安意識。認清這四條邊界，才知道何時該補上雲端、主機或人員層的防護。
對應的做法是分層防禦。網站層用 Wordfence，網路層用 CDN 或雲端 WAF 過濾惡意流量，主機層靠主機商的安全維護，人員層靠 2FA 與最小權限原則。每一層都不需要做到極致，但每一層都要有，這樣某一層失守時，其他層還能擋一陣子，為你爭取發現與修補的時間。這種纵深防禦的觀念，跟做WordPress 備份與還原時要準備多種還原方式的邏輯是一致的。
進階設定：Rate Limiting 與國家封鎖
當網站開始穩定運作、基本防護到位之後，可以進一步用 Wordfence 的 Rate Limiting 與國家封鎖功能收緊防護。這兩項設定不是每個網站都需要，但在特定情境下能大幅降低攻擊噪音，把 CPU 留給真正的訪客。
Rate Limiting 的概念是對單一 IP 在單位時間內的請求數設上限，超過就暫時封鎖。它對付的是掃描機器人與內容爬蟲，這類請求特色是單一 IP 短時間內密集打同一批網址。設定時要拿捏閾值：設太嚴會誤擋正常訪客或監控服務，設太鬆等於沒設。一個起點是每分鐘 240 次請求封鎖 5 分鐘，再依 Live Traffic 的實際狀況微調。如果你的網站會被合法的監控服務或第三方 API 大量呼叫，記得把這些來源 IP 加入白名單，避免被 Rate Limiting 擋掉。
國家封鎖則是把整個國家的 IP 段擋在外面。適用情境是網站明確只服務特定地區，且攻擊絕大多數來自其他地區。例如純本地服務的網站，可以封鎖從未來過訪客的國家。但這項功能要慎用，理由有幾個。一個是合法訪客可能透過 VPN 或旅行中從海外連線，整段封鎖會把他們一起擋掉。另一個是 CDN 或代理服務會改變來源 IP，封鎖結果可能不如預期。建議先用 Live Traffic 觀察一段時間，確認確實沒有來自該地區的合法流量，再進行封鎖。
| 進階功能 | 主要對抗 | 誤殺風險 | 建議啟用時機 |
|---|---|---|---|
| Rate Limiting | 掃描機器人、爬蟲 | 中，可能擋合法監控 | 站點被密集掃描、CPU 常被吃滿 |
| 國家封鎖 | 特定地區的攻擊源 | 高，誤擋 VPN 與海外訪客 | 純本地服務、無海外合法流量 |
| 即時 IP 黑名單（Premium） | 已知惡意 IP 網段 | 低 | 資源充足、追求即時防護 |
常見問題
Wordfence 兩階段驗證手機遺失怎麼辦？
用設定時下載的 5 組單次備用還原碼登入，每組只能用一次。這就是為什麼綁定 2FA 時備用碼務必存在安全的地方，否則手機弄丟會被鎖在後台外面。
Wordfence 掃到惡意檔案該直接刪除嗎？
先確認再刪。紅色 Critical 提示的惡意程式碼通常可依 Wordfence 的修復選項處理，但有些被誤判的合法檔案也可能出現在清單上。刪除前比對檔案路徑與外掛名稱，確認它不是合法外掛或佈景的一部分。若不確定，先把它隔離或改名，不要直接刪，刪錯可能讓網站出現白畫面。
什麼時候該手動觸發完整掃描？
排程掃描之外，有幾個時機值得手動跑一次。剛更新完外掛或佈景主題、剛搬完家、剛還原備份、或懷疑網站被入侵時，手動觸發完整掃描可以確認環境處於乾淨狀態。資源充足的 VPS 或雲端主機可以順手開 High Sensitivity 做一次更全面的檢查，共享主機則維持標準掃描即可。
把 Wordfence 當成一鍵解，是它被誤用最常見的原因。把掃描靈敏度、流量紀錄模式、學習模式照主機型態調對，這套外掛才不會反過來拖累網站。再搭好快取外掛，網站才有機會兼顧安全與速度。