阿里雲國際帳號註冊 阿里雲 SLB 負載均衡設定教學

第一章：為什麼要用 SLB？先把目標想清楚

在小型網站階段，大家常把「多開幾台後端」和「前面放一個反向代理」當成解法。但當流量變得不可預測，你會立刻遇到幾個現實問題：第一，某台後端慢了或掛了，流量仍被導到它身上；第二，擴容後你希望前端配置不必頻繁改動；第三，HTTPS 要處理證書與安全策略；第四，會話狀態如果需要保持，不能憑運氣。

阿里雲 SLB（Server Load Balancer）就是把這些問題集中處理：它提供統一入口，根據你設定的規則把連線分發到後端 ECS 或其他目標；它還會透過健康檢查判斷後端是否可用，避免故障擴散。更重要的是，它讓你把「流量入口」與「業務後端」解耦：後端怎麼加、怎麼換，前端入口可以維持穩定。

你在開始設定 SLB 前，先回答三個問題，後面每一步都會更順：

• 入口要做什麼協議？HTTP、HTTPS，還是純 TCP？
• 你的後端是誰？是 ECS、還是用了容器服務，或是透過內網地址？
• 阿里雲國際帳號註冊 需要哪些控制策略？例如權重分流、會話保持、是否要限制來源 IP、以及健康檢查方式。

接下來我們按實作順序，把 SLB 從零搭起來。

第二章：建立 SLB 實例前的準備工作

SLB 設定看似點幾個按鈕，但成功率往往取決於前置條件是否齊全。建議你先把以下資訊整理在一張紙或記事本：

• 你的前端訪問方式：網際網路（Internet）或內網（VPC/內網）
• 後端服務端口：例如 80、443、8080、9000 等
• 後端部署方式與地址：每台 ECS 的內網 IP 或私網地址
• 健康檢查路徑或探測方式：例如 HTTP `/health`，或 TCP 連線探測
• 證書資訊（若使用 HTTPS）：證書內容或證書 ID
• 預期策略：是否需要權重、是否需要會話保持、容忍延遲與超時設定

此外，不要忽略安全群組（Security Group）。SLB 本身通常需要放行到後端的端口；後端安全群組也要允許 SLB 入口的流量。很多「SLB 建好了但網站不通」的原因，都卡在這裡。

網路與地域：確保同一個邏輯範圍內可通

阿里雲 SLB 的選項會依你的網路模式不同而不同。一般你會在相同地域（Region）下選擇 VPC，以及與 ECS 同網段或可路由的子網。若你後端在不同 VPC 或路由不通，SLB 再怎麼設定都會徒勞。

DNS 與域名規劃：提前決定你要怎麼對外

如果你是要對外提供網站服務，通常會搭配域名解析。SLB 會給你入口地址或域名；你再把自家域名指向它。這一步可以後做，但你要確認：你的域名要走 HTTP 還是 HTTPS？是否要把 HTTP 301 到 HTTPS？這些都影響監聽器與規則。

阿里雲國際帳號註冊 第三章：建立負載均衡實例（SLB）—從控制台一步步到可用

登入阿里雲控制台後，找到「負載均衡 SLB」服務，通常會看到「負載均衡實例」的建立入口。你可以把流程理解為：選類型 → 選網路 → 設基本配置 → 配置監聽器 → 綁定後端 → 健康檢查 → 完成。

選擇負載均衡型態：常見是 SLB 七層或四層

在實際應用中，你多半會碰到兩種思路：

• 七層（HTTP/HTTPS）：能做 URL、Host、Header 等更細的路由與規則。
• 四層（TCP）：主要根據端口轉發，偏向傳統網路轉發。

如果你是網站，通常選七層更合適。若你是自訂協議或純 TCP 服務，就選四層。

網路選項：選 VPC、選可用區與容量

SLB 通常需要你選 VPC 與交換的子網。你也可能需要配置可用區（Zone）。選擇策略很直覺：讓後端 ECS 分散在不同可用區，SLB 就能在某一區故障時維持可用性（前提是後端也同樣分散部署）。

容量與規格方面，你可以先用預設值建立可用版本，後續再依流量與穩定性調整。不要一開始就追求最大值，否則成本容易失控。

建立後的基本檢查：先看狀態是否正常

實例建立完成後，通常會有「綁定的監聽器」與「後端」的配置狀態。此時你可能還不能真正打通業務，但要先確認：實例狀態是正常、沒有明顯配置錯誤提示。

第四章：配置監聽器（Listener）—把流量「怎麼進來」講清楚

阿里雲國際帳號註冊 監聽器是 SLB 的入口規則。你可以把它想像成「大門的門牌」。同一個 SLB 實例可以配置多個監聽器，例如：80 對應 HTTP，443 對應 HTTPS，或不同域名對應不同後端。

HTTP 監聽器：基礎但最容易漏設定

假設你要提供網站服務，常見流程是建立 HTTP 監聽器：

• 協議：HTTP
• 監聽端口：80
• 阿里雲國際帳號註冊 轉發協議/目標：通常也是 HTTP
• 後端端口：例如 80 或 8080

阿里雲國際帳號註冊 建立監聽器時，你通常還會看到「請求轉發」相關選項。重點是：監聽器與後端端口必須匹配你的實際服務。很多人會因為後端是 8080，卻在監聽器填 80，最後表面上 SLB 正常、實際卻一直 502。

HTTPS 監聽器：證書、協議版本與重定向策略

若你要用 HTTPS，通常要做兩件事：上傳或選擇證書，並配置 443 監聽器。你可能還會選擇是否支援 HTTP/2、TLS 版本等。

另外，你往往希望：

• 80 端口的請求自動 301 到 443
• HTTPS 訪問時能正確帶上 Host，讓後端知道是誰在訪問

這些通常都能在監聽器規則或轉發配置裡完成。若你沒有做重定向，訪客可能會混用 HTTP/HTTPS，導致後端程式邏輯複雜化。

多監聽器與路由：從「一套服務」到「多服務」

當你需要一個域名下多個業務（例如 api、admin、web），你可能會用到基於 Host 或 URL 的轉發規則。這時監聽器就是入口，路由規則決定把請求分到哪個後端池。

建議你開始時先只做最基本：一個監聽器、一個後端。打通後再擴展到複雜路由，否則排錯會變得很痛苦。

第五章：配置後端服務（Backend）—把流量送到哪裡

SLB 的後端配置決定了連線最後會落在哪些目標上。後端可以是 ECS、也可以是其他支持的目標類型。你通常需要建立「後端服務」或在監聽器中指定後端集合。

後端類型選擇：ECS 最常見

如果你的後端是阿里雲 ECS，通常你會在後端池中添加 ECS。你要注意：

• 阿里雲國際帳號註冊 選用內網地址（通常）以確保效率與安全
• 後端端口必須與你的應用服務一致
• 如果使用多可用區，後端池最好包含多區的實例

權重與分配策略：用它來做「慢慢上線」

SLB 常見的分配策略包含權重。權重的直觀含義是：在可用的後端中，某些目標獲得更多流量。

實務上你可以用它做漸進式發布：

• 剛上線新版本時，把新後端權重設小（例如 10%）
• 觀察健康狀態與錯誤率
• 逐步提高新版本權重，最後把舊版本權重降到 0 或移除

這樣比直接全量切換更穩定。

會話保持：當你的應用不是無狀態時

阿里雲國際帳號註冊 很多現代架構偏向無狀態（stateless），即便落到不同後端也不影響。但若你的應用依賴本機記憶體存 session，或 session 存在後端本地，就可能需要「會話保持」。

會話保持常見做法是依據 Cookie 或源 IP 維持一致性。你要理解它只是解決問題的折衷，真正的長期解法通常是讓服務無狀態化或把 session 存放到集中式存儲（如 Redis）。不過在短期內，它能讓你先把服務跑起來。

第六章：健康檢查（Health Check）—SLB 的良心與防火牆

健康檢查是 SLB 能否「真正負載均衡」的分水嶺。沒有健康檢查時，SLB 只會照你設定的分配規則把流量丟給後端；但後端可能已經不可用，你的用戶仍會遇到錯誤。

健康檢查方式：HTTP 還是 TCP？

常見健康檢查類型：

• HTTP/HTTPS 探測：例如訪問 `/health`，看狀態碼是否在可接受範圍
• TCP 探測：只要端口能連上就算健康，但無法保證應用正常

如果你的應用有明確的健康狀態（例如依賴資料庫、依賴第三方），用 HTTP 探測更準。你可以讓 `/health` 同時檢查關鍵依賴，避免「端口開了但業務已經失敗」的狀況。

健康檢查參數：超時、間隔、重試次數要合理

健康檢查通常會有以下參數：

• 檢查間隔（interval）
• 超時（timeout）
• 連續失敗次數（unhealthy threshold）
• 連續成功次數（healthy threshold）

初學者常見誤區是把阈值設太小：後端短暫慢一下就被判定不健康，導致流量頻繁抖動。相反，如果你把檢查設太慢，故障發生後用戶仍會先遇到錯誤一段時間。

阿里雲國際帳號註冊 建議你依業務特性設定：例如 10 秒內檢測一次，超時 2 秒，失敗 3 次才標記不健康，成功 2 次才恢復。這只是起步方案，你需要依你的應用延遲與波動調整。

健康檢查路徑設計：不要只回 200

很多人直接讓 `/health` 永遠回 200，結果 SLB 只是看到「服務進程還活著」，卻沒看到依賴是否可用。

比較好的做法是：

• 檢查資料庫連線是否成功
• 檢查關鍵核心服務是否可用
• 如果不可用，回應合適的狀態碼（例如 500）或在回應內容中標記狀態

這樣 SLB 才能真正幫你隔離故障。

第七章：安全與連通性—把「能用」變成「穩定可用」

SLB 能否正常工作，最後仍取決於網路連通。建議用「最小必要放行」思維：先放行能打通的端口，再逐步收斂。

後端安全群組放行：允許 SLB 入口

如果你的後端 ECS 設了安全群組，必須允許 SLB 發出的流量到後端端口。通常可以讓安全群組信任 SLB 的安全群組來源（若控制台提供這種引用方式）。若不方便，就允許對應的內網段或 SLB 網卡所使用的安全域。

不要只看 SLB 端的配置，因為兩邊都要通。你可以用「從後端看」來排查：確定 SLB 的來源 IP/安全群組能打到你的服務端口。

後端應用的綁定與防火牆

另一個常見問題是應用只綁在 127.0.0.1 或特定網卡。當 SLB 把流量打到 ECS 的內網 IP 時，服務可能根本沒在那個介面上監聽，導致一直失敗。

此外，機器上的防火牆（例如 iptables、ufw）也可能阻擋。你可以先用簡單方式驗證：在 ECS 上確認端口監聽正常，並從同網段測試可連。

第八章：超時、連接數與行為細節—容易被忽略，但影響體驗很大

阿里雲國際帳號註冊 當你已經「能通了」，下一步就要讓它「用得舒服」。使用者體驗中，有很多問題並不是流量分配，而是連線行為。

連接超時與空閒超時：避免瀏覽器一直轉圈

監聽器或 SLB 層級往往有連接超時與空閒連接超時設定。若後端處理較慢，而 SLB 超時設得太短，就會造成用戶端看到 504 或連線中斷。

建議你把超時設定與應用的最大處理時間對齊。例如你的接口最慢可能需要 20 秒，那就不要把超時只設 5 秒。當然，超時設太長也會拖慢資源回收，你仍要平衡。

HTTP 頭與真實 IP：讓後端知道誰在請求

當流量透過 SLB 轉發，後端看到的來源 IP 可能變成 SLB 的內網地址。很多框架需要透過 X-Forwarded-For 或相關 header 還原真實 IP。

因此，你需要確認 SLB 是否會在轉發時加入對應 header，以及後端框架是否正確解析。否則日誌、限流、風控都會失真。

壓縮與快取（視需求）：提升吞吐但更要謹慎

有些場景你可以在 SLB 層啟用壓縮或做快取策略。但要注意快取一致性與內容更新頻率。對於動態 API，不建議直接在入口層做強快取。對於靜態資源，才更常見。

第九章：從 0 到 1 的範例配置（以網站為例）

下面用一個典型網站案例串起來，你可以把它當成設定清單：

案例假設

• 你的網站部署在 2 台 ECS：ecs-1 與 ecs-2
• 服務端口：80
• 你要提供 HTTP 與 HTTPS
• 健康檢查路徑：`/health`，期望狀態碼 200

步驟 1：建立 SLB 實例並選 VPC

在控制台建立 SLB：選七層（或對應模式），選 VPC、選子網。確保 ecs-1 與 ecs-2 所在子網與 SLB 所選網段可路由。

步驟 2：添加後端服務（後端池）

新增後端目標：ecs-1 與 ecs-2 的內網 IP，指定後端端口 80。設定權重先相同（例如 100/100），便於驗證穩定性。

步驟 3：建立健康檢查

選 HTTP 健康檢查，探測路徑 `/health`。設定超時與間隔，使其能快速反映狀態變化但不過度抖動。確認後端上確實有 `/health`，且回應 200。

步驟 4：建立監聽器—HTTP 80

建立 HTTP 監聽器：監聽端口 80，轉發到後端端口 80。若你希望全站強制 HTTPS，可在此處新增重定向規則。

步驟 5：建立監聽器—HTTPS 443

上傳或選擇證書，建立 HTTPS 監聽器：443。配置轉發到後端端口 80（或 443，取決於後端服務）。通常網站後端只跑 HTTP，SLB 做 TLS 終止，最常見。

步驟 6：安全群組放行

阿里雲國際帳號註冊 確認 SLB 能訪問到 ecs-1、ecs-2 的 80 端口。後端安全群組放行來源為 SLB 的安全群組或對應網段。完成後重新測試。

第十章：常見問題與排錯路徑（照著做很快找到原因）

再完整的教學也難免碰到例外狀況。你可以把下面的排錯順序當成「地圖」。

問題一：SLB 狀態正常，但訪問網站 502 / 504

優先檢查三件事：

• 監聽器轉發到正確後端端口嗎？例如後端實際是 8080，監聽器卻轉到 80。
• 健康檢查是否通過？後端若被判定不健康，流量會無法正確轉發或轉到空集合。
• 安全群組是否放行？SLB 到 ECS 連通性不通，健康檢查就會失敗。

通常看到 502/504 的原因，健康檢查失敗或轉發端口不對的機率很高。

問題二：健康檢查失敗，狀態一直是 unhealthy

從健康檢查的角度排查：

• 後端路徑 `/health` 是否真的存在？回應狀態碼是不是 200？
• 後端是否只允許特定來源訪問？若 `/health` 有防火牆或鉴權，健康檢查可能被拒。
• SLB 探測的協議（HTTP/HTTPS）要與後端一致。若探測 HTTPS 但後端其實只開 HTTP，必然失敗。
• 超時設定過短：後端冷啟動或依賴服務恢復慢，導致探測超時。

問題三：HTTPS 可以訪問，但後端拿不到正確 Host / 真實 IP

這通常是 header 轉發與框架解析設定問題。你需要：

• 確認 SLB 是否會附加 X-Forwarded-For、X-Forwarded-Proto、Host 等 header
• 在後端框架設定「信任代理」或「從 header 取真實 IP」
• 如果你有反向代理層級，確保只有最後一層或可信層做解析，避免 IP 欺騙風險

問題四：同一使用者行為不穩定（登出、購物車丟失等）

這通常和會話保持或 session 存放方式有關。如果你用無狀態框架但仍看到問題，可能是 Cookie 解析或域名路徑配置不一致。

你可以從以下方向改善：

• 若依賴後端本地 session，啟用會話保持（短期）
• 更長期：把 session 存到集中式（如 Redis），或讓應用完全無狀態
• 確認 Cookie 的 domain/path 設定與 HTTPS/HTTP 行為一致

第十一章：進階建議—把 SLB 當作產品的一部分，而不是一次性工具

當你把 SLB 跑起來後，真正的價值在於持續運維。你可以用幾個原則讓它更穩：

原則一：先做可用，再做最優

一開始只要「能正確轉發、健康檢查通過、後端服務穩定」就是勝利。等你確定通路穩，再調權重、會話保持、超時參數，甚至再加入更細的路由規則。

原則二：把健康檢查做成可觀測的檢查點

不要讓健康檢查只是「進程活著」。讓它能反映依賴狀態，並在出問題時能指向原因。這樣你在事故時不需要猜。

原則三：為擴容與滾動更新預留空間

當你採用權重與多後端池策略，擴容與更新會更可控。把目標提前設計好，後面才不會每次上線都在緊張中臨時調配置。

原則四：建立排錯習慣，而不是只記按鈕位置

每次出問題，你都要記錄當時的：監聽器配置、後端端口、健康檢查結果、安全群組狀態、後端應用日誌。幾次下來你會形成自己的「排錯路徑」。這比單次教學更有價值。

結語：把設定變成流程，把流程變成能力

SLB 的設定不難，難的是把各層之間的關係想明白：監聽器決定入口，後端池決定目標，健康檢查決定流量能否安全送達，安全群組決定通路是否存在，超時與行為細節決定用戶體驗是否穩定。當你理解這些關係，你就不會在每次上線時重新摸索。

你可以從最基本的 HTTP 監聽器開始，先把 80 端跑通，接著補上 `/health` 與 HTTPS 證書。最後再依需求加入權重、會話保持與更精細的路由。用這個節奏，你會更快得到可用的成果，也更容易在遇到問題時迅速定位。