如果你希望達到「保護敏感目錄，但又不誤殺正常圖片」且「排除多個網段與 IP」的效果，你需要修改原本的運算式。

目前的規則因為使用了 wildcard 且沒有限制檔案類型，會導致該資料夾下所有東西（含圖片、CSS、JS）都被封鎖。

推薦的 Expression 寫法

請在 Cloudflare WAF 規則編輯頁面點擊 Edit expression，並將以下內容貼入：

Plaintext

(
  (http.request.uri.path contains "/wp-includes/" and not http.request.uri.path contains ".js" and not http.request.uri.path contains ".css" and not http.request.uri.path contains ".gif") 
  or 
  (http.request.uri.path contains "/wp-content/uploads/" and http.request.uri.path contains ".php")
) 
and not (ip.src in {140.0.0.0/8 1.1.1.1})

請將 1.1.1.1 替換為你實際的其他管理 IP。

邏輯重點說明

• 精準防禦 wp-includes：這個目錄通常不應該被直接存取 PHP 檔案。但我排除了 .js 與 .css，因為有些佈景主題或外掛會需要載入這裡的靜態資源，這樣寫可以避免網站版面壞掉。
• uploads 目錄只擋 PHP：針對 /wp-content/uploads/，我們只封鎖 .php 檔案。這能精準擋掉上傳漏洞（Webshell），同時讓你所有的 .jpg、.png 圖片都能正常顯示。
• 白名單機制：後方的 and not (ip.src in { ... }) 會把你的 140 網段和其他指定 IP 排除在規則之外，讓你擁有最高權限。

設定後的檢查清單

1. 檢查圖片：點擊你之前貼的那張圖片連結，確認是否能正常開啟。
2. 檢查 VPS 負載：回到終端機輸入 top。
   • 如果 load average 降到 1.0 ~ 2.0 之間。
   • 如果 %Cpu(s) 的 id (idle) 數值增加。
   • 如果 php-fpm 的進程數量明顯減少。

這代表你的 WAF 已經在第一線發揮作用，把攻擊擋在 Cloudflare，你的伺服器終於可以「休息」處理正常的請求了。

你的網頁變白，是因為 Cloudflare 的 Rocket Loader 與你的 React 代碼發生了衝突。Rocket Loader 的原理是延遲所有 JavaScript 的執行，來讓網頁載入看起來變快。

但你的程式碼使用了 @babel/standalone 在瀏覽器現場解析 React。當 Rocket Loader介入時，它會打亂腳本執行的順序。原本應該先由 Babel 解析的代碼，可能因為順序錯亂而沒被處理，導致瀏覽器看不懂 <App /> 這種 JSX 語法，最後就卡死在空白畫面。

解決方法：關閉 Rocket Loader

最直接的解決方式是在 Cloudflare 控制台關閉這個功能。這是一個常見的坑，特別是對於直接在 HTML 寫 React 的專案。

1. 登入 Cloudflare 後台，選擇你的網域。
2. 點擊左側選單的 Speed（速度） -> Optimization（最佳化）。
3. 在標籤分頁中找到 Content Optimization。
4. 將 Rocket Loader 選項切換為 Off（關閉）。

另一種解法：略過特定腳本

如果你想保留 Rocket Loader 的其他功能，只想讓 React 正常運作，你可以告訴 Cloudflare 不要動你的腳本。

在你 HTML 裡所有的 <script> 標籤中，加入 data-cfasync="false"。例如：

<script data-cfasync="false" src="..."></script>

這樣 Cloudflare 就會跳過這些腳本，按照原本的順序執行，React 就能正常渲染畫面。

對網站速度的直覺影響

關閉 Rocket Loader 後，最明顯的變化是 WordPress 的 JavaScript 檔案會回到「原始載入順序」。如果你的佈景主題或外掛（例如投影片、彈出視窗）使用了大量的腳本，網頁在載入初期可能會感覺稍微慢一點點，因為瀏覽器必須先下載並執行這些 JS 檔案。

不過，這對於 WordPress 來說通常是更安全的做法。Rocket Loader 雖然能提高跑分數據，但它經常會導致某些功能失靈，比如選單點不開、聯絡表單送不出，或是像你剛才遇到的 React 畫面變白。

穩定性會大幅提升

WordPress 是一個由多種外掛組合起來的系統。很多外掛在寫代碼時，會假設某些資源（如 jQuery）是第一個載入的。Rocket Loader 為了求快，會強行改變這個規則。

關閉它之後，你的 WordPress 網站會變得更穩定。你不再需要擔心更新了某個外掛後，網站突然版面亂掉或功能失效。對於企業用的打卡管理系統來說，穩定性絕對比那零點幾秒的跑分差距更重要。

其他補償方案

如果你擔心關閉後速度變慢，WordPress 還有很多更好的優化方式。你可以使用快取外掛（如 WP Rocket 或 W3 Total Cache）來進行檔案壓縮（Minify）和延遲載入。

這些外掛比 Cloudflare 的 Rocket Loader 更了解 WordPress 的結構，處理起來會更細緻。你也可以保留 Cloudflare 的其他功能，例如 CDN 加速和內容快取，這些對速度的幫助依然很大，且不會像 Rocket Loader 那樣容易造成腳本衝突。

建議的操作步驟

既然你目前的打卡系統出現了白畫面，我強烈建議先關掉它。關閉後，請先清除瀏覽器快取再重新開啟網頁。

如果你發現 WordPress 真的慢了很多，我們可以再透過調整 functions.php 或是使用專業的優化外掛來補救。對於開發者來說，能掌握程式碼的執行順序，遠比交給 Cloudflare 自動處理來得安心。

伺服器現況分析

從你提供的日誌來看，你的伺服器正在遭受大規模的自動化掃描攻擊。這些攻擊者利用工具不斷嘗試存取你多個 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 的資源存取（例如大量的圖片請求）在消耗頻寬，到時候我們再針對那些行為調整規則。

最基本的檢查指令是 status，它會告訴你防火牆目前是開啟（active）還是關閉（inactive）狀態，並列出目前的過濾規則。

sudo ufw status

查看詳細資訊與編號

如果你需要更深入的資訊，例如預設的防火牆政策（Default policy）或是規則的建立順序，可以使用以下兩種進階用法。

使用 verbose 可以看到更詳細的設定：

sudo ufw status verbose

使用 numbered 可以顯示每條規則的編號。這在你想刪除特定規則時非常有用，因為你可以直接指定編號刪除，而不用輸入一長串的 IP 位址：

sudo ufw status numbered

規則內容解讀

當你執行上述指令後，會看到一個列表。主要包含以下欄位：

• To：目標連接埠或服務（例如 80/tcp）。
• Action：動作。ALLOW 代表允許，DENY 代表拒絕。
• From：來源。如果你之前設定了 Cloudflare，這裡會顯示 Cloudflare 的 IP 位段。如果顯示 Anywhere，則代表全世界的流量都能進入該連接埠。

刪除特定的防火牆規則

如果你發現某條規則設定錯誤，可以利用剛才提到的編號來快速刪除。例如，若要刪除編號為 3 的規則：

sudo ufw delete 3

檢查編號3的狀態:

sudo ufw status numbered

Status: inactive

啟用 UFW 防火牆

當你看到 Status: inactive 時，代表 UFW 雖然已經安裝，但目前並沒有在運作，所有的連線都不會被攔截。在正式啟用前，請務必確認你已經放行了 SSH 連接埠（預設是 22），否則你可能會失去遠端主機的控制權。

輸入以下指令啟用：

sudo ufw enable

系統會詢問你是否要繼續執行，輸入 y 並按下 Enter 即可。

確認預設政策

啟用後，建議先設定預設的連線政策。通常我們會設定為：預設拒絕所有連入（Incoming），但允許所有連出（Outgoing）。

sudo ufw default deny incoming
sudo ufw default allow outgoing

再次查看狀態

啟用並設定好 Cloudflare 腳本後，再次執行 status numbered，你應該會看到類似下面的輸出：

Status: active

     To                         Action      From
     --                         ------      ----
[ 1] 22/tcp                     ALLOW IN    Anywhere
[ 2] 80/tcp                     ALLOW IN    173.245.48.0/20
[ 3] 443/tcp                    ALLOW IN    173.245.48.0/20
...

停用或重新啟動

如果你在設定過程中發現連線出現問題，或是想暫時關閉防火牆進行除錯，可以使用以下指令：

• 停用防火牆：sudo ufw disable
• 重新載入規則（修改腳本後常用）：sudo ufw reload
• 重設所有規則（清空回預設狀態）：sudo ufw reset

➜  ~ sudo ufw status
Status: active

To                         Action      From
--                         ------      ----
22                         ALLOW       Anywhere
443                        ALLOW       Anywhere
80                         ALLOW       Anywhere
80,443/tcp                 ALLOW       173.245.48.0/20
80,443/tcp                 ALLOW       103.21.244.0/22
80,443/tcp                 ALLOW       103.22.200.0/22
80,443/tcp                 ALLOW       103.31.4.0/22
80,443/tcp                 ALLOW       141.101.64.0/18
80,443/tcp                 ALLOW       108.162.192.0/18
80,443/tcp                 ALLOW       190.93.240.0/20
80,443/tcp                 ALLOW       188.114.96.0/20
80,443/tcp                 ALLOW       197.234.240.0/22
80,443/tcp                 ALLOW       198.41.128.0/17
80,443/tcp                 ALLOW       162.158.0.0/15
80,443/tcp                 ALLOW       104.16.0.0/13
80,443/tcp                 ALLOW       104.24.0.0/14
80,443/tcp                 ALLOW       172.64.0.0/13
80,443/tcp                 ALLOW       131.0.72.0/22
19790 (v6)                 ALLOW       Anywhere (v6)
443 (v6)                   ALLOW       Anywhere (v6)
80 (v6)                    ALLOW       Anywhere (v6)
80,443/tcp                 ALLOW       2400:cb00::/32
80,443/tcp                 ALLOW       2606:4700::/32
80,443/tcp                 ALLOW       2803:f800::/32
80,443/tcp                 ALLOW       2405:b500::/32
80,443/tcp                 ALLOW       2405:8100::/32
80,443/tcp                 ALLOW       2a06:98c0::/29
80,443/tcp                 ALLOW       2c0f:f248::/32

修正防火牆規則衝突

從你提供的清單來看，目前的設定有一個嚴重的安全漏洞：雖然你加入了 Cloudflare 的 IP 範圍，但清單最上方仍有 443 與 80 埠開放給 Anywhere。

在 UFW 的邏輯中，規則是由上而下執行的。既然第一條已經允許了 Anywhere，後面的 Cloudflare 限制就不會生效，任何人還是可以直接連線到你的伺服器。

刪除過於寬鬆的規則

你需要先刪除允許 Anywhere 連入 80 與 443 的規則。請先列出編號：

sudo ufw status numbered

找到寫著 443 ALLOW Anywhere 與 80 ALLOW Anywhere 的編號（根據你的清單應該是 2 和 3，以及 v6 的部分），然後執行刪除。例如：

# 假設 2 號是 443 Anywhere
sudo ufw delete 2
# 刪除後編號會遞補，請再次查看編號後刪除 80 Anywhere

重複此動作，直到清單中不再出現 Anywhere 存取 80 和 443 為止。

驗證最終安全性

整理完畢後，你的 sudo ufw status 應該只剩下 SSH 埠（19790）是 Anywhere，而 80 與 443 的來源（From）欄位應該全部都是 Cloudflare 的 IP 位段。

為什麼 SSH 使用 xxx 埠

看到你的 SSH 埠設定在 xxx 而非預設的 22，這是一個很好的安全實踐，能避開大多數的自動化暴力掃描。請確保這個編號永遠保留在 ALLOW 清單中，否則一旦防火牆擋掉這個埠，你就無法再遠端登入伺服器。

你想知道如何測試目前的設定是否真的成功擋掉了非 Cloudflare 的連線嗎？

測試防火牆是否生效

要確認防火牆是否成功阻擋了非 Cloudflare 的連線，最直接的方法就是繞過域名，直接使用你的伺服器真實 IP 進行連線測試。

方法一：使用瀏覽器直接訪問

在瀏覽器的網址列輸入 http://你的伺服器IP 或 https://你的伺服器IP。

• 如果成功： 代表防火牆規則沒設好，或是 Anywhere 的規則還沒刪乾淨。
• 如果失敗（顯示連線逾時）： 代表防火牆運作正常，因為你的電腦 IP 不在 Cloudflare 的允許名單內。

方法二：使用 curl 指令測試

如果你手邊有另一台 Linux 或是在自己的電腦終端機，可以使用 curl 並設定連線逾時來快速檢查。

# 測試 80 埠
curl -I --connect-timeout 5 http://你的伺服器IP

# 測試 443 埠
curl -I --connect-timeout 5 https://你的伺服器IP

如果看到 curl: (28) Connection timed out，表示防火牆已經成功把非 Cloudflare 的流量擋在門外了。

方法三：透過 Cloudflare 診斷工具

如果你透過原本的網域名稱可以正常開啟網頁，但直接連 IP 會失敗，這就是最完美的狀態。這代表流量確實有經過 Cloudflare 代理，而你的伺服器也只聽 Cloudflare 的話。

檢查 UFW 日誌

如果你想親眼看到被擋掉的紀錄，可以開啟 UFW 的日誌功能：

sudo ufw logging on

接著查看 /var/log/ufw.log，你會看到許多來自不同 IP 但被 [UFW BLOCK] 的紀錄。

tail -f /var/log/ufw.log

需要我幫你確認如何從 Cloudflare 後台開啟「Authenticated Origin Pulls」，讓安全性再提升一個等級嗎？

在設定防火牆之前，必須先取得 Cloudflare 官方提供的 IP 位段。這包含 IPv4 與 IPv6 兩個部分。你可以直接從 Cloudflare 官網查看，或是使用 curl 指令在終端機抓取。

使用 UFW 設定步驟

UFW 是 Ubuntu 內建較簡單的防火牆工具。設定的邏輯是先拒絕所有連入 80 與 443 埠的流量，再逐一放行 Cloudflare 的 IP。

首先，確保你的 SSH 連線（通常是 22 埠）已經放行，否則你會把自己鎖在伺服器外：

sudo ufw allow 22/tcp

接著，利用迴圈將 Cloudflare 的 IP 加入允許清單：

# 允許 IPv4
for ip in $(curl -s https://www.cloudflare.com/ips-v4); do sudo ufw allow from $ip to any port 80,443 proto tcp; done

# 允許 IPv6
for ip in $(curl -s https://www.cloudflare.com/ips-v6); do sudo ufw allow from $ip to any port 80,443 proto tcp; done

最後啟用防火牆並檢查狀態：

sudo ufw enable
sudo ufw status

使用 iptables 設定方式

如果你偏好使用 iptables，原理相同，即針對特定的來源 IP 開放目的連接埠。

# 允許 IPv4
for ip in $(curl -s https://www.cloudflare.com/ips-v4); do sudo iptables -I INPUT -p tcp -s $ip --dport 80 -j ACCEPT; sudo iptables -I INPUT -p tcp -s $ip --dport 443 -j ACCEPT; done

請注意，iptables 的設定在重啟後會失效，建議安裝 iptables-persistent 來儲存規則。

自動化更新腳本

Cloudflare 的 IP 偶爾會變動。為了避免失效，建議將上述指令寫成一個 shell 腳本，並利用 crontab 設定每週執行一次。這樣當 Cloudflare 增加新機房時，你的防火牆規則也會自動同步，確保網站服務不會中斷。

如何設定 crontab 來定期自動執行這些指令？

建立自動化更新腳本

為了確保防火牆規則永遠跟隨 Cloudflare 的最新 IP 清單，我們可以寫一個簡單的腳本。請在你的家目錄建立一個檔案，例如叫 update_cf_ips.sh。

#!/bin/bash

# 先刪除現有的 Cloudflare UFW 規則（可選，或直接覆蓋）
# 這裡建議直接執行允許指令，UFW 會自動處理重複的規則

# 下載最新的 IPv4 並加入 UFW
for ip in $(curl -s https://www.cloudflare.com/ips-v4); do
    sudo ufw allow from $ip to any port 80,443 proto tcp
done

# 下載最新的 IPv6 並加入 UFW
for ip in $(curl -s https://www.cloudflare.com/ips-v6); do
    sudo ufw allow from $ip to any port 80,443 proto tcp
done

# 重新載入防火牆
sudo ufw reload

儲存後，記得給予執行權限：

chmod +x update_cf_ips.sh

設定 Crontab 定期執行

接著我們使用 crontab 讓系統每週一凌晨三點自動執行這個腳本。

輸入以下指令進入編輯介面：

sudo crontab -e

在檔案最後面加入這行（請將路徑替換成你實際存放腳本的位置）：

0 3 * * 1 /home/youruser/update_cf_ips.sh > /dev/null 2>&1

驗證規則是否生效

設定完成後，你可以從外部直接輸入你的伺服器 IP（而非網域名稱）來測試。如果防火牆運作正常，瀏覽器應該會顯示連線逾時，因為你的個人電腦 IP 不在 Cloudflare 的允許清單內。只有透過 Cloudflare 代理的流量才能順利讀取網頁。

使用對象與權限的區別

sudo crontab -e 是用來編輯個別使用者的排程。即便你加上 sudo，它通常也是針對 root 這個帳號的個人排程。每個使用者都有自己的 crontab 檔案，這些檔案存放在特定的系統目錄下，不建議直接手動改動。

vi /etc/crontab 則是編輯系統層級的排程。這是一個純文字檔，通常只有系統管理員會去動它。這裡定義的是整個系統要跑的任務，而不是針對某個特定的人。

格式上的關鍵不同

這兩者在語法上最大的差別在於有沒有使用者欄位。

在 sudo crontab -e 裡面，每一行只有五個時間參數加上指令。因為系統已經知道這是 root 的排程，所以不需要再特別註明由誰執行。

在 /etc/crontab 裡面，時間參數後面必須多加一個欄位，指定要用哪個帳號執行指令。例如你想用 root 權限跑程式，就得在指令前寫上 root。如果漏掉這個欄位，排程就不會動。

安全性與自動檢查

使用 crontab -e 有一個很大的好處，就是它會幫你檢查語法。如果你寫錯了，儲存離開時它會提醒你，甚至不讓你存檔。這可以避免因為一個小空格打錯，導致所有排程失效。

直接用 vi 修改 /etc/crontab 就沒有這種防護機制。如果你打錯字或格式不對，系統不會報錯，但任務就是不會執行。對於新手來說，用指令編輯會安全很多。

環境變數的設定

/etc/crontab 是一個設定檔，裡面通常會預設好 PATH 等環境變數。這讓管理系統任務變得比較直觀。

個別使用者的 crontab 往往比較乾淨，環境變數可能跟你的 shell 環境不太一樣。所以寫個人排程時，建議指令都要寫絕對路徑，才不會發生找不到程式的情況。

[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 的警告應該不再出現，因為連線資源已經釋放出來給正常的使用者了。

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

apache 的 log:

[Sun Jan 25 21:23:17.555354 2026] [autoindex:error] [pid 7395:tid 7395] [client 172.68.242.115:11609] AH01276: Cannot serve directory /var/www/html/wp-admin/css/: No matching DirectoryIndex (index.html,index.cgi,index.pl,index.php,index.xhtml,index.htm) found, and server-generated directory index forbidden by Options directive, referer: binance.com

方法一：透過 .htaccess 阻擋特定 Referer

請將以下設定加入到你的 /var/www/html/.htaccess 檔案最上方。這會讓所有來自 binance.com 的請求直接被伺服器拒絕，連目錄檢查的程序都不會執行。

RewriteEngine on
RewriteCond %{HTTP_REFERER} binance\.com [NC]
RewriteRule .* - [F]

• RewriteCond: 檢查來源網址是否包含 binance.com。[NC] 代表不區分大小寫。
• RewriteRule: 對於符合條件的請求，回傳 [F] (Forbidden，即 403 錯誤)。

方法二：利用 Cloudflare 阻擋 (更推薦)

從日誌的 IP 172.68.242.115 來看，這是 Cloudflare 的 IP。這代表攻擊流量是經過 Cloudflare 才到你的伺服器。直接在伺服器端阻擋雖然有用，但流量還是會進到你的主機。

最好的做法是在 Cloudflare 控制面板 設定防護：

1. 進入 Security (安全性) -> WAF -> Create rule (建立規則)。
2. 欄位選擇 Referer，運算子選擇 contains，值輸入 binance.com。
3. Action 選擇 Block。

這樣在流量到達你的主機之前就會被攔截，徹底釋放你的 Apache Worker。

方法三：禁止存取所有敏感目錄的 PHP 檔案

為了防止機器人以後換個來源網址繼續掃描，你可以針對 wp-admin 和 wp-includes 的內容加強防護。在 /var/www/html/.htaccess 中加入：

# 禁止直接存取 wp-includes 下的 PHP 檔案
<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteBase /
    RewriteRule ^wp-admin/includes/ - [F,L]
    RewriteRule !^wp-includes/ - [S=3]
    RewriteRule ^wp-includes/[^/]+\.php$ - [F,L]
    RewriteRule ^wp-includes/js/tinymce/langs/.+\.php - [F,L]
    RewriteRule ^wp-includes/theme-compat/ - [F,L]
</IfModule>

總結

建議優先執行 方法一 或 方法二，因為這能針對你日誌中看到的 binance.com 掃描進行精準打擊。

設定完成後，原本日誌中的 autoindex:error 應該會變成普通的 access_compat:error 或直接消失。

我建議將安全攔截規則放在 .htaccess 的最上方，確保這些惡意請求在進入快取邏輯（WP Fastest Cache）之前就被擋掉。這樣可以節省後續的比對運算與磁碟檢查。

以下是合併後的建議設定碼，我將安全防護規則（封鎖 XML-RPC、特定的 binance.com 來源、以及隱藏目錄列表）整合在你的快取規則之前：

# 1. 隱藏目錄檔案列表
Options -Indexes

# 2. 封鎖 XML-RPC (防止暴力破解)
<Files xmlrpc.php>
    <IfModule mod_authz_core.c>
        Require all denied
    </IfModule>
    <IfModule !mod_authz_core.c>
        Order deny,allow
        Deny from all
    </IfModule>
</Files>

# 3. 封鎖特定惡意來源與 Referer
<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteBase /

    # 阻擋來自 binance.com 的惡意掃描
    RewriteCond %{HTTP_REFERER} binance\.com [NC]
    RewriteRule .* - [F,L]

    # 4. 原有的 WP Fastest Cache 規則開始
    RewriteCond %{HTTPS} =on
    RewriteCond %{HTTP_HOST} ^max-everyday.com
    # Start WPFC Exclude
    # End WPFC Exclude
    # Start_WPFC_Exclude_Admin_Cookie
    RewriteCond %{HTTP:Cookie} !wordpress_logged_in_[^\=]+\=max-everyday-root
    # End_WPFC_Exclude_Admin_Cookie
    RewriteCond %{HTTP_HOST} ^max-everyday.com
    RewriteCond %{HTTP_USER_AGENT} !(facebookexternalhit|WP_FASTEST_CACHE_CSS_VALIDATOR|Twitterbot|LinkedInBot|WhatsApp|Mediapartners-Google)
    RewriteCond %{HTTP_USER_AGENT} !(WP\sFastest\sCache\sPreload(\siPhone\sMobile)?\s*Bot)
    RewriteCond %{REQUEST_METHOD} !POST
    RewriteCond %{REQUEST_URI} !(\/){2,}
    RewriteCond %{THE_REQUEST} !(\/){2,}
    RewriteCond %{REQUEST_URI} \/$
    RewriteCond %{QUERY_STRING} !.+
    RewriteCond %{HTTP:Cookie} !comment_author_
    RewriteCond %{HTTP:Profile} !^[a-z0-9\"]+ [NC]
    RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/all/$1/index.html -f [or]
    RewriteCond /var/www/html/wp-content/cache/all/$1/index.html -f
    RewriteRule ^(.*) "/wp-content/cache/all/$1/index.html" [L]
</IfModule>

調整重點說明

第一，我把 Options -Indexes 放在最前面，這能直接解決你日誌中大量的 AH01276 錯誤，不再讓機器人看到你的目錄內容。

第二，xmlrpc.php 的封鎖使用了 <Files> 標籤，這比 RewriteRule 更底層且有效，能直接阻斷這類型的暴力破解嘗試。

第三，在快取規則開始前，先用 RewriteCond %{HTTP_REFERER} binance\.com [NC] 進行過濾。這樣只要來源是那個網站，伺服器會立即回傳 403 Forbidden 並停止處理後續規則，這對減輕伺服器負擔非常有幫助。

設定完後，你可以再次觀察 error.log。原本來自 binance.com 的錯誤應該會從目錄掃描錯誤變成單純的 client denied。

零元方案的內容

對於一般使用者，Cloudflare 的 Free 方案 就已經非常夠用。

• Universal SSL（通用憑證）：免費。當你把小雲朵（Proxy）打開時，Cloudflare 會自動幫你的網域和第一層子網域（如 *.max-everyday.com）簽發憑證。
• Origin CA 憑證：免費。你可以從 Cloudflare 後台下載一張有效期長達 15 年的憑證裝在你的 Ubuntu Server 上，讓 Cloudflare 到你主機這一段路也是加密的。
• 自動續約：免費。Cloudflare 會自己處理憑證更新，你完全不需要跑 certbot 指令。

什麼時候需要花錢？

除非你有非常特殊的技術需求，否則通常碰不到付費項目：

• 進階憑證管理 (ACM)：每月約 10 美元。如果你需要更深層的子網域（例如 a.b.dictionary.max-everyday.com），或是想要自訂憑證的有效期、選擇特定的簽發機構，才需要這個。
• 自訂憑證上傳：需要 Business 方案（每月 200 美元）。如果你一定要把你在外面買的昂貴憑證上傳到 Cloudflare 使用才要買這個。

簡單總結

你現在的情況，只要把網域交給 Cloudflare 代管，並在 DNS 頁面把該子網域的 Proxy 狀態（橘色小雲朵）點亮，SSL 就會自動生效，且一毛錢都不用花。

在 Cloudflare 官網後台的 SSL/TLS 選項中，找到「Origin Server」頁面，點擊「Create Certificate」。直接點選建立後，你會得到兩段文字：一個是 Certificate（憑證），另一個是 Private key（私密金鑰）。

準備憑證檔案

請在你的 Ubuntu Server 上建立兩個檔案，把網頁上的內容分別貼進去。

• 新建 /etc/ssl/certs/cloudflare.pem，貼入 Certificate 內容。
• 新建 /etc/ssl/private/cloudflare.key，貼入 Private key 內容。

請務必保護好 key 檔案，不要讓其他人讀取。

修改 Apache 設定

你需要修改原有的設定檔，讓它監聽 443 埠。你可以參考下面的寫法。

<VirtualHost *:443>
    ServerAlias dictionary.max-everyday.com
    DocumentRoot /var/www/dictionaryweb

    SSLEngine on
    SSLCertificateFile /etc/ssl/certs/cloudflare.pem
    SSLCertificateKeyFile /etc/ssl/private/cloudflare.key

    <Directory /var/www/dictionaryweb/>
        AllowOverride All
        Require all granted
    </Directory>
</VirtualHost>

最後步驟

設定完成後，請先啟動 Apache 的 SSL 模組：執行
sudo a2enmod ssl
接著執行
sudo apache2ctl configtest
檢查語法，沒問題後用
sudo systemctl restart apache2
重啟。

最後，回到 Cloudflare 後台，將 SSL/TLS 模式從「Flexible」改成「Full (Strict)」。這樣從瀏覽器到 Cloudflare，再到你的伺服器，全程都會是加密的安全連線。

建議不要完全移除，但可以將其簡化為「自動轉址」功能。

保留 80 埠設定檔的原因

雖然你現在改用 HTTPS，但有些使用者或舊的書籤可能還是會輸入 http://。如果直接移除 80 埠的設定，當有人嘗試用 HTTP 訪問時，伺服器會因為找不到對應的設定而噴出錯誤，或是顯示出預設的 Apache 歡迎頁面。

最好的做法是讓 80 埠只負責一件事情：把所有訪客推向 HTTPS。

建議的簡化設定

你可以將原本 80 埠的設定檔內容改寫成這樣，就是一個「自動導航」：

<VirtualHost *:80>
    ServerAlias dictionary.max-everyday.com
    Redirect permanent / https://dictionary.max-everyday.com/
</VirtualHost>

這樣無論訪客從哪裡進來，都會被安全地引導到你剛設定好的 443 埠（HTTPS）。

Cloudflare 的替代方案

其實，如果你在 Cloudflare 後台開啟了「Always Use HTTPS」功能，Cloudflare 在雲端就會幫你處理掉轉址，流量根本不會到達你的 80 埠。

不過，在伺服器端保留這幾行設定是一種「保險」。萬一哪天你暫時關閉了 Cloudflare 的 Proxy（變回灰雲朵），你的網站依然能維持自動轉跳 HTTPS 的功能，不會因此變得混亂。

你想知道怎麼在同一個設定檔裡同時寫好 80 和 443 埠嗎？

在同一個設定檔裡，你只需要寫兩個 VirtualHost 區塊。這就像是在同一個檔案裡放兩個不同的導航說明。

設定檔寫法範例

你可以直接把原本的 015-dictionary.conf 修改成以下內容：

<VirtualHost *:80>
    ServerAlias dictionary.max-everyday.com
    # 把 HTTP 流量永久轉向 HTTPS
    Redirect permanent / https://dictionary.max-everyday.com/
</VirtualHost>

<VirtualHost *:443>
    ServerAlias dictionary.max-everyday.com
    DocumentRoot /var/www/dictionaryweb

    SSLEngine on
    SSLCertificateFile /etc/ssl/certs/cloudflare.pem
    SSLCertificateKeyFile /etc/ssl/private/cloudflare.key

    <Directory /var/www/dictionaryweb/>
        AllowOverride All
        Require all granted
    </Directory>

    ErrorLog ${APACHE_LOG_DIR}/dictionary_error.log
    CustomLog ${APACHE_LOG_DIR}/dictionary_access.log combined
</VirtualHost>

注意事項

雖然寫在一起很方便，但請記得檢查你的 Ubuntu 防火牆（例如 ufw）。如果之前只開了 80 埠，現在必須執行 sudo ufw allow 443/tcp。否則，雖然 Apache 設定好了，外面的封包還是進不來。

另外，如果你的主機上有其他網站，建議每個網站的 Log 檔案名稱稍微分開（例如上面的 dictionary_error.log），這樣出問題時才不會所有網站的錯誤訊息都擠在一起。

最後，存檔後一樣要執行
sudo apache2ctl configtest
看到 Syntax OK 的字樣，再重啟 Apache 才會生效。

需要我教你怎麼看 Apache 的錯誤日誌來確認設定有沒有成功嗎？

設定 Cloudflare 的 SSL 模式是確保連線安全的最後一步。這能保證從瀏覽器到伺服器的整條路徑都被嚴密加密。

進入 SSL/TLS 設定頁面

首先，登入 Cloudflare 後台並選擇你的網域（max-everyday.com）。在左側導覽列中，你會看到一個「SSL/TLS」的選項，點擊它後預設會進入「Overview（總覽）」頁面。

在這個頁面的中間，你會看到一個四格的選擇器，分別是 Off、Flexible、Full、Full (Strict)。

選擇 Full (Strict) 模式

請直接點擊「Full (Strict)」這個選項。

• 為什麼選這個？ 因為你已經在 Apache 上安裝了 Cloudflare 提供的 Origin Certificate。
• 與 Full 的差別： 「Full」只要有證書就行，不論過期或非法；而「Full (Strict)」會嚴格檢查你伺服器上的證書是否為 Cloudflare 簽發且有效。
• 安全性： 這是最高等級的加密方式，可以防止中間人攻擊，確保流量真的進到了你的 Ubuntu 伺服器。

開啟 Always Use HTTPS

設定完模式後，點擊左側選單「SSL/TLS」底下的「Edge Certificates」。在頁面下方找到「Always Use HTTPS」開關，將它切換為「On」。

這樣一來，Cloudflare 就會主動把所有嘗試連入 http 的訪客直接導向 https，這比你在 Apache 寫轉址反應更快，也能減少伺服器的負擔。

驗證設定是否生效

完成後，你可以再次使用 curl -v https://dictionary.max-everyday.com 進行測試。

如果設定成功，你應該會看到 SSL 連線建立成功，且不會再出現 301 轉址（因為你已經直接訪問 https 了）。如果畫面出現「526 Invalid SSL certificate」錯誤，通常代表你 Apache 上的 .pem 或 .key 檔案路徑貼錯了，或者是忘了重啟 Apache。

需要我幫你寫一段自動檢查 Apache 憑證路徑是否正確的指令嗎？