動手之前，先抓對方向
動手前先立三個原則：先保全現場，能備份就把檔案與資料庫先拉一份，免得救火救到把資料跟證據一起燒了；一次只動一個變數，改一處就驗一次，好了才知道是哪一步生效；由外而內，先懷疑最外層、最常出事的外掛與佈景，再往資料庫、核心檔，最後才是主機。光看一眼「前台白了，後台進不進得去」，八成方向就定了——後台還活著，兇手幾乎都在外掛或佈景；連後台都陣亡，就往資料庫或主機那層查。
白畫面 WSOD 與外掛佈景衝突
為什麼會整片空白
白畫面（White Screen of Death，簡稱 WSOD）在底層幾乎都是同一件事：PHP 執行到一半撞上致命錯誤（fatal error）而中止，或記憶體被耗盡把整支程序掐死。PHP 是逐行執行的，一旦某個外掛呼叫了不存在的函式、兩支外掛搶用同一個函式名稱、或某段程式吃光了記憶體，整個請求就會當場斷掉，回給瀏覽器一片空白，或一句「這個網站發生嚴重錯誤」。這也解釋了白畫面為什麼常常「昨天還好好的」——多半是某個外掛剛更新、或 PHP 版本被主機悄悄升級，觸發了潛伏的相容性地雷。
要看清楚哪裡爆，第一步永遠是打開除錯記錄。用 FTP 打開 wp-config.php，在那行「That's all, stop editing」的上面加三行：define('WP_DEBUG', true)、define('WP_DEBUG_LOG', true)、define('WP_DEBUG_DISPLAY', false)。巧妙在於，它把錯誤寫進 wp-content/debug.log，而不是直接噴在頁面上給訪客看——你拿到了出事的檔名與行號，又不會把敏感的伺服器路徑攤在外人眼前。打開那個 log，第一行通常就寫著哪個外掛、哪支檔案、第幾行出事。
後台進不去時的逐一排除法
如果連後台都打不開，沒辦法用滑鼠停外掛，就走檔案這條路。用 FTP 把整個 wp-content/plugins 資料夾改個名字，例如改成 plugins_hold，WordPress 在原路徑找不到外掛，就會把它們全部視為停用，網站通常立刻活過來。確認能進後台後，把名字改回來，這時外掛全部停用，你再一個一個重新啟用，每啟用一個就重整前台，哪個一啟用白畫面就復活，兇手就是它。佈景的邏輯一樣：把使用中的佈景資料夾改名，系統找不到就自動退回官方預設佈景，換成預設就正常，問題就出在你原本那套佈景。
如果 log 指向記憶體不足（Allowed memory size ... exhausted），可在 wp-config.php 加一行 define('WP_MEMORY_LIMIT', '256M') 把上限拉高，但這個值有天花板——它不可能超過主機 php.ini 裡的 memory_limit。你在 WordPress 寫 512M、主機只給 128M 也是白搭，該調的是主機那一層。
善用內建的復原模式
從 WordPress 5.2 起，核心內建了一套致命錯誤保護（復原模式，Recovery Mode），常能省下開 FTP 的功夫。它掛在 PHP 的 register_shutdown_function 上：當某次請求因致命錯誤中止，WordPress 會趕在程序關閉前攔下錯誤，判斷是哪個外掛或佈景闖的禍，然後寄一封帶密鑰登入連結的信到管理員信箱。點進去，你就能在「暫時停用問題外掛」的狀態下進後台把它關掉，訪客端看到的則是「網站發生技術性問題」而非空白。但要留意它的適用邊界：復原模式只攔得住外掛與佈景的錯誤，對於核心檔損毀、wp-config.php 寫錯、或主機層級的崩潰（PHP-FPM 掛掉、作業系統 OOM 殺掉程序）這類狀況接不住，那時仍會看到白畫面，得回頭走檔案排查。
資料庫連線錯誤：另一種急症
如果畫面只冷冷寫一句「Error establishing a database connection」，前後台一起陣亡，那跟外掛沒關係，是網站連不上資料庫了。WordPress 的內容——文章、設定、使用者、留言——幾乎全躺在 MySQL 或 MariaDB 裡，連線一斷，整站等於當場失憶。最常見是 wp-config.php 裡四個連線參數對不上：DB_NAME、DB_USER、DB_PASSWORD、DB_HOST。先到主機控制台把帳密與資料庫名逐字核對；特別留意 DB_HOST，有些主機不是填 localhost，而是 127.0.0.1、某個內部主機名，或一段 socket 路徑，這個填錯，會讓你怎麼看帳密都對、卻就是連不上。
如果連線參數沒問題，卻還是連不上或內容錯亂，那可能是資料表毀損。這時在 wp-config.php 暫時加一行 define('WP_ALLOW_REPAIR', true)，再用瀏覽器打開網址接 /wp-admin/maint/repair.php，就能修復。這個頁面刻意設計成不需登入也能進——因為資料庫壞了你本來就常登不進後台——所以修完務必立刻把那行常數刪掉，否則等於留了一道不需密碼的後門。至於突然發生、又查不出設定問題的，多半是主機端 MySQL 掛了，或連線數爆掉（Too many connections），流量一到尖峰就冒出來，找主機商最快。
網站被駭：先認徵兆，再懂為什麼
認出被入侵的跡象
被駭是最讓人心慌的一種，但它其實有很清楚的臉。典型徵兆包括：搜尋你的品牌名，卻跳出一堆藥品、賭博或日文垃圾關鍵字（業界俗稱藥廠外連 pharma hack 與日文 SEO 垃圾，是這幾年最猖獗的兩類）；訪客一點進來就被導去莫名的境外網站；後台冒出你沒建過的管理員帳號；或主機商通知你的伺服器正在大量寄送垃圾郵件。這些背後，通常是有人在你的檔案或資料庫裡塞了惡意程式與隱藏頁面。
WordPress 核心、外掛與佈景都可能出現漏洞，其中第三方元件數量多、維護狀態差異大，常是實務上的主要風險來源。漏洞數每天都會增加，也會因資料庫的收錄與分類方式不同；常設文章不再固定寫「某年近八千、96% 在外掛、核心只有七個」。維護時直接查 WPScan 最新資料庫與外掛官方公告，停用無人維護或來路不明的套件，並先在測試站更新。
為什麼「後台按重新安裝」清不掉問題
很多人第一直覺是到後台按「重新安裝 WordPress」，以為覆蓋一次就乾淨了，結果過兩天又復發。原因在於，重新安裝只會覆蓋既有的核心檔，而駭客最愛做的，是在你的目錄裡新增一支長相無害的後門檔（webshell），檔名甚至故意取得像正常系統檔。既有檔被覆蓋，新增的後門卻原封不動留著，只要它還在，對方隨時能再進來植入。這些後門往往經過混淆，常見 base64_decode 搭配 eval、或 gzinflate、str_rot13 這類函式，把編碼過的字串在執行的當下才還原成惡意程式碼，肉眼掃很容易被騙過去。最常被動手腳的，是根目錄的 .htaccess 與 index.php，以及佈景的 functions.php。
正確的清理與封門順序
清理要有章法，不能東抓一把西刪一個。順序大致是這樣：
- 先掃描定位：用專業的資安掃描外掛，搭配一個獨立的遠端惡意程式掃描服務交叉比對，把被植入與竄改的檔案都抓出來，避免單一工具漏網或誤判。
- 整包換掉核心：不要只覆蓋。正解是從官方 wordpress.org 重新下載對應版本的乾淨核心，用 SFTP 把 /wp-admin 與 /wp-includes 整包刪掉再換上，一併斬斷夾帶其中的後門。
- 重產金鑰把人踢下線：把 wp-config.php 裡那八組安全金鑰（salt keys）重新產生。這步很關鍵——現存的登入 session 都用舊金鑰簽章，金鑰一換，等於把所有還登著的人（包括潛伏的攻擊者）全部強制登出；再配合把全站與資料庫密碼一起更換，才算真的把鎖換了。
- 找出並補上入口：刪掉所有可疑的管理員帳號後，回頭把真正的破口補起來——絕大多數就是那個過期沒更新的外掛，或貪小便宜裝的盜版佈景。入口不補，清得再乾淨也只是在等下一次被打。
效能調校：別讓網站愈跑愈鈍
網站愈用愈慢，很少是單一原因，通常是好幾個小問題疊在一起。要調得有效，得先理解一次頁面請求的成本花在哪，再從最貴的環節下手。
頁面快取：把重複的勞動省下來
沒有快取時，每位訪客點進同一個頁面，伺服器都要從頭把整套 PHP 跑一遍、對資料庫下好幾條查詢，重新組出一模一樣的 HTML 再送出去，純屬浪費。頁面快取的原理，就是把第一次算好的成品存成靜態檔，之後的訪客直接拿現成的，PHP 與資料庫完全不必再動，回應時間常能從幾百毫秒掉到幾十毫秒。裝一個成熟的頁面快取外掛就能達成，這通常是投報率最高、該先揮出去的第一刀。
資料庫的隱形肥肉：autoload
有個很多人沒注意到的肥點，藏在 wp_options 這張表裡。每筆選項有個 autoload 欄位，設為 yes 的，會在每一次頁面載入時被 WordPress 透過 wp_load_alloptions() 一次全部撈進記憶體。問題是外掛裝了又刪，殘留設定常忘了把 autoload 關掉，日積月累就變成每個頁面都得背著跑的死重量，連前台訪客都被拖累。WordPress 6.6 起，官方的網站健康（Site Health）會在自動載入選項總量超過 800KB 時跳出警示；一般 800KB 以內算健康，800KB 到 5MB 值得清一清，超過 10MB 就該當緊急事件處理。清掉沒在用的外掛殘留選項、把過期的暫存資料（transients）掃一掃，全站都會跟著輕盈。
把地基升上去：PHP 版本與 OPcache
速度、轉換率與維護成本的改善幅度會受網站內容、流量來源、裝置與技術架構影響。先量目前的 Core Web Vitals、錯誤率與轉換漏斗，變更後用同一期間及相同口徑比較，不拿未附樣本與日期的比例當保證。
圖片與驗收：用真實使用者指標把關
幾個最常見的誤區，先記下來
幾條隨手可查的判準，能替你少走冤枉路：
- 白畫面別急著亂改：先看「後台進不進得去」定方向，再開 WP_DEBUG 看 log，讓證據帶著你走，而不是憑感覺猜。
- 設定值有天花板：WP_MEMORY_LIMIT 不可能超過主機 PHP 的 memory_limit，設再大也沒用；WP_ALLOW_REPAIR 這類不需登入的修復頁面，用完一定要移除。
- 被駭不能只覆蓋核心：後門是「新增」出來的檔，重裝只覆蓋既有檔，一定要換金鑰、補入口、刪可疑帳號三件事一起做。
- 別為省授權費裝盜版：九成以上的破口出在外掛，盜版更是預埋後門的重災區，省下的授權費常常轉頭就拿去付更貴的清理與商譽修復費。
說到底，WordPress 的故障多半不可怕，可怕的是不知道從哪查起，一慌了手腳、東點西改，反而把小問題弄成大災難。廷皓科技深耕高雄與南台灣，服務涵蓋高雄、台南、屏東，從白畫面急救、資料庫搶修、被駭清理與封門，到效能與資安的定期健檢都能接手，也提供長期維運，讓你不必半夜一個人對著 FTP 跟 log 硬撐。網站出了狀況，或想在出事前先做一次徹底的體檢，都歡迎跟廷皓聊聊。
