Traffic Manager Frequently Asked Questions (FAQ)

Traffic Manager basics

What IP address does Traffic Manager use?

As explained in How Traffic Manager Works, Traffic Manager works at the Domain Name System (DNS) level. It sends DNS responses to direct clients to the appropriate service endpoint. Clients then connect to the service endpoint directly, not through Traffic Manager.

Therefore, Traffic Manager doesn't provide an endpoint or IP address for clients to connect to. If you want a static IP address for your service, it must be configured in the service, not in Traffic Manager.

What types of traffic can be routed using Traffic Manager?

As explained in How Traffic Manager Works, a Traffic Manager endpoint can be any internet facing service hosted inside or outside of Azure. Hence, Traffic Manager can route traffic that originates from the public internet to a set of endpoints that are also internet facing. If you have endpoints that are inside a private network (for example, an internal version of Azure Load Balancer) or have users making DNS requests from such internal networks, then you can't use Traffic Manager to route this traffic.

Does Traffic Manager support "sticky" sessions?

As explained in How Traffic Manager Works, Traffic Manager works at the DNS level. It uses DNS responses to direct clients to the appropriate service endpoint. Clients connect to the service endpoint directly, not through Traffic Manager. Therefore, Traffic Manager doesn't see the HTTP traffic between the client and the server.

Additionally, the source IP address of the DNS query received by Traffic Manager belongs to the recursive DNS service, not the client. Therefore, Traffic Manager has no way to track individual clients and can't implement 'sticky' sessions. This limitation is common to all DNS-based traffic management systems and isn't specific to Traffic Manager.

Why am I seeing an HTTP error when using Traffic Manager?

As explained in How Traffic Manager Works, Traffic Manager works at the DNS level. It uses DNS responses to direct clients to the appropriate service endpoint. Clients then connect to the service endpoint directly, not through Traffic Manager. Traffic Manager doesn't see HTTP traffic between client and server. Therefore, any HTTP error you see must be coming from your application. For the client to connect to the application, all DNS resolution steps are complete. That includes any interaction that Traffic Manager has on the application traffic flow.

Further investigation should therefore focus on the application.

The HTTP host header sent from the client's browser is the most common source of problems. Make sure that the application is configured to accept the correct host header for the domain name you're using. For endpoints using the Azure App Service, see configuring a custom domain name for a web app in Azure App Service using Traffic Manager.

How can I resolve a 500 (Internal Server Error) problem when using Traffic Manager?

If your client or application receives an HTTP 500 error while using Traffic Manager, this can be caused by a stale DNS query. To resolve the issue, clear the DNS cache and allow the client to issue a new DNS query.

When a service endpoint is unresponsive, clients and applications that are using that endpoint don't reset until the DNS cache is refreshed. The duration of the cache is determined by the time-to-live (TTL) of the DNS record. For more information, see Traffic Manager and the DNS cache.

Also see the following related FAQs in this article:

• What is DNS TTL and how does it impact my users?
• How high or low can I set the TTL for Traffic Manager responses?
• How can I understand the volume of queries coming to my profile?

What is the performance impact of using Traffic Manager?

As explained in How Traffic Manager Works, Traffic Manager works at the DNS level. Since clients connect to your service endpoints directly, there's no performance impact incurred when using Traffic Manager once the connection is established.

Since Traffic Manager integrates with applications at the DNS level, it does require an additional DNS lookup to be inserted into the DNS resolution chain. The impact of Traffic Manager on DNS resolution time is minimal. Traffic Manager uses a global network of name servers, and uses anycast networking to ensure DNS queries are always routed to the closest available name server. In addition, caching of DNS responses means that the additional DNS latency incurred by using Traffic Manager applies only to a fraction of sessions.

The Performance method routes traffic to the closest available endpoint. The net result is that the overall performance impact associated with this method should be minimal. Any increase in DNS latency should be offset by lower network latency to the endpoint.

What application protocols can I use with Traffic Manager?

As explained in How Traffic Manager Works, Traffic Manager works at the DNS level. Once the DNS lookup is complete, clients connect to the application endpoint directly, not through Traffic Manager. Therefore, the connection can use any application protocol. If you select TCP as the monitoring protocol, Traffic Manager's endpoint health monitoring can be done without using any application protocols. If you choose to have the health verified using an application protocol, the endpoint needs to be able to respond to either HTTP or HTTPS GET requests.

Can I use Traffic Manager with a "naked" domain name?

Yes. To learn how to create an alias record for your domain name apex to reference an Azure Traffic Manager profile, see Configure an alias record to support apex domain names with Traffic Manager.

Does Traffic Manager consider the client subnet address when handling DNS queries?

Yes. In addition to the source IP address of the DNS query (usually the DNS resolver's IP address), Traffic Manager also considers the client subnet address if it's included in the DNS query that is sent by the DNS resolver making the request on behalf of the end user. These IP addresses are used to optimize geographic, performance, and subnet routing methods. Specifically, RFC 7871 - Client Subnet in DNS Queries provides an Extension Mechanism for DNS (EDNS0) can pass on the client subnet address from resolvers that support it.

What is DNS TTL and how does it impact my users?

When a DNS query lands on Traffic Manager, it sets a value in the response called time-to-live (TTL). This value, whose unit is in seconds, indicates to DNS resolvers downstream on how long to cache this response. While DNS resolvers aren't guaranteed to cache this result, caching it enables them to respond to any subsequent queries off the cache instead of going to Traffic Manager DNS servers. This impacts the responses as follows:

• a higher TTL reduces the number of queries that land on the Traffic Manager DNS servers, which can reduce the cost for a customer since number of queries served is a billable usage.
• a higher TTL can potentially reduce the time it takes to do a DNS lookup.
• a higher TTL also means that your data doesn't reflect the latest health information that Traffic Manager has obtained through its probing agents.

How high or low can I set the TTL for Traffic Manager responses?

You can set, at a per profile level, the DNS TTL to be as low as 0 seconds and as high as 2,147,483,647 seconds (the maximum range compliant with RFC-1035). A TTL of 0 means that downstream DNS resolvers don't cache query responses and all queries are expected to reach the Traffic Manager DNS servers for resolution.

How can I understand the volume of queries coming to my profile?

One of the metrics provided by Traffic Manager is the number of queries responded by a profile. You can get this information at a profile level aggregation or you can split it up further to see the volume of queries where specific endpoints were returned. In addition, you can set up alerts to notify you if the query response volume crosses the conditions you have set. For more details, Traffic Manager metrics and alerts.

When I delete a Traffic Manager profile, what is the amount of time before the name of the profile is available for reuse?

When you delete a Traffic Manager profile, the associated domain name is reserved for a period of time. Other Traffic Manager profiles in the same tenant can immediately reuse the name. However, a different Azure tenant isn't able to use the same profile name until the reservation expires. This feature enables you to maintain authority over the namespaces that you deploy, eliminating concerns that the name might be taken by another tenant.

For example, if your Traffic Manager profile name is label1, then label1.trafficmanager.cn is reserved for your tenant even if you delete the profile. Child namespaces, such as xyz.label1 or 123.abc.label1 are also reserved. When the reservation expires, the name is made available to other tenants. The name associated with a disabled profile is reserved indefinitely. For questions about the length of time a name is reserved, contact your account representative.

What version of TLS is required by Traffic Manager?

The Azure implementation of older TLS versions is not known to be vulnerable, however, TLS 1.2 and later offer improved security with features such as perfect forward secrecy and stronger cipher suites. To enhance security and provide best-in-class encryption for your data, Traffic Manger requires interactions with services to be secured using Transport Layer Security (TLS) 1.2 or later before February 28,2025. Traffic Manger support for TLS 1.0 and 1.1 will end on this date. This date might be different than the Azure-wide TLS 1.0 and TLS 1.1 retirement date .

Recommended action

To avoid service disruptions, resources that interact with Traffic Manager must use TLS 1.2 or later.

• If resources are already exclusively using TLS 1.2 or later, you don't need to take further action.
• If resources still have a dependency on TLS 1.0 or 1.1, transition them to TLS 1.2 or later by February 28, 2025.

For information about migrating from TLS 1.0 and 1.1 to TLS 1.2, see Solving the TLS 1.0 Problem.

Traffic Manager Geographic traffic routing method

What are some use cases where geographic routing is useful?

Geographic routing type can be used in any scenario where an Azure customer needs to distinguish their users based on geographic regions. For example, using the Geographic traffic routing method, you can give users from specific regions a different user experience than those from other regions. Another example is complying with local data sovereignty mandates that require that users from a specific region be served only by endpoints in that region.

How do I decide if I should use Performance routing method or Geographic routing method?

The key difference between these two popular routing methods is that in Performance routing method your primary goal is to send traffic to the endpoint that can provide the lowest latency to the caller, whereas, in Geographic routing the primary goal is to enforce a geo fence for your callers so that you can deliberately route them to a specific endpoint. The overlap happens since there's a correlation between geographical closeness and lower latency, although this isn't always true. There might be an endpoint in a different geography that can provide a better latency experience for the caller and in that case Performance routing sends the user to that endpoint but Geographic routing always sends them to the endpoint you've mapped for their geographic region. In that case, Geographic routing deliberately does exactly what you have configured it to do and performance optimization isn't a consideration.

What are the regions that are supported by Traffic Manager for geographic routing?

The country/region hierarchy that is used by Traffic Manager can be found here. While this page is kept up to date with any changes, you can also programmatically retrieve the same information by using the Azure Traffic Manager REST API.

How does traffic manager determine where a user is querying from?

Traffic Manager looks at the source IP of the query (this most likely is a local DNS resolver doing the querying on behalf of the user) and uses an internal IP to region map to determine the location. This map is updated on an ongoing basis to account for changes in the internet.

Is it guaranteed that Traffic Manager can correctly determine the exact geographic location of the user in every case?

No, Traffic Manager can't guarantee that the geographic region we infer from the source IP address of a DNS query always corresponds to the user's location due to the following reasons:

• First, as described in the previous FAQ, the source IP we see is that of a DNS resolver doing the lookup on behalf of the user. While the geographic location of the DNS resolver is a good proxy for the geographic location of the user, it can also be different depending upon the footprint of the DNS resolver service and the specific DNS resolver service a customer has chosen to use.

• Second, Traffic Manager uses an internal map to do the IP address to geographic region translation. While this map is validated and updated on an ongoing basis to increase its accuracy and account for the evolving nature of the internet, there's still the possibility that our information isn't an exact representation of the geographic location of all the IP addresses.

Does an endpoint need to be physically located in the same region as the one it's configured with for geographic routing?

No, the location of the endpoint imposes no restrictions on which regions can be mapped to it.

Can I assign geographic regions to endpoints in a profile that isn't configured to do geographic routing?

Yes, if the routing method of a profile isn't geographic, you can use the Azure Traffic Manager REST API to assign geographic regions to endpoints in that profile. For non-geographic routing type profiles, this configuration is ignored. If you change such a profile to geographic routing type at a later time, Traffic Manager can use those mappings.

Why am I getting an error when I try to change the routing method of an existing profile to Geographic?

All the endpoints under a profile with geographic routing need to have at least one region mapped to it. To convert an existing profile to geographic routing type, you first need to associate geographic regions to all its endpoints using the Azure Traffic Manager REST API before changing the routing type to geographic. If using portal, first delete the endpoints, change the routing method of the profile to geographic and then add the endpoints along with their geographic region mapping.

Why is it strongly recommended that customers create nested profiles instead of endpoints under a profile with geographic routing enabled?

A region can be assigned to only one endpoint within a profile if it's using the geographic routing method. If that endpoint isn't a nested type with a child profile attached to it, if that endpoint going unhealthy, Traffic Manager continues to send traffic to it since the alternative of not sending any traffic isn't any better. Traffic Manager doesn't fail over to another endpoint, even when the region assigned is a "parent" of the region assigned to the endpoint that went unhealthy. This is done to ensure that Traffic Manager respects the geographic boundaries that a customer has setup in their profile. To get the benefit of failing over to another endpoint when an endpoint goes unhealthy, it's recommended that geographic regions be assigned to nested profiles with multiple endpoints within it instead of individual endpoints. In this way, if an endpoint in the nested child profile fails, traffic can fail over to another endpoint inside the same nested child profile.

Are there any restrictions on the API version that supports this routing type?

Yes, only API version 2017-03-01 and newer supports the Geographic routing type. Any older API versions can't be used to created profiles of Geographic routing type or assign geographic regions to endpoints. If an older API version is used to retrieve profiles from an Azure subscription, any profile of Geographic routing type isn't returned. In addition, when using older API versions, any profile returned that has endpoints with a geographic region assignment, doesn't have its geographic region assignment shown.

Traffic Manager Subnet traffic routing method

What are some use cases where subnet routing is useful?

Subnet routing allows you to differentiate the experience you deliver for specific sets of users identified by the source IP of their DNS requests IP address. An example would be showing different content if users are connecting to a website from your corporate HQ. Another would be restricting users from certain ISPs to only access endpoints that support only IPv4 connections if those ISPs have subpar performance when IPv6 is used.

Another reason to use Subnet routing method is in conjunction with other profiles in a nested profile set. For example, if you want to use Geographic routing method for geo-fencing your users, but for a specific ISP you want to do a different routing method, you can have a profile withy Subnet routing method as the parent profile and override that ISP to use a specific child profile and have the standard Geographic profile for everyone else.

How does Traffic Manager know the IP address of the end user?

End-user devices typically use a DNS resolver to do the DNS lookup on their behalf. The outgoing IP of such resolvers is what Traffic Manager sees as the source IP. In addition, Subnet routing method also looks to see if there's EDNS0 Extended Client Subnet (ECS) information that was passed with the request. If ECS information is present, that is the address used to determine the routing. In the absence of ECS information, the source IP of the query is used for routing purposes.

How can I specify IP addresses when using Subnet routing?

The IP addresses to associate with an endpoint can be specified in two ways. First, you can use the quad dotted decimal octet notation with a start and end addresses to specify the range (for example, 1.2.3.4-5.6.7.8 or 3.4.5.6-3.4.5.6). Second, you can use the CIDR notation to specify the range (for example, 1.2.3.0/24). You can specify multiple ranges and can use both notation types in a range set. A few restrictions apply.

• You can't overlap address ranges since each IP address needs to be mapped to only a single endpoint
• The start address can't be more than the end address
• For the CIDR notation, the IP address before the '/' should be the network address of that range (for example, 1.2.3.0/24 is valid but 1.2.3.4.4/24 is NOT valid)

How can I specify a fallback endpoint when using Subnet routing?

In a profile with Subnet routing, if you have an endpoint with no subnets mapped to it, any request that doesn't match with other endpoints are directed to here. It's highly recommended that you have such a fallback endpoint in your profile since Traffic Manager returns an NXDOMAIN response if a request comes in and it isn't mapped to any endpoints or if it's mapped to an endpoint but that endpoint is unhealthy.

What happens if an endpoint is disabled in a Subnet routing type profile?

In a profile with Subnet routing, if you have an endpoint with that is disabled, Traffic Manager behaves as if that endpoint and the subnet mappings it has doesn't exist. If a query that would have matched with its IP address mapping is received and the endpoint is disabled, Traffic Manager returns a fallback endpoint (one with no mappings) or if such an endpoint isn't present, returns an NXDOMAIN response.

Traffic Manager MultiValue traffic routing method

What are some use cases where MultiValue routing is useful?

MultiValue routing returns multiple healthy endpoints in a single query response. The main advantage of this is that, if an endpoint is unhealthy, the client has more options to retry without making another DNS call (which might return the same value from an upstream cache). This is applicable for availability-sensitive applications that want to minimize the downtime. Another use for MultiValue routing method is if an endpoint is "dual-homed" to both IPv4 and IPv6 addresses and you want to give the caller both options to choose from when it initiates a connection to the endpoint.

How many endpoints are returned when MultiValue routing is used?

You can specify the maximum number of endpoints to be returned and MultiValue returns no more than that many healthy endpoints when a query is received. The maximum possible value for this configuration is 10.

Will I get the same set of endpoints when MultiValue routing is used?

We can't guarantee that the same set of endpoints are returned in each query. This is also affected by the fact that some of the endpoints might go unhealthy at which point they won't be included in the response

Traffic Manager endpoints

Can I use Traffic Manager with endpoints from multiple subscriptions?

Using endpoints from multiple subscriptions isn't possible with Azure Web Apps. Azure Web Apps requires that any custom domain name used with Web Apps is only used within a single subscription. It isn't possible to use Web Apps from multiple subscriptions with the same domain name.

For other endpoint types, it's possible to use Traffic Manager with endpoints from more than one subscription. In Resource Manager, endpoints from any subscription can be added to Traffic Manager, as long as the person configuring the Traffic Manager profile has read access to the endpoint. These permissions can be granted using Azure role-based access control (Azure RBAC role). Endpoints from other subscriptions can be added using Azure PowerShell or the Azure CLI.

Can I use Traffic Manager with Cloud Service 'Staging' slots?

Yes. Cloud Service 'staging' slots can be configured in Traffic Manager as External endpoints. Health checks are still be charged at the Azure Endpoints rate.

Does Traffic Manager support IPv6 endpoints?

Traffic Manager doesn't currently provide IPv6-addressable name servers. However, Traffic Manager can still be used by IPv6 clients connecting to IPv6 endpoints if the client's recursive DNS server supports IPv4. A client doesn't make DNS request directly to Traffic Manager. Instead, the client uses a recursive DNS service. An IPv6-only client sends requests to the recursive DNS service via IPv6. The recursive service must then be able to contact the Traffic Manager name servers using IPv4. Traffic Manager responds with the DNS name or IP address of the endpoint.

Can I use Traffic Manager with more than one Web App in the same region?

Typically, Traffic Manager is used to direct traffic to applications deployed in different regions. However, it can also be used where an application has more than one deployment in the same region. The Traffic Manager Azure endpoints don't permit more than one Web App endpoint from the same Azure region to be added to the same Traffic Manager profile.

How do I move my Traffic Manager profile's Azure endpoints to a different resource group or subscription?

Azure endpoints that are associated with a Traffic Manager profile are tracked using their resource IDs. When an Azure resource that is being used as an endpoint (for example, Public IP, Classic Cloud Service, WebApp, or another Traffic Manager profile used in a nested manner) is moved to a different resource group or subscription, its resource ID changes. In this scenario, currently, you must update the Traffic Manager profile by first deleting and then adding back the endpoints to the profile.

For more information, see To move an endpoint.

Does Azure Traffic Manager support IPv6 Extension Mechanisms for DNS (ECS)?

Azure Traffic Manager supports IPv6 addresses with Extension Mechanisms for DNS (ECS). This means that when a DNS query includes ECS information, Azure Traffic Manager can use the source IP address within the ECS to make intelligent routing decisions.

The support for IPv6 ECS brings several advantages:

• Improved Localization: By considering the IPv6 address in the ECS, Traffic Manager can route users to the nearest or most appropriate endpoint, enhancing the user experience with reduced latency.
• Enhanced Traffic Control: IPv6 ECS allows for more granular traffic routing decisions, enabling better management of global traffic and distribution.

When using IPv6 ECS, it's important to ensure that your endpoints are correctly configured to handle IPv6 traffic. Also verify that your DNS infrastructure, including recursive resolvers, is capable of handling ECS information with IPv6 addresses.

Traffic Manager endpoint monitoring

Is Traffic Manager resilient to Azure region failures?

Traffic Manager is a key component of the delivery of highly available applications in Azure. To deliver high availability, Traffic Manager must have an exceptionally high level of availability and be resilient to regional failure.

By design, Traffic Manager components are resilient to a complete failure of any Azure region. This resilience applies to all Traffic Manager components: the DNS name servers, the API, the storage layer, and the endpoint monitoring service.

In the unlikely event of an outage of an entire Azure region, Traffic Manager is expected to continue to function normally. Applications deployed in multiple Azure regions can rely on Traffic Manager to direct traffic to an available instance of their application.

How does the choice of resource group location affect Traffic Manager?

Traffic Manager is a single, global service. It isn't regional. The choice of resource group location makes no difference to Traffic Manager profiles deployed in that resource group.

Azure Resource Manager requires all resource groups to specify a location, which determines the default location for resources deployed in that resource group. When you create a Traffic Manager profile, it's created in a resource group. All Traffic Manager profiles use global as their location, overriding the resource group default.

How do I determine the current health of each endpoint?

The current monitoring status of each endpoint, in addition to the overall profile, is displayed in the Azure portal. This information also is available via the Traffic Monitor REST API, PowerShell cmdlets, and cross-platform Azure CLI.

You can also use Azure Monitor to track the health of your endpoints and see a visual representation of them. For more about using Azure Monitor, see the Azure Monitoring documentation.

Can I monitor HTTPS endpoints?

Yes. Traffic Manager supports probing over HTTPS. Configure HTTPS as the protocol in the monitoring configuration.

Traffic manager can't provide any certificate validation, including:

• Server-side certificates aren't validated
• SNI server-side certificates aren't validated
• Client certificates aren't supported

Do I use an IP address or a DNS name when adding an endpoint?

Traffic Manager supports adding endpoints using three ways to refer them:

• As a DNS name
• As an IPv4 address
• As an IPv6 address

If the endpoint is added as an IPv4 or IPv6 address, the query response is of record type A or AAAA, respectively. If the endpoint was added as a DNS name, then the query response is of record type CNAME. Adding endpoints as IPv4 or IPv6 address is permitted only if the endpoint is of type External.

All routing methods and monitoring settings are supported by the three endpoint addressing types.

What types of IP addresses can I use when adding an endpoint?

Traffic Manager allows you to use IPv4 or IPv6 addresses to specify endpoints. There are a few restrictions, which are listed below:

• Addresses that correspond to reserved private IP address spaces aren't allowed. These addresses include those called out in RFC 1918, RFC 6890, RFC 5737, RFC 3068, RFC 2544, and RFC 5771.
• The IP address must not contain any port numbers (you can specify the ports to be used in the profile configuration settings).
• No two endpoints in the same profile can have the same target IP address.

Can I use different endpoint addressing types within a single profile?

No. Traffic Manager doesn't allow you to mix endpoint addressing types within a profile, except for the case of a profile with MultiValue routing type where you can mix IPv4 and IPv6 addressing types.

What happens when an incoming query's record type is different from the record type associated with the addressing type of the endpoints?

When a query is received against a profile, Traffic Manager first finds the endpoint that needs to be returned as per the routing method specified and the health status of the endpoints. It then looks at the record type requested in the incoming query and the record type associated with the endpoint before returning a response based on the table below.

For profiles with any routing method other than MultiValue:

Incoming query request	Endpoint type	Response Provided
ANY	A / AAAA / CNAME	Target Endpoint
A	A / CNAME	Target Endpoint
A	AAAA	NODATA
AAAA	AAAA / CNAME	Target Endpoint
AAAA	A	NODATA
CNAME	CNAME	Target Endpoint
CNAME	A / AAAA	NODATA

For profiles with routing method set to MultiValue:

Incoming query request	Endpoint type	Response Provided
ANY	Mix of A and AAAA	Target Endpoints
A	Mix of A and AAAA	Only Target Endpoints of type A
AAAA	Mix of A and AAAA	Only Target Endpoints of type AAAA
CNAME	Mix of A and AAAA	NODATA

Can I use a profile with IPv4 / IPv6 addressed endpoints in a nested profile?

Yes you can, with the exception that a profile of type MultiValue can't be a parent profile in a nested profile set.

I stopped a web application endpoint in my Traffic Manager profile but I'm not receiving any traffic even after I restarted it. How can I fix this?

When an Azure web application endpoint is stopped Traffic Manager stops checking its health and restarts the health checks only after it detects that the endpoint has restarted. To prevent this delay, disable and then reenable that endpoint in the Traffic Manager profile after you restart the endpoint.

Can I use Traffic Manager even if my application doesn't have support for HTTP or HTTPS?

Yes. You can specify TCP as the monitoring protocol and Traffic Manager can initiate a TCP connection and wait for a response from the endpoint. If the endpoint replies to the connection request with a response to establish the connection, within the timeout period, then that endpoint is marked as healthy.

What specific responses are required from the endpoint when using TCP monitoring?

When TCP monitoring is used, Traffic Manager starts a three-way TCP handshake by sending a SYN request to endpoint at the specified port. It then waits for an SYN-ACK response from the endpoint for a period of time (specified in the timeout settings).

• If an SYN-ACK response is received within the timeout period specified in the monitoring settings, then that endpoint is considered healthy. A FIN or FIN-ACK is the expected response from the Traffic Manager when it regularly terminates a socket.
• If an SYN-ACK response is received after the specified timeout, Traffic Manager responds with an RST to reset the connection.

How fast does Traffic Manager move my users away from an unhealthy endpoint?

Traffic Manager provides multiple settings that can help you to control the failover behavior of your Traffic Manager profile as follows:

• you can specify that the Traffic Manager probes the endpoints more frequently by setting the Probing Interval at 10 seconds. This ensures that any endpoint going unhealthy can be detected as soon as possible.
• you can specify how long to wait before a health check request times out (minimum time-out value is 5 sec).
• you can specify how many failures can occur before the endpoint is marked as unhealthy. This value can be low as 0, in which case the endpoint is marked unhealthy as soon as it fails the first health check. However, using the minimum value of 0 for the tolerated number of failures can lead to endpoints being taken out of rotation due to any transient issues that may occur at the time of probing.
• you can specify the time-to-live (TTL) for the DNS response to be as low as 0. Doing so means that DNS resolvers can't cache the response and each new query gets a response that incorporates the most up-to-date health information that the Traffic Manager has.

By using these settings, Traffic Manager can provide failovers under 10 seconds after an endpoint goes unhealthy and a DNS query is made against the corresponding profile.

How can I specify different monitoring settings for different endpoints in a profile?

Traffic Manager monitoring settings are at a per profile level. If you need to use a different monitoring setting for only one endpoint, it can be done by having that endpoint as a nested profile whose monitoring settings are different from the parent profile.

How can I assign HTTP headers to the Traffic Manager health checks to my endpoints?

Traffic Manager allows you to specify custom headers in the HTTP(S) health checks it initiates to your endpoints. If you want to specify a custom header, you can do that at the profile level (applicable to all endpoints) or specify it at the endpoint level. If a header is defined at both levels, then the one specified at the endpoint level overrides the profile level 1. One common use case for this is specifying host headers so that Traffic Manager requests may get routed correctly to an endpoint hosted in a multitenant environment. Another use case of this is to identify Traffic Manager requests from an endpoint's HTTP(S) request logs

What host header do endpoint health checks use?

If no custom host header setting is provided, the host header used by Traffic Manager is the DNS name of the endpoint target configured in the profile, if that is available.

What are the IP addresses from which the health checks originate?

See this article to learn how to retrieve the lists of IP addresses from which Traffic Manager health checks can originate. You can use REST API, Azure CLI, or Azure PowerShell to retrieve the latest list. Review the IPs listed to ensure that incoming connections from these IP addresses are allowed at the endpoints to check its health status.

Example using Azure PowerShell:

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

How many health checks to my endpoint can I expect from Traffic Manager?

The number of Traffic Manager health checks reaching your endpoint depends on the following:

• the value that you have set for the monitoring interval (smaller interval means more requests landing on your endpoint in any given time period).
• the number of locations from where the health checks originate (the IP addresses from where you can expect these checks is listed in the preceding FAQ).

How can I get notified if one of my endpoints goes down?

One of the metrics provided by Traffic Manager is the health status of endpoints in a profile. You can see this as an aggregate of all endpoints inside a profile (for example, 75% of your endpoints are healthy), or, at a per endpoint level. Traffic Manager metrics are exposed through Azure Monitor and you can use its alerting capabilities to get notifications when there's a change in the health status of your endpoint. For more information, see Traffic Manager metrics and alerts.

Traffic Manager nested profiles

How do I configure nested profiles?

Nested Traffic Manager profiles can be configured using both the Azure Resource Manager and the classic Azure REST APIs, Azure PowerShell cmdlets and cross-platform Azure CLI commands. They're also supported via the new Azure portal.

How many layers of nesting does Traffic Manger support?

You can nest profiles up to 10 levels deep. 'Loops' aren't permitted.

Can I mix other endpoint types with nested child profiles, in the same Traffic Manager profile?

Yes. There are no restrictions on how you combine endpoints of different types within a profile.

How does the billing model apply for Nested profiles?

There's no negative pricing impact of using nested profiles.

Traffic Manager billing has two components: endpoint health checks and millions of DNS queries

• Endpoint health checks: There's no charge for a child profile when configured as an endpoint in a parent profile. Monitoring of the endpoints in the child profile is billed in the usual way.
• DNS queries: Each query is only counted once. A query against a parent profile that returns an endpoint from a child profile is counted against the parent profile only.

For full details, see the Traffic Manager pricing page.

Is there a performance impact for nested profiles?

No, there's no performance impact incurred when using nested profiles.

The Traffic Manager name servers traverse the profile hierarchy internally when processing each DNS query. A DNS query to a parent profile can receive a DNS response with an endpoint from a child profile. A single CNAME record is used whether you're using a single profile or nested profiles. There's no need to create a CNAME record for each profile in the hierarchy.

How does Traffic Manager compute the health of a nested endpoint in a parent profile?

The parent profile doesn't perform health checks on the child directly. Instead, the health of the child profile's endpoints is used to calculate the overall health of the child profile. This information is propagated up the nested profile hierarchy to determine the health of the nested endpoint. The parent profile uses this aggregated health to determine whether the traffic can be directed to the child.

The following table describes the behavior of Traffic Manager health checks for a nested endpoint.

Child Profile Monitor status	Parent Endpoint Monitor status	Notes
Disabled. The child profile has been disabled.	Stopped	The parent endpoint state is Stopped, not Disabled. The Disabled state is reserved for indicating that you've disabled the endpoint in the parent profile.
Degraded. At least one child profile endpoint is in a Degraded state.	Online: the number of Online endpoints in the child profile is at least the value of MinChildEndpoints. CheckingEndpoint: the number of Online plus CheckingEndpoint endpoints in the child profile is at least the value of MinChildEndpoints. Degraded: otherwise.	Traffic is routed to an endpoint of status CheckingEndpoint. If MinChildEndpoints is set too high, the endpoint is always degraded.
Online. At least one child profile endpoint is an Online state. No endpoint is in the Degraded state.	See above.
CheckingEndpoints. At least one child profile endpoint is CheckingEndpoint. No endpoints are Online or Degraded	Same as above.
Inactive. All child profile endpoints are either Disabled or Stopped, or this profile has no endpoints.	Stopped

Why can't I add Azure Cloud Services Extended Support Endpoints to my Traffic Manager profile?

In order to add Azure Cloud Extended endpoints to a Traffic Manager profile, the resource group must have compatibility with the Azure Service Management (ASM) API. Profiles located in the older resource group must adhere to ASM API standards, which prohibit the inclusion of public IP address endpoints or endpoints from a different subscription than that of the profile. To resolve this, consider moving your Traffic Manager profile and associated resources to a new resource group compatible with the ASM API.

Next steps:

• Learn more about Traffic Manager endpoint monitoring and automatic failover.
• Learn more about Traffic Manager traffic routing methods.