Azure帳號代開 Azure虛擬機如何配置負載均衡

前言：你到底要的是哪種「負載均衡」

談 Azure 虛擬機（VM）配置負載均衡，第一個問題不是「怎麼點按按鈕」，而是「你要分散的是什麼流量、需要多穩、要不要保證連線一致性」。因為 Azure 提供的負載均衡能力不只一種：有傳統意義的四層負載均衡，也有更高層的能力；而你的架構會決定你應該選哪一套，以及網路該怎麼設計。

以最常見的場景來說，你會有至少兩台（建議多台）虛擬機，運行同一個服務（例如 Web、API、或 TCP 服務）。你希望使用者的連線被分配到不同 VM 上，同時當某台 VM 異常時，流量能自動避開，並在其恢復後重新加入。

因此，一套清晰的目標可寫成：

• 對外入口要穩定：不因 VM 擴縮或故障而影響。
• 分散流量：讓多台 VM 共同承擔。
• 健康檢查：自動判斷哪些後端可用。
• 連線屬性可控：例如 TCP 連線維持、特定埠一致性。
• 易於運維：新增 VM 後可以快速納管。

接下來我們用一個實作型的思路，從網路到設定，逐步把「負載均衡」搭起來，並在每一步告訴你可能踩的坑。

第一章：在動手前先做需求與網路規劃

1.1 確認流量型態與協定層級

負載均衡器是否能支援你的協定，通常取決於你使用的能力層級。大多數 VM 上的 Web（HTTP/HTTPS）或一般 TCP 服務，都可以依照對應的埠與協定進行轉發與健康檢查。

你需要先回答：

• 對外提供哪個服務？（HTTP 80、HTTPS 443、或自訂 TCP 埠）
• 是否需要 TLS 終止？（有些情境在負載均衡層處理，有些在 VM 內處理）
• 是否需要會話一致性（sticky session）？例如部分 Web 應用把會話存在記憶體中。
• 健康檢查用什麼方式？HTTP 路徑？TCP 連線？或是其他探測方式。

1.2 設計 VNet 與子網：先把「可路由」想清楚

Azure 負載均衡常見做法是讓負載均衡器與後端 VM 位於同一個虛擬網路（VNet）架構下，並用子網管理 IP。你不需要複雜，但要確保：

• VM 網路介面（NIC）有可用的私有 IP，且部署在目標子網。
• 負載均衡器引用正確的子網/前端配置方式。
• 網路安全群組（NSG）與路由（UDR）不會擋掉健康檢查或服務流量。

很多「負載均衡器看起來設定成功但流量不進 VM」的問題，都與 NSG 或防火牆規則有關。後面我們會把排查清單整理成可以直接用的步驟。

1.3 規劃公網與私網：前端 IP 是誰？給誰用？

Azure帳號代開 你有兩種主要選擇：對外（公網）入口或內部（私網）入口。前端 IP 的選擇會影響你要怎麼測試，也影響客戶端來源。

• 公網：適合面向互聯網的服務。
• 私網：適合內部系統、跨 VNet、或需要走 VPN/ExpressRoute 的企業網路。

本文以最常見的「公網入口 + VM 後端」為思路描述，你若是內部入口，流程概念一樣，只是前端與路由策略不同。

第二章：建立負載均衡所需的核心元件

要把負載均衡器搭起來，通常至少包含幾個核心概念：前端、後端池、探測器、負載均衡規則。你可以把它理解成「入口如何接收」與「後端如何被判斷可用、以及如何轉發」。

2.1 前端（Front-end）：入口 IP 與連線接法

Azure帳號代開 前端是外界用來連到你的服務的位址。它可能是公網 IP 或內部 IP。你會為負載均衡器建立一個前端配置，並指定其對外使用的連接埠（例如 80 或 443）與協定。

重點是：前端負責「接到」連線，但真正決定「轉去哪台 VM」的是後端池與規則。

2.2 後端池（Backend pool）：哪些 VM 會被分流

後端池是一組候選目標。你會把 VM 的 NIC（網路介面）加入後端池，或用其他方式把 VM 納入。後端池的配置要一致：例如都提供同一埠的服務。

你至少需要兩台以上的 VM 才能體現負載均衡的意義；如果只有一台，健康檢查仍然能工作，但分流價值會大幅下降。

2.3 健康探測器（Health probe）：誰是可用的後端

健康探測器會對後端發出探測，判斷該 VM 是否可接流量。它是整個系統的「眼睛」。如果探測器設定錯了，你的負載均衡可能會把流量導到不可用的 VM，或反過來讓所有 VM 都被判定為不健康。

你需要考慮：

• 探測協定與端口：探測用的埠要與你的服務對應。
• 探測路徑（若是 HTTP/HTTPS 探測）：路徑必須存在且返回可預期的狀態碼。
• 超時與間隔：不要過於激進，也不要太慢。
• 允許的回應：例如 HTTP 探測要檢查特定狀態碼（200-399 常見）。

2.4 負載均衡規則（Load balancing rules）：如何把前端連到後端

規則描述「前端哪個連接埠、協定」要怎麼映射到「後端哪個連接埠」，以及使用哪個健康探測器。

常見規則包含：

• 前端埠與後端埠：例如前端 80 -> 後端 80。
• 協定：TCP。
• 會話持久性（如果需要）：例如同一用戶在一段時間內維持到同一台 VM。
• 來源 NAT（SNAT）相關行為：影響回應路由與連線數量，這也是常見的排查點。

第三章：實作步驟（以 Web 服務為例）

接下來用一個務實流程來走：假設你有兩台 VM（vm-01、vm-02），都部署了 Web 服務，並在 VM 上開放 HTTP 80 端口。目標是讓使用者存取負載均衡器的前端 IP（或 DNS）時，連線自動分配到健康的 VM。

3.1 建立或確認 VM 與服務

Azure帳號代開 首先確認每台 VM 上服務運行正常。你可以直接在 VM 內部測試：

• 本機或通過內網 IP 測試：curl 或瀏覽器訪問是否可用。
• 確認服務監聽在正確的埠（例如 0.0.0.0:80 或對應的網卡埠）。
• 確認 OS 防火牆（例如 Windows 防火牆或 Linux iptables/ufw）允許入站連線。
• 確認 NSG 規則允許負載均衡器探測與流量。

很多人只開了服務端口，但忽略了 NSG 或 VM 防火牆，結果探測失敗，後端池永遠不健康。

3.2 建立後端池並加入 VM NIC

進入負載均衡器配置頁面後，先建立後端池。然後把 vm-01 與 vm-02 的 NIC 加入後端池。這一步的關鍵是：你加入的是 NIC，而不是 VM 名稱；每台 VM 可能有多張 NIC，但負載均衡通常針對特定 NIC。

若你有多 NIC，建議先確認哪張 NIC 承載服務流量，並確保 NSG 附在正確的 NIC 上。

3.3 設定健康探測器

接著建立健康探測器。對於 Web 常見做法是 HTTP 探測。例如：

• 協定：HTTP
• 端口：80
• 路徑：/health 或 / （看你服務提供什麼）
• 探測間隔：例如每 5 秒
• 不健康閾值/健康閾值：例如連續幾次失敗視為不健康

你要特別小心探測路徑不要依賴外部條件（例如需要存取資料庫才回應 200）。如果你的健康檢查過於嚴格，可能造成短暫故障就讓服務被迅速剔除，反而降低整體可用性。理想狀態是探測器反映「服務核心是否能提供回應」，而不是把所有依賴都納入。

3.4 建立負載均衡規則：前端到後端的映射

建立規則時，你需要選擇：

• 前端 IP：負載均衡器的前端（公網 IP 或內部 IP）
• 前端埠：例如 80
• 後端埠：例如 80
• 協定：TCP
• 健康探測器：綁定你剛才建立的探測器
• 會話持久性：若應用需要，才開啟，否則可保持關閉（通常更利於均衡）。

如果你是 HTTP/HTTPS 服務，還要注意 HTTPS 可能牽涉憑證與 TLS 終止位置。簡單起見，若先跑 HTTP，流程會更容易驗證。

3.5 檢查 SNAT 與連線來源：別忽略這個細節

當負載均衡器把連線轉到後端 VM 時，回包如何回來會影響你的體驗。Azure 在很多情境會做來源 NAT（SNAT）或針對連線管理做特定行為。若你的流量來源多、連線數量大，SNAT 相關限制可能成為瓶頸。

雖然你可以先用預設值跑通流程，但在規模化或高併發場景，建議你提前評估：

• 連線數量預估：高併發下 SNAT 端口耗盡風險存在。
• 長連線：例如 WebSocket 或高頻 API 呼叫。
• 多端口映射：如果你的規則不只一個埠，回包壓力會更複雜。

這些因素不會影響「是否能通」，但會影響「上線後能不能穩」。因此在本文的實作驗證後，我也會在排查章節留下一些可觀察的指標。

3.6 建立並驗證前端：DNS 或直接測試 IP

配置完成後，你可以用公網 IP 直接測試：

• 從你的電腦或同網段主機訪問負載均衡器前端 IP 的 80。
• 觀察是否能輪流命中後端 VM。
• 在 VM 上準備能辨識來源的回應（例如顯示主機名），用來確認分流是否正常。

驗證方式要「可觀測」。你不應只用「能打開網頁」來判斷，因為健康探測器可能也在運作但尚未真的把流量平均分配。

第四章：健康檢查怎麼影響真實流量

健康探測器的設定是負載均衡成敗的分界線。探測器判定不健康時，負載均衡器會把該 VM 排除在轉發清單之外。你要理解兩個時間概念：判定延遲與恢復延遲。這會影響故障切換速度。

4.1 HTTP 探測與 TCP 探測的差異

HTTP 探測比 TCP 探測更像「真正用戶體驗」。因為它不只看端口是否可連線，還會看應用層是否回應預期狀態碼。

• TCP 探測：只要端口能接受連線就算健康，可能會把應用故障仍判為可用。
• HTTP 探測：若應用返回 500/404 或超時，會被判為不健康，更符合 Web 服務需求。

但 HTTP 探測也有代價：探測路徑要維護、狀態碼要一致、應用要能快速回應。你應該提供一個專用的 /health 端點，讓健康檢查簡單且穩定。

Azure帳號代開 4.2 健康探測失敗的常見原因

Azure帳號代開 以下是最常見的失敗類型，你可以逐條對照檢查：

• VM 服務沒有在正確埠監聽。
• OS 防火牆擋住入站連線。
• NSG 沒有允許探測來源或探測端口。
• /health 路徑不存在，或回傳狀態碼不符合探測器的預期範圍。
• 應用依賴資料庫/外部服務才回應成功，導致探測器在外部故障時把 VM 全擋掉。
• 路徑或重導致探測超時（例如反向代理配置不一致）。

如果你把探測端點設計成「只檢查服務本體是否起來」，通常能避免過度排除。

Azure帳號代開 4.3 故障切換的行為：你會看到什麼

當其中一台 VM 故障時，你希望使用者的下一次連線會自動落在健康的 VM。你可以用兩種方法驗證：

• 停掉其中一台 VM 的服務（例如關閉 web server 或讓它回傳錯誤），看負載均衡器是否將它標記為不健康。
• Azure帳號代開 觀察連線命中：在健康與不健康切換期間，分流是否符合預期。

Azure帳號代開 如果你看到「健康狀態切很慢」，通常是因為探測間隔與閾值設得太保守。你可以調整，但也別讓它太快，避免抖動。

第五章：會話持久性與應用層設計

負載均衡把不同請求分配到不同 VM。這對無狀態（stateless）服務通常沒問題；但對把會話存放在記憶體的應用會造成問題。此時你可能會考慮會話持久性，但它只是緩解，不是根治。

5.1 何時需要 sticky session

當你有以下特徵，可能需要會話持久性：

• 應用把登入狀態存放在 VM 記憶體。
• 會話未使用共享儲存（例如 Redis、資料庫或集中式 session service）。
• 應用不具備水平擴展能力。

如果你能把會話設計成外部共享儲存，通常會比 sticky session 更可靠，因為它允許你更自由地擴縮與維護。

5.2 不建議把 sticky session 當作主要方案

sticky session 的問題在於：當某台 VM 故障，這個「黏」住的會話也會失效，使用者體驗仍會受到影響。更長遠的做法是讓應用更接近無狀態。

因此，在建立負載均衡規則時，你可以先用「不開啟會話持久性」跑通，驗證分流與健康檢查後，再依應用需求評估是否要開啟。

第六章：常見錯誤與排查清單

負載均衡最怕的是「表面正常、實際不通」。下面這份清單可以直接當作你 troubleshooting 的順序，從快到慢、從網路到應用。

6.1 用戶端測試能連，但後端不分流

• 確認規則是否綁定正確的健康探測器。
• 確認後端池是否真正包含 VM 的 NIC。
• 檢查健康探測器狀態：後端是否顯示 healthy。
• Azure帳號代開 確認 VM 是否開放服務埠（含 OS 防火牆）。
• 確認 NSG 是否允許來自負載均衡器所需的入站。

如果健康探測器顯示全部不健康，你就不必一直猜負載均衡器的轉發行為，應先回到探測器與網路規則。

6.2 健康探測器顯示不健康，但你手動訪問 VM 是正常的

這種情境常發生在「網路路徑不同」。你從電腦能訪問 VM，代表某些路徑打通了，但探測器的來源 IP、NSG 規則或防火牆策略可能不同。

• 檢查 NSG 是否針對探測端點/埠放行。
• 檢查 VM 上應用是否對特定 Host header 或路徑有不同邏輯，導致 /health 回傳非預期狀態碼。
• 如果使用 HTTP 探測，確認探測路徑與協定（http/https）一致。

6.3 連線在高併發下開始失敗

這不是一開始就出現的問題，但在正式環境會很常見。可能原因是 SNAT 端口耗盡、後端資源不足、或應用層超時。

• 監控負載均衡器的連線統計與錯誤（例如逾時、失敗）。
• Azure帳號代開 查看 VM CPU、記憶體、連線數、服務回應時間。
• 若使用多規則與多埠，確認負載均衡器的 NAT 行為與連線配額策略。

這階段的排查要偏「數據」而不是憑感覺：你要知道問題出在網路層還是應用層。

6.4 健康狀態抖動：忽好忽壞

抖動通常表示探測端點不穩定，例如探測間隔太短、應用偶發超時、或健康端點依賴外部系統。

• 調整探測間隔與閾值，讓判定更穩。
• 簡化 /health 邏輯，避免需要外部依賴才能回應成功。
• 檢查服務回應時間與錯誤率。

第七章：安全與合規：把負載均衡接好，也要保護好

負載均衡不只是讓流量分出去，也要把攻擊面降到最低。你需要在網路、主機與應用三個層次做控制。

7.1 NSG 原則：最小放行

NSG 建議採用最小權限。對外只開必要的埠（例如 80/443），對後端服務只允許所需來源或至少允許負載均衡器探測。

若你設定太寬，攻擊會更容易；設定太窄，又會導致健康探測不過。

7.2 VM 上的防火牆與應用層防護

即使 NSG 放行，也要在 VM 上確保防火牆符合預期。對 Web 服務，還要處理：

• HTTP 方法限制（若可行）。
• 速率限制或 WAF（視架構）。
• 更新與漏洞修補機制。

7.3 記錄與告警：不要等事故才看日志

上線後，你要能回答「為什麼今天突然變慢」或「為什麼某台 VM 被剔除」。因此建議至少具備：

• 健康探測結果的趨勢。
• 後端 VM 的服務錯誤率與回應時間。
• 負載均衡器的失敗或逾時統計。
• 資源指標（CPU、Memory、Network）。

第八章：運維與擴充：讓它可持續成長

負載均衡真正的價值在於「可擴」。如果你的新增 VM 都要手動重複設定，那運維成本會迅速上升。你需要思考如何讓擴充更簡單。

8.1 新增 VM 如何納管：保持一致性

當你要擴容時：

• 先部署相同的服務版本與健康端點。
• 確認防火牆/NSG一致。
• 加入後端池並等待健康探測變為 healthy。
• 用可觀測手段驗證分流是否命中新 VM。

Azure帳號代開 保持 VM 映像（image）與網路規則的一致性，是降低故障的核心。

8.2 零停機更新的基本思路

如果你要更新應用：

• 先在一台 VM 上部署新版本。
• 觀察健康端點與錯誤率。
• 通過後再逐台更新。
• 必要時可以先把不準備接流量的 VM 從後端池移除，避免影響用戶。

這種方式不需要花太多工具，卻能大幅降低風險。

結語：把負載均衡當作系統工程，而不是一次設定

Azure 虛擬機配置負載均衡，核心並不在於你能不能建立一個規則，而在於你能不能把「入口、分流、健康判斷、連線行為、安全與運維」做成一個穩定且可理解的系統。當你每一步都能回答「為什麼這樣設」與「出了問題要先看哪裡」，你就會從反覆嘗試，走向可預期的交付。

如果你現在正準備上線，建議你用本文提供的流程做一次完整的自我檢查：後端池是否正確、健康探測是否真的通、服務端點是否可被探測器穩定回應、NSG 與防火牆是否一致、以及在高併發下是否有 SNAT 與資源的風險。把這些先想透，上線後你會省下很多不必要的時間。