Merge pull request #297896 from jaesoni/default-probe-host-update

Update application-gateway-probe-overview.md

Author: prmerger-automator[bot]

articles/application-gateway/application-gateway-probe-overview.md

@@ -5,7 +5,7 @@ services: application-gateway
 author: greg-lindsay
 ms.service: azure-application-gateway
 ms.topic: concept-article
-ms.date: 09/14/2023
+ms.date: 04/09/2025
 ms.author: greglin 
 ms.custom: devx-track-azurepowershell
 ---
@@ -46,15 +46,15 @@ Once the probe detects a failed response, the counter for "Unhealthy threshold"
 
 An application gateway automatically configures a default health probe when you don't set up any custom probe configuration. The monitoring behavior works by making an HTTP GET request to the IP addresses or FQDN configured in the backend pool. For default probes if the backend http settings are configured for HTTPS, the probe uses HTTPS to test health of the backend servers.
 
-For example: You configure your application gateway to use backend servers A, B, and C to receive HTTP network traffic on port 80. The default health monitoring tests the three servers every 30 seconds for a healthy HTTP response with a 30-second-timeout for each request. A healthy HTTP response has a [status code](/troubleshoot/developer/webapps/iis/www-administration-management/http-status-code) between 200 and 399. In this case, the HTTP GET host header for the health probe looks like `http://127.0.0.1/`. Also see [HTTP response codes in Application Gateway](http-response-codes.md).
+For example: You configure your application gateway to use backend servers A, B, and C to receive HTTP network traffic on port 80. The default health monitoring tests the three servers every 30 seconds for a healthy HTTP response with a 30-second-timeout for each request. A healthy HTTP response has a [status code](/troubleshoot/developer/webapps/iis/www-administration-management/http-status-code) between 200 and 399. In this case, the HTTP GET Host header for the health probe appears as `http://127.0.0.1/`, unless a hostname is configured in the [Backend Settings](configuration-http-settings.md#configuring-the-host-name).
 
 If the default probe check fails for server A, the application gateway stops forwarding requests to this server. The default probe still continues to check for server A every 30 seconds. When server A responds successfully to one request from a default health probe, application gateway starts forwarding the requests to the server again.
 
 ### Default health probe settings
 
 | Probe property | Value | Description |
 | --- | --- | --- |
-| Probe URL |\<protocol\>://127.0.0.1:\<port\>/ |The protocol and port are inherited from the backend HTTP settings to which the probe is associated |
+| Probe URL |\<protocol\>://127.0.0.1:\<port\>/ |The protocol and port are inherited from the Backend Settings to which the probe is associated. The default host is 127.0.0.1 unless one is specified in the associated Backend Settings. |
 | Interval |30 |The amount of time in seconds to wait before the next health probe is sent.|
 | Time-out |30 |The amount of time in seconds the application gateway waits for a probe response before marking the probe as unhealthy. If a probe returns as healthy, the corresponding backend is immediately marked as healthy.|
 | Unhealthy threshold |3 |Governs how many probes to send in case there's a failure of the regular health probe. In v1 SKU, these additional health probes are sent in quick succession to determine the health of the backend quickly and don't wait for the probe interval. For v2 SKU, the health probes wait the interval. The backend server is marked down after the consecutive probe failure count reaches the unhealthy threshold. |