Merge pull request #193191 from paulth1/troubleshoot-issues

ShawnJackson · web-flow · commit 5b83597530e4 · 2022-03-30T12:10:42.000-05:00
edit pass: troubleshoot-issues
diff --git a/articles/frontdoor/troubleshoot-issues.md b/articles/frontdoor/troubleshoot-issues.md
@@ -13,98 +13,100 @@ ms.author: duau
 
 This article describes how to troubleshoot common routing problems that you might face for your Azure Front Door configuration.
 
-## Additional debugging HTTP headers
+## Other debugging HTTP headers
 
-You can request Front Door to return additional debugging HTTP response headers. For more details, refer to [optional response headers](front-door-http-headers-protocol.md#optional-debug-response-headers).
+You can request Azure Front Door to return more debugging HTTP response headers. For more information, see [optional response headers](front-door-http-headers-protocol.md#optional-debug-response-headers).
 
 ## 503 response from Azure Front Door after a few seconds
 
 ### Symptom
 
 * Regular requests sent to your backend without going through Azure Front Door are succeeding. Going via Azure Front Door results in 503 error responses.
-* The failure from Azure Front Door typically shows after about 30 seconds.
-* Intermittent 503 errors with log `ErrorInfo: OriginInvalidResponse`.
+* The failure from Azure Front Door typically appears after about 30 seconds.
+* Intermittent 503 errors appear with "ErrorInfo: OriginInvalidResponse."
 
 ### Cause
 
 The cause of this problem can be one of three things:
- 
-* Your origin is taking longer than the timeout configured (default is 30 seconds) to receive the request from Azure Front Door.
+
+* Your origin is taking longer than the timeout configured to receive the request from Azure Front Door. The default is 30 seconds.
 * The time it takes to send a response to the request from Azure Front Door is taking longer than the timeout value.
-* Client sent a byte range request with `Accept-Encoding header` (compression enabled).
+* The client sent a byte range request with an **Accept-Encoding** header, which means compression is enabled.
 
 ### Troubleshooting steps
 
-* Send the request to your backend directly (without going through Azure Front Door). See how long your backend usually takes to respond.
+* Send the request to your backend directly without going through Azure Front Door. See how long your backend usually takes to respond.
 * Send the request via Azure Front Door and see if you're getting any 503 responses. If not, the problem might not be a timeout issue. Contact support.
-* If requests going through Azure Front Door results in a 503 error response code, configure the **Origin response timeout (in seconds)** for the endpoint. You can extend the default timeout to up to 4 minutes (240 seconds). The setting can be configured by going to the *Endpoint manager* and selecting **Edit endpoint**.
+* If requests going through Azure Front Door result in a 503 error response code, configure **Origin response timeout (in seconds)** for the endpoint. You can extend the default timeout to up to 4 minutes, which is 240 seconds. To configure the setting, go to **Endpoint manager** and select **Edit endpoint**.
+
+    :::image type="content" source="./media/troubleshoot-issues/origin-response-timeout-1.png" alt-text="Screenshot that shows selecting Edit endpoint from Endpoint manager.":::
 
-    :::image type="content" source="./media/troubleshoot-issues/origin-response-timeout-1.png" alt-text="Screenshot of selecting edit endpoint from Endpoint manager.":::
+    Then select **Endpoint properties** to configure **Origin response timeout**.
 
-    Then select **Endpoint properties** to configure the **Origin response timeout**:
+    :::image type="content" source="./media/troubleshoot-issues/origin-response-timeout-2.png" alt-text="Screenshot that shows selecting Endpoint properties and the Origin response timeout field." lightbox="./media/troubleshoot-issues/origin-response-timeout-2-expanded.png":::
 
-    :::image type="content" source="./media/troubleshoot-issues/origin-response-timeout-2.png" alt-text="Screenshot of select endpoint properties and Origin response timeout field." lightbox="./media/troubleshoot-issues/origin-response-timeout-2-expanded.png":::
+* If the timeout doesn't resolve the issue, use a tool like Fiddler or your browser's developer tool to check if the client is sending byte range requests with **Accept-Encoding** headers. Using this option leads to the origin responding with different content lengths.
 
-* If the timeout doesn’t resolve the issue, use a tool like Fiddler or your browser's developer tool to check if the client is sending byte range requests with Accept-Encoding headers, leading to the origin responding with different content lengths. If yes, then you can either disable compression on the Origin/Azure Front Door or create a Rules Set rule to remove `accept-encoding` from the request for byte range requests.
+   If the client is sending byte range requests with **Accept-Encoding** headers, you have two options. You can disable compression on the origin/Azure Front Door. Or you can create a rules set rule to remove **Accept-Encoding** from the request for byte range requests.
 
-    :::image type="content" source="./media/troubleshoot-issues/remove-encoding-rule.png" alt-text="Screenshot of accept-encoding rule in a Rule Set.":::
+    :::image type="content" source="./media/troubleshoot-issues/remove-encoding-rule.png" alt-text="Screenshot that shows the Accept-Encoding rule in a rule set.":::
 
 ## 503 responses from Azure Front Door only for HTTPS
 
 ### Symptom
 
-*	503 responses are returned only for AFD HTTPS enabled endpoints
-*	Regular requests sent to your backend without going through Azure Front Door are succeeding. Going via Azure Front Door results in 503 error responses.
-*	Intermittent 503 errors with log `ErrorInfo: OriginInvalidResponse`
+* Any 503 responses are returned only for Azure Front Door HTTPS-enabled endpoints.
+* Regular requests sent to your backend without going through Azure Front Door are succeeding. Going via Azure Front Door results in 503 error responses.
+* Intermittent 503 errors appear with "ErrorInfo: OriginInvalidResponse."
 
 ### Cause
+
 The cause of this problem can be one of three things:
-*	Backend Pool is an IP address
-*	Backend Server is returning a certificate that does not match the FQDN of the AFD backend Pool
-*	Backend Pool is an Azure Web Apps server
+
+* The backend pool is an IP address.
+* The backend server returns a certificate that doesn't match the FQDN of the Azure Front Door backend pool.
+* The backend pool is an Azure Web Apps server.
 
 ### Troubleshooting steps
 
-*	Backend Pool is an IP address
+* The backend pool is an IP address.
 
-    `EnforceCertificateNameCheck` must be disabled.
+   `EnforceCertificateNameCheck` must be disabled.
     
-    AFD has a switch called "enforceCertificateNameCheck". By default, this setting is enabled. When enabled, AFD checks that the backend pool host name FQDN matches the backend server certificate's Certificate Name (CN) or one of the entries in the Subject Alternative Names (SAN) extension.
+    Azure Front Door has a switch called `EnforceCertificateNameCheck`. By default, this setting is enabled. When enabled, Azure Front Door checks that the backend pool host name FQDN matches the backend server certificate's certificate name or one of the entries in the subject alternative names extension.
 
-    How to disable EnforceCertifiateNameCheck from Portal:
+    - How to disable `EnforceCertificateNameCheck` from the Azure portal:
     
-    In the portal there is a toggle button, that will allow you to turn this on/off in the Azure Front Door Design Blade.
+      In the portal, use a toggle button to turn this setting on or off in the Azure Front Door **Design** pane.
     
-    ![image](https://user-images.githubusercontent.com/63200992/148067710-1b9b6053-efe3-45eb-859f-f747de300653.png)
+      ![Screenshot that shows the toggle button.](https://user-images.githubusercontent.com/63200992/148067710-1b9b6053-efe3-45eb-859f-f747de300653.png)
 
-*	Backend Server is returning a certificate that does not match the FQDN of the AFD backend Pool
+* The backend server returns a certificate that doesn't match the FQDN of the Azure Front Door backend pool. To resolve this issue, you have two options:
 
-    - To resolve we will either need the certificate returned to match the FQDN (or)
-    
-    - The EnforceCertificateNameCheck must be disabled
+    - The returned certificate must match the FQDN.
+    - `EnforceCertificateNameCheck` must be disabled.
   
-*	Backend Pool is an Azure Web Apps server
+* The backend pool is an Azure Web Apps server:
 
-    - Check if Azure web app is configured with Ip Based SSL instead of SNI based. If it’s configured as IpBased then this should be changed to SNI.
-    
-    - If the backend is unhealthy due to a certificate failure, we will return a 503. You can verify the health of the backends on port 80 and 443.  If only 443 is unhealthy, this is likely an issue with SSL.  Since the backend is configured to use the FQDN, we know it’s sending SNI.
+    - Check if the Azure web app is configured with IP-based SSL instead of being SNI based. If the web app is configured as IP based, it should be changed to SNI.
+    - If the backend is unhealthy because of a certificate failure, a 503 error message is returned. You can verify the health of the backends on ports 80 and 443. If only 443 is unhealthy, it's likely an issue with SSL. Because the backend is configured to use the FQDN, we know it's sending SNI.
 
-    Using OPENSSL, verify the certificate that is being returned. To do this, connect to the backend using "-servername" and it should return the SNI which needs to match with the FQDN of the backend pool.
+    Use OPENSSL to verify the certificate that's being returned. To do this check, connect to the backend by using `-servername`. It should return the SNI, which needs to match with the FQDN of the backend pool:
+
+    `openssl s_client -connect backendvm.contoso.com:443  -servername backendvm.contoso.com`
 
-    _openssl s_client -connect backendvm.contoso.com:443  -servername backendvm.contoso.com_
-    
 ## Requests sent to the custom domain return a 400 status code
 
 ### Symptom
 
-* You created an Azure Front Door instance, but a request to the domain or frontend host is returning an HTTP 400 status code.
-* You created a DNS mapping for a custom domain to the frontend host that you configured. However, sending a request to the custom domain host name returns an HTTP 400 status code. It doesn't appear to route to the backend that you configured.
+* You created an Azure Front Door instance. A request to the domain or frontend host returns an HTTP 400 status code.
+* You created a DNS mapping for a custom domain to the frontend host that you configured. Sending a request to the custom domain host name returns an HTTP 400 status code. It doesn't appear to route to the backend that you configured.
 
 ### Cause
 
-The problem occurs if you didn't configure a routing rule for the custom domain that was added as the frontend host. A routing rule needs to be explicitly added for that frontend host. That's true even if a routing rule has already been configured for the frontend host under the Azure Front Door subdomain (*.azurefd.net).
+The problem occurs if you didn't configure a routing rule for the custom domain that was added as the frontend host. A routing rule needs to be explicitly added for that frontend host. That's true even if a routing rule was already configured for the frontend host under the Azure Front Door subdomain, which is ***.azurefd.net**.
 
-### Troubleshooting steps
+### Troubleshooting step
 
 Add a routing rule for the custom domain to direct traffic to the selected origin group.
 
@@ -116,7 +118,7 @@ Azure Front Door has a routing rule that redirects HTTP to HTTPS, but accessing
 
 ### Cause
 
-This behavior can happen if you didn't configure the routing rules correctly for Azure Front Door. Basically, your current configuration isn't specific and might have conflicting rules.
+This behavior can happen if you didn't configure the routing rules correctly for Azure Front Door. Your current configuration isn't specific and might have conflicting rules.
 
 ### Troubleshooting steps
 
@@ -125,22 +127,27 @@ This behavior can happen if you didn't configure the routing rules correctly for
 
 ### Symptom
 
-You created an Azure Front Door Standard/Premium instance and configured a frontend host, an origin group with at least one origin in it, and a routing rule that connects the frontend host to the origin group. Your content doesn't seem to be available when a request goes to the configured frontend host because an HTTP 411 status code gets returned.
+You created an Azure Front Door Standard/Premium instance and configured:
 
-Responses to these requests might also contain an HTML error page in the response body that includes an explanatory statement. For example: `HTTP Error 411. The request must be chunked or have a content length`.
+- A frontend host.
+- An origin group with at least one origin in it.
+- A routing rule that connects the frontend host to the origin group.
+
+Your content doesn't seem to be available when a request goes to the configured frontend host because an HTTP 411 status code gets returned.
+
+Responses to these requests might also contain an HTML error page in the response body that includes an explanatory statement. An example is "HTTP Error 411. The request must be chunked or have a content length."
 
 ### Cause
 
-There are several possible causes for this symptom. The overall reason is that your HTTP request isn't fully RFC-compliant. 
+There are several possible causes for this symptom. The overall reason is that your HTTP request isn't fully RFC-compliant.
 
-An example of noncompliance is a `POST` request sent without either a `Content-Length` or a `Transfer-Encoding` header (for example, using `curl -X POST https://example-front-door.domain.com`). This request doesn't meet the requirements set out in [RFC 7230](https://tools.ietf.org/html/rfc7230#section-3.3.2). Azure Front Door would block it with an HTTP 411 response.
+An example of noncompliance is a `POST` request sent without either a **Content-Length** or a **Transfer-Encoding** header. An example would be using `curl -X POST https://example-front-door.domain.com`. This request doesn't meet the requirements set out in [RFC 7230](https://tools.ietf.org/html/rfc7230#section-3.3.2). Azure Front Door would block it with an HTTP 411 response.
 
-This behavior is separate from the Web Application Firewall (WAF) functionality of Azure Front Door. Currently, there's no way to disable this behavior. All HTTP requests must meet the requirements, even if the WAF functionality isn't in use.
+This behavior is separate from the web application firewall (WAF) functionality of Azure Front Door. Currently, there's no way to disable this behavior. All HTTP requests must meet the requirements, even if the WAF functionality isn't in use.
 
 ### Troubleshooting steps
 
 - Verify that your requests are in compliance with the requirements set out in the necessary RFCs.
-
 - Take note of any HTML message body that's returned in response to your request. A message body often explains exactly *how* your request is noncompliant.
 
 ## Next steps
