之前產生的 SSH 金鑰有設定密碼鎖。雖然這比沒設密碼安全，但每次都要輸入確實很麻煩。如果你不想重新產生金鑰，有兩個方法可以解決。

使用 ssh-agent 自動管理

這是最推薦的做法。你可以讓系統在背景跑一個代理程式，幫你記住解鎖後的金鑰。只要在 WSL 終端機執行這兩行指令：

eval $(ssh-agent -s)
ssh-add ~/.ssh/id_rsa_personal

執行第二行時，輸入最後一次密碼。之後只要這個視窗沒關掉，再次 push 就不會再問你密碼。

如果你希望每次開啟 WSL 都自動生效，可以把這兩行指令加到 ~/.bashrc 檔案的最末端。這樣每天第一次開機輸入一次，之後整天都不用再打。

移除金鑰本身的密碼

如果你覺得在私有電腦上不需要這層保護，也可以直接把金鑰的密碼拿掉。執行這行指令：

ssh-keygen -p -f ~/.ssh/id_rsa_personal

系統會先要求你輸入舊密碼。接著會問你新的密碼，這時直接按兩次 Enter 留白。這樣這組金鑰就會變成無密碼狀態，以後執行 git push 就會直接通過。

確認設定是否正確

處理完密碼後，你可以測試一下連線是否正常。輸入：

ssh -T git@github.com -i ~/.ssh/id_rsa_personal

如果看到 Hi 帳號名！You’ve successfully authenticated，就代表搞定了。以後不管 Windows 那邊登入哪個帳號，WSL 這邊都會走你這組專屬的 SSH 金鑰。

如果你使用的是 zsh，要把設定寫在 ~/.zshrc 這個檔案裡。

修改設定檔

你可以使用 nano 或 vim 來編輯：

nano ~/.zshrc

把下面這段程式碼貼到檔案的最末端：

Bash

if [ -z "$SSH_AUTH_SOCK" ]; then
   eval $(ssh-agent -s)
   ssh-add ~/.ssh/id_rsa_personal
fi

存檔離開後，執行 source ~/.zshrc 讓設定立即生效。這樣你下次開啟新的 zsh 視窗時，系統就會自動啟動代理並載入你的金鑰。

使用 oh-my-zsh 插件

如果你有安裝 oh-my-zsh，其實有一個更優雅的插件做法。在 ~/.zshrc 找到 plugins=(…) 這行，把 ssh-agent 加進去：

plugins=(git ssh-agent)

接著在下面補上一行設定，指定要自動載入的金鑰名稱：

zstyle :omni:plugins:ssh-agent identities id_rsa_personal

這樣它會在你開啟終端機時自動處理一切，不用自己寫 shell script。

解決重複啟動問題

要注意的是，如果直接在設定檔寫 eval，每次開新視窗都會產生一個新的 ssh-agent 處理程序。如果你發現系統變慢，或是用 ps 指令看到一堆 ssh-agent，建議使用上面提到的 if 判斷式，或是安裝 keychain 這個套件來管理。

keychain 會幫你找現有的代理程序，確保整個系統只跑一個 ssh-agent。這對於習慣開多個分頁的人來說，是比較乾淨的做法。

關於 Keychain

keychain 是一個用來管理 ssh-agent 的工具。它的好處是能讓所有開啟的終端機視窗共用同一個 ssh-agent。如果不使用它，你每開一個新的 zsh 分頁，系統可能就會跑一個新的 ssh-agent 程式，久了會變得很亂。

keychain 會在背景記住你解鎖過的金鑰。只要你在第一次登入時輸入過一次密碼，之後不管是重開分頁還是執行 git push，它都不會再煩你。

安裝方式

在 Ubuntu 或 WSL (Ubuntu) 環境下，安裝非常簡單。直接輸入這行指令：

sudo apt update && sudo apt install keychain

安裝完後，它還不會自動運作，需要去修改你的 zsh 設定檔。

設定 zsh 自動執行

你需要把啟動指令加進 ~/.zshrc。請編輯該檔案：

nano ~/.zshrc

在檔案最後面加上這兩行程式碼：

Bash

/usr/bin/keychain --nogui ~/.ssh/id_rsa_personal
source ~/.keychain/$HOST-sh

第一行是叫 keychain 去管理你的那把金鑰。第二行則是載入相關的環境變數，讓目前的 zsh 知道要去哪裡找已經解鎖的金鑰。

實際使用效果

設定完成後，執行 source ~/.zshrc 或是重開視窗。這時候系統會最後一次詢問你金鑰的密碼。

輸入完畢後，這把金鑰就會一直保持在解鎖狀態。就算你開了十個 zsh 視窗，也都只需要輸入那一次密碼。這對頻繁使用 git push 的開發者來說，是最省心也兼顧安全的方法。

在 Windows CMD 環境下，Git 每次 push 都要求輸入密碼鎖，通常是因為 SSH Agent 沒有在背景執行，或是金鑰沒有被正確載入。以下提供兩個主要的解決方案。

使用 Windows 內建的 OpenSSH 服務

這是最推薦的做法，因為它可以讓 SSH Agent 在開機時自動啟動，並持久化儲存你的金鑰密碼。

以管理員身分開啟 PowerShell，執行以下指令將 OpenSSH Authentication Agent 服務設定為自動啟動

Set-Service -Name ssh-agent -StartupType AutomaticStart-Service ssh-agent

回到一般的 CMD 視窗，將你的私鑰加入 Agent。假設你的金鑰路徑是預設值：

ssh-add %USERPROFILE%\.ssh\id_rsa

執行後系統會要求你輸入最後一次密碼鎖。之後只要服務維持執行狀態，重開 CMD 也不需要再輸入密碼。

執行上述指令, 錯誤訊息:

Error connecting to agent: No such file or directory

這個錯誤通常是因為 CMD 無法識別 %USERPROFILE% 後接續的路徑格式，或是 ssh-agent 服務雖然啟動了，但目前的視窗環境變數還沒有對接上。你可以依照以下步驟排查並修正。

修正路徑格式與環境變數

在 CMD 中，路徑的分隔符號與變數引用非常嚴格。請嘗試手動補上反斜線，並加上雙引號確保路徑正確：

ssh-add "%USERPROFILE%\.ssh\id_rsa"

如果依然顯示無法連線到 Agent，請在同一個 CMD 視窗內執行以下指令，手動啟動 Agent 並設定環境變數：

for /f "tokens=1-2 delims==;" %a in ('ssh-agent -s') do set %a=%b

執行完畢後，再次嘗試執行 ssh-add 指令。

確認 SSH 服務執行狀態

如果手動啟動有效，但每次開新視窗都要重來，代表系統服務沒有正確常駐。請再次確認服務狀態：

1. 按下 Win + R 鍵，輸入 services.msc 並執行。
2. 找到 OpenSSH Authentication Agent。
3. 確認狀態為 正在執行，且啟動類型為 自動。

結果是服務被停用, 啟用就好了.

檢查 GIT_SSH 環境變數

有時候安裝 Git 時會內建自家的 SSH 套件，這會干擾系統內建的 ssh-add。請檢查你的環境變數中是否有名為 GIT_SSH 的變數。如果有，請將它刪除，讓 Git 預設使用系統路徑 C:\Windows\System32\OpenSSH\ssh.exe。

另外，請確認你的 .ssh 資料夾內確實存在 id_rsa 這個檔案。你可以輸入 dir %USERPROFILE%.ssh 來查看檔案清單。如果你的金鑰檔名不是 id_rsa (例如是 id_ed25519)，請將指令中的檔名更換為正確的名稱。

設定 Git 使用內建的 SSH 工具

有時候 Git 會使用自己打包的 SSH 工具而不是 Windows 系統路徑下的工具，這會導致兩者金鑰紀錄不互通。你可以強制 Git 指向系統的 SSH 路徑：

git config --global core.sshCommand C:/Windows/System32/OpenSSH/ssh.exe

修改金鑰設定移除密碼鎖

如果你覺得維護 Agent 服務太麻煩，且確認電腦環境安全，也可以選擇直接移除私鑰的密碼鎖。

執行以下指令：

ssh-keygen -p -f %USERPROFILE%.ssh\id_rsa

系統會先要求輸入舊密碼，當詢問新密碼時直接按兩次 Enter 留白。這樣該金鑰就會變成無密碼狀態，之後任何 Git 操作都不會再跳出輸入提示。不過請注意，這會降低金鑰外洩時的安全性。

# 更新套件清單
sudo apt update

# 安裝 Redis 伺服器與 PHP Redis 擴展
sudo apt install redis-server php-redis -y

安裝完成後，確認 Redis 是否正常啟動：

sudo systemctl status redis-server

配置 Redis 記憶體限制

為了防止 Redis 佔用過多系統記憶體導致主機當機，建議設定上限。編輯設定檔：

sudo nano /etc/redis/redis.conf

在檔案中找到或加入以下兩行（假設分配 256MB 給快取，可根據你的 VPS 記憶體大小調整）：

程式碼片段

maxmemory 256mb
maxmemory-policy allkeys-lru

這代表記憶體滿了時，Redis 會自動刪除最近最少使用的舊資料。修改後重啟 Redis：

sudo systemctl restart redis-server

WordPress 設定檔調整

雖然外掛會幫你處理大部分工作，但有時候需要手動在 wp-config.php 定義 Redis 的連線資訊，特別是如果你有特殊需求時。編輯 WordPress 根目錄下的 wp-config.php，在 /* That's all, stop editing! */ 之前加入：

define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);
// 如果這台主機上有連往不同網站，可以用這個區分快取
define('WP_CACHE_KEY_SALT', 'my_site_name_');

安裝與啟用外掛

1. 登入 WordPress 後台。
2. 前往 外掛 -> 安裝外掛。
3. 搜尋 Redis Object Cache（作者通常是 Till Krüss）。
4. 點擊安裝並啟用。
5. 前往 設定 -> Redis，點擊 Enable Object Cache 按鈕。

驗證快取是否運作

啟用後，你可以在後台看到 Status 顯示為 Connected。你也可以在主機終端機輸入以下指令來即時監控：

redis-cli monitor

當你重新整理網頁時，終端機會瘋狂跳出 GET 或 SET 的指令，這代表 WordPress 已經成功將原本要丟給 MySQL 的負擔，轉移到 Redis 記憶體快取中了。

Redis 記憶體分配評估

從你的系統負載來看，總實體記憶體只有 961Mi（約 1GB），目前已使用了 537Mi，可用空間（available）僅剩 423Mi。在這種記憶體受限的環境下，將 Redis 設定為 256MB 會有點冒險，因為這還沒計算 PHP-FPM 或是其他系統服務在流量高峰時可能增加的消耗。

為了確保系統穩定，不至於因為記憶體耗盡（OOM）而導致資料庫連線或 PHP 崩潰，我建議將 Redis 的 maxmemory 調低。

修正後的設定建議

建議先從 128MB 開始，這對於一般的 WordPress 網站來說，存放 Object Cache（如選單、文章 metadata、選項等）通常已經足夠。

編輯 /etc/redis/redis.conf：

程式碼片段

# 針對 1GB RAM 的小主機建議值
maxmemory 128mb
maxmemory-policy allkeys-lru

這樣的設定能確保 Redis 在記憶體用滿時，會優先刪除最久沒被使用的資料，而不會導致系統當機。

觀察可用記憶體

你可以定期觀察 available 這一欄。如果設定 128MB 後，available 穩定維持在 200Mi 以上，且 Redis 的命中率很高，則可以維持現狀。如果 available 掉到 100Mi 以下，你就必須考慮縮減 Redis 或是 PHP-FPM 的行程數量。

設定完成並重啟 Redis 後，可以到 WordPress 後台的 Redis 設定頁面看目前的 Memory Usage，如果它一直沒用到 100MB，那就代表 128MB 的上限非常安全。

查看 Redis 記憶體即時狀態

你可以直接在終端機輸入以下指令，這會顯示 Redis 目前實際使用的記憶體、峰值以及目前的碎片率：

Bash

redis-cli info memory | grep -E "used_memory_human|used_memory_peak_human|maxmemory_human"

這條指令會讓你看到：

• used_memory_human：目前 Redis 裡面存的資料佔了多少空間。
• used_memory_peak_human：從啟動到現在，最高曾經用到多少。
• maxmemory_human：你剛剛在設定檔限制的 128MB。

判斷是否需要加碼記憶體

在觀察一段時間後，你可以根據顯示的數據做調整：

• 如果 used_memory 經常達到 128MB：代表你的網站資料量大，Redis 正在頻繁刪除舊快取來放新資料（這稱為 Eviction）。這時連線效率會稍微下降，如果 available 還有剩，可以考慮調到 192MB。
• 如果 used_memory 遠低於 128MB：代表 128MB 非常充足，不需要再動它。

另一個實用的監控指令

如果你想看更細節的統計資訊（例如快取命中率），可以執行：

Bash

redis-cli info stats | grep keyspace

• keyspace_hits：從快取拿到資料的次數（越高越好）。
• keyspace_misses：快取找不到，必須跑去問 MySQL 的次數（越低越好）。

如果你的命中率（Hits）遠高於遺失率（Misses），恭喜你，你的兩台 VPS 溝通效率已經因為 Redis 的加入而大幅提升，因為很多請求在 WordPress 這台就處理完了，根本不需要跨網段去吵 MySQL。

建立 Redis 與系統監控指令腳本

這個腳本會整合 Linux 剩餘記憶體、Redis 記憶體使用狀況以及快取命中率，方便你隨時檢查主機健康狀態。

請在 WordPress 主機執行以下步驟：

建立腳本檔案：

nano check_redis.sh

貼入以下內容：

#!/bin/bash
echo "=== 系統記憶體狀態 ==="
free -h | grep -E "Mem|可用"
echo ""
echo "=== Redis 記憶體使用現況 ==="
redis-cli info memory | grep -E "used_memory_human|used_memory_peak_human|maxmemory_human"
echo ""
echo "=== Redis 快取命中統計 ==="
redis-cli info stats | grep -E "keyspace_hits|keyspace_misses"

3. 儲存離開，並賦予執行權限：chmod +x check_redis.sh

如何閱讀監控結果

之後你只需要輸入 ./check_redis.sh 就能看到結果。

• used_memory_human 如果接近你設定的 maxmemory，代表快取空間快滿了。
• keyspace_hits 與 keyspace_misses 的比例很重要。例如命中 1000 次、遺失 10 次，代表 99% 的請求都直接在本地端處理，兩台 VPS 之間的網路負擔降低了 99%。

進階調整建議

如果你發現 keyspace_misses 很高，通常是因為 WordPress 還有許多資料沒被快取進去，或是快取時間太短。這時可以檢查 WordPress 的 Redis 外掛設定，確保 Object Cache 確實有發揮作用。

另外，如果這兩台主機在同機房，別忘了檢查 WordPress 連接 MySQL 的 DB_HOST 是不是已經改成 內網 IP，這是最直接影響延遲的物理因素。

Redis 多網站衝突問題與解決方案

在同一台 VPS 上讓多個網站共用同一個 Redis 伺服器，確實會發生衝突。如果沒有特別設定，網站 A 的快取資料可能會被網站 B 讀取或覆蓋，導致登入狀態錯亂、顯示錯誤的文章內容或是後台設定被跳槽。

要解決這個問題，有兩種最常見且有效的方法：

方法一：使用不同的資料庫編號（最簡單）

Redis 預設提供 16 個資料庫（編號為 0 到 15）。你可以指定網站 A 使用資料庫 0，網站 B 使用資料庫 1。

編輯每個網站根目錄下的 wp-config.php，加入對應的資料庫編號：

PHP

// 網站 A 的設定
define('WP_REDIS_DATABASE', 0);

// 網站 B 的設定
define('WP_REDIS_DATABASE', 1);

這樣兩個網站的資料就會在 Redis 內部被隔離開來。

方法二：使用 Cache Key Salt（最推薦）

如果你的網站超過 16 個，或是想更保險一點，可以使用「加鹽」機制。這會讓 Redis 在儲存每一筆資料時，都在 key 的前面加上一段特定的前綴字串。

在每個網站的 wp-config.php 加入唯一的識別碼：

PHP

// 網站 A
define('WP_CACHE_KEY_SALT', 'site_a_name_');

// 網站 B
define('WP_CACHE_KEY_SALT', 'site_b_name_');

這樣即使它們都在同一個 Redis 資料庫裡，Key 的名稱也會變成 site_a_name_options 與 site_b_name_options，彼此互不干涉。

注意事項與記憶體壓力

雖然解決了衝突，但你必須注意記憶體用量。

• 加總計算：你之前設定的 maxmemory 128mb 是所有網站共用的總額。如果 site A 佔了 80MB，site B 佔了 60MB，總合就會超過 128MB。
• LRU 機制：當總量超過 128MB 時，Redis 會根據我們設定的 allkeys-lru 策略，隨機刪除所有網站中最舊的快取。這不會讓網站掛掉，但會導致兩邊的快取命中率都下降。

如果你發現 check_redis.sh 顯示的 used_memory 經常卡在 128MB，建議稍微上修這個數值，或是增加 VPS 的實體記憶體。

需要我幫你檢查目前這台 VPS 上所有網站加起來大約佔用了多少 Redis Key 嗎？

查看 Redis 中各網站的 Key 數量

你可以利用 Redis 的 INFO keyspace 指令來查看目前各個資料庫（Database）分別存了多少筆資料。如果你是使用「方法一」（不同資料庫編號）來區隔網站，這個指令最精準。

請執行：

redis-cli info keyspace

輸出的結果會像這樣：

db0:keys=1250,expires=1200,avg_ttl=4500

db1:keys=850,expires=800,avg_ttl=3800

這代表 db0（網站 A）存了 1250 個 Key，而 db1（網站 B）存了 850 個。如果某個 db 的 keys 數量遠高於其他網站，代表該網站對 Redis 的依賴度最高，或是該網站的外掛/佈景產生了大量的快取資料。

查看具體的前綴分佈

如果你是使用「方法二」（Cache Key Salt），所有的 Key 都會擠在同一個 db0 裡面。這時我們可以用 SCAN 指令搭配 grep 來估算各網站的比例：

# 查看 site_a 開頭的 key 有多少個
redis-cli --scan --pattern 'site_a_name_*' | wc -l

# 查看 site_b 開頭的 key 有多少個
redis-cli --scan --pattern 'site_b_name_*' | wc -l

綜合效能評估建議

當多個網站併行時，請持續關注你的 check_redis.sh 指令。如果發現以下情況，請採取對應行動：

• Evicted Keys 增加：執行 redis-cli info stats | grep evicted_keys。如果這個數字一直跳動，代表 128MB 真的不夠用了，Redis 正在被迫踢掉舊資料來塞新網站的資料。
• CPU 使用率飆升：如果 Redis 所在的 WordPress 主機 CPU 負載變高，可能是因為某些網站的快取過期時間（TTL）設太短，導致 Redis 頻繁處理寫入動作。

目前你總共架設了幾個 WordPress 網站？如果超過 3 個，且平均流量不低，建議將 maxmemory 稍微放寬到 200mb 到 256mb，只要確保系統整體的 available 記憶體還有 100Mi 以上即可。

建立多網站 Redis 統計腳本

這個腳本會自動掃描 Redis 裡所有的資料庫（Database），並針對你設定的網站前綴（Salt）進行統計。這能讓你一眼看出哪個網站最佔空間。

建立腳本：

nano redis_sites_check.sh

貼入以下內容（請根據你實際在 wp-config.php 設定的 SALT 修改 SITES 列表）：

#!/bin/bash
# 在下方的括號內填入你各個網站設定的 WP_CACHE_KEY_SALT
SITES=("site_a_name_" "site_b_name_" "site_c_name_")

echo "=== 各資料庫 Key 總數 (按 DB 編號) ==="
redis-cli info keyspace | grep "^db"

echo ""
echo "=== 各網站前綴 Key 統計 (按 SALT 區分) ==="
for prefix in "${SITES[@]}"
do
    count=$(redis-cli --scan --pattern "${prefix}*" | wc -l)
    echo "網站前綴 [${prefix}]: ${count} 個 Key"
done

echo ""
echo "=== Redis 強制刪除統計 (Evicted) ==="
redis-cli info stats | grep evicted_keys

賦予權限並執行：

chmod +x redis_sites_check.sh && ./redis_sites_check.sh

如何解讀統計數據

• Key 數量落差大：如果某個網站有數千個 Key，而其他只有幾百個，通常是因為該網站安裝了較多外掛（如 WooCommerce、多語系外掛），或是佈景主題寫得比較肥大。
• evicted_keys > 0：如果這個數字不是 0，代表你的 maxmemory 已經封頂，Redis 正在「丟車保帥」。只要這數字增加得很快，就建議加碼 50-100MB 的記憶體。

最終優化小提醒

由於你的主機記憶體只有 1GB 左右，跑多個網站加上 Redis 會讓記憶體非常吃緊。除了 Redis 優化，建議也要檢查兩台 VPS 之間的 Ping 值。

在 WordPress 主機輸入：

ping <MySQL 主機內網 IP>

• < 1ms：完美，同機房內網。
• 1ms ~ 10ms：普通，可能是同地區但不同機房。
• > 50ms：不理想，建議考慮將兩台主機遷移到同一個機房，這比任何軟體優化都有效。

如果你發現 Ping 值過高，或是想要了解如何優化 PHP-FPM 的行程數量來騰出記憶體，隨時告訴我。

選擇建議：維持現狀使用 DB0 加前綴即可

針對只有 3 個網站的情況，我建議繼續使用 DB0 並搭配 Salt 前綴，不需要刻意切換到不同的 Keyspace（DB 1, DB 2 等）。

主要原因有三點：

1. 管理方便：從你跑出來的腳本可以看到，目前 3 個網站的 Key 總數才 3300 多個，佔用記憶體僅 7.41MB，遠低於 128MB 的上限。放在一起管理非常輕鬆。
2. 性能差異極小：在 Redis 中，切換 DB 並不會帶來明顯的性能提升，反而會讓你的監控腳本變複雜（需要切換資料庫才能掃描）。
3. 擴充性：使用前綴（Salt）是目前 WordPress 社群最主流的做法，許多自動化備份或快取清理外掛對前綴的支援度也比切換 DB 來得好。

數據診斷與優化建議

從你的 redis_status.sh 結果來看，有幾個有趣的發現：

• 命中率 (Hits) 表現良好：你的 keyspace_hits (25104) 遠大於 keyspace_misses (7042)，這代表大約 78% 的請求已經不需要去吵 MySQL 了，這對提升兩台 VPS 間的溝通效率非常有感。
• 記憶體非常充裕：目前只用了 7.41MB，你可以放心地把這 3 個網站都跑在 Redis 上，完全不需要擔心 128MB 不夠用。
• 第三個網站活性低：stickerline_ 只有 47 個 Key，這通常代表該網站流量極低，或者 Redis Object Cache 外掛雖然啟用了，但還沒累積足夠的存取資料。

下一個優化重點：減少 Misses

雖然 78% 的命中率不錯，但如果你想進一步壓榨效能，可以觀察 keyspace_misses。這通常是因為：

1. 快取過期：某些資料的 TTL（存活時間）設太短。
2. 不支援快取的查詢：某些複雜的 SQL 查詢或特定外掛（如購物車、會員中心）為了即時性會避開快取。

你可以試著在離峰時段執行 redis-cli monitor，看看哪些 Key 經常出現 MISS，如果是某些特定的頁面，可以檢查該頁面的外掛設定。

目前你的兩台 VPS 溝通效率已經比「裸奔」狀態好很多了。需要我幫你看看 MySQL 那台主機的 slow query log (慢查詢日誌)，找出那些 Redis 擋不掉、且執行太慢的 SQL 指令嗎？

要提升兩台主機間的溝通效率，首要任務是減少網路延遲。如果這兩台 VPS 位在同一個機房，請務必使用內網 IP（Private IP）進行連線，不要走公網 IP。內網傳輸不只速度快、頻寬不受限，還能省下流量費用。如果機房支援虛擬私有網路（VPC），也建議將兩者放在同一個 VPC 網段。

在 Linux 系統層面，可以調整 TCP 堆疊參數來優化連線回收速度。當 WordPress 頻繁讀取資料庫時，會產生大量短暫連線，透過修改 /etc/sysctl.conf 並開啟 net.ipv4.tcp_tw_reuse，可以讓系統更有效率地重複使用連線，避免因等待連線關閉導致的延遲。

資料庫連線技術優化

傳統的資料庫連線方式是每次請求都要重新握手，這會消耗大量時間。建議在 WordPress 主機端安裝並配置持久連線（Persistent Connections）。在 PHP 設定中啟用 mysqli.allow_persistent，或是在 WordPress 的資料庫設定中調整，讓 PHP 與 MySQL 之間維持長連線，避免反覆登入登出的開銷。

另外，如果資料庫查詢量極大，可以在兩台主機之間架設資料庫代理（Database Proxy），例如 ProxySQL。它可以處理連線池（Connection Pooling），將大量前端請求整合進少數幾個後端長連線，對提升高併發環境下的效率非常有幫助。

軟體層與快取機制

WordPress 預設每次載入頁面都會去資料庫撈資料，這對遠端資料庫來說負擔很大。建議安裝 Redis 或 Memcached 作為 Object Cache。當 WordPress 讀取過一次資料後，就直接存在主記憶體中，下次再有人訪問同一篇文章時，WordPress 會直接從記憶體拿資料，根本不需要跨過網路去問 MySQL 主機。

最後要檢查 MySQL 主機的 my.cnf 設定。確保 bind-address 綁定在內網 IP，並且檢查 max_connections 是否夠大。另外，如果在內網環境，可以關閉 MySQL 的 DNS 反向解析功能（在設定檔加入 skip-name-resolve），這能防止 MySQL 在每次連線時都去查主機名，直接提升連線反應速度。

MySQL 主機連線優化

在 MySQL 主機的設定檔（通常是 /etc/mysql/mysql.conf.d/mysqld.cnf）中，有幾個關鍵點可以調整。最重要的是關閉 DNS 反解，因為這常是導致連線延遲數秒的元兇。

Ini, TOML

[mysqld]
# 禁用 DNS 反向解析，直接用 IP 驗證，速度最快
skip-name-resolve

# 增加最大連線數，避免 WordPress 併發高時被拒絕
max_connections = 500

# 調整等待逾時，避免無效的長連線佔用資源
wait_timeout = 600
interactive_timeout = 600

修改完畢後，記得重啟 MySQL 服務。

WordPress 端的 Object Cache

與其優化連線，不如減少連線。在 WordPress 這台 VPS 安裝 Redis，並搭配 Redis Object Cache 外掛。這樣重複的資料庫查詢結果會直接存在記憶體，減少跨主機存取 MySQL 的次數。

如果你使用的是 Ubuntu，可以快速安裝：

sudo apt install redis-server php-redis

安裝後在 WordPress 後台啟用外掛，並將資料庫主機地址改為內網 IP。

WordPress 主機的重點

這台主機扮演的是發起請求的角色。它會產生大量的短暫連線去詢問資料庫，因此最重要的參數是 net.ipv4.tcp_tw_reuse = 1。

由於 PHP 處理完請求後會關閉連線，這些連線在 Linux 系統中會進入 TIME_WAIT 狀態，佔用連接埠（Port）。開啟這個參數可以讓 WordPress 主機更快速地回收這些舊連線，避免在流量高峰時因為連接埠用盡而導致連線失敗或變慢。

MySQL 主機的重點

這台主機扮演的是接收請求的角色。它的壓力來自於同時要處理非常多個來自 WordPress 的連線請求，因此最重要的參數是 net.core.somaxconn。

當瞬間湧入大量查詢時，如果 MySQL 來不及處理，這些請求會先被放在系統的監聽佇列（Listen Queue）中。將這個數值調大（例如 4096），可以防止在高負載時請求被直接丟棄（Packet Drop），確保連線穩定不中斷。

具體操作建議

請在兩台主機分別執行以下步驟：

1. 編輯設定檔：sudo nano /etc/sysctl.conf
2. 將剛才提到的參數貼在檔案最末端。
3. 存檔離開後執行：sudo sysctl -p

如果你之後發現資料庫主機的 CPU 負載過高，那可能就不是網路連線的問題，而是需要調整 MySQL 的 innodb_buffer_pool_size 等記憶體參數。

你想先檢查目前的網路連線狀態，看看是否有大量 TIME_WAIT 堆積嗎？

WordPress 主機的優化建議

這台主機主要是作為 Client 端頻繁發起請求。重點在於加速連線回收與擴大發送端緩衝，避免因為連接埠（Port）回收不及導致的連線延遲。

# 允許將 TIME_WAIT 狀態的連線重新用於新的 TCP 連線
net.ipv4.tcp_tw_reuse = 1
# 增加系統同時保持 TIME_WAIT 的最大數量
net.ipv4.tcp_max_tw_buckets = 50000
# 擴大本機暫時連接埠的範圍，增加可同時建立的連線數
net.ipv4.ip_local_port_range = 1024 65535
# 增加 TCP 傳輸與接收的緩衝區最大值（16MB）
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
# 增加接收封包的排隊佇列
net.core.netdev_max_backlog = 5000
# 調整虛擬記憶體交換傾向
vm.swappiness = 10

MySQL 主機的優化建議

這台主機作為 Server 端負責接收大量併發連線。重點在於擴大監聽佇列（Listen Queue）以及優化記憶體對大型資料傳輸的處理能力，防止請求在系統層級就被丟棄。

# 增加系統同時處理的監聽佇列上限，防止高併發連線溢出
net.core.somaxconn = 8192
# 增加接收封包的排隊佇列
net.core.netdev_max_backlog = 5000
# 擴大 TCP 緩衝區最大值，有利於大型查詢結果的傳輸
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
# 開啟連線重用（Server 端同樣建議開啟）
net.ipv4.tcp_tw_reuse = 1
# 增加 TCP SYN 隊列長度，容納更多等待握手的連線
net.ipv4.tcp_max_syn_backlog = 4096
# 減少快取壓力，優先使用記憶體
vm.swappiness = 10

套用與驗證步驟

將上述內容分別複製到對應主機的 /etc/sysctl.conf 檔案末尾。請確保不要重複設定相同的變數，如果有重複的請以我給的新數值為主。

套用設定請執行：

sudo sysctl -p

驗證連線狀況：

你可以執行 netstat -n | awk '/^tcp/ {print $6}' | sort | uniq -c 來檢查目前連線狀態。如果看到大量的 TIME_WAIT 且你的連線效率還是沒提升，那我們就得從 PHP-FPM 的連線池（Pool）設定下手。

要精確限制只有 10.130.0.6 這個 IP 能夠連線到本機的 3306 埠口，請執行以下指令：

sudo ufw allow from 10.130.0.6 to any port 3306

這條規則會明確指定來源（from）必須是 10.130.0.6，目標（to any）則是本機任何網路介面上的 3306 埠口。如果你有多張網卡，想限制得更嚴格，可以把 any 改成本機在該網路環境下的私人 IP。

確認規則優先順序

在 UFW 中，規則的順序非常重要。如果之前已經有過開放給所有人的規則（例如 allow 3306），新加入的特定 IP 規則可能會失效。請使用以下指令檢查：

sudo ufw status numbered

請確認針對 10.130.0.6 的規則排在最前面。如果發現有其他更寬鬆的規則排在上面（例如 3306 ALLOW ANYWHERE），請使用 sudo ufw delete 加上編號將其刪除，確保防火牆只對特定 IP 放行。

資料庫連線配置

即使防火牆門開了，MySQL 或 MariaDB 如果沒有監聽正確的介面，連線依然會失敗。請檢查設定檔（通常在 /etc/mysql/mariadb.conf.d/50-server.cnf 或 /etc/mysql/mysql.conf.d/mysqld.cnf）：

bind-address = 0.0.0.0

如果這裡設定為 127.0.0.1，則外部 IP（包含 10.130.0.6）將無法連入，因為資料庫只接受來自 localhost 內部的連線。修改後記得重啟資料庫服務：sudo systemctl restart mysql。

查詢 IP 位址與網路設定

在 Ubuntu 中，最常用且推薦的指令是 ip addr，你可以簡寫為 ip a。這個指令會列出所有網路介面的詳細資訊。

常用查詢指令

如果你只需要快速看一眼 IP，或是需要詳細的設定資訊，可以參考以下幾種指令：

• 詳細資訊： ip addr show 或 ip a。這會顯示每個介面的 MAC 位址、IPv4、IPv6 以及運作狀態。
• 精簡格式： ip -br addr。這會以一行一個介面的方式列出 IP，適合快速閱讀。
• 純 IP 位址： hostname -I。這會直接印出本機目前所有的私人 IP，不含其他雜訊。
• 對外公網 IP： curl ifconfig.me。如果你想知道在網際網路上的 IP，可以使用這個指令向外部伺服器查詢。

解讀 ip addr 輸出內容

當你執行 ip a 時，你會看到類似以下的內容：

2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 …

link/ether 08:00:27:xx:xx:xx brd ff:ff:ff:ff:ff:ff

inet 192.168.1.105/24 brd 192.168.1.255 scope global dynamic enp0s3

valid_lft 86134sec preferred_lft 86134sec

• enp0s3： 這是網路介面的名稱（以前常叫 eth0）。
• inet： 後面接的就是你的 IPv4 位址（例如 192.168.1.105）。
• UP： 代表該介面目前正在運作中。
• link/ether： 這是你的硬體位址（MAC Address）。

靜態 IP 設定位置

如果你想修改 IP 設定使其永久生效，Ubuntu 現在預設使用 Netplan 工具。設定檔通常存放在以下路徑：

/etc/netplan/

檔案通常是 .yaml 格式，例如 01-netcfg.yaml。編輯該檔案後，需要執行 sudo netplan apply 才能讓設定生效。

安裝 Zsh

Ubuntu 預設使用 Bash，所以要先安裝 Zsh 並將其設為預設 shell。

Bash

# 更新套件清單
sudo apt update

# 安裝 zsh 與 git（下載框架時需要）
sudo apt install zsh git curl -y

# 確認安裝版本
zsh --version

# 將 Zsh 設為目前使用者的預設 shell
chsh -s $(which zsh)

執行完成後，需要登出並重新登入，或者直接重啟電腦，變更才會生效。

安裝 Oh My Zsh

Oh My Zsh 提供了一鍵安裝腳本，你可以選擇使用 curl 或 wget 來執行。

Bash

# 使用 curl 安裝
sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"

安裝過程中，腳本會詢問是否要將 Zsh 設為預設 shell，如果你剛才已經執行過 chsh，這裡選 Y 或 N 都可以。安裝成功後，你會看到經典的 Oh My Zsh 大 Logo。

常用插件與主題設定

預設的主題是 robbyrussell。如果想修改主題或啟用插件，請編輯家目錄下的設定檔。

Bash

nano ~/.zshrc

在檔案中找到以下內容進行修改：

• 主題：修改 ZSH_THEME=”robbyrussell” 這一行。
• 插件：找到 plugins=(git) 這一行，可以在括號內加入其他預設插件，例如 plugins=(git docker sudo)。

推薦安裝外掛（自動補全與語法高亮）

這兩個外掛能大幅提升使用體驗，需要額外從 GitHub 下載。

Bash

# 語法高亮 (zsh-syntax-highlighting)
git clone https://github.com/zsh-users/zsh-syntax-highlighting.git ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-syntax-highlighting

# 自動補全建議 (zsh-autosuggestions)
git clone https://github.com/zsh-users/zsh-autosuggestions ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-autosuggestions

下載後，請再次編輯 ~/.zshrc，將它們加入 plugins 清單中：

Bash

plugins=(git zsh-syntax-highlighting zsh-autosuggestions)

最後執行 source ~/.zshrc 讓設定立即生效。

這是一個完整的自動化腳本，你可以將其內容複製並存成 install_zsh.sh，然後執行它。這個腳本會幫你安裝 Zsh、Oh My Zsh 以及兩個最受歡迎的插件。

自動化安裝腳本

這個腳本包含了環境檢查與插件配置，適合在乾淨的 Ubuntu 24.04 環境執行。

Bash

#!/bin/bash

# 更新套件並安裝必要工具
sudo apt update && sudo apt install -y zsh git curl

# 下載並安裝 Oh My Zsh (自動跳過互動模式)
sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)" "" --unattended

# 定義插件路徑
ZSH_CUSTOM_DIR=${ZSH_CUSTOM:-$HOME/.oh-my-zsh/custom}

# 安裝 zsh-syntax-highlighting
git clone https://github.com/zsh-users/zsh-syntax-highlighting.git $ZSH_CUSTOM_DIR/plugins/zsh-syntax-highlighting

# 安裝 zsh-autosuggestions
git clone https://github.com/zsh-users/zsh-autosuggestions $ZSH_CUSTOM_DIR/plugins/zsh-autosuggestions

# 修改 .zshrc 啟用插件
sed -i 's/plugins=(git)/plugins=(git zsh-syntax-highlighting zsh-autosuggestions)/' ~/.zshrc

# 切換預設 Shell
sudo chsh -s $(which zsh) $USER

echo "安裝完成，請重新啟動終端機或輸入 'zsh' 開始使用。"

如何執行

請在終端機依照順序輸入以下指令。

Bash

# 建立腳本檔案
nano install_zsh.sh

# 將上面的程式碼貼入後，按 Ctrl+O 儲存，Ctrl+X 離開

# 賦予執行權限
chmod +x install_zsh.sh

# 執行腳本
./install_zsh.sh

注意事項

腳本執行完畢後，目前的畫面可能還是舊的 Bash，請直接輸入 zsh 切換，或者關閉視窗重新開啟。如果你發現指令補全的顏色太暗看不清楚，這是因為終端機配色（如預設的 Ubuntu 紫色背景）與外掛顏色衝突，建議到終端機設定調整配色方案為內建的 Color schemes 即可。

檢查目前的 swap 狀態

在開始之前，先確認系統是否已經有 swap 空間。輸入 free -h 或是 swapon –show。如果輸出結果是空的，代表目前沒有 swap。

建立 swap 檔案

決定你要增加的大小，通常建議是記憶體的 1 倍到 2 倍。這裡以增加 2G 為例。

使用 fallocate 指令快速建立檔案：

sudo fallocate -l 2G /swapfile

如果系統提示找不到 fallocate，也可以使用傳統的 dd 指令：

sudo dd if=/dev/zero of=/swapfile bs=1M count=2048

設定檔案權限

為了安全起見，只有 root 使用者應該有讀寫 swap 檔案的權限。

sudo chmod 600 /swapfile

格式化並啟用檔案

將該檔案轉化為 swap 格式：

sudo mkswap /swapfile

接著啟用它：

sudo swapon /swapfile

此時你可以再次輸入 free -h，應該就能看到 swap 欄位出現了剛才設定的大小。

設定開機自動掛載

目前的設定在重啟伺服器後會消失。為了讓它永久生效，需要修改 /etc/fstab 檔案。

建議先備份檔案：

sudo cp /etc/fstab /etc/fstab.bak

然後將設定寫入：

echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

調整 swappiness 參數

swappiness 決定系統使用 swap 的頻率，數值在 0 到 100 之間。對於 VPS 來說，通常設定在 10 到 60 之間比較合適。數值愈小，系統愈傾向使用實體記憶體。

查看目前數值：

cat /proc/sys/vm/swappiness

如果你想暫時修改為 10：

sudo sysctl vm.swappiness=10

若要永久修改，請編輯 /etc/sysctl.conf

sudo nano /etc/sysctl.conf

在檔案末尾加入

vm.swappiness=10

或直接使用 script 修改

echo "調整 swappiness 為 10..."
sysctl vm.swappiness=10
if ! grep -q "vm.swappiness" /etc/sysctl.conf; then
    echo "vm.swappiness=10" >> /etc/sysctl.conf
else
    sed -i 's/vm.swappiness=.*/vm.swappiness=10/' /etc/sysctl.conf
fi

這是一個自動化腳本，你可以將它儲存在伺服器上執行。這個腳本會自動建立一個 2G 的 swap 檔案，並完成所有權限與永久掛載的設定。

建立自動化腳本

你可以使用 nano 建立檔案：

nano setup_swap.sh

將以下內容貼上：

Bash

#!/bin/bash

# 設定 swap 大小為 2G
SWAP_SIZE="2G"
SWAP_PATH="/swapfile"

# 檢查是否具備 root 權限
if [[ $EUID -ne 0 ]]; then
   echo "請使用 sudo 執行此腳本"
   exit 1
fi

echo "正在建立 ${SWAP_SIZE} 的 swap 檔案..."
fallocate -l $SWAP_SIZE $SWAP_PATH || dd if=/dev/zero of=$SWAP_PATH bs=1M count=2048

echo "設定權限..."
chmod 600 $SWAP_PATH

echo "格式化 swap..."
mkswap $SWAP_PATH

echo "啟用 swap..."
swapon $SWAP_PATH

echo "設定開機自動掛載..."
if ! grep -q "$SWAP_PATH" /etc/fstab; then
    echo "$SWAP_PATH none swap sw 0 0" >> /etc/fstab
fi

echo "調整 swappiness 為 10..."
sysctl vm.swappiness=10
if ! grep -q "vm.swappiness" /etc/sysctl.conf; then
    echo "vm.swappiness=10" >> /etc/sysctl.conf
else
    sed -i 's/vm.swappiness=.*/vm.swappiness=10/' /etc/sysctl.conf
fi

echo "完成！目前的記憶體狀態："
free -h

執行腳本

存檔離開後（Ctrl+O 然後 Ctrl+X），賦予執行權限並執行：

chmod +x setup_swap.sh
sudo ./setup_swap.sh

確認結果

執行完畢後，你可以觀察最後顯示的表格。如果 swap 這一列的總量（total）不再是 0，就代表設定成功。這個腳本也幫你處理了 swappiness 的設定，讓伺服器優先使用物理記憶體，只有在必要時才動用硬碟上的 swap，這有助於維持效能。

使用虛擬環境安裝

這是目前最推薦且標準的作法，可以避免不同專案之間的套件衝突。你必須先安裝 venv 工具，然後建立一個獨立的資料夾來存放套件。

sudo apt update
sudo apt install python3-venv
python3 -m venv myenv
source myenv/bin/activate

進入虛擬環境後，終端機提示字元前會出現環境名稱，這時你就可以放心使用 pip install 安裝任何套件，它們會被存放在 myenv 資料夾內。

使用 pipx 安裝工具

如果你想安裝的是像 black、ansible 或 flake8 這種可以在終端機直接執行的工具，而不是要在程式碼裡 import 的函式庫，pipx 是最好的選擇。它會自動幫每個工具建立隔離環境並設定好執行路徑。

sudo apt install pipx
pipx ensurepath
pipx install 套件名稱

使用 APT 系統套件管理

如果你需要的套件非常常見，例如 NumPy 或 Requests，Ubuntu 的官方軟體倉庫通常會有維護好的版本。這些套件會安裝在全域，且由系統統一管理。

sudo apt install python3-numpy

強制全域安裝

雖然非常不建議，但如果你非得在全域環境安裝套件且不在乎系統穩定性，可以使用 break-system-packages 參數來跳過保護機制。請注意這可能會導致 Ubuntu 系統內建的 Python 工具故障。

pip install 套件名稱 --break-system-packages

要退出已經啟動的 Python 虛擬環境，方法非常簡單，只需要在終端機輸入一個指令即可。

使用 deactivate 指令

當你完成工作，想要回到 Ubuntu 系統預設的 Python 環境時，直接輸入：

deactivate

執行後，你會發現終端機提示字元前方的括號環境名稱（例如 (myenv)）消失了，這表示你已經成功登出虛擬環境。這個指令不需要加上 sudo，也不需要路徑，因為在你啟動環境時，deactivate 函式就已經被載入到目前的 shell 階段中。

刪除虛擬環境

如果你不再需要這個虛擬環境，想要徹底移除它，做法並非透過 pip 卸載，而是直接刪除該環境所在的資料夾。

rm -rf myenv

這會刪除所有在該環境中安裝的套件與相關設定，且不會影響到系統其他的 Python 設定。

python3 -m pip install pr pip-req.txt
error: externally-managed-environment

× This environment is externally managed
╰─> To install Python packages system-wide, try apt install
python3-xyz, where xyz is the package you are trying to
install.

If you wish to install a non-Debian-packaged Python package,
create a virtual environment using python3 -m venv path/to/venv.
Then use path/to/venv/bin/python and path/to/venv/bin/pip. Make
sure you have python3-full installed.

If you wish to install a non-Debian packaged Python application,
it may be easiest to use pipx install xyz, which will manage a
virtual environment for you. Make sure you have pipx installed.

See /usr/share/doc/python3.12/README.venv for more information.

note: If you believe this is a mistake, please contact your Python installation or OS distribution provider. You can override this, at the risk of breaking your Python installation or OS, by passing –break-system-packages.
hint: See PEP 668 for the detailed specification.

python3 -m venv ./venv
The virtual environment was not created successfully because ensurepip is not
available. On Debian/Ubuntu systems, you need to install the python3-venv
package using the following command.

apt install python3.12-venv

You may need to use sudo with that command. After installing the python3-venv
package, recreate your virtual environment.

Failing command: /root/venv/bin/python3

➜ ~ apt install python3-venv

在 Ubuntu 24.04 上為 Python 3.12 安裝 MySQL 連接器，最穩定的做法是透過虛擬環境。目前主流有兩種套件選擇：官方的 mysql-connector-python 或社群常用的 mysqlclient。

準備系統依賴項目

在安裝 Python 套件之前，建議先安裝編譯所需的系統開發庫。如果是要安裝 mysqlclient（效能較好），則必須先執行以下指令：

sudo apt update

sudo apt install python3-dev default-libmysqlclient-dev build-essential

在虛擬環境中安裝

首先建立並進入虛擬環境，接著使用 pip 安裝。

python3 -m venv env

source env/bin/activate

如果你想安裝官方提供的連接器：

pip install mysql-connector-python

如果你想安裝效能較佳、符合 Python DB API 規範的套件：

pip install mysqlclient

驗證安裝結果

你可以進入 Python 互動環境測試是否安裝成功：

python

import mysql.connector

print(mysql.connector.version)

或是針對 mysqlclient：

python

import MySQLdb

print(MySQLdb.version)

使用 APT 安裝（全域環境）

如果你不想使用虛擬環境，而是希望整個系統都能使用，可以使用 Ubuntu 官方維護的套件。這會自動處理所有依賴關係，且不會觸發 PEP 668 的外部環境錯誤。

sudo apt install python3-mysql.connector

這種方式安裝的版本通常比較舊，但保證與系統相容。

需要我提供一段連接 MySQL 資料庫並執行查詢的範例程式碼嗎？

準備工作

在開始搬運之前，請確保你已經把新伺服器的 SSH 公鑰加入到舊伺服器，或者擁有新伺服器的 root 密碼。此外，新舊伺服器之間必須網路互通，因為你提供的是私有 IP (10.130.0.5)，這代表兩台伺服器必須位在同一個 VPS 的 VPC 網路內。

執行資料搬移

請在舊伺服器上執行以下指令，這會將 /root 目錄下的所有內容同步到新伺服器：

rsync -avzP /root/ root@10.130.0.5:/root/

指令參數解釋：

• -a：代表歸檔模式，會保留連結檔、權限、時間戳記等資訊。
• -v：顯示詳細過程。
• -z：傳輸時進行壓縮，加快速度。
• -P：顯示進度條，如果中斷了可以續傳。

搬移系統設定檔

如果你指的 config 包含 /etc 底下的系統設定（例如 Nginx 或資料庫設定），建議針對特定目錄個別搬移，而不是直接覆蓋整個 /etc，因為新舊伺服器的硬體驅動或部分系統組件可能略有不同。

例如搬移 Nginx 設定：

rsync -avzP /etc/nginx/ root@10.130.0.5:/etc/nginx/

資料庫搬移建議

如果你的 /root 底下包含資料庫原始檔案（例如 MySQL 的 /var/lib/mysql），直接用 rsync 搬移運行中的資料庫檔案可能會導致資料損壞。建議先在舊伺服器執行資料庫匯出（dump），將產出的 .sql 檔放在 /root 內，再執行上述的 rsync 指令，最後到新伺服器匯入。

這是一個簡單的自動化搬移腳本。這個腳本會先在舊伺服器將資料庫打包（假設使用 MySQL/MariaDB），接著把 /root 目錄與指定的設定目錄同步到新伺服器。

自動化搬移腳本

請在舊伺服器上建立一個名為 migrate.sh 的檔案，並貼入以下內容：

#!/bin/bash
# 設定變數
NEW_SERVER_IP="10.130.0.5"
BACKUP_SQL="/root/all_databases.sql"

echo "正在匯出資料庫..."
mysqldump --all-databases > $BACKUP_SQL

echo "正在傳輸 /root 目錄資料..."
rsync -avzP /root/ root@$NEW_SERVER_IP:/root/

echo "正在傳輸 Nginx 設定 (如果有)..."
if [ -d "/etc/nginx" ]; then
    rsync -avzP /etc/nginx/ root@$NEW_SERVER_IP:/etc/nginx/
fi

echo "正在傳輸 SSL 憑證 (LetsEncrypt)..."
if [ -d "/etc/letsencrypt" ]; then
    rsync -avzP /etc/letsencrypt/ root@$NEW_SERVER_IP:/etc/letsencrypt/
fi

echo "搬移完成"

如果要改變 port

#!/bin/bash

# 設定變數
NEW_SERVER_IP="10.130.0.5"
PORT="22"

echo "正在傳輸 /root 目錄資料 (Port: $PORT)..."
rsync -avzP -e "ssh -p $PORT" /root/ root@$NEW_SERVER_IP:/root/

修改後的指令碼

如果你想要在使用 rsync 時排除所有以點號開頭的隱藏檔案或目錄，可以使用 –exclude 參數並配合通配符。

NEW_SERVER_IP="10.130.0.5"
PORT="22"

echo "正在傳輸 /root 目錄資料 (排除隱藏檔, Port: $PORT)..."
rsync -avzP -e "ssh -p $PORT" --exclude=".*" /root/ root@$NEW_SERVER_IP:/root/

參數說明

在 rsync 中加入 –exclude=”.*” 會讓程式跳過所有名稱開頭為點的檔案與資料夾。這包括常見的設定檔如 .bashrc 或隱藏目錄如 .ssh。

需要注意的是，這個寫法會排除所有層級下的隱藏內容。如果你原本的 /root/ 目錄下有特定的隱藏資料夾是你需要的，則必須改用更具體的排除規則。另外，rsync 預設就不會處理代表目前目錄的 . 與上層目錄的 ..，所以加上這個排除規則不會影響基本的目錄定位。

搬移自定義 Service 設定檔

在 Linux 系統中，使用者自定義的 service 設定檔通常放在 /etc/systemd/system/ 目錄下。你可以延用之前的 rsync 指令，將這些 .service 檔案同步到新伺服器。

NEW_SERVER_IP="10.130.0.5"
PORT="22"
echo "正在傳輸自定義 service 設定檔 (Port: $PORT)..."
rsync -avzP -e "ssh -p $PORT" /etc/systemd/system/*.service root@$NEW_SERVER_IP:/etc/systemd/system/

注意事項與後續步驟

同步完成後，新伺服器不會自動偵測到這些新檔案，你需要手動執行以下步驟來啟動服務：

重新載入系統設定登入新伺服器，執行以下指令讓系統辨識新加入的 service 檔案：

systemctl daemon-reload

啟用並啟動服務針對你搬移過來的特定服務，執行啟用與啟動指令：

systemctl enable 服務名稱
systemctl start 服務名稱

安全建議

如果你的 service 檔案中包含 ExecStart 指向的路徑（例如 /root/my-app/start.sh），請確保這些執行檔也已經透過之前的指令搬移到新伺服器的相同位置，否則服務將無法順利啟動。

這是一個自動化腳本片段，你可以將它加入到之前的搬移腳本中。這段程式碼會找出你搬移過去的 service 檔案名稱，並在新伺服器上執行重新載入與啟動的動作。

自動化啟動腳本 (新伺服器執行)

你可以將以下指令存在新伺服器的 setup_services.sh 並執行：

#!/bin/bash

echo "正在重新載入 systemd 設定..."
systemctl daemon-reload

# 取得剛剛搬移過來的自定義 service 列表 (排除系統預設連結)
SERVICES=$(ls /etc/systemd/system/*.service | xargs -n 1 basename)

for SERVICE in $SERVICES; do
    echo "正在啟動並設定服務開機啟動: $SERVICE"
    systemctl enable $SERVICE
    systemctl restart $SERVICE
done

echo "所有自定義服務已嘗試啟動，請執行 systemctl status [服務名] 檢查狀態"

遠端一鍵執行 (從舊伺服器觸發)

如果你希望在舊伺服器同步完檔案後，直接遠端觸發新伺服器載入設定，可以在原本的 rsync 指令後加上這行：

ssh -p $PORT root@$NEW_SERVER_IP "systemctl daemon-reload && echo '新伺服器已重新載入設定'"

貼心提醒

自定義服務通常會依賴特定的執行環境，請確認以下項目在新伺服器是否已就緒：

1. 執行路徑：檢查 .service 檔內的 ExecStart 路徑是否存在。如果路徑是在 /root 底下，請確認你之前的 rsync 已經完整同步該目錄。
2. 軟體環境：如果你的服務是用 Python、Node.js 或 Docker 執行，新伺服器必須先安裝好對應的 runtime。
3. 使用者權限：如果服務設定以特定使用者執行 (User=xxx)，新伺服器必須建立該使用者。

執行腳本

賦予執行權限並執行：

chmod +x migrate.sh
./migrate.sh

後續操作

當資料傳輸完成後，請登入到新伺服器（10.130.0.5）執行以下步驟來恢復資料庫：

mysql < /root/all_databases.sql

如果你的服務包含 Nginx 或 Docker，記得在新伺服器安裝對應的軟體後，重啟服務以讀取搬過來的設定檔。

為了讓新伺服器能承接舊有的服務，你需要安裝與舊伺服器相同的執行環境。以下是一個針對常見網頁環境（Ubuntu/Debian 系統）的自動化安裝腳本，它會安裝 Nginx、MariaDB（MySQL）以及 PHP。

環境安裝腳本

請在新伺服器（10.130.0.5）建立並執行這個腳本：

#!/bin/bash

echo "更新系統軟體源..."
apt update && apt upgrade -y

echo "安裝基礎工具..."
apt install -y curl wget vim rsync unzip

echo "安裝 Nginx..."
apt install -y nginx

echo "安裝 MariaDB 資料庫..."
apt install -y mariadb-server
systemctl enable mariadb
systemctl start mariadb

echo "安裝 PHP 常用組件..."
apt install -y php-fpm php-mysql php-common php-cli

echo "環境安裝完成"

匯入資料與恢復服務

在環境安裝好，且你已經執行過舊伺服器的搬移腳本後，請在新伺服器執行以下指令來完成最後的對接：

匯入資料庫：

mysql < /root/all_databases.sql

檢查 Nginx 設定並重啟：

nginx -t && systemctl restart nginx

注意事項

由於新舊伺服器的 IP 不同，如果你的設定檔（如 Nginx 的 config 或網站的 wp-config.php）中有寫死舊伺服器的 IP 位址，記得要搜尋並修改為新伺服器的位址。另外，如果原本有設定防火牆（如 ufw），在新伺服器上也需要重新開啟對應的連接埠（80, 443, 22 等）。

既然要使用 MySQL，我們需要調整安裝腳本的套件名稱，並在安裝過程中處理可能的權限問題。

MySQL 環境安裝腳本

請在新伺服器（10.130.0.5）執行以下指令：

#!/bin/bash

echo "更新系統軟體源..."
apt update

echo "安裝 MySQL Server..."
# 設定非互動模式，避免安裝過程跳出視窗要求輸入密碼
export DEBIAN_FRONTEND=noninteractive
apt install -y mysql-server

echo "啟動並設定 MySQL 開機自啟..."
systemctl start mysql
systemctl enable mysql

echo "安裝 Nginx 與 PHP 組件..."
apt install -y nginx php-fpm php-mysql

echo "MySQL 環境安裝完成"

匯入資料庫的注意事項

在執行 mysql < /root/all_databases.sql 之前，由於 MySQL 8.0 以上版本的 root 帳號預設使用 auth_socket 認證，你可能需要使用 sudo 權限才能順利匯入：

sudo mysql < /root/all_databases.sql

調整舊 IP 關鍵字

如果你擔心舊的設定檔（例如 Nginx config）裡還留著舊伺服器的 IP，可以在新伺服器的 /etc 目錄執行這行指令，將所有舊 IP 批次替換成新的（請將 1.2.3.4 替換為你的舊伺服器公網或私網 IP）：

grep -rl "1.2.3.4" /etc/nginx | xargs sed -i 's/1.2.3.4/10.130.0.5/g'

最後記得重啟服務讓設定生效：

systemctl restart nginx
systemctl restart mysql

伺服器現況分析

從你提供的日誌來看，你的伺服器正在遭受大規模的自動化掃描攻擊。這些攻擊者利用工具不斷嘗試存取你多個 WordPress 網站的敏感目錄，例如 wp-includes 或 wp-admin。雖然 Apache 正確地攔截了這些請求並顯示 client denied，但短時間內湧入的龐大連線數已經讓你的系統吃不消。在重啟之前，load average 高達 56，這表示你的 CPU 負載已經爆表，且 1GB 的記憶體完全耗盡，迫使系統頻繁使用硬碟的 Swap 空間，這正是伺服器變得極度緩慢的主因。

重啟後的觀察

重啟 Apache 後，記憶體雖然釋放出了一些空間，load average 也降到了 22，但這個數值對 1GB 的小主機來說依然非常危險。日誌中出現的大量 TIME_WAIT 代表剛才有非常多連線被切斷。目前掃描行為明顯還在持續，如果不做進一步的防護，系統很快會再次因為記憶體不足而陷入卡頓。此外，你在這台小主機上跑了至少五個不同的 WordPress 網站，這會讓資源分配變得非常吃緊。

具體應對建議

既然你的伺服器在 Cloudflare 後面，最有效的辦法是到 Cloudflare 的後台開啟 Under Attack 模式，或者建立 WAF 防護規則。你可以設定一條規則：只要請求的路徑包含 wp-includes 或以 .php 結尾且位於敏感目錄，就直接在 Cloudflare 端阻擋或要求驗證。這樣惡意流量就不會直接撞擊你的 Apache。另外，建議你檢查各個網站的 .htaccess 檔案，確保已經關閉目錄瀏覽功能。如果預算允許，這台主機的記憶體建議增加到 2GB 以上，才能比較穩定地運行這麼多網站。

Cloudflare WAF 防護規則建議

既然你的日誌顯示攻擊者都在掃描 wp-includes 與 wp-admin 底下的特定 PHP 檔案，你可以直接在 Cloudflare 的 Security -> WAF 建立一條規則。這能讓惡意請求在到達你的 Ubuntu 伺服器前就被攔截，大幅降低 CPU 負載與記憶體消耗。

建議的 WAF 規則邏輯

你可以選擇 Block (直接阻擋) 或 Managed Challenge (要求過圖形驗證)。規則條件建議如下：

• Field: URI Path
• Operator: contains
• Value: /wp-includes/
• AND
• Field: URI Path
• Operator: ends with
• Value: .php

這條規則會抓出所有嘗試直接執行 wp-includes 資料夾內程式碼的行為，這在正常的 WordPress 運作中幾乎是不需要的。

伺服器端優化建議

除了外層防護，你的主機目前資源非常緊繃，建議調整 Apache 的設定來避免記憶體被耗盡：

• 降低 MaxRequestWorkers: 你的記憶體僅 1GB，如果這個數值設得太高，當攻擊來襲時，Apache 會開啟過多處理程序導致進入 Swap。
• 調整 KeepAliveTimeout: 將這個數值改為 2 或 3 秒，讓閒置連線快點斷開，釋放資源給下一個請求。
• 安裝 Fail2Ban: 雖然在 Cloudflare 後面，但如果你有安裝 mod_remoteip，Fail2Ban 依然可以根據日誌自動將頻繁掃描的 IP 加入系統防火牆阻擋。

Apache 記憶體優化設定

針對 1GB 記憶體的伺服器，我們必須嚴格限制 Apache 的行程數量，避免它把記憶體吃光導致系統進入 Swap 甚至當機。請根據你使用的 MPM 模式（通常是 event 或 worker）修改設定。

請編輯 /etc/apache2/mods-available/mpm_event.conf 或 /etc/apache2/mods-available/mpm_worker.conf：

Apache

<IfModule mpm_event_module>
    StartServers             2
    MinSpareThreads          10
    MaxSpareThreads          25
    ThreadsPerChild          25
    # 這是關鍵，限制最大同時連線數，1GB 建議設在 100-150 之間
    MaxRequestWorkers        100
    MaxConnectionsPerChild   1000
</IfModule>

連線控制優化

接著請編輯 /etc/apache2/apache2.conf，調整連線回收的速度：

• KeepAlive On: 保持開啟，但要縮短時間。
• MaxKeepAliveRequests 100: 限制每個連線的請求數。
• KeepAliveTimeout 2: 原本預設通常是 5 秒，縮短到 2 秒可以讓無用的連線趕快斷開。

針對 wp-includes 的本地端防護

雖然 Cloudflare 擋了第一層，但在伺服器本機端也可以加上這段設定，直接在 Apache 層級拒絕非法存取。請將此段加入你的 VirtualHost 設定中：

Apache

<Directory "/var/www/*/wp-includes">
    <Files "*.php">
        Require all denied
    </Files>
</Directory>

這樣即便攻擊者繞過 Cloudflare 直接連到你伺服器的 IP，Apache 也會直接回絕請求，不會去執行 PHP 程式，能省下大量 CPU 運算。

設定完成後，請記得執行 sudo apachectl configtest 確認沒語法錯誤，再重啟服務：

sudo systemctl restart apache2

在 Ubuntu 系統中，這類設定通常有兩個地方可以放，取決於你想針對單一網站還是全伺服器生效。

1. 針對特定網站（建議做法）

如果你想針對特定的 WordPress 網站進行防護，請到 /etc/apache2/sites-available/ 目錄下找對應的設定檔。例如你的網站名稱可能是 vpn.conf 或 000-default.conf。

你可以使用這個指令列出所有啟用的設定檔路徑：

ls /etc/apache2/sites-enabled/

然後使用編輯器開啟該檔案：

sudo nano /etc/apache2/sites-available/你的檔案名稱.conf

將防護程式碼放在 <VirtualHost *:80> 或 <VirtualHost *:443> 的區塊內即可。

2. 針對伺服器所有網站

因為你這台主機跑了 vpn, jasonfonts, stackoverflow, krita 等多個網站，如果你想一次全部保護，可以修改全域安全性設定檔：

sudo nano /etc/apache2/conf-available/security.conf

將這段程式碼貼在檔案的最末端：

Apache

<Directory "/var/www/*/wp-includes">
    <Files "*.php">
        Require all denied
    </Files>
</Directory>

<Directory "/var/www/*/wp-content/uploads">
    <Files "*.php">
        Require all denied
    </Files>
</Directory>

補充：我也順便幫你加上了 uploads 資料夾的 PHP 阻擋，因為那是駭客最常上傳惡意後門程式的地方。

3. 套用並重啟

如果你是修改 security.conf，請確保該設定檔已啟用：

sudo a2enconf security

最後檢查語法並重啟 Apache：

sudo apachectl configtest

sudo systemctl restart apache2

你可以將新的規則邏輯直接加入現有的表達式中。為了讓規則更嚴謹，我們使用括號將 wp-includes 的路徑與 .php 副檔名組合起來。

修改後的 Cloudflare WAF 規則表達式如下：

SQL

(http.request.uri.path contains "/cgi-bin/") 
or (http.referer contains "binance.com") 
or (http.request.uri.path eq "/xmlrpc.php")
or (http.request.uri.path contains "/wp-includes/" and http.request.uri.path targets_lib_path_suffix ".php")

或是更直覺的寫法：

SQL

(http.request.uri.path contains "/cgi-bin/") 
or (http.referer contains "binance.com") 
or (http.request.uri.path eq "/xmlrpc.php")
or (http.request.uri.path contains "/wp-includes/" and http.request.uri.path matches ".*\.php$")

設定說明

• 為什麼要加 AND: 如果只阻擋 /wp-includes/，會連帶擋掉正常的 CSS 或 JS 檔案，導致網站排版壞掉。加上 .php 的條件後，就只會針對該目錄下的程式執行檔進行阻擋，這是最安全的作法。
• 建議動作 (Action): 既然你目前的 Log 顯示這全是惡意掃描，建議將此規則的 Action 設為 Block（阻擋）或 Managed Challenge（驗證碼）。

後續檢查

設定完成後，你可以觀察 Cloudflare 的 Security -> Events，看是否有攔截到來自 /wp-includes/ 的請求。如果攔截成功，你 Ubuntu 伺服器上的 Apache error.log 應該就不會再出現這些 IP 的掃描紀錄，系統負載也會隨之下降。

既然無法使用 Matches 運算子，我們可以改用比較基礎的 contains 或 ends with 來組合。這在 Cloudflare 免費版或一般方案都能運作。

修改後的 WAF 規則建議

你可以將表達式改成以下內容，這樣就不需要 Matches：

SQL

(http.request.uri.path contains "/cgi-bin/") 
or (http.referer contains "binance.com") 
or (http.request.uri.path eq "/xmlrpc.php")
or (http.request.uri.path contains "/wp-includes/" and http.request.uri.path contains ".php")

為什麼這樣寫有效

• contains “.php”: 雖然沒有正則表達式那麼精準，但絕大多數針對 wp-includes 的攻擊都是直接存取 .php 檔案。在正常情況下，WordPress 核心不會讓使用者從瀏覽器直接讀取該目錄下的 PHP 檔案，所以這條規則非常安全。
• 組合條件: 透過 and 將目錄與副檔名綁在一起，可以確保不會誤擋到 wp-includes 裡的圖片或樣式表（CSS/JS）。

操作步驟

1. 登入 Cloudflare，進入 Security > WAF。
2. 點擊現有規則旁邊的 Edit。
3. 點擊右下角的 Edit expression 切換到純文字模式。
4. 將上面的代碼貼上並點擊 Deploy。

設定完成後，建議你先觀察半小時，看伺服器的 load average 是否有從 22 慢慢降下來。如果還有其他特定路徑在報錯，我們可以再繼續擴充這條規則。

好的，我們把 wp-content/uploads 的防護也併入。在 WordPress 中，uploads 資料夾是用來存放圖片和媒體檔的，絕對不應該出現任何可執行的 .php 檔案。如果有人嘗試在裡面執行 PHP，那幾乎可以確定是駭客上傳了後門程式。

更新後的 Cloudflare WAF 表達式

請將規則更新為以下內容：

SQL

(http.request.uri.path contains "/cgi-bin/") 
or (http.referer contains "binance.com") 
or (http.request.uri.path eq "/xmlrpc.php")
or (http.request.uri.path contains "/wp-includes/" and http.request.uri.path contains ".php")
or (http.request.uri.path contains "/wp-content/uploads/" and http.request.uri.path contains ".php")

規則說明與後續建議

• 阻擋 uploads 內的 PHP: 這是非常強效的防護。駭客最常見的手法是利用外掛漏洞上傳一個名為 shell.php 或 info.php 的檔案到圖片區。現在這條規則會在對方執行這些後門時，直接在 Cloudflare 端切斷連線。
• 確認負載: 更新規則後，你可以再次觀察伺服器的 top 指令或 load average。如果規則奏效，連線數（Connection Counts）裡的 ESTABLISHED 數量應該會顯著減少，因為惡意請求在進入你的 Apache 之前就被擋掉了。
• 檢查其他目錄: 你的日誌中還提到了 wp-admin/css/colors/ectoplasm/ 這種奇怪的掃描，這通常是針對特定外掛漏洞。目前的規則已經涵蓋了最危險的兩個區域（includes 和 uploads）。

要查看 Cloudflare 攔截了哪些 IP，請按照以下步驟操作，這能幫你確認防護規則是否發揮作用：

1. 進入 Cloudflare 事件日誌

登入 Cloudflare 後，在左側選單點擊 Security（安全性） > Events（事件）。

2. 查看活動摘要

在該頁面你會看到一個圖表和下方的清單。你可以從清單中看到：

• Action taken: 如果顯示 Block，表示該請求已被成功攔截。
• Rule ID: 確認是否為剛才設定的那條 WAF 規則。
• IP address: 攻擊者的來源 IP。
• Path: 對方嘗試存取的路徑（例如 /wp-includes/xxx.php）。

3. 使用篩選功能（選用）

如果事件太多，你可以點擊 Add filter，選擇 Service 等於 WAF，或是直接搜尋特定路徑，這樣就能精確看到針對 WordPress 敏感目錄的攻擊頻率。

觀察伺服器壓力是否釋放

在 Cloudflare 設定好之後，建議你在 Ubuntu 終端機執行 uptime 或 top。

• 如果 load average 從原本的 20-50 降到 2 以下，說明 Cloudflare 已經幫你的 CPU 擋掉了大半的工作。
• 如果負載依然很高，請再執行一次 netstat -n | awk '/^tcp/ {print $6}' | sort | uniq -c | sort -n，看看 ESTABLISHED 的數量有沒有減少。

如果負載還是降不下來，可能還有其他非 PHP 的資源存取（例如大量的圖片請求）在消耗頻寬，到時候我們再針對那些行為調整規則。

[Mon Jan 26 00:26:10.407883 2026] [core:error] [pid 13727:tid 13727] [client 103.142.62.35:34636] AH10244: invalid URI path (/cgi-bin/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/bin/sh)

攻擊行為分析

對手嘗試利用 /%2e%2e/（即 ../ 的編碼）來跳出網頁根目錄，目標是存取系統底層的 /bin/sh（Shell 執行檔）。這是一種典型的自動化漏洞掃描，試圖尋找設定不當的 CGI 腳本來執行遠端指令。

好消息是，日誌中的 AH10244: invalid URI path 代表 Apache 的核心模組已經識別出這是一個無效且具威脅的路徑，並在進入任何處理程序前就直接封鎖了它。這說明你的 Apache 版本（2.4.66）具有基本的防護能力。

進一步防護建議

雖然 Apache 已經幫你擋下了，但這種掃描會佔用連線資源。

1. 使用 Fail2Ban 自動封鎖 IP

你可以設定 Fail2Ban 監控 error.log。只要同一個 IP 出現多次 AH10244 或 AH01276 等錯誤，就直接在系統防火牆（iptables/ufw）層級封鎖該 IP。這樣流量連進入 Apache 的機會都沒有，能徹底節省 CPU 資源。

2. 停用不必要的 CGI 模組

如果你沒有使用 CGI 腳本，建議確保相關模組已關閉，減少攻擊面：

sudo a2dismod cgi
sudo a2dismod cgid
sudo systemctl restart apache2

3. 檢查檔案權限

請確認 /var/www/ 以外的系統目錄權限正確，確保 www-data 使用者無法讀取 /etc/shadow 或執行不必要的系統指令。

目前 Apache 已經正確攔截了這個請求，你不需要太過驚慌。

要在 Cloudflare 阻擋這種路徑穿越（Path Traversal）攻擊，最快且最有效的方式是建立一條 WAF Custom Rule。這類攻擊的特徵非常明顯，通常包含 cgi-bin 或連續的 ../（或其編碼後的變體如 %2e%2e）。

Cloudflare WAF 規則設定步驟

1. 登入 Cloudflare，進入你的網站網域。
2. 導覽至 Security (安全性) -> WAF -> Custom rules (自訂規則)。
3. 點擊 Create rule (建立規則)。

請依照以下內容填寫：

• Rule name: Block Path Traversal and CGI Scans
• If incoming requests match: (使用 Edit expression 模式貼入以下代碼，或手動建立欄位)

欄位設定建議：

進階 Expression (直接貼入 Edit expression 效果更好)：

SQL

(http.request.uri.path contains "/cgi-bin/") or (http.request.uri.path contains "..") or (http.request.uri.path contains "%2e%2e")

• Choose action: Block (直接封鎖)
• 最後點擊 Deploy (部署)。

為什麼這樣設定有效？

這條規則鎖定了攻擊者的核心手段。

首先，cgi-bin 是老式伺服器漏洞的常見入口，現代 WordPress 網站幾乎不會用到這個路徑，直接阻斷可以過濾掉大量老舊漏洞掃描器。

其次，針對 .. 和 %2e%2e 的檢查，能攔截所有嘗試跳出網頁根目錄的行為。即便攻擊者像你提供的日誌那樣使用了雙重編碼或變體（例如 .%%32%65），Cloudflare 的 WAF 在解碼處理後通常也能識別出其代表的 .. 意圖。

額外安全加固建議

如果你發現攻擊依然頻繁，可以考慮在同一條規則中增加 Bot Score 的判斷：

• 在規則中加入 And (Cloudflare Bot Score < 30)。
• 這會確保這條嚴格的規則主要針對自動化腳本，而不影響少數可能路徑中帶有兩個點的正常開發者工具或特殊網頁。

部署完這條規則後，你可以觀察 Cloudflare 的 Events (事件) 儀表板。你應該會看到這些 cgi-bin 的請求在到達你的伺服器之前，就已經被 Cloudflare 擋下來了。

需要我幫你確認如何合併之前提到的 binance.com Referer 規則到這條新規則中嗎？

將這幾項威脅合併成一條 Cloudflare 規則是最高效的做法，這樣可以減少規則數量的消耗，同時一次解決多種掃描問題。

合併規則設定步驟

在 Cloudflare 的 Custom rules 中，點擊進入剛才建立的規則，選擇 Edit expression 模式，直接將以下內容替換進去：

SQL

(http.request.uri.path contains "/cgi-bin/") 
or (http.request.uri.path contains "..") 
or (http.request.uri.path contains "%2e%2e") 
or (http.referer contains "binance.com")
or (http.request.uri.path eq "/xmlrpc.php")

規則內容詳解

這條合併後的規則包含了以下三道防線：

1. 路徑穿越與 CGI 掃描：cgi-bin、.. 與 %2e%2e 會攔截嘗試讀取系統底層檔案（如 /bin/sh）的行為。
2. 特定的惡意來源：referer contains "binance.com" 會阻斷你日誌中看到的那批偽裝來源。
3. XML-RPC 保護：uri.path eq "/xmlrpc.php" 直接在雲端攔截針對 WordPress 的暴力破解與 Pingback 攻擊，流量完全不會進到你的主機。

驗證效果

部署完這條合併規則後，建議你觀察以下兩處：

一、 Cloudflare Events (安全性事件)

在 Security -> Events 頁面，你應該會看到大片的 Block 紀錄。點開細節，你會發現這些請求的來源（Source）是 WAF custom rule，這代表它們在到達你的 Apache 之前就被解決掉了。

二、 Apache Error Log

再次檢查你的 error.log。原本頻繁出現的 AH10244（URI 無效）或 AH01797（Denied by config）應該會顯著減少。更重要的是，那條關於 MaxRequestWorkers reached 的警告應該不再出現，因為連線資源已經釋放出來給正常的使用者了。

設定完成後，你的伺服器負載應該會大幅下降。