AWS SNI 是什麼？在 ALB 上安裝多張 SSL 憑證的完整教學

在上一篇文章中，我們學會了用 ACM 幫網站申請 SSL 憑證，讓網站支援 HTTPS。

但如果你有兩個以上的網站，都想用同一台 Load Balancer 來服務呢？

舉個例子：你手上有 myshop.com 和 travelblog.com 兩個網站，它們各自需要自己的 SSL 憑證。

最直覺的做法是：每個網站各開一台 Load Balancer。

但這樣做不只浪費錢，管理起來也很麻煩。

好消息是，AWS 的 Application Load Balancer（ALB）支援一個叫做 SNI（Server Name Indication） 的技術，讓你只用一台 ALB，就能同時服務多個網站，而且每個網站都有自己的 SSL 憑證。

這篇文章會帶你搞懂：

• 一台 ALB 多個網站，為什麼需要 SNI？
• 沒有 SNI vs 有 SNI，憑證選擇差在哪？
• 怎麼在 ALB 上設定 SNI，讓多個網站共用同一台 Load Balancer？

如果你已經有一台 ALB 在運作，想再加掛第二個網站，這篇就是你需要的。

一台 ALB 多個網站：為什麼需要 SNI？

SNI（Server Name Indication，伺服器名稱指示） 是 TLS 協定的一個擴充功能。

要理解 SNI，我們先回想一下上一篇提到的 TLS 握手流程。

當你在瀏覽器輸入一個 HTTPS 網址，瀏覽器會跟伺服器進行一次「握手」，過程中伺服器會把自己的 SSL 憑證交給瀏覽器驗證。

這在「一台伺服器只服務一個網站」的時候完全沒問題——伺服器上就只有一張憑證，拿出來就對了。

但現實中，很多時候你會把好幾個網站放在同一台伺服器上（或同一台 Load Balancer 後面）。

這時問題就來了：伺服器上有好幾張憑證，分別對應不同的網域，但在握手的最一開始，伺服器根本不知道訪客要連的是哪個網站。

為什麼不知道？因為在原本的 TLS 握手流程中，瀏覽器只會跟伺服器說「我要建立加密連線」，但不會說「我要連的是哪個網域」。

伺服器收到請求後，只能硬拿一張預設的憑證出來用。

如果剛好拿對了，沒事；如果拿錯了（比如訪客要連 travelblog.com，結果伺服器拿出 myshop.com 的憑證），瀏覽器就會發現憑證上的網域對不上，直接跳出安全警告。

SNI 就是為了解決這個問題而生的。

它的做法很簡單：在 TLS 握手的第一步（Client Hello），讓瀏覽器多帶一個資訊——「我要連的網域名稱是什麼」。

伺服器收到之後，就能根據這個名稱，從多張憑證中挑出正確的那張來完成握手。

整個過程對使用者來說是完全無感的，瀏覽器會自動處理，不需要任何額外設定。

沒有 SNI vs 有 SNI：憑證選擇差在哪？

假設你有一台 ALB，同時服務 myshop.com 和 travelblog.com 兩個網站。

沒有 SNI 的情況：

1. 訪客在瀏覽器輸入 travelblog.com
2. 瀏覽器向 ALB 發出連線請求
3. ALB 收到請求，但不知道訪客要連哪個網站
4. ALB 只能拿出預設的那張憑證（可能是 myshop.com 的）
5. 瀏覽器發現憑證上的網域跟自己要連的不一樣 → 跳出安全警告

有 SNI 的情況：

1. 訪客在瀏覽器輸入 travelblog.com
2. 瀏覽器向 ALB 發出連線請求，同時告訴 ALB：「我要連的是 travelblog.com」
3. ALB 根據這個資訊，從多張憑證中找到 travelblog.com 對應的那張
4. ALB 用正確的憑證建立加密連線
5. 瀏覽器驗證通過，顯示鎖頭，一切正常

差別就在第 2 步：瀏覽器有沒有「先報上名來」。

沒有 SNI 的時代：一個網站就要一台 Load Balancer

在 SNI 還沒被廣泛支援之前，解法很粗暴：一台伺服器（或一台 Load Balancer）只能綁一張 SSL 憑證。

也就是說，你有三個網站要跑 HTTPS，就得開三台 Load Balancer，各自掛各自的憑證。

每多一台 Load Balancer，就多一筆月費、多一組設定要維護、多一個可能出錯的地方。

對個人開發者或小團隊來說，這完全不划算。

現在 SNI 已經被所有主流瀏覽器支援（Chrome、Safari、Firefox、Edge 都支援），所以你可以放心地在一台 ALB 上掛多張憑證，不用擔心相容性問題。

在 ALB 上設定 SNI 多憑證

接下來我們實際操作，把第二個網站加到現有的 ALB 上。

開始前的準備

在開始之前，請確認你已經完成以下幾件事：

• 你已經有一台 ALB 正在運作，並且服務著你的第一個網站（例如 myshop.com）
• 第一個網站已經透過 ACM 申請了 SSL 憑證，HTTPS 正常運作
• 你已經購買或擁有第二個網域（例如 travelblog.com）

如果以上還沒搞定，建議先參考上一篇文章完成基本設定。

申請 ACM 憑證與建立 Target Group

步驟 1：為第二個網域申請 ACM 憑證

首先，你需要幫第二個網域申請一張新的 SSL 憑證。

1. 登入 AWS Certificate Manager 控制台
2. 點選「Request a certificate」
3. 選擇「Public certificate」
4. 在網域名稱欄位輸入你的第二個網域，例如 travelblog.com
5. 選擇「DNS validation」
6. 送出申請

接著到你的 DNS 控制台（GoDaddy、Cloudflare 等），把 ACM 提供的 CNAME 驗證記錄加進去。

等幾分鐘後，回到 ACM 頁面確認憑證狀態變成「Issued」就完成了。

這一步跟上一篇的流程完全一樣，只是這次是幫第二個網域申請。

步驟 2：建立第二個網站的 Target Group

ALB 需要知道第二個網站的流量要導到哪裡，所以你要建立一個新的 Target Group。

1. 進入 EC2 控制台
2. 左側選單 → 點選「Target Groups」
3. 點選「Create target group」
4. 設定名稱，例如 travelblog-tg
5. 選擇目標類型（通常是 Instance）
6. 設定 Health Check 路徑（例如 /）
7. 建立後，把你第二個網站的 EC2 instance 加進這個 Target Group

步驟 3：把第二個網域的 DNS 指向 ALB

現在要讓訪客輸入 travelblog.com 的時候，能連到你的 ALB。

到你的 DNS 控制台，新增一筆 CNAME 記錄：

注意：這裡指向的是跟第一個網站同一台 ALB，不是新的。

上面的 CNAME 設定適用於 www.travelblog.com 這種子網域。

但如果你想讓使用者直接輸入 travelblog.com（不帶 www）就能連上，就不能用 CNAME——因為 DNS 規範不允許根網域設定 CNAME 記錄。

這時候你需要用替代方案：如果你的 DNS 是用 Route 53，可以用 Alias Record；如果是用 Cloudflare，可以用 CNAME Flattening。

這部分在上一篇文章有完整說明，這裡就不重複了。

在 ALB 加上 SNI 憑證與 Listener Rule 分流

步驟 4：在 ALB Listener 加上第二張 SSL 憑證

到目前為止，你的 ALB 上只掛了一張憑證（myshop.com 的）。

現在我們要把第二張憑證（travelblog.com 的）也加上去，這樣 ALB 才能用 SNI 根據訪客要連的網域，自動選對應的憑證。

做法是到 ALB 的 HTTPS Listener 設定頁面，把新憑證「附加」上去：

1. 進入 EC2 控制台 → 左側選單 → 「Load Balancers」
2. 點進你的 ALB
3. 找到 HTTPS:443 這個 Listener，選取它
4. 點選「Actions」→「Add SSL certificates for SNI」
5. 畫面會列出你在 ACM 中所有的憑證
6. 找到 travelblog.com 的憑證，勾選它
7. 點選「Include as pending below」
8. 點選「Add pending certificates」

完成後，你的 ALB 上就同時掛了兩張憑證。

當訪客連上來的時候，ALB 會根據 SNI 帶來的網域名稱，自動選擇正確的那張。

步驟 5：新增 Listener Rule 根據網域名稱分流

憑證掛好了，但 ALB 還不知道「收到 travelblog.com 的請求時，要把流量導去哪裡」。

所以你需要新增一條 Listener Rule：

1. 回到你的 ALB → 選取 HTTPS:443 Listener
2. 點選「Actions」→「Manage rules」
3. 點選「Add rule」（新增規則）
4. 條件設定為：Host header 等於 travelblog.com
5. 動作設定為：Forward to → 選擇你在步驟 2 建立的 Target Group（travelblog-tg）
6. 點選「Save」

這條規則的意思是：只要訪客的請求是來自 travelblog.com 這個網域，ALB 就會把流量轉發到 travelblog-tg 這個 Target Group。

其他不符合這條規則的請求（例如 myshop.com），會走原本的預設規則，導到第一個網站的 Target Group。

測試 SNI 是否設定成功

打開瀏覽器（建議用無痕模式，避免快取干擾），分別測試：

1. 輸入 https://travelblog.com → 應該看到第二個網站的內容，且網址列顯示鎖頭
2. 輸入 https://myshop.com → 應該看到第一個網站的內容，一樣有鎖頭

如果兩個網站都能正常顯示 HTTPS，恭喜你，SNI 設定成功了。

常見問題排查

總結

SNI 讓你不用為每個網站各開一台 Load Balancer，只需要一台 ALB 就能同時服務多個網站，每個網站都有自己的 SSL 憑證。

整個設定流程回顧一下：

1. 幫新網域申請 ACM 憑證
2. 建立新的 Target Group
3. 把新網域的 DNS 指向同一台 ALB
4. 在 ALB 的 HTTPS Listener 加上新憑證
5. 新增 Listener Rule，根據網域名稱分流到對應的 Target Group

只要這五步都完成，你的 ALB 就能用 SNI 自動辨識訪客要連哪個網站，並拿出正確的憑證建立加密連線。

如果你還沒看過第一篇，建議先回去了解 ACM 憑證申請與 DNS 設定的基礎，會讓這篇的操作更順暢。