Azure企業帳號購買 香港伺服器搭建NodeJS環境：安裝NVM、Node.js並配置PM2守護進程

第一章：為什麼要先把 Node 環境建好

在香港伺服器上跑 Node.js，很多人一開始只追求「跑起來」：把程式丟上去、npm 安裝完、用 node 啟動。可是一旦進入日常維運，你會很快遇到幾個問題：版本控管混亂、重啟後服務不在、進程意外退出卻沒人察覺、日誌散落難查、環境變數難以一致復現。這些問題的共同點是：缺少一個可靠的作業基礎。

比較穩妥的做法是：用 NVM 管理 Node 版本，用 PM2 管理進程。NVM 讓你能在同一台機器上維持多個 Node 版本，並且在部署時指定目標版本；PM2 則把「常駐、重啟、日誌、開機自啟」這些運維工作變成標準流程。當你的服務要在香港的線路上長時間提供 API、Web 或背景任務時，這套基礎會讓你少踩很多坑。

第二章：前置準備與目標

在開始之前，先確認你手上的是哪類伺服器環境。通常你會面對其中幾種情況：Linux 發行版（Ubuntu、Debian、CentOS、AlmaLinux 等）、虛擬機或雲主機、是否使用 root 登入、是否已有某個 Node 或 npm。不同發行版的安裝命令略有差異，但主流程一致。

本文目標分三步完成：

• 安裝 NVM，並能透過它安裝指定版本的 Node.js。
• 安裝 Node.js 與常用工具，確認可正常執行。
• 安裝 PM2，使用它啟動你的 Node 應用，並配置開機自啟與日誌。

另外，因為你是在「香港伺服器」環境中做部署，網路速度與套件下載體驗可能會與海外或國內不同。這不是要你做複雜的加速方案，但我們會在流程中保留排錯點，避免你卡在網路下載上找不到原因。

第三章：安裝 NVM

NVM（Node Version Manager）是管理 Node.js 版本的工具。你會用它來安裝你需要的 Node 版本，並在切換版本時保持環境一致。安裝 NVM 通常只需一段腳本，但你要注意：安裝目標使用哪個使用者、以及安裝後要讓 shell 能讀到 nvm 指令。

3.1 登入並選擇非 root 使用者

如果你用的是 root 登入也不是完全不能做，但實務上建議使用普通使用者，降低誤操作風險。假設你已登入並確認為某個使用者（例如 ubuntu、deployer 或 cloud-user），接下來直接進行 NVM 安裝即可。

3.2 執行 NVM 安裝

在使用者家目錄下安裝 NVM。常見的流程是先確保有 curl 或 wget；若沒有，你可以先安裝基礎工具。

你可以使用以下命令（不同 Linux 發行版對套件名可能略有差異）：

sudo apt-get update
sudo apt-get install -y curl ca-certificates

接著安裝 NVM。執行時請留意網路環境，若下載超時，稍後再看排錯章節。

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash

如果你使用的是某個特定版本的 NVM，你也可以固定版本；但對多數情境，使用安裝腳本的默認方式即可。安裝完成後，NVM 會被寫入到你的家目錄下（通常是 ~/.nvm），並需要讓 shell 讀取。

3.3 讓 nvm 在終端可用

安裝腳本通常會提示你編輯 ~/.bashrc 或 ~/.zshrc。如果你的使用環境是 bash，一般是 ~/.bashrc。你可以在檔案末尾加入（或確定已存在）以下內容：

export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && . "$NVM_DIR/nvm.sh"
[ -s "$NVM_DIR/bash_completion" ] && . "$NVM_DIR/bash_completion"

然後重新載入設定：

source ~/.bashrc

確認 nvm 是否可用：

command -v nvm
nvm --version

若看到版本號或輸出正常，就表示 NVM 已可用。

3.4 常見問題：nvm 指令找不到

如果你執行 nvm 提示 command not found，通常原因是：你沒有 source 對應的設定檔，或你實際使用的 shell 不是 bash。檢查你當前 shell：

echo $SHELL

如果是 zsh，那你要編輯 ~/.zshrc。只要對應到正確的 shell 初始化檔，問題就能解決。

第四章：安裝 Node.js（透過 NVM）

有了 NVM，你就可以安裝你需要的 Node.js 版本。實務上，選擇版本要符合你的專案需求。你的專案 package.json 可能指定了 engine，或某些依賴只支援特定版本。

4.1 列出可用的 Node 版本

使用以下命令查看可安裝的版本：

nvm ls-remote

如果輸出太長，可以用 grep 篩選。例如只看 20.x：

nvm ls-remote | grep "v20\."

4.2 安裝目標版本

假設你要安裝 Node 20（這是近年的常用 LTS）。你可以執行：

nvm install 20

若你要固定到某個 patch，例如 20.11.1，就用：

nvm install 20.11.1

4.3 使用並確認版本

安裝完成後切換：

nvm use 20

確認 Node 與 npm：

node -v
npm -v

你也可以查看目前 nvm 指向的版本：

nvm current

4.4 設定預設版本（讓新開終端也用同一版）

若你希望每次新開終端都自動使用某個 Node 版本，執行：

nvm alias default 20

之後重新登入或重新 source 確認：

node -v

第五章：安裝與調整 npm 設定（讓部署更順）

Node 環境搭好了，但部署流程仍可能卡在 npm/yarn 的行為差異。你要做的不是「盲目加速」，而是確保 npm 的基本行為可預期。

5.1 使用專案內的 package-lock

如果你的專案使用 npm，通常建議提交 package-lock.json。部署時用 npm ci 會比 npm install 更一致，尤其在不同機器上。

PM2 啟動前你至少要跑通：

• 進入專案目錄
• 安裝依賴
• 確保啟動腳本可用

5.2 設定 npm 的 registry（可選）

如果你發現 npm 下載套件速度很慢或超時，可以考慮設定 registry。但這一步要針對你的實際狀況做選擇。若你暫時沒有遇到問題，就先保持預設。

Azure企業帳號購買 若需要替換 registry（以可選方式示意），可以透過：

npm config set registry https://registry.npmjs.org/

不同地區可能更偏好不同鏡像，但你應該優先確保可用性與一致性。避免切來切去導致緩存與鎖文件不一致。

第六章：安裝 PM2 並配置守護進程

PM2 是 Node 生態常用的進程管理工具，擅長處理：崩潰自動重啟、集群模式、重啟保留環境、日誌分檔、開機自啟等。對於需要 24/7 提供服務的應用，它的價值在於讓你把「維運工作」變成「設定一次，長期可靠」。

6.1 安裝 PM2

你可以用 npm 全域安裝 PM2。假設你已切換到正確的 Node 版本，執行：

npm install -g pm2

確認：

pm2 -v

6.2 在專案目錄啟動程式

假設你的專案入口檔是 server.js 或 app.js。你可以先直接用 PM2 啟動一次，確認程式沒有立即退出。

例如啟動 server.js：

cd /path/to/your-project
pm2 start server.js --name my-app

若你的啟動腳本是 npm 的 start，也可以用：

pm2 start npm --name my-app -- start

這種方式通常適合專案的 package.json 已正確定義啟動命令。

6.3 觀察狀態與日誌

查看進程：

pm2 status

看即時日誌：

pm2 logs my-app

或用更完整的摘要查看：

pm2 show my-app

Azure企業帳號購買 若你發現服務反覆重啟（狀態顯示 unstable 或多次 restart），通常是程式在初始化時報錯。此時日誌是你的第一線索，直接看 PM2 的 stderr/stdout。

6.4 設定環境變數（不要硬編在程式裡）

部署時常見需求是設定 NODE_ENV、資料庫連線字串、API Key、服務端口等。建議用 PM2 的環境配置能力，讓部署可維護。

簡單方式是用 --env 或在指令中指定環境變數。更常見的是用 ecosystem 檔。

6.5 使用 ecosystem.config.js 建立可維護配置

在專案根目錄建立 ecosystem.config.js。例如：你的應用使用 Node 啟動，且你需要設定端口與環境。

module.exports = {
  apps: [
    {
      name: 'my-app',
      script: 'server.js',
      instances: 1,
      autorestart: true,
      watch: false,
      max_memory_restart: '300M',
      env: {
        NODE_ENV: 'production',
        PORT: 3000
      },
      // 也可以加入 pm2 管理用的其他環境
      // 例如：DATABASE_URL: '...'
    }
  ]
};

啟動 ecosystem：

pm2 start ecosystem.config.js

如果你要更新配置後重新載入：

pm2 reload ecosystem.config.js

當然，如果你的應用不是可平滑重載，也可以用：

pm2 restart ecosystem.config.js

6.6 開機自動啟動 PM2

如果你不設定開機自啟，重啟後服務就消失。PM2 提供一鍵配置，但你需要依賴你的系統初始化機制（常見是 systemd）。執行：

pm2 startup

它會輸出一段需要你執行的命令。你要照它給的命令複製執行，通常會涉及 sudo 與 env PATH=...。

設定後，保存當前 PM2 進程列表：

pm2 save

這樣重啟後 PM2 會自動拉起你管理的應用。

6.7 PM2 守護與重啟策略：autorestart 與健康狀態

PM2 的 autorestart 會在應用退出後自動重啟，這對於意外錯誤很重要。但如果你的程式是因為配置錯誤持續退出，PM2 會一直重啟直到你修正配置。所以你要把它當成「自動修復管線」，同時也要讓日誌明確可查。

你可以在 ecosystem 中設定 max_memory_restart，避免記憶體洩漏逐步拖垮機器。至於 watch 模式，生產環境通常建議關閉，避免檔案變動導致不必要重啟。

Azure企業帳號購買 第七章：日誌與故障排查流程（從日常維運角度）

部署成功只是第一步。你真正需要的是：出事時能快速定位問題，而不是「重啟後看看」。以下是一個務實的排查流程。

7.1 先確認 PM2 是否還在跑

執行：

pm2 status

如果你的狀態是 online，表示進程仍在；若是 errored、stopped 或重啟中，就需要看日誌。

7.2 檢查日誌：log 不是一種東西

PM2 的 pm2 logs 會把 stdout/stderr 合併顯示。你可以針對你的應用看最近錯誤：

pm2 logs my-app --lines 200

常見錯誤包含：

• 端口被占用（EADDRINUSE）
• 環境變數缺失（例如連線字串為 undefined）
• 找不到入口檔或路徑錯誤（MODULE_NOT_FOUND）
• 依賴套件版本不匹配導致啟動失敗

把錯誤訊息第一行抓出來通常就能直接定位。

7.3 確保重啟後環境一致

你可能遇到「手動啟動 OK，但 PM2 啟動不行」或反過來。這通常是因為手動啟動使用了你互動 shell 的環境，但 PM2 啟動時的環境不同。

因此你要確保：所有必要環境變數都在 ecosystem 中定義，或在 PM2 啟動命令之前正確載入。不要只把重要設定放在 .bashrc 裡，因為 PM2 的啟動可能不會使用互動式 shell 的載入流程。

第八章：整合部署步驟（把流程串起來）

當你要把它變成可重複的部署方式，可以把整體流程整理成一個固定節奏：

1. 登入香港伺服器，確保 NVM 可用並切到指定 Node 版本。
2. 進入專案目錄，使用 npm ci 或 npm install 安裝依賴。
3. 確認應用啟動命令正確（可先用 node 直接測試）。
4. 用 ecosystem 配置啟動腳本與環境變數。
5. 用 PM2 啟動、檢查狀態與日誌。
6. 執行 pm2 startup 與 pm2 save 完成開機自啟。
7. Azure企業帳號購買 部署後保留一段時間觀察錯誤與資源占用，確保穩定。

你會發現這套流程的關鍵不是某一條指令，而是「把不確定性吸收掉」：版本用 NVM 釘住；進程用 PM2 管住；環境用 ecosystem 明確寫清。

第九章：常見坑位與排錯清單

下面整理一些最常見的問題，讓你在香港伺服器上遇到時能快速處理。

9.1 NVM 安裝成功但切換失敗

可能原因包括：你沒有 source 正確的 shell 設定，或安裝過程中編譯工具缺失（某些 Node 版本會需要 build 工具）。

可以先確認：

nvm --version
nvm current

若仍不行，檢查是否有安裝編譯依賴（依發行版安裝 build-essential、gcc、g++ 等）。

9.2 npm 套件安裝卡住或失敗

如果網路下載超時，你通常會看到像是 ETIMEDOUT、ECONNRESET。這時你可以先換一個你能穩定連上的 registry，或重試。也要確認防火牆規則沒有阻擋。

Azure企業帳號購買 另外，確保你已切到目標 Node 版本再跑 npm ci，避免依賴安裝到錯誤版本的行為。

9.3 PM2 啟動後立即退出

這是最常見的「以為部署成功但其實沒有」。通常是程式初始化直接 throw error。你應該：

• Azure企業帳號購買 用 pm2 logs my-app 看到真正的錯誤
• 檢查 ecosystem 的 script 路徑是否正確
• 檢查環境變數是否缺失
• Azure企業帳號購買 檢查 port 是否已被其他服務占用

很多時候，錯誤訊息一眼就能看出是配置問題，而不是「PM2 壞了」。

9.4 重啟後服務沒有自動起來

這通常是沒執行 pm2 startup 的系統指令，或沒有執行 pm2 save 保存當前進程列表。按照下列順序檢查：

pm2 status
pm2 startup
pm2 save

也要確認你不是只在臨時 session 啟動、但沒有保存配置。

第十章：把它做成你自己的標準化配置

當你完成上述流程，你其實已經具備一個可以穩定運行 Node.js 的底座。下一步要做的，是把這套流程標準化，讓你每次部署都不靠運氣。

你可以在專案中固定：

• 入口檔名與啟動方式（script 或 npm start）
• ecosystem.config.js 的模板（含 env、autorestart、記憶體重啟策略）
• Azure企業帳號購買 日誌策略（確保你能快速定位錯誤）
• 部署命令（npm ci、pm2 reload/restart）

當你在香港伺服器上面對更高流量或更多服務時，這種「可重複」會直接降低維運成本。你不是在修一次性的問題，而是在建立一套能長期使用的工作方式。

結語：從可用到可靠的差距

很多新手停在「能跑」；真正讓你省心的是「可靠」。NVM 解決的是版本可控與環境一致；PM2 解決的是進程保活、重啟與開機自啟；而你的專案配置（ecosystem 與環境變數）則把那些容易出錯的差異變得可見。當這三者拼起來，你在香港伺服器上的 Node.js 部署會更像工程，而不是臨時救火。