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