Azure App gateway 設定自訂網域指向應用程式閘道

這是一個常見的誤解。事實上，一個公用 IP 位址可以同時對應到多個不同的 Web App（網站）。

在現代的網路架構中，主要透過以下兩種技術來達成：

1. 使用主機名稱識別（Host Header）

這是最常見的做法。當多個網站共享同一個 IP 時，伺服器會根據瀏覽器傳送的 HTTP Request 中的 Host 欄位來判斷要由哪一個 App 處理。

• 用戶輸入 A.com，請求送到 IP 1.2.3.4。
• 伺服器看見要求的主機名稱是 A.com，於是把流量導向 Web App A。
• 另一個用戶輸入 B.com，同樣送到 IP 1.2.3.4。
• 伺服器看見要求的主機名稱是 B.com，則導向 Web App B。

這也是為什麼在 Azure App Service 或應用程式閘道上，你需要註冊自訂網域的原因，這樣伺服器才知道這個網域是歸屬於哪一個服務。

2. 使用反向代理（Reverse Proxy）

像你提到的 Azure 應用程式閘道（Application Gateway）就是一個強大的反向代理伺服器。

一個應用程式閘道通常只有一個公用 IP，但它可以根據不同的規則來分流：

• 根據網域分流：例如 shop.example.com 導向後端的「購物車服務」，而 blog.example.com 導向「部落格服務」。
• 根據路徑分流：同一個網域下，[example.com/api](https://example.com/api) 導向「後端 API 服務」，而 [example.com/static](https://example.com/static) 導向「靜態網頁服務」。

總結

一個 IP 確實可以對應多個 Web App。這不僅節省了公用 IP 的資源（IP 資源很貴且有限），也讓系統架構更具靈活性。

你目前正在設定的應用程式閘道，正是利用這種機制來管理多個後端服務，只要確保 DNS 正確指向該 IP，並在 Azure 上完成對應的網域註冊即可。

---

有多個網域分流, app gateway how to setup

在 Azure 應用程式閘道（Application Gateway）中處理多個網域分流，核心機制是使用 多站台（Multi-site）接聽程式。

這就像是在同一個門牌號碼（IP）下，根據信封上的收件人姓名（網域）把信件分派給不同的辦公室。

以下是具體的設定步驟：

1. 建立後端集區（Backend Pools）

首先，你要為不同的 App 建立各自的集區。

• 建立後端集區 A：加入第一個 Web App 的位址。
• 建立後端集區 B：加入第二個 Web App 的位址。

2. 設定接聽程式（Listeners）

這是最關鍵的一步。你需要為每個網域建立一個獨立的接聽程式。

• 接聽程式 A：
  • 關聯的前端 IP：選擇你的公用 IP。
  • 接聽程式類型：選擇多站台（Multi-site）。
  • 主機名稱：輸入第一個網域（例如 app1.example.com）。
• 接聽程式 B：
  • 接聽程式類型：選擇多站台（Multi-site）。
  • 主機名稱：輸入第二個網域（例如 app2.example.com）。

3. 設定後端設定（Backend Settings）

針對多租用戶服務（如 App Service），這裡有兩個重點：

• 主機名稱覆寫：根據 Azure 的建議，如果你已經在後端 App 註冊了自訂網域，請選擇從後端目標選取主機名稱，或者手動輸入對應的網域。
• 通訊協定：通常設定為 HTTPS (Port 443)。

4. 建立路由規則（Routing Rules）

最後，把「接聽程式」與「後端集區」串聯起來。

• 規則 A：當接聽程式 A 收到請求時，將流量導向後端集區 A。
• 規則 B：當接聽程式 B 收到請求時，將流量導向後端集區 B。

---

常見問題排查

如果設定後無法連線，請檢查以下幾點：

• DNS 設定：確認 app1.example.com 與 app2.example.com 的 CNAME 或 A 紀錄都指向應用程式閘道的 IP。
• 後端註冊：在 Azure App Service 的自訂網域設定中，必須已經新增了該網域，否則 App Service 會因為無法識別 Host Header 而回傳 404 錯誤。
• 憑證問題：如果你使用 HTTPS，接聽程式必須上傳對應網域的 SSL 憑證。如果是多網域，可以使用萬用字元憑證（Wildcard Certificate）或針對每個接聽程式上傳專屬憑證。

---

同一個 port 只能有一個Listeners?

在 Azure 應用程式閘道中，同一個 Port（埠號）是可以有多個接聽程式（Listeners）的，但前提是這些接聽程式必須是 多站台（Multi-site） 類型。

如果你的設計是想在同一個 IP 的 Port 80 或 443 下跑多個網站，這是完全沒問題的。

以下是運作的核心規則：

1. 基本規則：唯一性

應用程式閘道判斷要把流量交給哪個接聽程式，是根據 IP + Port + 主機名稱（Host Name） 的組合來決定的。

• 基本型（Basic）接聽程式：會「佔據」該 Port 的所有流量。如果你在 Port 443 設了一個基本型接聽程式，你就不能再針對同一個 Port 建立其他的接聽程式。
• 多站台（Multi-site）接聽程式：允許多個接聽程式共享同一個 Port。

2. 如何在同一個 Port 設定多個接聽程式

當你需要多個網域（例如 a.com 和 b.com）都使用 Port 443 時，你的設定會長這樣：

接聽程式名稱	類型	埠號	主機名稱
Listener-A	多站台	443	a.com
Listener-B	多站台	443	b.com
Listener-C	多站台	443	*.c.com (萬用字元)

3. 系統如何判斷流量去哪？

當一個請求進來時，應用程式閘道會檢查 HTTP 標頭中的 Host 欄位：

1. 如果連線請求的網域是 a.com，它會精準比對到 Listener-A。
2. 如果連線請求的網域是 b.com，它會精準比對到 Listener-B。
3. 如果 Host 欄位跟所有接聽程式都對不起來，該連線就會失敗（回傳錯誤），除非你有設定一個「預設」的路由規則。

4. 注意事項

• SSL 憑證：如果你在同一個 Port 跑多個 HTTPS 站台，應用程式閘道會使用 SNI（伺服器名稱指示） 技術。這意味著每個接聽程式都可以綁定各自對應網域的 SSL 憑證。
• 避免衝突：你不能在同一個 Port 同時存在一個「基本型」接聽程式與多個「多站台」接聽程式，系統會判定這會產生衝突。

簡單來說： 只要你把接聽程式類型選為 多站台（Multi-site） 並填入正確的 主機名稱，你就可以在同一個 Port 上掛載非常多個不同的網站。

---

Error log

無法將設定變更儲存至應用程式閘道 'agw-stg-jpe-001'。錯誤: Application Gateway listener-policyhub-stg 和 appGatewayHttpsListener 的兩個 Http Listener 使用了相同的 Frontend Port

這個錯誤訊息非常明確，問題在於你的應用程式閘道中發生了 設定衝突。

簡單來說，系統發現你有兩個接聽程式（Listeners）在搶奪相同的「通訊窗口」。

衝突原因分析

根據錯誤訊息，以下三個關鍵要素在兩個接聽程式之間完全重複了：

1. Frontend Port：都是 port_443。
2. Frontend IP：都是 appGatewayFrontendIP。
3. HostName：都是 policyhub.test.com.tw。

在 Azure 應用程式閘道中，這三個元素的組合必須是 唯一 的。如果 HostName 完全一樣，閘道器就無法判斷當流量進來時，到底該交給 listener-hub-stg 還是 appGatewayHttpsListener 來處理。

---

解決方案

請依照你的實際需求，選擇以下其中一種調整方式：

方案一：刪除多餘或舊的接聽程式

如果你發現 appGatewayHttpsListener 是之前測試留下的舊設定，或者它原本就應該被新的 listener-hub-stg 取代，請直接刪除其中一個。

方案二：合併路由規則（最推薦）

如果你希望這個網域 hub.test.com.tw 對應到某個後端，你只需要 一個 接聽程式。

1. 保留其中一個接聽程式（例如 listener-hub-stg）。
2. 確保該接聽程式關聯到正確的 要求路由規則（Request Routing Rule）。
3. 在路由規則中定義流量該去哪個 後端集區（Backend Pool）。

方案三：區分主機名稱（Host Name）

如果你原本的意圖是要讓兩個不同的網域共用 443 Port，請檢查這兩個接聽程式的 HostName 設定：

• 將 listener-hub-stg 設定為 hub.test.com.tw。
• 將另一個接聽程式設定為另一個網域，例如 other.test.com.tw。
• 注意：不可以兩個都留空白（基本型），也不可以兩個都填入相同的網域。

---

操作建議步驟

1. 進入 Azure 入口網站，開啟 agw-stg-jpe-001。
2. 點選左側選單的 接聽程式 (Listeners)。
3. 找到 appGatewayHttpsListener 和 listener-policyhub-stg。
4. 檢查這兩個接聽程式是否都設定了相同的網域。如果是，請決定要保留哪一個，並將另一個 刪除 或 更改主機名稱。
5. 儲存變更後，再次嘗試部署。

通常這種情況發生在「手動新增新的接聽程式」時，忘記舊有的接聽程式已經佔用了該網域的 443 Port。

---

Error:

502 Bad Gateway
Microsoft-Azure-Application-Gateway/v2

遇到這個錯誤代表你的 Application Gateway 已經收到請求，但它在嘗試與後端伺服器（如 App Service 或 VM）溝通時失敗了。

既然你正在進行多租用戶服務（App Service）的設定，這通常與「主機名稱不一致」或「健康狀態探查（Health Probe）失敗」有關。請依照以下步驟排查：

1. 檢查後端健康狀態 (最直接的方法)

在 Azure 入口網站中，進入您的 Application Gateway：

• 點選左側選單的 後端狀況 (Backend Health)。
• 查看您的後端集區狀態。如果是 Unhealthy，右側通常會顯示具體的錯誤訊息。

2. 常見原因：主機名稱（Host Name）不匹配

多租用戶服務（如 App Service）非常依賴 HTTP 要求中的 Host 標頭。

• 問題點：如果你的 Gateway 傳送要求到後端時，使用的是 hub.test.com.tw，但後端的 App Service 沒有註冊這個網域，App Service 會拒絕連線，導致 502。
• 解決方案：
  1. 確認 App Service 的 自訂網域 (Custom domains) 中已經新增了 hub.test.com.tw。
  2. 在 Application Gateway 的 後端設定 (Backend Settings) 中，確認是否開啟了 覆寫後端主機名稱。
  3. 根據先前的建議，應選擇 從後端目標選取主機名稱 或手動輸入該 App 的預設網域（如 xxxx.azurewebsites.net）。

3. 健康狀態探查 (Health Probe) 失敗

如果後端設定要求使用 HTTPS，但探查的目標不正確，閘道器會認為後端已掛掉，進而回傳 502。

• 檢查點：進入 健康狀態探查 (Health Probes) 設定。
• 建議：針對 App Service，勾選 從後端設定中選取主機名稱。這能確保探查時傳送的主機名稱與後端設定一致。

4. SSL 憑證與 HTTPS 握手失敗

如果你在 Application Gateway 與後端 App Service 之間使用 HTTPS 連線：

• 確認後端 App Service 能夠處理 HTTPS。
• 如果使用自簽憑證，必須在 Application Gateway 中上傳該信任的根憑證（.cer 檔）。

5. 後端伺服器逾時

如果你的 Web App 處理請求的時間太長（例如正在進行大型資料庫搬遷或運算），Application Gateway 會因為超過預設的 要求逾時 (Request timeout) 時間而主動中斷連線。

• 檢查點：進入 後端設定，嘗試增加 要求逾時 的秒數（預設通常是 20 秒，可以試著改為 60 秒或更高）。

---

快速排查建議

如果你剛處理完前面的 Listeners 衝突問題，請先確認：

1. 路由規則 是否正確連結到正確的 後端集區。
2. 後端集區 內的位址（FQDN）是否正確無誤。

只要 後端狀況 (Backend Health) 顯示為 Healthy，502 錯誤通常就會消失。