WordPress × Redis 物件快取：網站遷移、複製與 Staging 完整 SOP (避免快取互洗與網址錯置)

當你的 WordPress 使用 Redis 物件快取 (Redis Object Cache) 時，網站「複製、遷移、建立 Staging」並不是單純搬檔案 + 匯出/匯入資料庫這麼簡單。

因為 Redis 會保留物件層的暫存資料，如果來源站與目標站共用同一個 Redis「資料庫索引 (DB index)」或使用相同前綴，就容易出現：

搬完之後，原站的內容被 Staging 的網址覆蓋。
清快取時「兩站同時被清除」，甚至不同網站互相影響。
停用 Lua 群組清除後 (WP_REDIS_DISABLE_GROUP_FLUSH)，按下清除快取變成整庫清空，影響同資料庫索引的所有站點。

常見情境：換新主機搬站、建立測試站 (Staging)、或外掛大改版前的測試

本文整理完整的注意事項與 SOP，讓你在 ServerAvatar 環境或一般 VPS 上，都能安全完成搬站與測試。

為什麼使用 Redis 的網站在遷移/複製會出現問題？

WordPress 的資料分兩層：

SQL：文章、頁面、使用者、選項 (wp_options) 等
Redis 物件快取：把常用查詢、設定、Query 結果「暫存」在記憶體，以減少重複查詢

當網站 clone 或遷移時，如果目標站啟動後仍連到與來源站「同一個」Redis DB，或使用相同 WP_REDIS_PREFIX，兩個網站就會讀寫同一批快取鍵。

會造成以下問題：

目標站啟動寫入自己的 URL/設定 → 原站讀到錯的暫存 → 看起來像是被「換站」
任一站清快取 → 因為共用同一 DB 索引 → 彼此快取互洗

先了解 Redis 快取的核心觀念

Redis Instance、DB Index、Prefix 是什麼？

Instance：同一個 redis-server 進程。CPU/記憶體上限、持久化 (RDB/AOF)、淘汰策略都「整體共享」。

DB Index (資料庫索引)：邏輯分區 (預設從 0 開始)。不同索引不是儲存在不同的表或不同進程，但指令可以只作用在當前的 DB 索引，例如，FLUSHDB 只清當前 DB。

Key Prefix (前綴)：同一 DB 內的「命名區隔」。外掛通常以網站為單位加前綴避免衝突。

FLUSHDB、FLUSHALL 與 Lua 群組清除

FLUSHDB：清除當前 DB 內的所有鍵 (Key Prefix)。

FLUSHALL：清除整個 Instance 的所有 DB。

Lua 群組清除 (group flush)：透過 EVAL 搜尋特定前綴的鍵並刪除 (不清除整個 DB)。

若關閉 Lua 群組清除功能，多數外掛會 fallback 成 FLUSHDB，風險是共用相同 DB 索引的其它站也會一起被清掉。

連線與權限：Socket/TCP、ACL、EVAL

僅本機或 Unix socket 連線，避免把 6379 對外曝露。

ACL 最小權限：給 WordPress 的 Redis 帳號僅允許需要的指令；如暫時因安全需求禁用 EVAL/EVALSHA，要同步考量清除快取機制 (見下文 SOP)。

日常安全設定 – Redis 物件快取

每個網站唯一 DB 索引 + 前綴

如果在同一台主機上有多個 WordPress 網站，每個網站請一律使用不同的 WP_REDIS_DATABASE，同時設定有識別性的 WP_REDIS_PREFIX。

這樣一來：

任何網站執行 FLUSHDB 時只會清理自己的 Redis DB，不會波及其他網站。
同一站不同環境 (prod/staging/dev) 也不互相污染。

// 每個站/每個環境請使用不同的數字 (0~15)
define('WP_REDIS_DATABASE', 3);

// 前綴建議包含站名與環境，易讀且避免混用
define('WP_REDIS_PREFIX', 'siteA:prod:');

只允許本機連線、給最小權限

bind 127.0.0.1 或改用 Unix socket
protected-mode yes
為 WordPress 建一個 ACL 使用者，授權「必需」指令 (GET/SET/DEL/EXPIRE/...)，如暫不需要 Lua 群組清除，移除 EVAL/EVALSHA 權限。

暫停 Lua 群組清除時的影響與替代

因安全政策或暫時風險管控 (例如特定 CVE) 需要禁用 EVAL 時，可在 wp-config.php 設定：

define('WP_REDIS_DISABLE_GROUP_FLUSH', true); // 改用 FLUSHDB

務必先把每個網站的 Redis DB 拆開 (設定不同的 WP_REDIS_DATABASE) 再啟用此設定。

否則任一站清除快取時都會洗掉同 DB 索引的其它網站。

👉 詳細設定說明，可以參考在 WordPress 安裝與設定 Redis Object Cache (含 WP_REDIS_* 常數)。

遷移/複製 (Clone) 前的準備清單

先「急停」物件快取 (避免互寫)

後台停用外掛不一定等於停用 object cache，因為 drop-in 檔 /wp-content/object-cache.php 還在。
建議使用 WP-CLI：wp redis disable 或手動暫時移除/更名 wp-content/object-cache.php 檔案，可以確保搬站過程不會寫入 Redis。

清理 Page/CDN Cache

若同時使用 Page Cache、CDN (如 Cloudflare、Super Page Cache)，請依照原本的快取策略做「來源站凍結」：

暫停 Worker 改寫或特別規則 (避免 query 參數影響快取鍵)。
清理來源站的頁面快取，避免網站搬移後誤判。

預先規劃 DB 索引/前綴

在搬移前先決定好相關設定規劃，例如：staging 使用 DB=5、prefix=siteA:stg:。

👉 關於 ServerAvatar 搬站/升級，可以參考 ServerAvatar 搬站/升級主機規格完整流程。

遷移/複製 (Clone) 操作流程 (SOP)

Step 1：來源站預先處理

從 WordPress 網站後台或使用 WP-CLI 停用 Redis 物件快取 (或直接移除 drop-in 檔案)。
(可選) 清空來源站 Redis 當前 DB，以確保導出的資料庫快照不包含過時快取資訊：
redis-cli -n <來源站 DB 索引> FLUSHDB
清理頁面快取/CDN 快取，避免舊頁面殘留。

Step 2：複製檔案與資料庫

複製 WordPress 檔案與 uploads。
匯出資料庫 (若需更換網域，僅針對 DB 內的 siteurl/home 與必要的序列化欄位做安全替換；不要替換 Redis 相關設定)。

如果是使用 ServerAvatar 或其他 Panel 服務，就是使用其 Site Clone、Create Staging Area、Site Migration 等功能。

Step 3：目標站啟動前的「環境就緒」

在目標站 wp-config.php 設定全新的 WP_REDIS_DATABASE 與 WP_REDIS_PREFIX： define('WP_REDIS_DATABASE', 5); define('WP_REDIS_PREFIX', 'siteA:stg:');
(若安全政策需要) 暫時啟用 define('WP_REDIS_DISABLE_GROUP_FLUSH', true); 但請確認「目標站」確實使用獨立 DB，清除快取時才不會清到其他網站。
以 ACL 控制 WordPress 帳號指令集 (如前述最小權限)。

Step 4：目標站初始化

先不要啟用 Redis 物件快取，確認網站可正常登入、siteurl/home 正確。
啟用 Redis 物件快取 (WP-CLI)
- 啟用：wp redis enable
- 檢查狀態：wp redis status
只清目標站的 Redis DB (初始化乾淨狀態)：redis-cli -n 5 FLUSHDB

Step 5：驗證與 Rollback

驗證前台/後台是否出現「跳回來源站」或「資料混用」情形。
若有狀況，先 wp redis disable，檢查 WP_REDIS_DATABASE、WP_REDIS_PREFIX 是否搞混，再行啟用。
建議記錄一組 Rollback Script (關閉 object cache、清 DB、重啟服務) 以縮短復原時間。

Staging 環境的專屬建議

避免影響 SEO 與外部服務 (noindex/停用寄信與金流)

Staging 一律加 noindex，封鎖搜尋引擎 (robots.txt 與後台設定並行)。
關閉對外金流/金流測試模式、停用發信或改走獨立 SMTP 沙盒，避免誤發送正式郵件。
第三方金鑰 (GA4、像素、Webhook) 區分管理，避免正式站、Staging 資料混送。

資安與快取隔離 (DB 隔離)

Staging 與正式站使用不同的 Redis DB。
若採用 WP_REDIS_DISABLE_GROUP_FLUSH，務必確認 Staging 的 FLUSHDB 不會清到正式站。
建議為 Staging 設定更嚴的 ACL (僅基本指令；必要時完全禁用 Lua)。

👉 關於測試規劃，可以參考建立 Staging 測試站的規劃與準備。

常見問題與排查

Clone 後首頁正常，但後台偶爾跳回來源站？

多半是快取污染。檢查：

目標站是否仍連到來源站的 Redis DB 索引？
WP_REDIS_PREFIX 是否仍用來源站的前綴字串？
先 wp redis disable → 清理快取 redis-cli -n <目標站 DB 索引> FLUSHDB → 重新 wp redis enable。

清除快取導致兩站同時被清，怎麼辦？

代表共用同一個 DB，或啟用 WP_REDIS_DISABLE_GROUP_FLUSH 後用 FLUSHDB 清到整庫。

解決方法：每個網站使用不同的 WP_REDIS_DATABASE；若需要群組清除，再評估是否恢復 EVAL (並確認資安風險已解決)。

Multisite 要如何規劃 Redis？

Multisite 通常共享同一 WordPress 安裝。若以一個 instance 服務整個網路站群，可：

使用同一個 DB，但前綴區分各子站 (外掛會處理)。
若要把其中一個子站獨立出去，搬離前仍建議暫停 object cache、清 DB、再單獨設置新站的 DB index。

結語

Redis 用的好，能大幅降低資料庫壓力、提升 WordPress 的回應速度；但在遷移、複製、建置 Staging 的過程中，務必先將「快取隔離」處理好。

只要掌握這三個關鍵就能避開 90% 的問題：

每個網站/環境都有唯一 WP_REDIS_DATABASE 與 WP_REDIS_PREFIX。
搬站前先「停用」物件快取，搬完再啟用並清空「目標站快取」。
清楚理解 WP_REDIS_DISABLE_GROUP_FLUSH 的效果 (FLUSHDB)，搭配 DB 隔離使用。

如果有什麼心得、想法或建議，歡迎大家留言或加入社團一起討論！

我們在測試各家品牌伺服器控制面板時發現，面板廠商如果特別著重在 WordPress 功能整合的開發上，並且提供深度的快取外掛整合 (包含 Redis Object Cache)，通常在建立 Staging 時就會自動完成 Redis 隔離，從架構層面避免此類風險。

xCloud 就是其中一個，如果是追求效率的團隊，不妨可以看看我們對 xCloud 的評測文章多加了解！