您可以使用應用程式閘道將流量重新導向。 它有一般重新導向機制，可讓您將一個接聽程式收到的流量重新導向至另一個接聽程式或外部網站。 這可簡化應用程式組態、將資源使用量最佳化，並支援新的重新導向案例，包括全域和路徑式重新導向。
許多 Web 應用程式的常見重新導向案例是支援自動 HTTP 到 HTTPS 重新導向，以確保應用程式與其使用者之間的所有通訊都會透過加密路徑發生。 在過去，客戶會使用一些技巧 (例如建立專屬後端集區)，其唯一目的是要將其在 HTTP 上接收的要求重新導向至 HTTPS。 藉由應用程式閘道中的重新導向支援很容易就能達成，只要將新的重新導向設定新增至路由規則，並將另一個採用 HTTPS 通訊協定的接聽程式指定為目標接聽程式即可。 如需 HTTP 到 HTTPS 重新導向的詳細資訊，請參閱 使用 Azure 入口網站建立具有 HTTP 到 HTTPS 重新導向的應用程式閘道。
重新導向類型
重新導向類型會設定回應狀態碼，讓用戶端了解重新導向的目的。 支援下列重新導向類型：
- 301 (永久移動)：表示已指派新的永久 URI 給目標資源。 未來參考此資源時都將使用其中一個含括的 URI。 針對 HTTP 至 HTTPS 重新導向使用 301 狀態碼。
- 302 (已找到)：表示目標資源暫時位於不同的 URI。 由於重新導向有時會變更，對於未來的要求，用戶端應該繼續使用有效要求 URI。
- 303 （請參閱其他）：指出目標資源正在將使用者代理程式重新導向至不同的資源，如 [位置] 標頭欄位中的 URI 所指出。
- 307 (暫時重新導向)：表示目標資源暫時位於不同的 URI。 如果使用者代理程式會自動重新導向該 URI，則「不可」變更要求方法。 由於重新導向可能隨著時間而改變，對於未來的要求，用戶端應該繼續使用原始的有效要求 URI。
重新導向功能
接聽程式重新導向
從一個接聽程式到另一個接聽程式的重新導向。 接聽程式重新導向通常用來啟用 HTTP 至 HTTPS 重新導向。
當使用多網站目標接聽程式來設定重新導向時，需要確保所有定義為來源接聽程式一部分的主機名（包含或不含通配符）也必須是目的地接聽程式的一部分。 這可確保在設定 HTTP 至 HTTPS 重新導向時，目的地接聽程式上缺少主機名稱，因此不會捨棄流量。
路徑式重新導向
這種類型的重新導向只在特定的網站區域啟用，例如，將 HTTP 請求重新導向至標示為購物車區域
/cart/*的 HTTPS 請求。重新導向至外部網站
有了這項變更，客戶必須建立新的重新導向組態物件，以指定重新導向所需的目標接聽程式或外部網站。 此組態元素也支援能將 URI 路徑和查詢字串附加至重新導向 URL 的選項。 您也可以選擇重新導向的類型。 一旦建立，此重新導向組態會透過新規則附加至來源接聽程式。 若使用時基本規則，重新導向組態會與來源接聽程式相關聯並為全域重新導向。 使用路徑式規則時，就會在 URL 路徑對應上定義重新導向組態。 因此它只適用於網站的特定路徑區域。