ossentoo
ossentoo

Reputation: 2019

Azure Front Door configured site is returning "Services not available"

I've got an Azure resource group with two App Service web applications in separate locations deployed and working as expected. I also have a Front Door configuration setup. This is responding as expected when accessed via the azurefd.net address.

I want to add a custom domain to this configuration. First, I created a CNAME in my DNS for a www address.

I then added a simple custom domain configuration (via an ARM template), passing the fully qualified custom domain name as a parameter.

The frontend section looks like this when deployed via the template:

                "frontendEndpoints": [
                {
                    "name": "frontendEndpoint1",
                    "properties": {
                        "hostName": "[concat(parameters('frontDoorName'), '.azurefd.net')]",
                        "sessionAffinityEnabledState": "Enabled",
                        "sessionAffinityTtlSeconds": 0
                    }
                },
                {
                    "name": "frontendEndpoint2",
                    "properties": {
                        "hostName": "[parameters('customDomainName')]",
                        "sessionAffinityEnabledState": "Enabled",
                        "sessionAffinityTtlSeconds": 0
                    }
                }
            ],

The frontend is deployed as expected and I can still access the azurefd.net address.

However, when I try and access the www address, I receive an error in the browser with the message:

Our services aren't available right now. We're working to restore all services as soon as possible. Please check back soon. 0tEdHXAAAAAADUxvBayGtQLDTjRthnz9XTE9OMjFFREdFMDMyMQBFZGdl

I have waited more than half an hour for any DNS changes to roll out, but it still doesn't work.

What could the problem be? What's a easy way of troubleshooting such errors? To be clear, I haven't yet added any HTTPS certificates to this configuration. The web applications do respond to both HTTP and HTTPS, so hopefully that isn't the issue.

Upvotes: 13

Views: 40986

Answers (5)

Erikest
Erikest

Reputation: 5097

Another reason is that the origin is unresponsive or times out.

There are some response headers that are set to indicate what's happening at the origin. In my case, it said that the origin timed out (there was a problem with my configuration that prevented the response).

The docs point to a way to enable debug response headers, which can give you more information as well: https://learn.microsoft.com/en-us/azure/frontdoor/front-door-http-headers-protocol#optional-debug-response-headers

Of note: I didn't actually need to enable the above debug headers in my case, so at least in some scenarios, it will indicate the issue without debug mode enabled.

Upvotes: 2

ysong4
ysong4

Reputation: 191

Today I ran into a same error message.

But I guess this error message actually did not tell you anything. Many different setup errors could result in this error message.

It is really frustrating... In my case, it turns out that when I open the URL in chrome, by default, chrome will use HTTPS. But my services are only available in HTTP. So I have to manually type the http:// in the browser...

Hope this could help someone else.

Upvotes: 2

Sagar Kulkarni
Sagar Kulkarni

Reputation: 676

Sometimes we have to wait for a while to make it work.

Upvotes: 1

Lukasvan3L
Lukasvan3L

Reputation: 731

I had the same problem. In my specific case the issue, and solution, were different from the above mentioned.

My configuration was so that I only had routing rules for HTTPS, not for HTTP.

Turns out you have to enable "custom domain https" with your own, or a frontdoor managed certicate. Enabling this with an frontdoor managed certicate fixed the issue. The website was instantly reachable, I didn't even have to wait for the certificate to be provisioned.

Upvotes: 2

Joey Cai
Joey Cai

Reputation: 20067

This symptom can happen if you have not configured a routing rule for the custom domain that you added as a frontend host. A routing rule needs to be explicitly added for that frontend host, even if one has already been configured for the frontend host under the Front Door subdomain (*.azurefd.net) that your custom domain has a DNS mapping to.

So add a routing rule from the custom domain to the desired backend pool. And wait for several minutes and it will work fine.

enter image description here

Upvotes: 14

Related Questions