Search code examples
azureazure-traffic-manager

Azure Traffic Manager shows endpoints degraded but they return 200

Similar to this question, but I don't think it applies in my case.

I have two total endpoints that are both showing a status of "Degraded."

I read that this usually indicates that the monitor configuration is resulting in a response other than 200. However, testing with curl shows a 200 response for both endpoints. I initially had it set to probe the homepage (which also returned a 200), but added a dedicated 'probe' page just in case, which made no difference.

Here's my traffic manager configuration (classic portal, but that shouldn't matter):

enter image description here

Browser network inspector:

enter image description here

Here's my curl results:

enter image description here

Apparently if all endpoints are degraded, the traffic manager will still function, but I'm concerned that it may be affecting our geo-redundancy.

Thank you in advance for any help!

Solution

  • The -L in your curl invocation is for "follow redirects" which is throwing you off.

    Traffic Manager won't follow HTTP redirects!

    Because your endpoints now return a 301 Moved Permanently they are being rendered Degraded.

    $ curl -Ii http://posguys-east.cloudapp.net/probe.html

HTTP/1.1 301 Moved Permanently
Content-Length: 147
Content-Type: text/html; charset=utf-8
Location: https://posguys.com/probe.html

    This is most probably because you have a HTTP → HTTPS redirect configured in your web.config.

    The solution is simple, remove and re-add endpoints with https:// instead.

    LATER EDIT

    It's not that simple, looks like your application is responding with a 301 redirect on https:// too.

    $ curl -kIiL https://posguys-east.cloudapp.net/probe.html
HTTP/1.1 301 Moved Permanently
Content-Length: 147
Content-Type: text/html; charset=utf-8
Location: https://posguys.com/probe.html
Server: Microsoft-IIS/8.5

HTTP/1.1 200 OK
Cache-Control: max-age=5184000
Content-Length: 149
Content-Type: text/html

    You'll need to address that part. Add an exception for /probe.html to whatever rewrite rule you're hitting there. Test with curl, but no -L this time.