Azure帳號充值方案 香港雲伺服器搭建LNMP環境：Linux系統下Nginx、MySQL與PHP優化配置

第一章：為什麼要在香港雲伺服器上優化 LNMP

很多人搭 LNMP 的第一反應是：把 Nginx、MySQL、PHP 跑起來就算完成。但在雲端環境，尤其是面向香港與華語用戶時，你真正要解決的是「延遲、吞吐與穩定性」。同樣的網站，在本地機器看起來很快，上線到雲伺服器後可能變慢；同樣的設定，在高峰期可能出現連線堆積、CPU 飆升、偶發的 502/504、或資料庫被寫鎖拖垮。

LNMP 的優化不是把參數堆到極限，而是讓每一層都在合理範圍內工作：Nginx 把連線與靜態資源處理好，減少不必要的上游請求；PHP-FPM 控制併發，避免進程失控；MySQL 保障查詢效率與緩衝命中，同時把安全與容量規劃做穩。當你這三層的節奏對上了，整體體感就會明顯提升。

Azure帳號充值方案 本文以「香港雲伺服器」為場景，但原理通用。你會得到一套可以直接落地的思路：先把基礎做對，再按優先級調整，最後用監控和日誌把問題定位到具體原因，而不是靠運氣。

第二章：前置準備與目標設定

2.1 確認系統與網路狀況

在開始之前，請確認你的系統版本與基本資源。至少要知道：CPU 核心數、可用記憶體、磁碟類型（SSD/HDD）、以及安全群組/防火牆是否允許 80/443 與 SSH。你也需要了解你的磁碟是否是雲端網路磁碟（延遲更高時 MySQL 的配置要更保守）。

建議你先記錄：

• CPU：`nproc`
• 記憶體：`free -h`
• 磁碟：`lsblk`、`df -h`
• 系統網路：`ip a`、`ss -s`

2.2 設定目標：快、穩、可維護

不要只追求「單次請求最快」。雲端服務最怕的是高峰時的雪崩效應：Nginx 把請求堆給 PHP，PHP 再把連線堆給 MySQL，最後整個系統卡死。你的目標應該是：

• 正常負載下延遲低：優先讓常見請求快速返回。
• 高峰時不崩：限制併發、設置超時與緩衝策略。
• 易排錯：日誌結構清晰、能追蹤到具體層。
• 安全可控：關閉不必要服務、最小權限與基本硬化。

Azure帳號充值方案 第三章：Linux 基礎設定（讓後面都更順）

3.1 更新系統與基礎工具

無論你選擇哪個發行版，第一步都是更新包倉庫並安裝必要工具。常見的包括 build 工具、curl、vim 或你偏好的編輯器。

如果你使用的是 Debian/Ubuntu 系列，通常會做：

• 更新索引：`apt update`
• 安裝工具：`apt install -y nginx mysql-server php-fpm ...`（此處略，視你用的版本與來源而定）

重點是：選擇官方倉庫或穩定第三方倉庫，避免版本混雜導致相依錯亂。

3.2 時區、時鐘與系統時序

資料庫與應用對時間很敏感。請把時區設為香港（Asia/Hong_Kong）。另外建議確保 NTP 同步正常，避免時間偏移引發證書、日誌與排程錯誤。

• 設定時區：`timedatectl set-timezone Asia/Hong_Kong`
• 確認同步：`timedatectl status`

3.3 設定文件描述符與開檔限制

LNMP 在高併發下很吃文件描述符（socket、檔案、日誌）。你可以先查看目前限制：`ulimit -n`。對於 Nginx 與 PHP-FPM，通常需要較高上限。具體值要依你的系統與負載規模調整，過大也不一定更好，但太小會讓服務在壓力下突然報錯。

實務做法是修改 systemd 或 limits 配置，讓 Nginx/PHP-FPM 都能拿到更高的 `nofile`。

第四章：Nginx 搭建與優化（面向延遲與吞吐）

4.1 安裝與啟動基本服務

Nginx 的核心在於：把「能由它直接處理的」都直接處理掉，把「需要交給上游」的請求用可靠的方式轉發。你可以先做一個最小可用站點，確認 80/443 正常運作，再進行優化。

啟動後確認端口：`ss -tulpen | grep nginx`。

4.2 站點結構與根目錄設計

建議採用一致的目錄結構，例如：

• 站點根目錄：`/var/www/yourapp`
• 靜態資源：`/var/www/yourapp/public`（或與你的框架一致）
• PHP 入口：通常是 `index.php`

重點是：讓 Nginx 能清晰判斷靜態資源與動態請求，並配好快取與壓縮策略。

4.3 關鍵：upstream 與 fastcgi 設定

PHP 通常由 PHP-FPM 以 socket 或 TCP 提供。若你在同機上，建議優先使用 Unix socket（通常較省開銷），但使用 TCP 也可以。這裡示範以 socket 為例。

在 Nginx 的 server 區塊中，你要確保：

• fastcgi_param 正確傳遞到 PHP
• 超時與緩衝要合理，避免 PHP 超時導致請求堆積
• 對大回應設置必要緩衝，減少慢客戶端拖垮

一個典型的片段（你可按實際版本調整）會包含：

• `fastcgi_pass unix:/run/php/php-fpm.sock;` 或對應路徑
• `fastcgi_read_timeout 60s;` 視你的 PHP 任務耗時設定
• `include fastcgi_params;`（確保基本參數一致）

4.4 壓縮與快取：讓「重複訪問」更省成本

網站速度的最大提升往往來自快取，而不是硬上更快的 CPU。針對靜態資源：

• 啟用 gzip 或 brotli（若你的版本支持）
• 對帶版本號的靜態檔（例如使用 hash 的檔名）設置較長 `expires`
• 對圖片、CSS、JS 做合理的缓存控制

你可以在 Nginx 配置中利用 `location` 對 `css/js/img` 類型設置快取策略。注意：如果你的前端資源沒有版本號，過長快取會造成更新不生效，所以要搭配你的資源發布策略。

4.5 反向代理與錯誤頁：處理好邊界

就算你只做 LNMP，仍可能有上游（例如某些 API 或後端服務）。當上游異常時，Nginx 是第一個暴露錯誤行為的層。你需要讓錯誤頁面乾淨、同時不要把敏感信息暴露給用戶。

實務上要做到：

• 自訂 502/503/504 回應
• 關閉不必要的 server token
• 限制 request body 大小（避免大檔把 PHP 或磁碟拖垮）

4.6 Nginx 併發核心參數：不是越大越好

Nginx 的併發設定通常包含：

• `worker_processes`（建議設為 CPU 核心數或 auto）
• `worker_connections`（要結合系統限制與實際需求）
• 合理設置 `keepalive_timeout`，避免長連線堆積

最常見的錯誤是把 worker_connections 設得太小導致排隊；或設太大卻忽略文件描述符限制，最後反而報錯。這也說明了：前面 Linux 基礎設定的重要性。

第五章：MySQL 搭建與優化（讓查詢快、寫入穩）

Azure帳號充值方案 5.1 安裝與初始安全

MySQL 的「性能」和「安全」通常是同時做的。你至少需要做：

• root 密碼與權限控制
• Azure帳號充值方案 移除匿名用戶（視系統預設）
• 限制遠程 root 登入

如果你使用的是 `mysql_secure_installation`（或類似工具），請按步驟配置。

Azure帳號充值方案 5.2 調整關鍵參數：從緩衝命中到落盤節奏

MySQL 的配置要根據你的內存大小調整。以下是最常被忽略、卻影響巨大的一組核心參數：

• `innodb_buffer_pool_size`：InnoDB 緩衝池，通常是影響最大的一項。一般建議在可用 RAM 的 60%~75% 範圍內，但要留出給 OS 與其他服務（Nginx、PHP、cache）。
• `max_connections`：不要無腦調大。連線過多會導致調度成本上升與鎖爭用。
• `innodb_log_file_size`、`innodb_flush_log_at_trx_commit`：影響寫入落盤頻率與崩潰恢復時間。高可靠場景要更保守。
• `query_cache_size`：新版本多數情況已被移除或不建議使用。性能更應該依賴索引與查詢設計。
• `slow_query_log` 與 `long_query_time`：把慢查詢打出來，才能真正優化。

你可以先用保守值上線，再根據監控逐步調整。MySQL 最怕「一次改太多」，因為你會不知道哪個參數導致抖動。

5.3 索引比參數更重要：用數據改變結果

很多人把 MySQL 慢當成參數問題，其實更常是查詢沒有索引或條件寫法不利於索引使用。你需要：

• 對常用查詢條件建立索引（WHERE、JOIN、ORDER BY、GROUP BY 的欄位）
• 避免在 WHERE 中對欄位做函數運算，導致索引失效
• 檢查外鍵、唯一鍵與實際資料分佈（避免「錯的索引」）

搭 LNMP 後的第一件事，不是立刻調參，而是把慢查詢找出來。當你修掉 20% 最慢的 SQL，整體速度往往會有明顯提升，且更穩。

5.4 連線與事務：避免長事務拖死全場

PHP-FPM 下每個請求都有可能連上 MySQL。若你的應用中存在長時間事務（例如批量更新、導入、錯誤的 while 循環導致一直不提交），會把鎖持有時間拉長。這時即使你把 MySQL 調到再強也會卡。

實務建議：

• 把大批量操作拆分為小批次
• 必要時使用更合理的隔離級別（通常預設就足夠）
• 避免在同一事務中做不必要的外部 I/O

5.5 字元集、排序規則與一致性

字符集問題看似不影響性能，但會帶來額外的轉換成本與難排錯的資料異常。確保資料庫、連接層與表設置一致（例如 UTF8MB4）。同時建議在建表與連接時就固定好 collation，避免不同模組使用不同設置。

第六章：PHP-FPM 搭建與優化（控制併發，避免崩盤）

6.1 選擇監控與部署方式

PHP-FPM 的目標是「穩定地處理請求」。你需要關注兩件事：

• 在高峰時，PHP-FPM 進程不會無限制增長
• 每個請求都有合理的超時與內存限制，避免單一請求把資源耗盡

6.2 核心參數：pm 與進程數的選擇

PHP-FPM 常見參數包含：

• `pm`：動態（dynamic）或靜態（static）等模式。多數情況 dynamic 更平衡。
• `pm.max_children`：最大子進程數，是最重要的上限。
• `pm.start_servers`、`pm.min_spare_servers`、`pm.max_spare_servers`：控制啟動與空閒進程維持。

怎麼估算？你需要知道單個 PHP 請求的平均記憶體占用（實際依程式而定），並留給 OS 與其他服務。若你無法精確估算，寧可先保守，讓系統在壓力下排隊而不是直接耗盡記憶體。

6.3 超時與記憶體：保護系統，而不是放任

你應該設定：

• `request_terminate_timeout`：限制單次請求最大執行時間，防止無限等待。
• `php_admin_value[memory_limit]`：限制單次請求可用記憶體（尤其避免巨型緩衝導致 OOM）。

同時要配合 Nginx 的超時。若 Nginx 比 PHP 更早超時，可能造成 PHP 還在跑但用戶已經斷開；反之亦然。所以要讓兩者對齊：Nginx 的 read/fastcgi timeout 要比 PHP-FPM 的內部上限更合理。

6.4 OpCache：最划算的 PHP 優化之一

如果你的 PHP 版本支持 OpCache，建議啟用。OpCache 會把編譯結果緩存在記憶體中，減少每次請求的編譯開銷。關鍵參數包括：

• 記憶體大小（`opcache.memory_consumption`）
• 最大加載文件數（`opcache.max_accelerated_files`）
• 重新驗證頻率（`opcache.revalidate_freq`）與部署方式的匹配

如果你使用的是容器化或有明確的部署流程，可以把 revalidate 設得合理，避免每次請求都去檢查檔案變更。

6.5 日誌：把問題留在可追蹤的地方

很多團隊的排錯難點是：日誌混在一起、沒有請求上下文，導致追蹤困難。你至少要確保：

• Azure帳號充值方案 Nginx access/error 分離
• PHP-FPM error 日誌位置固定
• 慢請求能定位到具體 URL 或處理階段

第七章：整合測試與常見問題定位

7.1 從靜態到動態：逐層驗證

不要一開始就上全功能。建議流程：

• 驗證 Nginx 是否正常服務：訪問靜態 HTML/圖片
• 驗證 PHP-FPM：訪問 `index.php` 輸出 phpinfo 或簡單腳本
• Azure帳號充值方案 驗證 MySQL：在 PHP 中連接資料庫執行簡單查詢
• 加上 HTTPS 與重定向後再測一輪

每一步都確認日誌沒有明顯錯誤。這樣即使出現慢或錯誤，也能快速縮小範圍。

7.2 常見故障：502/504/超時與原因樹

LNMP 常見的錯誤可以用「哪一層先出問題」來定位：

• 502 Bad Gateway：通常是 Nginx 到上游（PHP-FPM）通信失敗，或上游崩潰/拒絕連線
• 504 Gateway Timeout：上游處理超時，可能是 PHP 執行太久或 MySQL 查詢慢
• PHP 腳本報 500：檢查 PHP-FPM 日誌、`display_errors` 不要對外開，改看 error log

7.3 慢：用數據說話，而不是感覺

慢可以是網路、DNS、TLS 握手、上游處理、資料庫查詢、或 PHP 邏輯。建議你至少有：

• Nginx access log（含 request_time、upstream_response_time，如有設定）
• PHP-FPM status（若你允許可用監控介面）
• MySQL 慢查詢日誌

Azure帳號充值方案 當你知道慢發生在「連上 PHP 的時間」還是「PHP 內執行 DB 的時間」，才會找到正確方向。

第八章：安全強化（讓伺服器不只快，還可長跑）

8.1 防火牆與最小暴露

在香港雲伺服器上，不少攻擊來自常規掃描。你至少要確保：

• 只開必要端口：80/443/22（SSH 建議限制來源 IP）
• 關閉面向外網的管理面板或只允許特定 IP

8.2 TLS 與安全標頭

即使你只有 LNMP，也要重視 HTTPS。Nginx 配置中可以加入合理的安全標頭（例如 HSTS、X-Content-Type-Options 等）。同時不要忽略 TLS 版本與密碼套件，避免使用過時方案。

8.3 MySQL 權限策略與遠程連線限制

Azure帳號充值方案 MySQL 不要使用 root 連接到應用。你應該：

• 為應用建立專用用戶
• 只給必要的資料庫與權限（SELECT/INSERT/UPDATE/DELETE，視需求）
• 必要時限制只能從本機或特定網段連線

8.4 PHP 安全：關閉敏感輸出與限制執行

確保不對外暴露錯誤堆疊。`display_errors` 建議關閉，改看 error log。對檔案上傳要設置合理大小限制，並確保上傳目錄權限策略正確（避免被當成可執行腳本）。

第九章：監控與維運（優化的終點其實是持續）

9.1 建立最基本的三個指標

如果你只想先做最小可行監控，建議至少盯三類：

• 系統層：CPU、Load、Memory、Disk 使用率
• Web 層：Nginx 錯誤率（4xx/5xx）、上游超時次數
• 資料層：MySQL 的慢查詢數、連線數、InnoDB 狀態（如緩衝池命中/鎖等待）

9.2 日誌輪轉與保留策略

很多事故不是配置錯，而是日誌打爆磁碟。請確保有 logrotate 或雲平台的日誌策略，並設定合理的保留時間與壓縮。

9.3 版本與更新：避免「改了才發現不兼容」

Azure帳號充值方案 LNMP 中 Nginx、PHP、MySQL 任何一個升級都可能引發相依行為差異。建議把更新變更與配置變更分開做：先更新測試環境，穩定後再上線。

第十章：給香港用戶的思考：延遲、CDN 與緩存層

香港用戶的體感不只取決於你伺服器在香港，而更取決於整體路徑。即使你選擇香港區域，仍可能受：

• 用戶到機房的網路狀況
• TLS 握手與回程路徑
• 靜態資源是否命中快取

Azure帳號充值方案 如果你有條件，CDN 仍是最有效的降延遲方式之一。即使不用 CDN，也可以從「正確的 HTTP Cache-Control」與「合理的壓縮」獲得很大提升。

另外，針對 API，你可以考慮：

• 為可快取的 GET 返回加上 ETag 或 Last-Modified
• 對頻繁查詢的資料做服務端快取（如 Redis），把壓力從 MySQL 分流

本文聚焦 LNMP，但要記得：LNMP 的瓶頸常常出在「資料庫」。當你做出快取與索引後，整體瓶頸會移動，你才知道下一步該去哪。

結語：把優化做成可持續的流程

搭建 LNMP 不難，真正難的是在真實流量下讓它穩定、可排錯、可擴展。你應該遵循的順序是：先確保 Nginx 的請求處理正確且安全，再控制 PHP-FPM 的進程與超時，最後用慢查詢和索引把 MySQL 的效率拉起來。當三層節奏對上後，你會發現很多「不合理的延遲」其實是被層與層之間的配置放大了。

最後提醒一句：不要一次性調太多參數。每次改動都要有理由，也要有可驗證的指標。這樣你做的優化才不是暫時有效的賭博，而是能長期維運、越跑越穩的工程能力。