cPanel 網站資源用量監控教學：流量、CPU、記憶體分析

資源用量頁面很多人看了還是看不懂，因為它不像錯誤訊息那樣直接告訴你哪裡壞掉。實際上只要知道每個指標代表什麼，你就能分辨是網站突然爆流量、程式太重，還是主機規格真的該升級。

你如果不想每次都只是照著別人的畫面一步一步跟著按，卻不知道自己到底改了什麼，這篇會比較適合你。重點不是讓你背流程，而是讓你下次遇到類似情況時，還知道該怎麼自己判斷。

你會學到什麼

看懂 cPanel 最常見的資源指標與限制。
知道哪種資源爆掉時，網站通常會出現什麼症狀。
把監控頁面變成排錯工具，而不是看了更焦慮。
學會基本的效能優化手段。

什麼情況最適合先看這篇

剛接手虛擬主機、想自己把網站日常維護做好的人
你現在正要處理「cPanel 網站資源用量監控」這類操作
你希望做完之後不只功能能用，連驗證與排錯也有概念

開始前先確認

先觀察網站最近是否有改版、裝新外掛或流量異常。
如果是偶發問題，記得記錄發生時間。
準備對照 Google Analytics、Cloudflare 或應用程式 log。

先提醒你一件事

cPanel 很多功能都和網域、目錄、Email、憑證綁在一起，設定前先確認你改的是哪個站。

資源指標速查

詳細教學與操作步驟

頻寬用量（Bandwidth）

登入 cPanel，在「Metrics」區塊中點擊「Bandwidth」。
您可以查看當月與歷史的頻寬使用量，包含 HTTP、FTP、IMAP/POP3 等各項流量。

流量超額費用： 若當月流量超出方案配額，超出部分將以 NT$3/GB 計費，費用會自動加入下期帳單。

怎麼看頻寬數字：

一個一般的 WordPress 頁面大約 1-3 MB。
1000 個訪客、每人看 5 頁 = 大約 5-15 GB 流量。
圖片和影片是流量大戶。一張未壓縮的照片可能就 5 MB。

資源使用量（Resource Usage）

侃瑞科技虛擬主機採用 CloudLinux 作業系統，透過 LVE（Lightweight Virtual Environment）技術為每個帳號分配獨立的資源配額，確保所有用戶獲得穩定的效能。

在 cPanel 的「Metrics」區塊中，點擊「Resource Usage」。
您可以查看以下資源的即時與歷史使用率：

指標	說明	超限症狀
CPU	處理器使用率（100% = 1 核心）	網站回應變慢、最後 503
Physical Memory (RAM)	實體記憶體使用量	PHP 進程被殺、白屏
I/O	磁碟讀寫速度（MB/s）	資料庫查詢和檔案操作變慢
Entry Processes (EP)	同時處理的 PHP 請求數	503 錯誤（最常見的超限指標）
NPROC	同時執行的程序數	新請求無法處理
IOPS	每秒磁碟操作次數	資料庫密集操作變慢

圖表中紅色區域表示已達到上限，此時網站可能出現 503 錯誤或回應緩慢。

怎麼看圖表：

偶爾碰到紅線：正常，尖峰時刻的短暫觸碰不影響。
頻繁碰到紅線（每天多次）：需要優化或升級。
長時間待在紅線：網站可能已經持續出現 503，需要立刻處理。

各指標的深度解讀

Entry Processes（最重要）

EP 是虛擬主機最容易超限的指標。它代表「同時有幾個 PHP 請求在處理中」。

為什麼重要： 每個訪客載入一個頁面，後端可能同時需要處理主頁面 PHP + AJAX 請求 + cron 任務。如果 EP 上限是 20，代表只能同時處理 20 個 PHP 請求。

EP 超限的常見原因：

網站沒有開快取，每個訪客都要跑一次完整的 PHP 流程。
有跑很久的 PHP 進程（例如大型資料庫查詢、備份外掛）佔住了 EP。
網站被爬蟲大量掃描。
WordPress 的 wp-cron.php 太頻繁被觸發。

最有效的解法： 開啟 LiteSpeed Cache，大部分請求直接回覆快取頁面，不需要佔用 EP。

CPU

CPU 超限通常代表你的 PHP 程式太重。

常見原因：

WordPress 外掛太多（每個都在執行 PHP 邏輯）。
某個外掛有迴圈或低效率的資料庫查詢。
未壓縮的圖片在每次載入時做即時處理。

Physical Memory

記憶體超限會讓 PHP 進程直接被系統殺掉。

常見原因：

PHP 的 memory_limit 設太高，每個請求都佔用大量記憶體。
頁面建構器（如 Elementor、WPBakery）的編輯模式吃很多記憶體。
WooCommerce 產品數量多時，某些外掛會一次載入所有產品到記憶體。

訪客統計分析

cPanel 提供多種統計工具，可在「Metrics」區塊中找到：

Awstats：詳細的訪客分析，包含訪問量、來源國家、瀏覽器、搜尋引擎關鍵字等。
Webalizer：圖形化的月度流量統計報表。
Raw Access：下載原始的存取記錄（Access Log），適合進階分析。
Errors：查看近期的錯誤記錄，有助於排除 404、500 等問題。

Awstats 實用技巧：

看「Pages」和「Hits」的差別。Pages 是頁面載入次數，Hits 包含所有資源請求（CSS、JS、圖片等），Hits 數字通常是 Pages 的 10-50 倍。
看「Robots/Spiders」確認有沒有異常爬蟲。如果爬蟲流量比人類訪客還多，可能需要在 robots.txt 做限制。

資源達到上限時怎麼辦？

若您的網站經常觸及資源上限，建議依序嘗試以下方式：

1. 優化網站效能（最優先）

開啟快取（效果最大）：

WordPress 請安裝 LiteSpeed Cache 外掛。
確認快取有正確啟用（到 LiteSpeed Cache → 快取 → 確認「啟用 LiteSpeed Cache」為開）。
開啟 Guest Mode 加速未登入訪客的體驗。

壓縮圖片：

使用 ShortPixel、Imagify 等工具壓縮圖片，或將圖片轉為 WebP 格式。
不要上傳相機直出的原圖（通常 3-10 MB），先縮小到 1200px 寬再上傳。

減少外掛：

停用不必要的 WordPress 外掛，特別是會增加資料庫查詢的外掛。
用 Query Monitor 外掛找出哪些外掛跑了最多 SQL 查詢。

優化資料庫：

定期清理 post revisions、spam 留言、transients 等無用資料。
安裝 WP-Optimize 外掛一鍵清理和優化資料表。

使用 CDN：

透過 Cloudflare 等 CDN 分散流量負載。
靜態資源（CSS、JS、圖片）由 CDN 提供，主機壓力大幅降低。

2. 進階優化

停用 WordPress 內建 Cron：

WordPress 預設每次頁面載入都會觸發 wp-cron.php，高流量站會佔用大量 EP。你可以改用系統 cron：

在 wp-config.php 加入：

define('DISABLE_WP_CRON', true);

在 cPanel 的「Cron Jobs」設定每 15 分鐘執行一次：

/usr/local/bin/php /home/使用者名稱/public_html/wp-cron.php > /dev/null 2>&1

阻擋惡意爬蟲：

在 .htaccess 加入：

# 阻擋常見惡意爬蟲
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} (SemrushBot|AhrefsBot|DotBot|MJ12bot) [NC]
RewriteRule .* - [F,L]

3. 升級主機方案

若優化後仍無法滿足需求，代表您的網站已超出目前方案的承載能力。請至客戶中心升級至更高規格的方案，或聯絡我們的業務團隊評估 VPS 主機方案。

什麼時候該考慮升級：

優化都做了，資源還是頻繁超限。
月流量超過 100 GB。
同時在線訪客經常超過 50 人。
需要 SSH 或自訂伺服器設定。

Imunify360 安全防護

您的主機內建 Imunify360 安全防護系統，可在 cPanel 的「Security」區塊中找到。Imunify360 提供：

即時惡意軟體掃描與清除
Web Application Firewall（WAF）防護
入侵偵測與自動封鎖

若 Imunify360 偵測到可疑檔案，會在儀表板中列出，請依照指示處理或提交工單尋求協助。

Imunify360 和資源用量的關係： 如果你的網站被植入惡意程式，這些程式可能在背景偷跑，消耗大量 CPU 和記憶體。如果你看到資源突然暴增但流量沒變，先查 Imunify360 有沒有警告。

Troubleshooting

網站間歇性 503 錯誤

排查順序：

到 Resource Usage 看是哪個指標超限（通常是 EP 或 CPU）。
記下超限的時間點，對照 Awstats 看那個時段有沒有流量尖峰。
如果流量正常但資源爆了，代表是程式效能問題 → 優化。
如果是流量突然暴增 → 確認是真人流量還是爬蟲。

網站平時正常，但每天固定某個時間變慢

可能原因：

WordPress cron 在那個時段執行大量排程任務。
備份外掛在那個時段做備份。
有排程寄送大量 Email 的外掛。

解法： 把重型排程任務調到凌晨低流量時段。

資源用量圖表顯示空白

可能原因： 帳號剛建立，還沒有足夠的數據。通常需要等 24 小時以上才能看到圖表。

做完後怎麼確認自己真的有設對

看一下過去 24 小時的 Resource Usage 圖表，確認各指標的基準值。
確認 LiteSpeed Cache 有啟用（這是效能最大的保障）。
確認頻寬用量在方案配額的合理範圍內。
如果有 Imunify360 警告，已經處理完畢。

這一題最常踩的坑

只看 CPU，不看 Entry Processes 或 I/O，容易誤判瓶頸。
網站偶爾慢就立刻升級方案，沒先查原因。
沒把改版、排程任務與流量尖峰一起交叉看，很難找到真正原因。
沒開快取就說主機太慢，其實開了快取就能解決 80% 的問題。
被爬蟲佔用大量資源但沒注意到。

如果你要往下一步走

如果你發現主機規格真的不夠，下一步通常是評估 VPS 方案與價格或優化 WordPress / 程式本身。如果你需要更多效能調校，可以參考 PHP 版本切換教學和 WordPress 安全性強化教學。如果你想把這些功能直接用在穩定環境，侃瑞的 cPanel 虛擬主機方案可以直接對照本文操作。