當 Apache 面對大量連線時，即便 CPU 沒滿，使用者確實可能需要排隊。這通常是因為 Apache 的 mpm 設定限制了同時處理請求的數量（MaxRequestWorkers）。當請求超過這個值，後續的連線會被放在作業系統的 backlog 隊列中等待。如果這個隊列也滿了，使用者就會看到連線逾時或拒絕連線。

在高併發場景下，Apache 每個連線通常會佔用一個進程或線程，這非常消耗記憶體與 CPU 資源。即便你調整了核心網路參數，如果 Apache 本身的工人數量設得太低，連線進不來；設得太高，記憶體會耗盡導致系統瘋狂交換資料（Swap），進而讓 CPU 飆升到 100%。

記憶體與 Swap 的警訊

從你提供的資訊來看，這台 WordPress 主機只有約 1GB 的記憶體（961Mi），且目前已經使用了 196Mi 的 Swap。當系統開始頻繁讀寫 Swap 時，磁碟 I/O 會拖慢所有處理程序，CPU 會花費大量時間在等待 I/O 完成（iowait），這也是造成系統停擺與 CPU 滿載的常見原因。1GB 記憶體對於執行現代 WordPress 加上 Apache 來說非常吃力，建議至少提升至 2GB 以上，或嚴格限制 Apache 的進程數量。

動態請求的資源消耗

WordPress 是基於 PHP 的動態網站，每一個連線都要啟動 PHP 解釋器去抓資料庫、執行外掛程式碼，這比處理靜態網頁耗費更多資源。如果你沒有使用快取機制（如 Redis 或是 WP Super Cache），每個訪客都會對 CPU 造成直接壓力。即便你把網路隊列加長（如 somaxconn），那也只是讓訪客在「門外排隊」排得久一點，並沒有真正解決「門內的消化速度」。

改善建議

要解決排隊與 CPU 滿載問題，調整核心參數只是輔助，你需要針對軟體層優化：

• 檢查 Apache 的 mpm_event 設定，確保 MaxRequestWorkers 與你的記憶體大小匹配，避免觸發 Swap。
• 安裝 PHP 的 OPcache，這能顯著降低 CPU 處理 PHP 代碼的負擔。
• 強烈建議在 WordPress 加入物件快取（Object Cache）並搭配 Redis，減少對 MySQL 的重複查詢。
• 如果硬體資源無法提升，考慮將前端換成 Nginx 或是在 Apache 前面擋一層 Cloudflare，過濾掉不必要的壓力。

修改 prefork MPM 設定值:

nano /etc/apache2/mods-available/mpm_prefork.conf

prefork MPM 設定值:

StartServers 5
MinSpareServers 5
MaxSpareServers 10
MaxRequestWorkers 200
MaxConnectionsPerChild 2000

記憶體過載的風險

你目前的 MaxRequestWorkers 設定為 200，這對於一台只有 1GB 記憶體的主機來說非常危險。在 prefork 模式下，每個 Apache 進程都會消耗獨立的記憶體。以 WordPress 來說，一個 PHP 進程大約佔用 40MB 到 80MB 不等。

如果同時有 200 個請求進來，記憶體需求會來到 200 x 40MB = 8000MB（約 8GB）。你的主機只有 1GB，這會導致系統強制使用硬碟當記憶體（Swap），讓 CPU 飆升到 100% 且網頁完全打不開。這就是為什麼你感覺到系統停擺的主因。

針對 1GB 記憶體的設定建議

假設扣除作業系統與其他程序佔用的 300MB，剩下約 600MB 給 Apache 使用。以每個進程 40MB 計算，MaxRequestWorkers 設定在 15 到 20 之間比較安全。

以下是建議的設定值：

StartServers 5
MinSpareServers 5
MaxSpareServers 10
MaxRequestWorkers 20
MaxConnectionsPerChild 1000

設定值的邏輯說明

• MaxRequestWorkers (20)：
  這是最重要的防線。設定為 20 代表最多只允許 20 個連線同時進入 PHP 處理階段。雖然這會讓第 21 個人排隊，但至少能保證這 20 個人能快速拿到網頁，且不會搞垮整台主機。
• MaxConnectionsPerChild (1000)：
  原先的 2000 稍微偏高。調低到 1000 可以更頻繁地釋放可能洩漏的記憶體，對於小記憶體主機比較友善。
• 預留空間：
  當你發現 CPU 依然很高，但記憶體還有剩時，再以每次加 5 的幅度調升 MaxRequestWorkers。

如何減少排隊感

雖然限制了進程數可以防止當機，但使用者可能會因為排隊感到緩慢。你可以嘗試以下方法緩解：

1. 啟用 Page Cache：
   使用外掛如 WP Rocket 或 WP Super Cache 將頁面轉為靜態 HTML。這樣 Apache 處理請求的速度會快上百倍，同樣 20 個進程能服務的總人數會大幅提升。
2. 更換 MPM 模式：
   如果可能，建議將 Apache 從 prefork 換成 event 模式並搭配 PHP-FPM。event 模式處理連線的效率更高，且更省記憶體。
3. 檢查資料庫連線：
   確保你的 WordPress 設定指向 MySQL 主機時使用的是私有 IP（例如 10.x.x.x），避免走公網造成額外的連線延遲。

Q: 2GB swap 是否太多?

Swap 的定位與影響

在 1GB 記憶體的主機上，設定 2GB 的 Swap 並不算是「太多」，但它是一把雙刃劍。當你的實體記憶體用完時，Swap 可以作為緩衝，防止系統因為記憶體不足（OOM Killer）直接強制關閉資料庫或 Apache 進程。然而，Swap 的存取速度遠慢於記憶體，一旦系統頻繁使用 Swap，整台主機的效能會劇烈下降。

從你提供的數據看，目前已經使用了 196Mi 的 Swap，這代表 1GB 的記憶體已經不夠用了。系統正在把不常用的資料搬到硬碟，如果這個數值持續跳動或增加，就是 CPU 飆高的前兆，因為 CPU 會浪費大量時間在處理記憶體與硬碟之間的資料交換。

為什麼不建議依賴大量 Swap

• 效能瓶頸：
  硬碟（即使是 SSD）的速度比記憶體慢上千倍。當 Apache 請求排隊且又需要讀取 Swap 時，反應時間會從毫秒變成秒，使用者會感覺網站掛掉了。
• CPU 負擔：
  管理 Swap 需要 CPU 參與，當記憶體極度短缺導致系統瘋狂交換資料（Thrashing）時，CPU 使用率會直接衝上 100%，但實際上沒有處理任何網頁請求。
• 硬碟壽命：
  如果是雲端主機，頻繁的 Swap 讀寫會消耗大量的 IOPS，有些服務商會因此限制你的磁碟效能。

調整建議與優化

與其擔心 Swap 太大，不如減少系統對它的依賴。

1. 調整 Swappiness

你目前的 vm.swappiness = 10 已經是很合理的設定。這代表系統會盡可能使用實體記憶體，直到剩下約 10% 左右才會開始考慮使用 Swap。請保持這個設定。

2. 核心問題在記憶體配置

2GB 的 Swap 空間本身沒問題，問題出在你的 Apache 配置（MaxRequestWorkers 200）會輕易吃光 1GB 記憶體，強制系統去填滿那 2GB 的 Swap。這就像是雖然路邊有很大的路肩可以停車，但如果你把高速公路主線都塞滿了，車流還是會動彈不得。

3. 監控建議

你可以觀察 vmstat 1 指令中的 si (swap in) 與 so (swap out) 欄位。如果這兩個數字持續不是 0，代表系統正在發生頻繁交換，這才是真正的效能殺手。

目前的狀況下，2GB Swap 是安全的備援，但你應該透過調整 Apache 的進程數，讓 Swap 使用量維持在幾百 MB 以內甚至不使用。

apache 的 mods mpm_event 沒被 enable, 只有 enable mpm_prefork

為什麼你的主機只開啟了 mpm_prefork

在較舊的系統或預設安裝中，Apache 為了確保與 PHP 的相容性（特別是當 PHP 以 mod_php 模組運行時），會預設使用 mpm_prefork。這個模式的特色是每個請求由一個獨立的進程處理，雖然穩定，但非常耗費記憶體，這正是導致你 1GB 記憶體主機容易 CPU 100% 的根本原因。

如果你想大幅提升連線處理能力，並讓 CPU 不再輕易滿載，切換到 mpm_event 是最有效的做法。mpm_event 使用線程（threads）處理連線，能用極少的記憶體處理數倍於 prefork 的併發量。

切換到 mpm_event 的必要前提

在切換之前，你必須確認 PHP 的運行方式。mpm_event 不支援傳統的 mod_php。

安裝 PHP-FPM：你必須先安裝並啟動 php-fpm 服務。

停用 mod_php：切換 MPM 前需要先停用 PHP 模組。

更換模組：

停用 mpm_prefork：

sudo a2dismod mpm_prefork

啟用 mpm_event：

sudo a2enmod mpm_event

重啟 Apache：

sudo systemctl restart apache2

如果決定留在 mpm_prefork 的優化

如果你因為某些舊外掛必須維持 mpm_prefork，那麼你必須嚴格執行我之前建議的 MaxRequestWorkers 20。

在 prefork 模式下，當連線數超過 MaxRequestWorkers 時，多出來的連線會進入作業系統的等待隊列（backlog）。這就是你問的「排隊等待」：

• CPU 沒滿載但要排隊：這是因為 MaxRequestWorkers 限制了同時作業的人數，門外的人在排隊，但門內的人處理很快。
• CPU 滿載且要排隊：這是因為 MaxRequestWorkers 設太大（如你原本的 200），門內擠滿了人，大家都在互搶記憶體跟磁碟 IO，導致系統接近崩潰。

總結建議

以你目前的硬體資源（1GB RAM），維持 mpm_prefork 並設定 MaxRequestWorkers 200 絕對會當機。

• 短期方案：立即將 MaxRequestWorkers 調降至 20 左右，保證系統不崩潰。
• 長期方案：改用 mpm_event 搭配 PHP-FPM。這樣同樣 1GB 的記憶體，你可能可以將 MaxRequestWorkers 開到 100 以上而不會觸發 Swap。

如何知道目前是使用 mod_php or php-fpm?

確認目前 PHP 運行方式

你可以透過以下兩種方式快速判斷：

查看 Apache 模組清單：執行指令

apache2ctl -M | grep php

如果你看到 php_module 或 php7.x_module / php8.x_module，代表你正在使用 mod_php。

建立 info.php 網頁：在網頁根目錄建立一個檔案，內容寫

<?php phpinfo(); ?>

用瀏覽器開啟後，搜尋 Server API 這一項：

如果顯示 Apache 2.0 Handler，就是 mod_php。

如果顯示 FPM/FastCGI，就是 php-fpm。

修改前: Server API: Apache 2.0 Handler

切換至 mpm_event 與 PHP-FPM 詳細步驟

假設你使用的是 PHP 8.3（請根據你的版本自行調整數字，例如 7.4 或 8.1）：

1. 安裝 PHP-FPM 與相關模組

sudo apt update
sudo apt install php8.3-fpm libapache2-mod-fcgid

安裝完成後，確認 FPM 已經啟動：

sudo systemctl status php8.3-fpm

2. 啟用必要模組並停用 mod_php

這是一連串的模組切換動作，請依序執行：

# 啟用 proxy 相關模組，讓 Apache 能溝通 PHP-FPM
sudo a2enmod proxy_fcgi setenvif

# 啟用 FPM 的設定檔
sudo a2enconf php8.3-fpm

# 停用 PHP 模組 (注意版本號要對應)
sudo a2dismod php8.3

# 核心切換：停用 prefork 並啟用 event
sudo a2dismod mpm_prefork
sudo a2enmod mpm_event

3. 檢查設定並重啟

在重啟前先測試設定檔是否正確：

sudo apache2ctl configtest

如果顯示 Syntax OK，就重啟服務：

sudo systemctl restart apache2

為什麼這能解決你的問題

切換到 mpm_event 後，Apache 不再為每個連線維持一個笨重的進程。這對你的 1GB 記憶體主機有以下好處：

• 記憶體佔用極低：Apache 進程只負責把連線傳遞給 PHP-FPM，閒置連線幾乎不佔記憶體。
• 併發能力提升：你可以安全地將同時連線數設得更高。
• 獨立管理：PHP-FPM 有自己的進程管理設定檔，你可以獨立限制 PHP 能用多少記憶體，而不會跟 Apache 搶資源。

切換完成後，原本在 /etc/apache2/mods-enabled/mpm_prefork.conf 的設定就失效了，你需要去修改 /etc/apache2/mods-enabled/mpm_event.conf。

修改用指令:

nano /etc/apache2/mods-available/mpm_event.conf

針對 1GB 記憶體的 event 模式優化

切換到 mpm_event 後，你的主機體質已經大幅改善。在 event 模式下，Apache 的進程變得很輕量，主要的記憶體壓力轉移到了 PHP-FPM 手上。你提供的預設值對於 1GB 記憶體來說稍嫌激進，特別是 MaxRequestWorkers 150。如果這 150 個連線同時觸發 PHP 運算，主機依然會因為記憶體耗盡而崩潰。

以下是針對 1GB 記憶體環境的建議設定值：

StartServers 2
MinSpareThreads 25
MaxSpareThreads 50
ThreadLimit 64
ThreadsPerChild 25
MaxRequestWorkers 50
MaxConnectionsPerChild 1000

設定值調整邏輯

• MaxRequestWorkers (50)：雖然 event 模式很省資源，但後端的 PHP-FPM 依然很吃記憶體。將此值設為 50 是一個安全的基準，代表 Apache 最多同時送 50 個請求給 PHP 處理。這能確保在高負載時，系統仍有足夠的緩衝記憶體，不至於觸發大量的 Swap 讀寫。
• MaxSpareThreads (50)：將最大閒置線程調低，可以讓 Apache 在離峰時段釋放不必要的資源。
• MaxConnectionsPerChild (1000)：建議不要設定為 0（無限）。設定一個數值（如 1000）可以讓進程在處理一定量請求後重啟，有效防止長期運行可能產生的記憶體洩漏問題。

同步檢查 PHP-FPM 的設定

切換到 event 模式後，你還需要檢查 PHP-FPM 的設定檔：

nano /etc/php/8.3/fpm/pool.d/www.conf

這才是決定 CPU 是否衝到 100% 的關鍵：

pm = dynamic
pm.max_children = 15
pm.process_idle_timeout = 10s
pm.start_servers = 5
pm.min_spare_servers = 5
pm.max_spare_servers = 10
pm.max_requests = 500

• pm.max_children (20)：這限制了同時運行的 PHP 進程數。因為每個 PHP 進程大約 40-60MB，20 個大約佔用 1GB 左右的空間。這個數值應與 Apache 的 MaxRequestWorkers 搭配。如果你發現記憶體還有剩餘，可以慢慢往上加。 反之，如果設了 20 還是占用掉大量 swap 就要降低。

觀察成效

完成設定後，請重啟服務：

sudo systemctl restart php8.3-fpm apache2

你可以觀察 top 或 htop。如果 CPU 負載下降且 Swap 使用量不再增加，代表目前的平衡點是正確的。如果使用者仍反映要排隊，但 CPU 很閒，再逐步調高 pm.max_children 與 MaxRequestWorkers。

修改之後: Server API: FPM/FastCGI

計算單個 PHP 進程的記憶體平均值

要精確設定 pm.max_children，你需要知道每個 PHP 進程實際上吃了多少記憶體。請在終端機執行以下指令：

ps -ylC php-fpm8.3 --sort:rss | awk '{sum+=$8; ++n} END {if (n > 0) print sum/n/1024 " MB"}'

（請根據你的版本修改 php-fpm8.3）

這條指令會抓取所有正在執行的 PHP-FPM 進程，並計算出平均每個進程佔用的實體記憶體（RSS）。

如何根據結果調整 pm.max_children

得到平均值後，你可以使用以下公式來估算：

(可用記憶體 - 系統預留) / 單個 PHP 進程平均大小 = pm.max_children

舉例來說：

• 可用記憶體：1024MB
• 系統預留（作業系統 + Apache + MySQL）：400MB
• 剩餘空間：624MB
• 如果你的 PHP 進程平均是 40MB，則 $624 / 40 = 15.6$。
• 建議設定：pm.max_children = 15。

優化 PHP-FPM 與 Apache 的連動

當你設定好 pm.max_children 後，Apache 的 MaxRequestWorkers 應該設為與其相同或略大一點。如果 pm.max_children 設得太小，Apache 送過去的請求會因為沒有多餘的 PHP 工人處理而在後台排隊，這就是為什麼 CPU 沒滿但使用者要等待的原因之一。

其他關鍵優化

為了讓這 1GB 記憶體發揮最大效益，請檢查以下設定：

• pm.max_requests：在 www.conf 中將此值設為 500 或 1000。這會讓 PHP 進程在處理完固定次數請求後重啟，能有效清理記憶體殘留，對小主機非常重要。
• opcache：確保 /etc/php/8.3/fpm/php.ini 中的 opcache.enable=1 與 opcache.memory_consumption=128 是開啟的。這能大幅降低 CPU 負擔。
• MySQL 檢查：你的 WordPress 與 MySQL 分開兩台，這很好。但請確保 WordPress 那台主機的 wp-config.php 是使用私有 IP 連線，避免 DNS 解析或公網延遲拖慢 PHP 進程的存活時間。

為什麼預設 /etc/php/8.3/fpm/php.ini 中的 opcache.enable 沒被啟用?

PHP FPM 與 OPcache 的預設行為

在多數 Linux 發行版（如 Ubuntu 或 Debian）中，當你透過套件管理員安裝 PHP 8.3 時，你會發現 php.ini 檔案裡的 opcache.enable 前面標註了分號，這代表該行是被註釋掉的。雖然在 php.ini 檔案中看起來像是沒啟用，但實際上 OPcache 在 FPM 環境下通常是運行的。

這是因為 PHP 的設定採用了模組化管理。在 /etc/php/8.3/fpm/conf.d/ 目錄下，會有一個類似 10-opcache.ini 的符號連結，它指向 /etc/php/8.3/mods-available/opcache.ini。在這個獨立的設定檔中，通常已經包含了 zend_extension=opcache.so 以及 opcache.enable=1。

PHP 在啟動時會先讀取主 php.ini，接著讀取 conf.d 目錄下的所有額外設定。由於 conf.d 中的設定載入順序較晚，它會覆蓋掉 php.ini 裡的預設值。

為什麼不直接在主設定檔啟用

這種設計主要是為了維護的便利性。透過將不同擴充功能的設定拆分到獨立檔案，系統管理員可以簡單地使用 phpenmod 或 phpdismod 指令來開啟或關閉特定功能，而不需要去更動核心的 php.ini 檔案。

如果 opcache.enable 在 php.ini 中被硬編碼啟用，當你想暫時停用它來進行除錯時，操作會變得比較麻煩。模組化的做法讓升級 PHP 版本時，設定檔的遷移與管理變得更加直覺，也能避免主設定檔變得過於臃腫。

如果你想確認目前 OPcache 是否真的有在運作，可以撰寫一個包含 phpinfo(); 內容的檔案並透過瀏覽器執行，或者在終端機輸入 php-fpm8.3 -i | grep opcache.enable 來查看最終生效的數值。

指令實際執行畫面:

opcache.enable 在 php.ini 裡, 是被註解沒啟用, 實際上是有被 enable

如何在負載測試期間（例如使用 ab 工具）監控記憶體與 Swap 的即時變化？

即時監控與測試方法

要找出系統的極限，最有效的方法是在模擬負載時觀察資源變化。你可以使用 Apache 內建的 $ab$ (Apache Benchmark) 工具，從外部或另一台主機進行測試。

1. 準備監控視窗

建議同時開啟兩個終端機視窗：

視窗 A（觀察記憶體與 Swap）： 執行

watch -n 1 free -m

這讓你每秒看到記憶體減少與 Swap 增加的速度。

視窗 B（觀察 PHP 進程）： 執行

watch -n 1 "ps aux | grep php-fpm | grep -v grep | wc -l"

這能讓你確認 pm.max_children 是否已經達到上限。

使用 ab 進行壓力測試

在另一台電腦執行以下指令（不要在 WordPress 主機自己跑，會影響測試準確性）：

ab -n 500 -c 20 http://你的網站IP/

• -n 500：總共發出 500 個請求。
• -c 20：同時有 20 個連線（併發）。

測試時的觀察重點：

• 情境 1： 如果 Swap 數字開始快速跳動，代表 pm.max_children 設得太高，記憶體爆了。
• 情境 2： 如果 free 顯示記憶體還有剩，但 ab 測試結果很慢，且 PHP 進程數卡在 20 不動，代表你的 pm.max_children 設太低，CPU 沒事做但大家在排隊。

count children = 10, each thread 127MB 已大於該 VPS 的 1GB RAM.

找出完美的平衡點

理想的狀態是：當併發連線進來時，CPU 使用率上升（代表有在做事），實體記憶體用到約 80%~90%，但 Swap 幾乎不動。

如果你的測試結果顯示 CPU 還是很容易衝到 100%，即使記憶體夠用，那通常是因為 WordPress 處理每個請求的時間太長。這時你需要檢查：

• MySQL 慢查詢： 檢查 MySQL 主機是否因為沒有索引導致查詢變慢，拖住 PHP 進程。
• Object Cache： 在 WordPress 安裝 Redis Object Cache 插件。這能讓原本需要 0.5 秒處理的頁面縮短到 0.1 秒，同樣的進程數就能服務 5 倍的使用者。

記憶體共享機制與計算誤差

這是一個非常經典的誤區。雖然指令算出的平均值是 127MB，但這 10 個進程並不是真的佔用了

10 x  127 = 1270MB

1. 共享記憶體 (Shared Memory)

PHP-FPM 的主進程啟動時，會載入 PHP 核心、擴充功能和常用代碼（特別是開啟 OPcache 後）。當它產生子進程（Workers）時，這些子進程會共享主進程已經載入的唯讀記憶體區塊。

ps 指令算出的 RSS（Resident Set Size）包含了進程自己獨有的資料以及它跟別人共享的資料。如果你把每個進程的 RSS 全部加總，會重複計算那些「共享的部分」，導致總數看起來超過了實體記憶體。

2. 為什麼系統沒崩潰

從你的 free -m 來看，used 是 678Mi，這才是系統目前真正消耗的實體記憶體。扣除掉快取後，你的 available 還有 282Mi。這代表這 10 個 PHP 進程實際上扣除掉彼此重複的部分，總共只佔用了大約 400 到 500MB 左右。

3. 127MB 的警訊

雖然有共享機制，但平均每個進程 127MB 在 WordPress 裡算是偏肥大的。這通常代表：

• 你安裝了較多或較大型的外掛。
• 你的主題（Theme）載入了大量函式庫。
• 這些進程在處理完請求後，還沒釋放某些動態生成的資料。

如何更精準地觀察與調整

1. 使用 PSS 計算（更準確）

如果你想看扣除共享後「真正」佔用的記憶體，可以試試安裝 smem 工具，它計算的 PSS (Proportional Set Size) 會把共享記憶體平攤給每個進程，算出來的總和才等於系統實際消耗量。

2. 調整 pm.max_requests

你的進程長到 127MB，有可能是因為處理過太多請求而累積了碎片。在 www.conf 裡設定：

pm.max_requests = 500

這能強迫進程在處理 500 次請求後重啟，把記憶體歸零，防止它無限制長大到真的塞爆 RAM。

3. 修正 pm.max_children

根據你現在 127MB 的觀察值，即便有共享，我也建議你的 pm.max_children 最多設 10 到 12 就好。因為在高負載下，每個進程處理複雜查詢時，獨有的記憶體會迅速增加，那時共享部分的比例會下降，如果不限制數量，136Mi 的 Swap 很快就會變成 500Mi，到時 CPU 就會衝上 100%。

你想確認目前 www.conf 裡的 pm 模式是 static 還是 dynamic 嗎？這會影響這 10 個進程是否會自動增減。

雖然把數值調低, 在 CPU / RAM / Disk IO 都明顯下降，但實際上造成的平均反應時間是大大的上升，所以讓 CPU / RAM 微微滿載，可能可以再降低一點回應時間。

page views 下降，且page load time 還上升，也許不去調整，performance 才是更好的, 呵呵。

使用 SetEnvIf 過濾特定副檔名

你可以透過 Apache 的 SetEnvIf 指令，根據檔案請求的副檔名來標記不需要紀錄的請求。只要在 Apache 的設定檔（通常是網站的 VirtualHost 設定區塊）加入以下設定即可：

# 標記不需要紀錄的副檔名
SetEnvIf Request_URI "\.(?:gif|jpe?g|png|ico|css|js|swf|woff2?|svg)$" dontlog

# 在 CustomLog 指令最後加上 env=!dontlog
CustomLog ${APACHE_LOG_DIR}/other_vhosts_access.log combined env=!dontlog

這段設定的作用是：如果請求的網址結尾是 css 或 js 等檔案，系統會賦予它一個名為 dontlog 的環境變數。而在輸出 log 時，後方的 env=!dontlog 則告訴 Apache，只有在沒有這個標記的情況下才寫入檔案。

過濾 Log 的優缺點

減少紀錄靜態檔案可以讓 log 變得易讀，也能稍微減輕磁碟寫入的負擔。不過，如果你未來需要排查網頁樣式載入失敗（例如 404 錯誤）或某些資安攻擊，少了這些 log 就會比較難追蹤。

如果你希望在保留 log 的同時又不影響閱讀主流程，也可以考慮將靜態檔案的 log 導向另一個獨立的檔案：

CustomLog ${APACHE_LOG_DIR}/static_assets.log combined env=dontlog
CustomLog ${APACHE_LOG_DIR}/access.log combined env=!dontlog

這樣你就能在 access.log 中看到乾淨的頁面存取紀錄，而把瑣碎的靜態資源存取留在另一個檔案備查。

要修改 Apache 設定，請找到負責該網站的設定檔（通常位在 /etc/apache2/sites-enabled/ 目錄下），並依照下列步驟調整。

修改步驟

請在 VirtualHost 區塊內加入過濾邏輯。如果你的 log 格式包含虛擬主機名稱（如你提供的範例），通常對應的是 vhost_combined 格式：

<VirtualHost *:443>
    ServerName stackoverflow.max-everyday.com

    # 1. 定義哪些副檔名不要記錄
    SetEnvIf Request_URI "\.(?:css|js|png|jpg|jpeg|gif|ico|woff|woff2?|svg)$" dontlog

    # 2. 修改 CustomLog，在最後加上 env=!dontlog
    # 請根據你原本的 log 路徑與格式名稱修改
    CustomLog ${APACHE_LOG_DIR}/other_vhosts_access.log vhost_combined env=!dontlog

    # 其他設定...
</VirtualHost>

注意事項

修改完成後，必須重新載入 Apache 設定才會生效：

先檢查語法是否正確：使用指令

sudo apache2ctl configtest

重新載入設定：使用指令

sudo systemctl reload apache2

這樣一來，未來所有對 .js 或 .css 的正常存取就不會出現在這個 log 檔案中，讓你能專注於分析網頁的存取行為。

需要我解釋如何針對特定的 IP 地址（例如你自己的機器）也排除在 log 之外嗎？

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。

異常請求與機器人掃描

日誌中出現大量來自 binance.com 的 Referer（來源網址），正在存取你的 wp-includes 目錄下的 PHP 檔案，例如 class-wp-block-parser-frame.php。這明顯是針對 WordPress 核心檔案的惡意探測，雖然回傳 200，但如果你的檔案權限設定正確，通常不會有立即危險，不過這會增加伺服器負荷。

另外，還有一些看起來像是在搜尋特定關鍵字的請求（例如波斯文或阿拉伯文的搜尋字串），這可能是嘗試進行 SQL 注入或利用搜尋功能消耗你的 CPU 資源。

內部虛擬連線 (Internal Dummy Connection)

日誌中頻繁出現 OPTIONS * HTTP/1.0 來自 ::1（本機端）的請求。這是 Apache 用來喚醒閒置子行程的機制。如果你覺得這很佔日誌空間，可以在設定中過濾掉，但它本身不是安全威脅。

針對性的優化建議

一、 封鎖特定 Referer 攻擊

既然這些惡意探測都偽裝成從 binance.com 過來的請求，你可以直接在 .htaccess 阻擋這種來源：

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

如果你的網站掛在 cloudflare 後面, 也可以設定 rule 來擋, 會更有效率:

二、 保護 wp-includes 目錄

除了 xmlrpc.php，wp-includes 目錄也不應該被外部直接執行 PHP 檔案。你可以將以下程式碼放入 wp-includes/ 目錄下的 .htaccess 檔案中（如果沒有就建立一個）：

<Files *.php>
    deny from all
</Files>
<Files wp-tinymce.php>
    allow from all
</Files>
<Files ms-files.php>
    allow from all
</Files>

這會封鎖該目錄下所有 PHP 的直接存取，但保留幾個 WordPress 運作必要的例外。

三、 處理搜尋功能濫用

如果你的網站不需要搜尋功能，或者被大量垃圾關鍵字搜尋，可以考慮安裝外掛限制搜尋頻率，或是透過 Cloudflare 的 WAF 規則，阻擋包含特殊字元或非預期語系的搜尋請求。

四、 設定連線超時 (Timeout)

在 Apache 設定中縮短連線等待時間，可以讓那些佔著連線不放的機器人趕快斷線，釋放 Workers：

將 Timeout 改為 30 甚至 15（秒），並確保 KeepAliveTimeout 設在 2 到 5 之間。

你目前的伺服器負載感覺已經緊繃，調整完這些設定後，建議觀察 top 或 htop 查看記憶體與 CPU 的即時變化。

這個參考解法，由原本預設的的 mpm_prefork 切換為改用 mpm_event
https://stackoverflow.max-everyday.com/2026/02/1cpu-1gb-ram-wordpress-vps/#mpm_event

基礎執行指令

在 CMD 視窗中，請先切換到該目錄。你需要輸入完整路徑或是先進入該資料夾。

DOS

cd /d C:\xampp_lite\apps\apache\bin
httpd.exe

如果直接執行沒有反應，或是跳出錯誤，通常是因為它找不到 httpd.conf。你可以使用 -f 參數來指定設定檔的路徑。

DOS

httpd.exe -f "C:\xampp_lite\apps\apache\conf\httpd.conf"

檢查是否執行成功

執行後，如果命令提示字元視窗停住（沒有出現新的輸入列），代表 Apache 正在運行。這時候可以打開瀏覽器輸入 localhost 測試。

如果視窗立刻跳回輸入狀態，代表啟動失敗。你可以輸入以下指令來檢查錯誤原因：

DOS

httpd.exe -t

這個指令會檢查設定檔的語法。如果顯示 Syntax OK，代表設定沒問題；如果有錯，它會告訴你是哪一行寫錯了。

解決路徑變數問題

由於你是使用 xampp-lite，設定檔中常使用 ${XAMPP_LITE_ROOT} 這種變數。如果你不是透過控制面板啟動，而是直接點 exe，這些變數可能無法解析。

建議檢查 httpd.conf 頂端的 Define SRVROOT。如果它長得像 ${XAMPP_LITE_ROOT}/apps/apache，請試著手動改成絕對路徑，例如：

Apache

Define SRVROOT "C:/xampp_lite/apps/apache"

正確的修改標的是 C:/xampp/htdocs , 而我修改錯誤的是 C:/xampp/apache

要修改 XAMPP 的網頁根目錄，主要需要動到 Apache 的設定檔。這個檔案路徑通常在 C:\xampp\apache\conf\httpd.conf。

修改設定檔內容

打開 httpd.conf 檔案後，利用搜尋功能尋找 DocumentRoot 這個關鍵字。你會看到兩行需要修改的地方。

第一行是 DocumentRoot “C:/xampp/htdocs”，請把它改成你的新路徑 “C:/Max/Documents/fonts/dictionary/dictionaryweb”。

第二行緊接在下面，通常是 <Directory “C:/xampp/htdocs”>。請同步修改成 <Directory “C:/Max/Documents/fonts/dictionary/dictionaryweb”>。

確認權限設定

在 <Directory> 區塊內，要確認權限是否有開放。確保裡面的設定包含 AllowOverride All 以及 Require all granted。這樣 Apache 才有權限讀取你放在文件資料夾裡的檔案。

有些 Windows 資料夾會有權限限制，如果修改後出現 403 Forbidden 錯誤，可能需要手動去資料夾內容調整安全安全性設定，讓 Everyone 或 Everyone 組群有讀取權限。

重啟服務生效

修改完儲存檔案後，設定並不會立刻生效。你必須回到 XAMPP Control Panel，先點擊 Apache 的 Stop 停止服務，等待幾秒後再點擊 Start 重新啟動。

重新啟動後，你在瀏覽器輸入 localhost，它就會自動讀取你新路徑下的 index.php 或 index.html 了。

需要幫你檢查如何設定虛擬主機（Virtual Host）來對應不同的專案路徑嗎？

零元方案的內容

對於一般使用者，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 憑證路徑是否正確的指令嗎？

SSLSessionCache: 'shmcb' session cache not supported (known names: ). Maybe you need to load the appropriate socache module (mod_socache_shmcb?) 

發生原因，只有更新 ssl.conf 和 ssl.load 到 /etc/apache2/mods-enabled 目錄下造成。

解法，在 mods-enabled 目錄下執行下列指令，讓網站 redirect 到 ssl 優先：

ln -s ../mods-available/socache_shmcb.load socache_shmcb.load
ln -s ../mods-available/ssl.load ssl.load
ln -s ../mods-available/ssl.conf ssl.conf

Step 1：設定 mysql 資料庫

在 mysql 裡增加新的database: krita，並一組帳號給新的站台登入使用。可以參考下列的 sql command:

create database krita;
CREATE USER 'kritauser1'@'localhost' IDENTIFIED BY 'your-krita-user-password';
GRANT ALL PRIVILEGES ON krita.* TO kritauser1@localhost;
FLUSH PRIVILEGES;

Step 2：設定 WordPress

複製一份空的 wordpress source code 到 /var/www/krtia 目錄下，最後修改 wp-config.php ，修改下面的這3個欄位內容：

define('DB_NAME', 'krita');
define('DB_USER', 'kritauser1');
define('DB_PASSWORD', 'your-krita-user-password');

還有把 source code 的所有權設定給 www-data 讓更新和下載 php 的主題、佈景和外掛會方便一些。

chown -R www-data:www-data .

Step 3：修改 /etc/hosts 檔案

增加

127.0.0.1 krita.max-everyday.com

Step 4：在 Apache 增加新站台

在 /etc/apache2/sites-available 裡增加一個新的 web 站台。

這個可以使用第一個預設站台裡的內容，直接 copy 為新的檔名，例如：

cp 000-default.conf 114-krita.conf

修改 114-krita.conf 檔案內容：

• DocumentRoot /var/www/krita
• <Directory /var/www/krita
• ServerName krita.max-everyday.com

到 /etc/apache2/sites-enabled/ 目錄下，使用下面指令，增加一個 enable 的 web site:

ln -s ../sites-available/114-krita.conf 114-krita.conf

Step 5：重啟 apache

服用下列指令：

service apache2 restart

Step 6：在DNS 增加子網域

增加 A Record

proxy 狀態的欄位，先點一下，切換為「僅DNS」(DNS only)，暫時不需要對內容做快取。

Step 7：取得 SSL 憑證

服用下面的指令：

certbot --apache

執行畫面：

這時候，輸入 10 再按 Enter 就會接著問，要不要重導 http 的 URL 到 https，選1或選 2都行，我是選1。

Step 8：完成

連到 https://krita.max-everyday.com 就可以開始設定 WordPress 站台。

解法，是先設定 /etc/hosts ，先加入 hosts 只連到 localhost 做測試。再使用 curl command 來看設定結果。

如果還是查不到卡關的原因，只好來看 apache log 檔。

默认的错误日志

在基于Debian的Linux上，系统范围的Apache错误日志默认位置是/var/log/apache2/error.log。默认位置可以通过编辑Apache的配置文件进行修改。

自定义的错误日志

要找到自定义的错误日志位置，请用文本编辑器打开 /etc/apache2/apache2.conf，然后查找以 ErrorLog 开头的行，该行指定了自定义的 Apache 错误日志文件的位置。例如，在未经修改的 Apache 配置文件中可以找到以下行：

ErrorLog ${APACHE_LOG_DIR}/error.log

在本例中，该位置使用 APACHELOGDIR 环境变量进行配置，该变量在 /etc/apache2/envvars 中已被定义。

export APACHE_LOG_DIR=/var/log/apache2$SUFFIX

在实际情况中， ErrorLog 可能会指向你 Linux 系统中任意路径。