華為雲帳號購買 華為雲香港節點搭建Nodejs服務：配置PM2實現守護進程與自動重啟

第一章：為什麼要用華為雲香港節點與 PM2

如果你的 Node.js 服務需要面向本地或區域用戶，部署在哪裡比你想的更關鍵。以「華為雲香港節點」為例，它能縮短跨境延遲，讓回應時間更穩，尤其是涉及網頁即時互動、API 調用頻繁或對延遲敏感的業務。更重要的是，雲主機本身提供可控的計算資源、快照與擴容可能，讓你把精力放在業務而不是反覆救火。

但部署完不是終點。長期穩定運行才是考驗：服務進程可能因為未捕獲異常、內存泄漏、網絡抖動、系統更新或配置變更而意外退出。你不想每次都手動重啟，也不想等到用戶投訴才發現問題。

這時 PM2 就派上用場。它本質上是進程管理器：負責在服務崩潰後自動拉起、統一管理日誌、支援負載或多進程（按需）、並能設置開機自啟。對小型團隊或個人開發來說，PM2 能把「維運成本」壓到最低，同時讓服務更像一個穩定的產品，而不是一個脆弱的腳本。

第二章：部署前的準備清單

開始之前，先把目標拆清楚。你要完成的事情其實是幾步：選擇雲上環境並連到主機；把 Node.js 應用部署上去；讓服務在後台持續運行；保證退出後能重啟；最後讓系統重啟後仍自動恢復。

建議你提前準備以下資訊：

• 雲主機的 IP、登入用戶名、SSH 私鑰或密碼
• Node.js 版本要求（建議在本地與伺服器一致，如 18.x 或 20.x）
• 應用啟動方式（例如 npm run start 或 node dist/index.js）
• 華為雲帳號購買 需要的環境變數（例如 PORT、NODE_ENV、資料庫連線串等）
• 對外服務的端口（例如 3000 或 8080）

除此之外，還有一個常被忽略的點：你要確定你的服務能「在非交互模式」運行。也就是說，不要依賴終端輸入。PM2 管理進程時是以後台方式啟動，應用必須能正常讀取環境變數並啟動。

第三章：連上華為雲香港節點並準備執行環境

3.1 連線與基礎檢查

登入雲主機後，建議先做基本檢查。你可以查看系統版本、磁碟空間、網絡狀態，確認部署環境不是一個「看似能跑、實際有問題」的狀態。

常用操作思路如下：

• 確認系統（例如 Ubuntu 或 CentOS）
• 更新套件索引（如 apt update / yum update）
• 檢查 Node.js 是否已安裝，沒有就安裝

如果你不確定 Node.js 怎麼安裝，最穩妥的做法是使用與你本地一致的方法（例如使用官方 Node 版本管理器或直接安裝對應版本）。關鍵是：版本一致可以大幅降低「部署後突然報錯」的機率。

3.2 安裝 Node.js 與 PM2

當 Node.js 就位後，接著安裝 PM2。一般做法是用 npm 全域安裝：

• 華為雲帳號購買 安裝：npm install -g pm2
• 驗證：pm2 -v 確認版本

如果你在企業環境遇到權限問題，常見原因是全域安裝目錄不可寫。此時可以選擇使用 sudo，或調整 npm 全域目錄權限。總之目標是：確保你能順利安裝 PM2，且之後的 pm2 命令能正常使用。

第四章：準備與上傳 Node.js 應用

4.1 選擇部署型態：源碼直接跑或打包後跑

你可以用兩種常見方式部署：

• 直接跑源碼：適合簡單項目，但依賴路徑與編譯步驟可能在伺服器上不一致
• 打包後跑：例如 TypeScript 編譯到 dist，部署 dist 更穩，並降低伺服器安裝依賴的複雜度

若你使用 TypeScript 或框架（如 NestJS、Next.js API 等），通常建議打包後部署。這樣 PM2 啟動時只需要執行已編譯的入口檔。

4.2 上傳檔案與安裝依賴

華為雲帳號購買 你可以使用 scp、sftp 或 Git 拉取上線。無論哪種方式，上線流程都應包含：

• 把程式碼放到伺服器固定路徑（例如 /var/www/myapp 或 /opt/myapp）
• 安裝 production 依賴：npm ci --omit=dev 或 npm install --production
• 確認 package.json 中的啟動腳本

注意：如果你使用了 lockfile（package-lock.json），npm ci 會更可預期。部署環境越穩，你後續排查問題越省時間。

第五章：配置啟動腳本與環境變數

5.1 package.json 啟動腳本

PM2 通常會直接執行你指定的啟動命令。你可以在 package.json 設定類似：

• start：node dist/index.js
• 華為雲帳號購買 或 start：node server.js

如果你打算用 PM2 監控重啟（例如只要程式崩潰就重啟），就保持啟動命令簡潔明確。複雜的 shell 展開或多步指令，可能導致環境變數沒有正確注入。

5.2 環境變數的注入策略

很多人上線後才發現：應用在本地有 .env，卻忘了在伺服器配置。結果服務雖然啟動了，但連資料庫、讀配置失敗。解法有兩種主流路徑：

• 在 PM2 啟動時明確傳入 env（推薦清晰管理）
• 在伺服器建立環境檔並讓應用讀取（如 dotenv），但要確保路徑與權限正確

我更建議把關鍵環境變數交給 PM2 管。你可以把 PORT、NODE_ENV、DB_URL 等寫在 PM2 的 ecosystem 檔案裡，讓每次啟動都一致，降低「改了 .env 卻沒生效」的麻煩。

第六章：使用 PM2 實現守護與自動重啟

6.1 最簡單的啟動方式：pm2 start

當你的應用入口檔明確（例如 dist/index.js），你可以先用最簡單的方式讓它跑起來，確認沒有語法或依賴問題。

基本流程：

• 華為雲帳號購買 進入應用目錄
• 執行 pm2 start 你的入口檔
• 查看狀態：pm2 status

此階段你要特別注意：服務是否綁定了正確的網卡與端口。有些框架預設綁在 localhost（127.0.0.1），導致外部無法訪問。建議你的服務在生產環境下綁定到 0.0.0.0（或至少確保雲上安全組放行正確端口）。

6.2 ecosystem.config.js：把配置變成可管理的資產

當你希望長期維運，單次命令不夠穩妥。最實用的方法是建立 ecosystem.config.js（或 JSON），把所有啟動參數整理成檔案。這樣你可以清楚地看到：服務名稱、執行檔、執行參數、環境變數、重啟策略等。

一般你會在 ecosystem 裡設定以下重點：

• name：例如 my-node-api
• 華為雲帳號購買 script：入口檔路徑，例如 dist/index.js
• env：生產環境變數，例如 PORT、NODE_ENV、DB_URL
• autorestart：建議設為 true（默認即是）
• restart_delay：避免瞬間重啟造成資源暴衝
• max_memory_restart：例如設置 300M，防止內存持續上漲後拖垮系統

其中 max_memory_restart 非常適合排除「不易立刻修復但能保護服務」的問題：當程式因記憶體洩漏導致內存一路上升，PM2 能在達到閾值後重啟進程，讓服務恢復到可用狀態。當然，根本解決仍是修復洩漏，但這個策略能提供緩衝時間。

6.3 自動重啟策略：重啟但要可控

「會重啟」不等於「重啟得好」。你需要考慮兩種情況：

• 服務因偶發錯誤退出：你希望快速重啟恢復服務
• 服務因配置錯誤或程式 bug 持續崩潰：你希望不要陷入無限快速重啟耗盡資源

因此，重啟延遲（restart_delay）和最大內存重啟（max_memory_restart）就顯得重要。必要時，你也可以設置重啟次數限制或根據日誌判斷是否需要人工介入。但對多數情況，上述兩項已足夠提升穩定性。

第七章：日誌管理與排錯思路

7.1 日誌放哪裡：不要只看終端

部署後你一定要能回答：服務怎麼了？PM2 會把 stdout/stderr 進行記錄，讓你可以追溯啟動失敗或運行異常的原因。建議你在 ecosystem 裡指定 log 文件路徑，讓不同服務的日誌不互相干擾。

你至少要掌握三件事：

• 如何查看即時日誌（pm2 logs 或依你設置的 log 路徑）
• 如何定位最近一次崩潰時間點
• 如何確定錯誤是來自依賴、環境變數還是程式邏輯

7.2 常見錯誤：端口、綁定地址與權限

下面幾類錯誤幾乎是部署 Node.js 的「必經之路」，你可以用更高效的方式排查。

• 華為雲帳號購買 應用啟動但無法訪問：通常是綁定地址錯或安全組未放行端口。檢查監聽的 IP 與雲上放行規則。
• 連線失敗：常是資料庫連線串缺少必要參數或環境變數未注入。
• 權限問題：log 目錄或程式目錄權限不足導致寫入失敗，進而讓服務啟動中斷。
• 依賴缺失：使用了 npm install 但少了 production 依賴，或 lockfile 不一致。

把 PM2 當成「守護者」的同時，也要把它當成「資訊入口」。日誌越清楚，修復越快。

第八章：開機自啟與長期維運

8.1 保存 PM2 設定：讓服務重啟也站得起來

雲主機可能會因為維護、調整或意外重啟而停機。你希望服務重新起來，而不是等你手動登機處理。

PM2 提供保存進程狀態與開機腳本的方式。你需要做的就是：

• 在服務啟動並驗證正常後保存狀態
• 讓系統重啟後自動載入並啟動 PM2 進程

實務上，建議你把「保存狀態」作為部署流程的一步，確保每次更新後都不會遺漏。

8.2 設定啟動順序與健康檢查思路

當你的服務依賴資料庫或外部服務時，開機瞬間可能連線尚未可用。這時，服務可能啟動失敗又重啟，造成短暫不可用。解法可以是：

• 在應用端加入重試策略（例如連線失敗後延遲重試）
• 使用 PM2 的重啟延遲，降低立即失敗後的抖動
• 必要時在 Nginx 或反向代理層做健康檢查與上線策略

如果你使用反向代理（例如 Nginx），健康檢查與緩衝會更顯著。即使後端在短時間內不可用，用戶仍可能看到可控的錯誤或重試體驗，而不是整站崩掉。

第九章：可選的反向代理思路（提升可用性）

很多人部署 Node.js 後，直接把應用端口對外放行。這能跑起來，但會讓你在未來面對 SSL、壓縮、靜態資源與跨域策略時更被動。

華為雲帳號購買 比較常見的做法是：在雲主機上配置反向代理（例如 Nginx），讓外部只暴露 80/443，內部 Node.js 服務跑在私有端口（如 3000）。這樣你可以把：

• HTTPS（證書續期）
• 壓縮（gzip/brotli）
• 緩存與限流
• 路由轉發

交給反向代理處理，而 PM2 只負責守護 Node.js 進程。兩者分工明確，長期更好維護。

即使你現在不打算上 Nginx，仍建議你在設計時預留這個架構：應用端不要依賴外部必然透過固定域名才可運作；同時把 CORS、信任代理（trust proxy）等因素整理好。

第十章：一次完整上線流程範例（你可以照著做）

10.1 在本地完成打包與測試

先在本地或 CI 環境確認：

• 執行測試或至少跑通主要 API
• 配置文件與環境變數在打包後仍能正確被應用讀取
• 輸出 dist 或構建產物存在，入口檔確實可被執行

10.2 上傳到華為雲香港節點

把應用上傳到伺服器固定路徑，然後：

• 安裝 production 依賴
• 確認檔案權限可以讀寫

10.3 先用 pm2 啟動驗證，再用 ecosystem 管理

流程可以這樣：

• 先 pm2 start 入口檔，確保服務能正常回應
• 確認日誌沒有致命錯誤
• 建立 ecosystem.config.js，把你用到的參數固化
• 用 ecosystem 啟動並查看 pm2 status

10.4 設置自動重啟與開機自啟

最後：

• 啟動完成後保存 PM2 狀態
• 驗證重啟後仍能自動拉起
• 檢查監控指標或至少確保日誌輪轉策略不會讓磁碟爆掉（如果你日誌量很大，這點尤其重要）

第十一章：常見踩坑總結（把失敗變成經驗）

11.1 服務綁定問題導致外部不可訪問

最常見的情況是服務只綁在 127.0.0.1，結果雲端安全組放行端口也沒用。檢查你的服務啟動參數或框架設定，確保監聽地址正確。

11.2 環境變數沒有注入到 PM2

你在 shell 裡能跑，不代表 PM2 能跑。因為 PM2 啟動時的環境不同。把環境變數寫入 ecosystem 的 env，或在啟動命令中明確傳入，能顯著降低這類問題。

11.3 依賴安裝不一致造成啟動失敗

本地 npm install 過但伺服器沒有 lockfile 或 npm ci 沒用，可能造成依賴版本差異，導致某些 API 行為不同甚至啟動失敗。使用 lockfile 與 npm ci 是更穩妥的習慣。

11.4 日誌太大導致磁碟滿

PM2 會持續記錄日誌，若不做控制，長期可能填滿磁碟。你可以規劃日誌路徑與輪轉策略，或把過期策略納入運維流程。穩定不只是進程重啟，更是資源管理。

第十二章：結語：把部署做成可預期的流程

在華為雲香港節點部署 Node.js 服務，最大的價值不在於「第一次能跑」，而在於「未來一直能穩」。PM2 的守護與自動重啟，解決的是進程意外退出帶來的可用性問題；而你在部署前後補齊的環境變數、日誌管理與權限檢查，則是決定這套方案能否長期可靠的關鍵。

當你把 ecosystem 設定固化，把啟動流程變成可重複的 SOP，把開機自啟納入部署步驟，你會發現維運的焦慮明顯降低。服務像產品一樣持續運行，而你把更多時間用在真正提升系統能力與使用體驗上，而不是反覆修補意外中斷。