流量管理員常見問題集 (FAQ)

流量管理員基本概念

「流量管理員」使用什麼 IP 位址？

如流量管理員的運作方式所述，流量管理員在 DNS 層級運作。 它會傳送 DNS 回應，將用戶端導向適當的服務端點。 用戶端會接著直接連線到服務端點，而不會透過「流量管理員」。

因此，流量管理員不提供端點或 IP 位址讓用戶端連線。 如果您想要為您的服務使用靜態 IP 位址，就必須在服務上設定，而不是在「流量管理員」中設定。

哪種類型的流量可以使用流量管理員路由傳送？

如流量管理員的運作方式中所述，流量管理員端點可以是 Azure 內部或外部裝載的任何網際網路對向服務。 因此，流量管理員可以將源自公用網際網路的流量路由傳送至一組也是網際網路面向的端點。 若您的端點位於私人網路內 (如 Azure Load Balancer 內部版本)，或是讓使用者從這類內部網路提出 DNS 要求，便無法使用流量管理員來路由傳送此流量。

流量管理員是否支援「黏性」工作階段？

如流量管理員的運作方式所述，流量管理員是在 DNS 層級運作。 它會使用 DNS 回應將用戶端導向到適當的服務端點。 用戶端會直接連接至服務端點，而不會透過流量管理員。 因此，流量管理員看不到用戶端與伺服器之間的 HTTP 流量。

此外，流量管理員收到之 DNS 查詢的來源 IP 位址屬於遞迴 DNS 服務，而不是用戶端。 因此，流量管理員無法追蹤個別用戶端，也無法實作「黏性」工作階段。 不是只有流量管理員才受此限制，以 DNS 為基礎的所有流量管理系統也會受到同樣限制。

我在使用流量管理員時為何看到 HTTP 錯誤？

如流量管理員的運作方式所述，流量管理員是在 DNS 層級運作。 它會使用 DNS 回應將用戶端導向到適當的服務端點。 用戶端會接著直接連線到服務端點，而不會透過「流量管理員」。 流量管理員看不到用戶端與伺服器之間的 HTTP 流量。 因此，您看到的任何 HTTP 錯誤必定來自您的應用程式。 為了讓用戶端連接至應用程式，所有 DNS 解析步驟都已完成。 這包括流量管理員在應用程式流量流程上的任何互動。

因此，進一步的調查應該將焦點放在應用程式上。

從用戶端的瀏覽器傳送的 HTTP 主機標頭是最常見的問題來源。 請確定應用程式已設定為接受使用網域名稱的正確主機標頭。 關於使用 Azure App Service 的端點，請參閱在使用流量管理員的 Azure App Service 中設定 Web 應用程式的自訂網域名稱。

如何使用流量管理員來解決 500 (內部伺服器錯誤) 問題？

如果您的用戶端或應用程式在使用流量管理員時收到 HTTP 500 錯誤，可能是因過時的 DNS 查詢而造成。 若要解決此問題，請清除 DNS 快取並允許用戶端發出新的 DNS 查詢。

當服務端點沒有回應時，直到重新整理 DNS 快取之前，都不會重設使用該端點的用戶端和應用程式。 快取持續時間是依據 DNS 記錄的「存留時間」(TTL) 而定。 如需詳細資訊，請參閱流量管理員與 DNS 快取。

另請參閱本文中的下列相關常見問題：

• 什麼是 DNS TTL，以及其如何影響我的使用者？
• 我可以將流量管理員回應的 TTL 設為多高或多低？
• 如何了解傳送至我的設定檔的查詢量？

使用「流量管理員」對效能有什麼影響？

如流量管理員的運作方式所述，流量管理員是在 DNS 層級運作。 由於用戶端直接連線至服務端點，因此在連線建立後，使用流量管理員時並不會影響效能。

因為流量管理員會在 DNS 層級與應用程式整合，所以它確實需要在 DNS 解析鏈結中插入額外的 DNS 查閱。 「流量管理員」對 DNS 解析時間的影響極小。 流量管理員使用全球網路上的名稱伺服器，並使用任一傳播網路功能，以確保一律將 DNS 查詢路由傳送至最靠近的可用名稱伺服器。 此外，快取 DNS 回應意謂著因使用「流量管理員」而造成的額外 DNS 延遲僅適用於一小部分工作階段。

「效能」方法會將流量路由傳送至最靠近的可用端點。 最後結果就是這個方法引起的整體效能影響會降到最低。 增加的任何 DNS 延遲都被端點更短的網路延遲所抵銷。

我可以搭配「流量管理員」使用哪些應用程式通訊協定？

如流量管理員的運作方式所述，流量管理員是在 DNS 層級運作。 完成 DNS 查閱之後，用戶端就會直接連線到應用程式端點，而不會透過「流量管理員」。 因此，連線可以使用任何應用程式通訊協定。 如果您選取 TCP 作為監視通訊協定，流量管理員的端點健康情況監視可以在不使用任何應用程式通訊協定的情況下完成。 如果您選擇使用應用程式通訊協定來驗證健康情況，端點必須能夠回應 HTTP 或 HTTPS GET 要求。

我是否可在流量管理員中使用「裸」網域名稱？

是。 若要了解如何建立網域名稱頂點的別名記錄，以參考 Azure 流量管理員設定檔，請參閱使用流量管理員設定別名記錄以支援頂點網域名稱。

處理 DNS 查詢時，流量管理員會考量用戶端子網路位址嗎？

是。 除了所收到 DNS 查詢的來源 IP 位址 (通常是 DNS 解析程式的 IP 位址) 之外，若代表使用者發出要求的 DNS 解析程式在 DNS 查詢中包含用戶端子網路位址，則流量管理員也會考量該位址。 這些IP位址可用來最佳化地理、效能和子網路路由方法。 具體而言，RFC 7871 – DNS 查詢中的用戶端子網路提供 DNS 的延伸機制 (EDNS0)，並可將用戶端子網路位址從支援它的解析程式中傳遞出去。

什麼是 DNS TTL，以及它如何影響我的使用者？

DNS 查詢進入流量管理員時，它會在稱為存留時間 (TTL) 的回應中設定值。 此值 (單位為秒) 會向 DNS 解析程式下游表示快取此回應要多久時間。 DNS 解析程式雖不保證會快取此結果，但解析程式可透過快取來回應快取的任何後續查詢，而無須傳送至流量管理員 DNS 伺服器。 這會影響回應，如下所示：

• 較高的 TTL 會減少進入流量管理員 DNS 伺服器的查詢數目，因為提供服務的查詢數目是可計費的使用量，所以可減少客戶的成本。
• 較高的 TTL 可能會減少執行 DNS 查閱所花費的時間。
• TTL 較高時，也表示您的資料不會反映出流量管理員透過探查代理程式所取得的最新健康情況資訊。

我可以將流量管理員回應的 TTL 設為多高或多低？

您可以在每個設定檔層級將 DNS TTL 設定為最低 0 秒、最高 2,147,483,647 秒 (符合 RFC-1035 的最大範圍)。 當 TTL 為 0 時，表示下游 DNS 解析程式不會快取查詢回應，並預期所有查詢皆會送至流量管理員 DNS 伺服器進行解析。

如何了解傳給我的設定檔的查詢量？

流量管理員提供的其中一個計量是由設定檔所回應的查詢數量。 您可以在設定檔層級的彙總取得此資訊，或者也可以進一步分割此資料，以查看所傳回特定端點的查詢量。 此外，您可以設定警示，以在查詢回應量跨越設定的條件時通知您。 如需詳細資訊，請參閱流量管理員的計量與警示。

刪除流量管理員設定檔時，要過多久才能重複使用設定檔名稱？

當您刪除流量管理員設定檔時，相關聯的網域名稱會保留一段時間。 相同租用戶中的其他流量管理員設定檔可以立即重複使用名稱。 不過，在保留到期之前，不同的 Azure 租使用者無法使用相同的配置檔名稱。 這項功能可讓您維護您部署之命名空間的授權，並排除另一個租用戶可能採用該名稱的疑慮。

例如，如果您的流量管理員設定檔名稱為 label1，那麼即使您刪除設定檔，label1.trafficmanager.net 仍然會保留給租用戶。 子命名空間例如 xyz.label1 或 123.abc.label1 也會被保留。 保留到期時，該名稱會提供給其他租用戶使用。 與停用設定檔相關聯的名稱會無限期保留。 關於名稱保留時間長度的問題，請連絡您的帳戶代表。

流量管理員地理流量路由方法

地理路由派上用場的使用案例有哪些？

每當 Azure 客戶需要依據地理區域來區別他們的使用者位置時，就可以使用地理路由類型。 例如，使用地理流量路由方法，您可以為特定區域的使用者提供不同於其他區域的使用者體驗。 另一個例子是符合本機資料主權規定，要求特定區域的使用者只能由該區域中的端點提供服務。

如何決定應該要使用效能路由方法或使用地理路由方法？

這兩個常用路由方法的主要差異，在於效能路由的主要目標是將流量傳送至能提供呼叫者最低延遲的端點，而地理路由的主要目標則是對您的呼叫者強制使用地理柵欄，這樣就能特意將他們路由到特定端點。 若發生重疊，則因為地理位置相近度與低延遲相互關聯 (但不一定如此)。 可能有其他地理位置的端點可提供呼叫者更佳的延遲體驗。在此情況下，「效能」路由會傳送使用者至該端點，但「地理位置」路由則會一律傳送至該地理位置所對應的端點。 為了進一步釐清，請考慮以下範例：您可以使用地理路由製造不尋常的對應，例如將來自亞洲的所有流量都傳送到在美國的端點，或將所有來自美國的流量傳送到在亞洲的端點。 在此情況下，地理路由完全依設定執行，而不會考量效能最佳化。

注意

在某些情況下，您可能需要效能路由和地理路由功能兩者，對於這些情況，巢狀設定檔可能是最佳選擇。 例如，您可以設定使用地理路由的父設定檔，將所有來自北美洲的流量，傳送到所含端點在美國的巢狀設定檔，並使用效能路由將那些流量傳送到該集合中的最佳端點。

流量管理員的地理路由支援哪些區域？

這裡可以找到流量管理員所使用的國家/區域階層。 雖然此頁面一有變動就會隨時更新，但您也可透過程式設計方式，利用 Azure 流量管理員 REST API 擷取相同的資訊。

流量管理員如何判斷使用者從何處執行查詢？

流量管理員會查看查詢的來源 IP (這很可能是代表使用者執行查詢的本機 DNS 解析程式)，並使用內部 IP 至區域的對應來判斷位置。 此對應會融合網際網路上的變動而不斷更新。

它保證流量管理員可以在每個案例中正確判斷使用者確切的地理位置嗎？

否，基於下列因素，流量管理員無法保證從 DNS 查詢來源 IP 位址所推斷的地理區域一律對應至使用者位置:

• 首先，如先前的常見問題集所述，我們看到的來源 IP 為代表使用者進行查閱的 DNS 解析程式 IP。 儘管 DNS 解析程式的地理位置是使用者地理位置的良好 Proxy，但是，根據 DNS 解析程式服務的使用量和客戶選擇使用的特定 DNS 解析程式服務而定，它也可以不一樣。 例如，位於馬來西亞的客戶可在他們裝置的設定中指定使用 DNS 解析程式服務，此服務可能會挑選其位於新加坡的 DNS 伺服器來處理該使用者/裝置的查詢解析。 在此情況下，流量管理員只會看到該新加坡位置所對應的解析程式 IP。 此外，請參閱此頁面上先前有關用戶端子網路位址支援的常見問題集。

• 其次，流量管理員會使用內部對應來進行 IP 位址到地理區域的轉譯。 為改善精確度、符合網際網路的進化本質，此對應已經過驗證並持續更新，但我們的資訊仍有可能無法確切代表所有 IP 位址的地理位置。

端點必須實際位於地理路由設定的相同區域嗎？

否，端點的位置不限制哪些區域可以對應它。 例如，美國中部 Azure 區域的端點可以接納所有來自印度的使用者。

在未設定執行地理路由的設定檔中，是否可將地理區域指派給端點？

是，若設定檔的路由傳送方法並非地理性，則可使用 Azure 流量管理員 REST API，將地理區域指派給該設定檔中的端點。 針對非地理路由類型的設定檔，此設定將被忽略。 如果您稍後將此設定檔變更為地理路由類型，流量管理員可以使用這些對應。

當我嘗試將現有設定檔的路由方法變更為地理時為何會發生錯誤？

設為地理路由的設定檔下的所有端點，必須至少有一個區域對應到它。 若要將現有的設定檔轉換成地理路由類型，您需要先使用 Azure 流量管理員 REST API，將地理區域和其所有端點相關聯，才能將路由類型變更為地理。 如果使用入口網站，先刪除端點，將設定檔的路由方法變更為地理，然後新增端點及其地理區域對應。

為什麼強烈建議客戶建立巢狀設定檔，而不是在啟用地理路由的設定檔下新增端點？

在使用地理路由方法的設定檔內，一個區域只能指派給一個端點。 若該端點不是已連結子設定檔的巢狀類型，萬一該端點狀況不良，流量管理員會繼續將流量傳送給該端點，因為即使不傳送任何流量也不會改善。 即使指派的區域屬於狀況不良端點所獲派的區域「父系」，流量管理員也不會容錯移轉至另一個端點 (例如: 若端點的「西班牙」區域狀況不良，將不會容錯移轉至獲派「歐洲」地區的另一個端點)。 這是為了確保流量管理員會顧及客戶在其設定檔中已設定的地理界限。 若要在端點狀況不良時容錯移轉至另一個端點，建議將地理區域指派給具有多個端點的巢狀設定檔，而不是指派給個別端點。 如此一來，若巢狀子系設定檔中的端點失敗，流量便可容錯移轉至相同巢狀子系設定檔內的另一個端點。

支援此路由類型的 API 版本有任何限制嗎？

是，只有 2017 年 3 月 1 日的 API 版本和更新版本支援地理路由類型。 您無法使用任何舊版 API 來建立地理路由類型的設定檔，或將地理區域指派給端點。 若使用舊版 API 從 Azure 訂閱擷取設定檔，地理路由類型的任何設定檔不會被傳回。 此外，使用舊版 API 時，若任何所傳回設定檔的端點已有地理區域指派，便不會顯示該地理區域指派。

流量管理員子網路流量路由方法

子網路路由派上用場的使用案例有哪些？

「子網路」路由可讓您區分針對其 DNS 要求 IP 位址的來源 IP 所識別之特定使用者集合而提供的體驗。 如果使用者要從您的公司總部連線至網站，則範例將會顯示不同的內容。 若某些 ISP 使用 IPv6 時效能不彰，則也會限制這些 ISP 的使用者只能存取僅支援 IPv4 連線的端點。

另一個使用「子網路」路由方法的原因是搭配使用巢狀設定檔集合中的其他設定檔。 例如，如果您想要使用「地理」路由方法來異地隔離使用者，但想要針對特定 ISP 執行不同的路由方法，則可以有「子網路」路由方法作為父設定檔的設定檔，並覆寫該 ISP 以使用特定子設定檔，以及讓其他人都有標準「地理」設定檔。

注意

Azure 流量管理員 支援子網配置檔子網覆寫中的 IPv6 位址。 此功能可根據 DNS 查詢的來源 IP 位址，包括 IPv4 和 IPv6 位址，更細微地控制流量路由。

流量管理員如何知道終端使用者的 IP 位址？

使用者裝置通常會代表使用者身分，以 DNS 解析程式執行 DNS 查閱。 這類解析程式的連出 IP 就是流量管理員視為來源 IP 的 IP。 此外，「子網路」路由方法也會查看是否有與要求一起傳遞的 EDNS0 延伸用戶端子網路 (ECS) 資訊。 如果顯示 ECS 資訊，則這是用來判斷路由的位址。 如果沒有 ECS 資訊，則會將查詢的來源 IP 用於路由。

使用「子網路」路由時，如何指定 IP 位址？

有兩種方式可以指定要與端點建立關聯的 IP 位址。 首先，您可以使用具有開始和結束位址的四點十進制八進位標記法來指定範圍 (例如 1.2.3.4-5.6.7.8 或 3.4.5.6-3.4.5.6)。 其次，您可以使用 CIDR 標記法來指定範圍 (例如 1.2.3.0/24)。 您可以指定多個範圍，而且可以在範圍集合中使用這兩種標記法類型。 適用一些限制。

• 您無法重疊位址範圍，因為每個 IP 位址必須僅對應至單一端點
• 起始位址不能超過結束位址
• 針對 CIDR 標記法，「/」前的 IP 位址應為範圍的網路位址 (例如: 1.2.3.0/24 有效，但 1.2.3.4.4/24 無效)

使用「子網路」路由時，如何指定後援端點？

在具有「子網路」路由的設定檔中，若某端點未對應至任何子網路，與其他端點不相符的所有要求都會導向此處。 強烈建議設定檔中包含這類後援端點，由於若傳入的要求未對應至任何端點，或已對應至端點但該端點狀況不良，流量管理員會傳回 NXDOMAIN 回應。

如果「子網路」路由類型設定檔中已停用端點，則會發生什麼事？

在具有「子網路」路由的設定檔中，若某端點已停用該路由，流量管理員會視同該端點及其子網路對應不存在。 若收到的查詢符合 IP 位址對應，且已停用端點，則流量管理員會傳回後援端點 (無對應端點) ; 若沒有這類端點，NXDOMAIN 回應會被傳回。

流量管理員 MultiValue 流量路由方法

MultiValue 路由派上用場的使用案例有哪些？

MultiValue 路由會在單一查詢回應中傳回多個狀況良好的端點。 此方式的主要優點在於，如果端點狀況不良，則用戶端有更多的選項可重試，而不需要提出另一個 DNS 呼叫 (這可能會從上游快取傳回相同的值)。 若應用程式高度仰賴可用性，且要盡可能縮短停機時間，便適用於此做法。 MultiValue 路由方法的另一種用法是，若端點同時「雙重裝載」IPv4 和 IPv6 位址，且當呼叫者從初始端點連線時要同時提供這兩個選項。

使用 MultiValue 路由時，會傳回多少個端點？

您可以指定要傳回的端點數目上限，而且 MultiValue 所傳回的狀況良好端點數目不會超過收到查詢時的狀況良好端點數目。 此設定的最大可能值為 10。

使用 MultiValue 路由時，會取得一組相同的端點嗎？

我們無法保證每個查詢都會傳回同一組端點。 這也會受到下列事實的影響：有些端點未包含在回應時可能會狀況不良

真實使用者度量單位

使用「實際使用者度量」有哪些優點？

當您使用效能路由方法時，「流量管理員」會檢查來源 IP 和「EDNS 用戶端子網路」(如果已傳入)，並根據服務所維護的網路延遲智慧功能檢查這些資訊，為您的使用者挑選最佳的 Azure 區域來進行連線。 「實際使用者度量」不僅將使用者群的體驗納入延遲資料表，同時也確保這份資料表充分涵蓋了使用者用於連線至 Azure 的網路，進而強化這項功能。 這可提升使用者路由的精確度。

我是否可以將「實際使用者度量」與非 Azure 區域搭配使用？

「實際使用者度量」只會測量連線到 Azure 區域的延遲並進行回報。 若使用以效能為基礎的路由，以及非 Azure 區域所裝載的端點，仍可受益於這項功能，因為您可取得更多延遲相關資訊，了解要與此端點建立關聯的所選代表性 Azure 區域。

哪個路由方法可從「實際使用者度量」受益？

透過「實際使用者度量」取得的額外資訊僅適用於使用效能路由方法的設定檔。 透過 Azure 入口網站檢視實際使用者度量時，就能從所有設定檔使用 [實際使用者度量] 連結。

我是否需要為每個設定檔個別啟用「實際使用者度量」？

否，每一訂用帳戶只需啟用一次，所測量到和回報的所有延遲資訊便可供所有設定檔使用。

如何關閉我訂用帳戶的「實際使用者度量」？

當您從用戶端應用程式停止收集及傳回延遲度量時，即可停止產生與「實際使用者度量」相關的費用。 例如，當度量 JavaScript 內嵌在網頁中時，您可以移除該 JavaScript，或是在轉譯頁面時關閉其引動過程，來停止使用這項功能。

您也可以透過刪除您的金鑰來關閉「實際使用者度量」。 一旦您刪除金鑰，所有傳送給「流量管理員」且具有該金鑰的度量就都會被捨棄。

我是否可以將「實際使用者度量」與網頁以外的用戶端應用程式搭配使用？

是，「實際使用者度量」專門用於擷取各種不同類型的使用者用戶端所收集的資料。 當支援新類型的用戶端應用程式時，該常見問題集 (FAQ) 會進行更新。

每次轉譯已啟用「實際使用者度量」功能的網頁時，會執行多少個度量？

將「實際使用者度量」與所提供的度量 JavaScript 搭配使用時，每個頁面轉譯都會進行 6 個度量。 這些度量會接著回報給「流量管理員」服務。 根據回報給 流量管理員 服務的度量數目，您需支付這項功能的費用。 例如，若使用者在進行度量，但在回報度量前離開您的網頁，這些度量就不會被列入計費。

「實際使用者度量」在我的網頁中執行前是否會有延遲？

否，叫用此指令碼前不會有程式設計的延遲。

是否可以只搭配我想要測量的 Azure 區域來使用實際使用者度量？

否，每次叫用「實際使用者度量」指令碼時，便會測量該服務所決定的一組六個 Azure 區域。 這個集合會在不同的引動過程之間變更，當發生大量這樣的引動過程時，度量涵蓋範圍就會跨不同的 Azure 區域。

我是否可以將度量數目限制為特定數目？

測量 JavaScript 內嵌在您的網頁中，而且您完全控制何時開始和停止使用它。 只要「流量管理員」服務收到待測量 Azure 區域清單的要求，則會傳回一組區域。

我是否可以查看用戶端應用程式在「實際使用者度量」過程中所進行的度量？

由於度量邏輯是從用戶端應用程式執行，因此您可以完全控制發生的情況，包括查看延遲度量。 「流量管理員」不會提供訂閱連結金鑰下取得的度量彙總檢視報告。

我是否可以修改「流量管理員」所提供的度量指令碼？

當您控制網頁內嵌的內容時，我們強烈建議您不要對測量腳本進行任何變更，以確保其能正確測量和報告延遲。

其他人是否可能看到我搭配「實際使用者度量」使用的金鑰？

當您將度量腳本內嵌至網頁時，其他人可能會看到腳本和您的實際使用者度量 （RUM） 密鑰。 請務必了解：此金鑰與您的訂用帳戶識別碼不同，不僅是由流量管理員所產生，且僅供此用途使用。 請注意，您的 RUM 金鑰並不會危害您的 Azure 帳戶安全性。

其他人是否可能濫用我的 RUM 金鑰？

雖然他人可能會使用您的金鑰傳送錯誤資訊給 Azure，但數個錯誤度量並不會改變路由，因為這些度量會與收到的其他所有度量一併考量。 若必須變更金鑰，則可在捨棄舊金鑰時重新產生金鑰。

我是否需要將度量 JavaScript 放在所有網頁中？

「實際使用者度量」會隨著度量數目增加而變得更有價值。 儘管如此，是要將它放在所有網頁中，還是放在幾個選取的網頁中，仍是取決於您。 建議您一開始將它放在瀏覽次數最多且使用者應該至少會停留 5 秒的頁面中。

如果我使用「實際使用者度量」，「流量管理員」是否可以識別出使用者的相關資訊？

使用所提供的度量 JavaScript 時，「流量管理員」可以檢視使用者的用戶端 IP 位址，以及他們所用本機 DNS 解析程式的來源 IP 位址。 「流量管理員」會在將用戶端 IP 位址截斷成無法識別出傳送度量的特定使用者之後，才使用該 IP 位址。

測量「實際使用者度量」的網頁是否必須使用「流量管理員」來進行路由？

否，無須使用流量管理員。 「流量管理員」的路由端與「實際使用者度量」部分為分開運作，雖然將兩者置於相同 Web 屬性為建議做法，但非必要。

我是否必須在 Azure 區域裝載任何服務，才能搭配使用「實際使用者度量」？

否，實際使用者度量的運作無須在 Azure 上裝載任何伺服器端元件。 度量 JavaScript 所下載的單一像素影像，以及在不同 Azure 區域中執行它的服務，是由 Azure 所裝載並管理的。

使用「實際使用者度量」時，我的 Azure 頻寬使用量是否會增加？

如先前的回答中所述，「實際使用者度量」的伺服器端元件是由 Azure 所擁有和管理的。 這表示您的 Azure 頻寬使用量不會因為使用「實際使用者度量」而增加。 這不包含 Azure 收費項目外的任何頻寬使用量。 我們藉由只下載一個單一像素影像來測量連線到 Azure 區域的延遲，將使用的頻寬降到最低。

流量檢視

「流量檢視」有哪些功能？

「流量檢視」是「流量管理員」的一項功能，可協助您進一步了解使用者及他們的體驗情況。 它會使用「流量管理員」所收到的查詢和此服務所維護的網路延遲智慧表格，來提供您下列資訊：

• 使用者從所在區域連線至您在 Azure 中的端點。
• 有多少使用者從這些區域連線。
• 使用者路由傳送至的 Azure 區域。
• 使用者路由傳送至這些 Azure 區域時的延遲體驗。

此資訊除了以未經處理資料的形式供您下載之外，也可供您透過入口網站中的地理對應重疊和表格式檢視取用。

我如何從使用「流量檢視」受益？

「流量檢視」可提供您「流量管理員」所接收流量的整體檢視。 尤其是可用來了解您的使用者群從何處連線，以及同樣重要的是他們的平均延遲體驗。 您可以接著使用此資訊來找出所需專注的領域，例如，將您的 Azure 電腦設備擺設區域擴充到可以為這些使用者提供較低延遲的區域。 「流量檢視」可提供另一項深入解析，讓您查看不同區域的流量模式，有助於決定這些區域要增加或減少投資。

「流量檢視」與透過 Azure 監視器提供的「流量管理員」計量有何不同？

「Azure 監視器」可用來了解設定檔及其端點所收到流量的彙總層級。 它也可以顯示端點的健康情況檢查結果，來讓您追蹤端點的健康狀態。 若您必須進一步了解使用者連線至 Azure 的區域層級體驗，使用「流量檢視」則可達到目的。

「流量檢視」是否使用「EDNS 用戶端子網路」資訊？

由 Azure 流量管理員提供的 DNS 查詢確實會考量 ECS 資訊，以增加路由的精確度。 但是，當建立其中顯示使用者連線來源的資料集時，「流量檢視」僅使用 DNS 解析程式的 IP 位址。

「流量檢視」會使用多少天的資料？

建立輸出時，「流量檢視」會處理從您檢視資料的前一天起往前推七天內的資料。 這是一個移動時段，每次您瀏覽時會使用最新的資料。

「流量檢視」如何處理外部端點？

在流量管理員設定檔中使用 Azure 區域外的外部裝載端點時，您可選擇將其對應至 Azure 區域，作為其延遲特性的 Proxy (這其實是使用效能路由方法時的必要作業)。 若具有此 Azure 區域對應，建立「流量檢視」輸出時會使用該 Azure 區域的延遲計量。 如果未指定任何 Azure 區域，這些外部端點的資料中就不會有任何延遲資訊。

我是否必須為訂用帳戶中的每個設定檔啟用「流量檢視」？

在預覽期間，「流量檢視」會在訂用帳戶層級啟用。 作為我們在公開推出之前所做的改進的一部分，您現在可以在設定檔層級啟用「流量檢視」，以便能更細微地啟用此功能。 根據預設，「流量檢視」會針對設定檔停用。

注意

如果您在預覽期間於訂用帳戶層級啟用「流量檢視」，現在就必須針對該訂用帳戶下的每個設定檔，將它重新啟用。

我是否可以關閉「流量檢視」？

您可以使用入口網站或 REST API，針對任何設定檔關閉「流量檢視」。

「流量檢視」如何計費？

「流量檢視」價格取決於用來建立輸出的資料點數目。 目前，唯一支援的資料類型是您設定檔所接收的查詢。 此外，只有已啟用「流量檢視」時執行的處理才會計費。 這意謂著如果您在一個月中的某個期間啟用「流量檢視」，而在其他期間關閉此功能，則只有在啟用此功能之期間處理的資料點會列入您的帳單中。

流量管理員端點

可以將流量管理員用於來自多個訂用帳戶的端點嗎？

Azure Web 應用程式無法使用來自多個訂閱的端點。 Azure Web Apps 規定 Web Apps 使用的任何自訂網域名稱只能在單一訂用帳戶內使用。 若多個訂閱的 Web 應用程式網域名稱相同，則無法使用。

針對其他端點類型，流量管理員可使用來自多個訂閱的端點。 在 Resource Manager 中，來自任何訂用帳戶的端點都可以新增至流量管理員，只要設定流量管理員設定檔的人員具有端點的讀取權限即可。 使用 Azure 角色型存取控制 (Azure RBAC) 可授與這些權限。 您可使用 Azure PowerShell 或 Azure CLI 新增其他訂用帳戶的端點。

我可以使用流量管理員來設定雲端服務「預備」位置嗎？

是。 雲端服務「預備」位置可在流量管理員中設定為外部端點。 健康情況檢查仍然以 Azure 端點費率計費。

流量管理員是否支援 IPv6 端點？

流量管理員目前不提供 IPv6 可定址名稱伺服器。 不過，若用戶端的遞迴 DNS 伺服器支援 IPv4，連線至 IPv6 端點的 IPv6 用戶端仍然可以使用流量管理員。 用戶端不會直接向流量管理員提出 DNS 要求。 相反地，用戶端會使用遞迴 DNS 服務。 僅支援 IPv6 的用戶端會透過 IPv6 將要求傳送至遞迴 DNS 服務。 然後遞迴服務必須能夠使用 IPv4 來聯絡流量管理員名稱伺服器。 流量管理員會回應端點的 DNS 名稱或 IP 位址。

可以使用流量管理員搭配相同區域中的多個 Web 應用程式嗎？

通常，流量管理員用於將流量導向不同區域中部署的應用程式。 不過，也可用於應用程式在相同區域中有多個部署時。 流量管理員 Azure 端點不允許將相同 Azure 區域中的多個 Web 應用程式端點新增至相同的流量管理員設定檔。

如何將流量管理員設定檔的 Azure 端點移至不同的資源群組或訂用帳戶？

與流量管理員設定檔相關聯的 Azure 端點，是使用其資源識別碼來追蹤的。 若作為端點的 Azure 資源 (如公用 IP、傳統雲端服務、WebApp，或巢狀式運用的另一個流量管理員設定檔) 移至不同的資源群組或訂用帳戶，其資源識別碼也會隨之變更。 在此情況下，目前您必須先刪除端點，然後再將端點加回設定檔中，以更新流量管理員設定檔。

如需詳細資訊，請參閱移動端點。

Azure 流量管理員 支援 DNS 的 IPv6 擴充機制嗎？

Azure 流量管理員 支援具有 DNS 擴充機制的 IPv6 位址（ECS）。 這表示當 DNS 查詢包含 ECS 資訊時，Azure 流量管理員 可以使用 ECS 內的來源 IP 位址來進行智慧型路由決策。

IPv6 ECS 的支援帶來數個優點：

• 改善當地語系化：藉由考慮 ECS 中的 IPv6 位址，流量管理員 可以將使用者路由傳送至最接近或最適當的端點，以降低延遲來增強用戶體驗。
• 增強的流量控制：IPv6 ECS 允許更細微的流量路由決策，以便更妥善地管理全域流量和散發。

使用 IPv6 ECS 時，請務必確定您的端點已正確設定為處理 IPv6 流量。 也請確認您的 DNS 基礎結構，包括遞歸解析程式，能夠處理具有 IPv6 位址的 ECS 資訊。

流量管理員端點監視

流量管理員有能力從 Azure 區域失敗中恢復嗎？

流量管理員在 Azure 中是提供高可用性應用程式的一個重要元件。 若要提供高可用性，流量管理員必須擁有極高的可用性，並且可從區域失敗中恢復。

根據設計，流量管理員元件可從任何 Azure 區域的全面失敗中恢復。 此恢復功能適用於所有流量管理員元件︰DNS 名稱伺服器、API、儲存層及端點監視服務。

萬一整個 Azure 區域停機，也能預期流量管理員會持續正常運作。 在多個 Azure 區域中部署的應用程式可依賴流量管理員，將流量導向其應用程式的可用執行個體。

資源群組位置的選擇如何影響流量管理員？

流量管理員是單一全域服務。 此並非區域性。 如何選擇資源群組位置，對於部署在該資源群組中的流量管理員設定檔而言，並沒有差別。

Azure Resource Manager 需要所有資源群組指定位置，這會決定部署在該資源群組中資源的預設位置。 建立流量管理員設定檔時，其建立位置在資源群組中。 所有流量管理員設定檔都使用全域當作位置，覆寫資源群組預設值。

如何判斷每個端點目前的健全狀況？

每個端點的目前監視狀態以及整體設定檔都會顯示於 Azure 入口網站中。 您也可以透過流量監視 REST API、PowerShell cmdlets 和跨平台 Azure CLI 取得此資訊。

您也可以使用 Azure 監視器來追蹤端點的健康情況，並查看它們的視覺效果表示法。 如需如何使用 Azure 監視器的相關資訊，請參閱 Azure 監視文件。

我可以監視 HTTPS 端點嗎？

是。 流量管理員支援透過 HTTPS 探查。 在監視組態中將 HTTPS 設定為通訊協定。

流量管理員無法提供任何憑證驗證，包含:

• 不驗證伺服器端憑證
• 不驗證 SNI 伺服器端憑證
• 不支援用戶端憑證

新增端點時，使用 IP 位址還是 DNS 名稱？

流量管理員支援使用三種方式來新增要參照的端點：作為 DNS 名稱、IPv4 位址和 IPv6 位址。 如果端點新增為 IPv4 或 IPv6 位址，則查詢回應分別是 A 或 AAAA 記錄類型。 如果端點已新增為 DNS 名稱，則查詢回應會是 CNAME 記錄類型。 只有在端點的類型為外部時，才允許將端點新增為 IPv4 或 IPv6 位址。 三端點定址類型支援所有路由方法和監視設定。

新增端點時，可以使用哪些類型的 IP 位址？

流量管理員可讓您使用 IPv4 或 IPv6 位址來指定端點。 以下列出幾項限制：

• 不允許使用對應至保留私人 IP 位址空間的位址。 這些位址包含 RFC 1918、RFC 6890、RFC 5737、RFC 3068、RFC 2544 和 RFC 5771 中所呼叫的位址
• 位址不得包含任何連接埠號碼 (您可以在設定檔組態設定中指定要使用的連接埠)
• 在相同的設定檔中，不能有兩個端點具有相同的目標 IP 位址

我可以在單一設定檔內使用不同的端點定址類型嗎？

否，流量管理員不允許設定檔內混用端點定址類型 ; 除非設定檔具有 MultiValue 路由類型，則可混用 IPv4 和 IPv6 定址類型

若傳入查詢的記錄類型不同於端點定址類型的相關記錄類型，會發生什麼事？

收到設定檔的查詢時，流量管理員會先尋找需要根據指定路由方法和端點健康狀態所傳回的端點。 它接著會在根據下表傳回回應之前，查看傳入查詢中所要求的記錄類型以及與端點建立關聯的記錄類型。

針對任何具有 MultiValue 以外之路由方法的設定檔：

傳入查詢要求	端點類型	提供的回應
ANY	A/AAAA/CNAME	目標端點
A	A/CNAME	目標端點
A	AAAA	NODATA
AAAA	AAAA/CNAME	目標端點
AAAA	A	NODATA
CNAME	CNAME	目標端點
CNAME	A/AAAA	NODATA

針對路由方法設定為 MultiValue 的設定檔：

傳入查詢要求	端點類型	提供的回應
ANY	混用 A 和 AAAA	目標端點
A	混用 A 和 AAAA	僅限 A 類型的目標端點
AAAA	混用 A 和 AAAA	僅限 AAAA 類型的目標端點
CNAME	混用 A 和 AAAA	NODATA

我可以在巢狀設定檔中使用具有 IPv4/IPv6 定址端點的設定檔嗎？

是，可以，但有下列例外: MultiValue 類型的設定檔不得為巢狀設定檔集合中的父系設定檔。

我已停止「流量管理員」設定檔中的 Web 應用程式端點，但即使重新啟動後仍未收到任何流量。 我該怎麼辦？

當 Azure Web 應用程式端點停止時，「流量管理員」會停止檢查其健康情況，並僅在偵測到端點已重新啟動後，才會重新啟動健康情況檢查。 若要避免這種延遲，在重新啟動該端點之後，請在「流量管理員」設定檔中停用然後重新啟用該端點。

即使應用程式不支援 HTTP 或 HTTPS 也能使用流量管理員嗎？

是。 您可以指定 TCP 作為監視通訊協定，流量管理員可以起始 TCP 連線，並且等待端點的回應。 如果端點在逾時期間內以建立連線的回應來回覆連線要求，則該端點會標示為狀況良好。

使用 TCP 監視時需要端點的哪些特定回應？

使用 TCP 監視時，流量管理員會啟動三向 TCP 交握，方法是將 SYN 要求傳送至端點的指定連接埠。 接著便會等待一段時間 (在逾時設定中指定)，以取得端點的 SYN-ACK 回應。

• 若在監視設定中指定的逾時期間內收到 SYN-ACK 回應，則該端點視為狀況良好。 FIN 或 FIN-ACK 為流量管理員定期終止通訊端時的預期回應。
• 若在指定逾時時間後收到 SYN-ACK 回應，流量管理員會使用 RST 回應，以重設連線。

流量管理員將我的使用者從狀況不良的端點移開時間有多快？

流量管理員提供多項設定，可協助您控制流量管理員設定檔的容錯移轉行為，如下所示：

• 您可以將探查間隔設定為 10 秒，指定流量管理員更頻繁地探查端點。 這可確保能夠立即偵測到狀況不良的任何端點。
• 您可指定在健康情況檢查要求逾時前的等候時間 (最小逾時值為 5 秒)。
• 您可以指定在端點標示為狀況不良之前，可以發生多少次失敗。 這個值最低可以為 0，只要端點的第一次健康情況檢查失敗，就會標示為狀況不良。 不過，對於容許失敗次數使用最小值 0，可能會導致因為在探查時可能發生的任何暫時性問題，讓端點離開輪替。
• 您可以將 DNS 回應的存留時間 (TTL) 指定為最低的 0。 如此則表示 DNS 解析程式無法快取回應，且每個新的查詢皆會取得回應，並包含流量管理員的最新健康情況資訊。

藉由使用這些設定，流量管理員可以提供在端點變成狀況不良之後 10 秒內的容錯移轉，以及針對對應設定檔進行 DNS 查詢。

如何為設定檔中不同的端點指定不同監視設定？

流量管理員監視設定是在各個設定檔層級。 如果您只需要為一個端點使用不同的監視設定，可以藉由讓該端點成為巢狀設定檔來完成，其監視設定與父代設定檔不同。

如何將 HTTP 標頭指派給我端點的流量管理員健康狀態檢查？

流量管理員可讓您在對您端點起始的 HTTP(S) 健康狀態檢查中指定自訂標頭。 如果您想要指定自訂標頭，則可以在設定檔層級 (適用於所有端點) 或在端點層級指定。 若同時在兩個層級定義標頭，則在端點層級指定的標頭會覆寫設定檔層級 1 的標頭。 此狀況的一個常見使用案例是指定主機標頭，以將流量管理員要求正確地路由至裝載於多租用戶環境的端點。 另一個使用案例，則是識別來自端點 HTTP(S) 要求記錄的流量管理員要求

端點健全狀況檢查使用哪一個主機標頭？

如果未提供自訂主機標頭設定，則流量管理員所使用主機標頭即為設定檔中所設定端點目標的 DNS 名稱 (如果可用)。

健康情況檢查是從哪些 IP 位址產生？

請參閱此文章，了解如何擷取可起始流量管理員健康情況檢查的 IP 位址清單。 您可使用 REST API、Azure CLI 或 Azure PowerShell 擷取最新清單。 檢閱列出的 IP，確保端點允許來自這些 IP 位址的連線，以檢查其健康情況狀態。

使用 Azure PowerShell 的範例如下：

$serviceTags = Get-AzNetworkServiceTag -Location eastus
$result = $serviceTags.Values | Where-Object { $_.Name -eq "AzureTrafficManager" }
$result.Properties.AddressPrefixes

注意

公用 IP 位址可能變更且不另行通知。 請務必使用服務標籤探索 API 或可供下載的 JSON 檔案，以擷取最新資訊。

流量管理員會對端點進行多少健康情況檢查？

流量管理員對於您端點的健康情況檢查數目取決於下列項目：

• 您為監視間隔所設定的值 (較小間隔表示在任何指定時間期間內有更多要求進入端點)。
• 產生健康情況檢查的位置數目 (您可以預期這些檢查列在上述常見問題集的 IP 位址)。

如果我的其中一個端點關閉，我如何取得通知？

流量管理員所提供的其中一個計量是設定檔中端點的健全狀態。 您可以將此視為設定檔中所有端點的彙總 (例如，您的端點中 75% 是健康的)，或是依端點層級的端點彙總。 流量管理員計量透過 Azure 監視器呈現，因此您可使用其警示功能，在端點的健全狀態變更時取得通知。 如需詳細資訊，請參閱流量管理員的計量與警示。

流量管理員巢狀設定檔

如何設定巢狀設定檔？

您可以使用 Azure Resource Manager 和傳統 Azure REST API、Azure PowerShell Cmdlet 及跨平台 Azure CLI 命令來設定巢狀流量管理員設定檔。 新的 Azure 入口網站也支援這些設定檔。

流量管理員支援幾層巢狀結構？

設定檔的巢狀結構深度最多可達 10 層。 不允許使用「迴圈」。

在同一個「流量管理員」設定檔中，是否可以將其他端點類型與巢狀子設定檔混合使用？

是。 對於在設定檔內如何結合不同類型的端點，並沒有任何限制。

巢狀設定檔如何套用計費模型？

使用巢狀設定檔時不會有計價上的負面影響。

流量管理員計費有兩個要素︰端點健康狀態檢查和數百萬個 DNS 查詢

• 端點健康情況檢查: 當子系設定檔設為父系設定檔中的端點時，該子系設定檔便不會計費。 監視子設定檔中的端點將以一般方式計費。
• DNS 查詢：每個查詢只計算一次。 查詢父設定檔而從子設定檔傳回端點時，只計入父設定檔內。

如需完整的詳細資料，請參閱流量管理員定價頁面。

巢狀設定檔是否會對效能造成影響？

否，使用巢狀配置檔時不會產生任何效能影響。

在處理每個 DNS 查詢時，流量管理員名稱伺服器會周遊設定檔階層內部。 父設定檔的 DNS 查詢可能會收到從子設定檔傳回端點的 DNS 回應。 無論使用單一設定檔或巢狀設定檔，皆會使用單一 CNAME 記錄。 您無須為階層中的每個設定檔建立 CNAME 記錄。

流量管理員如何計算父設定檔中的巢狀端點健康狀態？

父設定檔不會直接對子系執行健康狀態檢查， 子設定檔端點的健康狀態會用來計算子設定檔的整體健康狀態。 這項資訊會在巢狀設定檔階層中往上傳播，以判斷巢狀端點的健康狀態。 父設定檔會使用此彙總健康狀態，以決定是否可以將流量導向子設定檔。

下表描述流量管理員檢查巢狀端點健康狀態時的行為。

子設定檔監視狀態	父端點監視狀態	備註
Disabled. 已停用子設定檔。	已停止	父端點狀態為「已停止」，不是「已停用」。 「已停用」狀態會保留，表示您已停用父系設定檔中的端點。
已降級。 至少有一個子設定檔端點的狀態為「已降級」。	線上︰子設定檔中「線上」端點的數目至少等於 MinChildEndpoints 的值。 CheckingEndpoint︰子設定檔中「線上」加 CheckingEndpoint 端點的數目至少等於 MinChildEndpoints 的值。 已降級︰其他情況。	系統會將流量傳遞給狀態為 CheckingEndpoint 的端點。 如果 MinChildEndpoints 設定太高，則端點一律會降級。
線上。 至少有一個子設定檔端點處於「線上」狀態。 沒有端點處於「已降級」狀態。	請參閱上方。
CheckingEndpoints。 至少有一個子設定檔端點是 'CheckingEndpoint'。 沒有端點是「線上」或「已降級」。	同上。
非使用中。 所有子設定檔端點不是「已停用」就是「已停止」，或者此設定檔沒有任何端點	已停止

重要

在 Azure 流量管理員 的父配置檔下管理子配置檔時，如果您同時停用並啟用兩個子配置檔，就會發生問題。 如果同時發生這些動作，則兩個端點停用時可能會有短暫的期間，導致父配置檔進入遭入侵狀態。

若要避免這個問題，在同時變更子配置檔時請小心。 請考慮稍微錯開這些動作，以避免流量管理設定發生非預期的中斷。

為什麼我無法將 Azure 雲端服務 擴充支援端點新增至我的 流量管理員 配置檔？

若要將 Azure 雲端擴充端點新增至 流量管理員 配置檔，資源群組必須與 Azure 服務管理 （ASM） API 相容。 位於較舊資源群組中的配置檔必須遵守 ASM API 標準，其禁止從與配置檔不同的訂用帳戶包含公用 IP 位址端點或端點。 若要解決此問題，請考慮將 流量管理員 配置檔和相關聯的資源移至與 ASM API 相容的新資源群組。

後續步驟：

• 深入了解「流量管理員」的 端點監視和自動容錯移轉。
• 深入了解「流量管理員」的 流量路由方法。