I have an Azure App Gateway connected to 3 different App Service apps all running as part of the same App Service Plan (3 different back-end pools). In the Backend Health section of the AG, one of the app/pool is constantly flipping between Healthy and Unknown states. I have checked the entire network configuration according to this article and everything seems to be configured properly.
I have configured ip restrictions on the app services according to this article specifying the subnet the AG resides in as allowed. I have also temporarily allowed my ip address and every time the health for the 1 app goes to "unknown", I am still able to access the app service using its native .azurewebsites.net url locally on my machine.
Any ideas how I can troubleshoot this?
Please check if below points help to work around the issue.
As a workaround initially,try to restart the application gateway after the backend is deployed .
Also check this discussion on github issue
Sometimes Appgateway will cache the response indefinitely and the fix
maybe "Dynamic DNS" which ensures that the "no existing domain" is not
cached on the Appgw.Also check for the fix using v16.
Also check this > similar issue which says to use custom domain names as the request looks for some domain.
Related
I have an application gateway running with a web application in a App service plan. The application gateway listens and passes requests to the backend, which is the web app. There is a health probe implemented that works fine.
The web app was reachable fine until I scaled up the Service plan. Suddenly the health probe timed out reaching the backend and I got a 502 bad gateway error in the browser trying to reach the web application. After hours the website suddenly was back and the backend was healthy again. I was under the impression that you could scale up and down the App plan without any noticeable effect on the website, but it seems the gateway was not playing along.
Did I configure something wrong or should this work like I assumed?
I tried to reproduce the same in environment create app service running with application gateway and got a 502 error.
The number of TCP connections allowed by the plan standard while is an older it contains the double make sure while scaling up and down in app service try to remain in same tier so that inbound IP will wait for sometimes and then scale back.
Try to update your default setting in configuration ->General setting-> ARR Affinity Off. Either your application isn't stateful, or the session state is kept on a distant service like a cache or database. And try to Run your application with a minimum of 2-3 instances to prevent from failure.
You can make use of app service diagnostics gives you the right information to more easily
For Reference:
Get started with autoscale in Azure - Azure Monitor| Microsoft
Guide to Running Healthy Apps - Azure App Service
And I got the same error in application gateway as well to avoid the issue
In your virtual network -> service endpoint -> Add endpoint Microsoft.web in default subnet
.
Working on a project where we are starting to use Deployment Slots in our App Services.
All our Prod apps are located behind Application Gateway, and we would like to also have our Slots located behind Application Gateway.
I understand we can not do this using "App Services" as target type in the Backend Pools as of now, but wondered if it is doable using "IP Address or FQDN" as target type.
I have tried to set it up, with various changes in the "HTTP Settings", Probe and so, but haven´t gotten it up spinning.
Can anyone confirm if this is possible, and have any tips on how this should be configured?
Thanks!
I was able to get this working on one of my slots.
Basically setup the listener with your necessary protocol, port cert, hostname, etc... I'm using multi-site listeners so I can have multiple URLs for the one AppGW/Public IP.
The rule points to the listenter, backend pool and appropriate http setting.
The HTTP setting should be configured to connect to your app service URL accordingly. I'm using the azurewebsite.net URL, so I use well known CA cert & override hostname from backend target:
The backend pool then points to the azurewebsites.net URL:
Make sure that GET / works on your app service and returns 200-399 HTTP status codes. Anything outside that range is a failure and the backend pool will be removed. If you need to create a custom health probe to a URL that will respond properly, or adjust the acceptable HTTP status code (if 401 or 403 due to required auth, then just override it with that for testing purposes for now).
I'm trying to do it again with a second slot and running into 502 errors from the App Gateway... However, I'm also waiting on DNS changes from my network team. My first one with my company domain works via hosts file edit, but the 2nd slot (which has 2 different URLs/listeners configured in the AppGW) doesn't want to work the same way for some reason.
Hi, I am trying to configure a basic traffic manager on my azure account. But I always got 404 not found when I using the traffic manager URL.
I have two app service for the TM endpoints:
1. xxxus.azurewebsites.net
2. xxxeu.azurewebsites.net
TM Url is:
xxxtm.trafficmanage.net
I was able to use www.whatsmydns.net to check what the tm is heading to.
But when I use the TM url, I got this:
Did anyone has the same issue? Looking forward to your help
Thank you
I ran into the exact same thing and just found the solution - the app service plan needs to be at least a standard SKU. I was using a free tier, and that was causing my 404.
From Microsoft's Traffic Manager documentation:
Only Web Apps at the 'Standard' SKU or above are eligible for use with Traffic Manager. Attempts to add a Web App of a lower SKU fail. Downgrading the SKU of an existing Web App results in Traffic Manager no longer sending traffic to that Web App.
Currently, you could not add web apps from different subscriptions to the same traffic manager configuration since It is not possible to use Web Apps from multiple subscriptions with the same domain name. Refer to this. You can check this on your side. If so, you can remove one website from your endpoint, then add the website to the same subscriptions.
Moreover, the 404 error always happen due to the domain name could not be resolved by its IP address. It may be one of the following reasons:
The custom domain configured is missing an A record and/or a CNAME record.
The browser client has cached the old IP address of your domain. Clear the cache and test DNS resolution again. On a Windows machine, you clear the cache with ipconfig /flushdns.
You can follow the quickstart to create a Traffic Manager profile, then follow this to verify your traffic manager settings.
I encountered similar issue. My problem is one of my app service is a free tier, so I scaled it up to standard one. And delete my traffic manager and reinstalled and add the service endpoint again, the issue gone.
It's strange. Nslookup will take you to the right web app but the browser will show 404. Changing the app service plan to 'Standard' SKU fixed it for me.
I'm taking my first foray into Azure Service Fabric using a cluster hosted in Azure. I've successfully deployed my cluster via ARM template, which includes the cluster manager resource, VMs for hosting Service Fabric, a Load Balancer, an IP Address and several storage accounts. I've successfully configured the certificate for the management interface and I've successfully written and deployed an application to my cluster. However, when I try to connect to my API via Postman (or even via browser, e.g. Chrome) the connection invariably times out and does not get a response. I've double checked all of my settings for the Load Balancer and traffic should be getting through since I've configured my load balancing rules using the same port for the front and back ends to use the same port for my API in Service Fabric. Can anyone provide me with some tips for how to troubleshoot this situation and find out where exactly the connection problem lies ?
To clarify, I've examined the documentation here, here and here
Have you tried logging in to one of your service fabric nodes via remote desktop and calling your API directly from the VM? I have found that if I can confirm it's working directly on a node, the issue likely lies within the LB or potentially an NSG.
I am trying to setup IP Based SSL instead of SNI SSL on an azure Web App.
The App Service Plan is Standard S1, but unfortunately I am getting the following error message:
There are no IP addresses in the App Service Environment that are available to be assigned to your app.
What are the possible options?
I believe moving the current Web App to a different App Service Plan in a different resource group would solve this issue. I Have already tried moving the App service plan to a different resource group but failed.
Note: Clicking the scale up button doesn't work and shows a JavaScript error in the console
JavaScript Error found in Chrome console
Byron is correct that this is a bug in the UX.
A fix has been made and should be live later today.
Your app is being hosted in an App Service Environment.
Looks like the scale up bottom is not working and that is probably a bug in the UX.
As a workaround you should be able to go directly to the App Service Environment that is hosting your app and perform the scale operation there.
once the scale operation in the App Service environment is done and the new IP Address is added, then you should be able to come back to the SSL binging UX in the app and try this again.