You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/application-gateway/application-gateway-faq.yml
+5-5Lines changed: 5 additions & 5 deletions
Original file line number
Diff line number
Diff line change
@@ -65,7 +65,7 @@ sections:
65
65
66
66
- question: What are the settings for Keep-Alive timeout and TCP idle timeout?
67
67
answer: |
68
-
*Keep-Alive timeout* governs how long the Application Gateway waits for a client to send another HTTP request on a persistent connection before reusing it or closing it. *TCP idle timeout* governs how long a TCP connection is kept open if there is no activity.
68
+
*Keep-Alive timeout* governs how long the Application Gateway waits for a client to send another HTTP request on a persistent connection before reusing it or closing it. *TCP idle timeout* governs how long a TCP connection is kept open if there's no activity.
69
69
70
70
The *Keep-Alive timeout* in the Application Gateway v1 SKU is 120 seconds and in the v2 SKU it's 75 seconds. The *TCP idle timeout* is a 4-minute default on the frontend virtual IP (VIP) of both v1 and v2 SKU of Application Gateway. You can configure the TCP idle timeout value on v1 and v2 Application Gateways to be anywhere between 4 minutes and 30 minutes. For both v1 and v2 Application Gateways, you need to navigate to the public IP of the Application Gateway and change the TCP idle timeout under the "Configuration" blade of the public IP on Portal. Changing the value of the private IP address isn't supported. You can set the TCP idle timeout value of the public IP through PowerShell by running the following commands:
71
71
@@ -78,10 +78,10 @@ sections:
78
78
For HTTP/2 connections to the frontend IP address on Application Gateway v2 SKU, the idle timeout is set to 180 seconds and is non-configurable.
79
79
80
80
- question: Can I rename my Application Gateway resource?
81
-
answer: No. There is no way to rename an Application Gateway resource. You must create a new resource with a different name.
81
+
answer: No. There's no way to rename an Application Gateway resource. You must create a new resource with a different name.
82
82
83
83
- question: Is there a way to restore an Application Gateway and its public IP if it has been deleted?
84
-
answer: No. There is no way to restore an Application Gateway resource or its public IP once deleted. You must create a new resource.
84
+
answer: No. There's no way to restore an Application Gateway resource or its public IP once deleted. You must create a new resource.
85
85
86
86
- question: Does the IP or DNS name change over the lifetime of the application gateway?
87
87
answer: In Application Gateway V1 SKU, the VIP can change if you stop and start the application gateway. But the DNS name associated with the application gateway doesn't change over the lifetime of the gateway. Because the DNS name doesn't change, you should use a CNAME alias and point it to the DNS address of the application gateway. In Application Gateway V2 SKU, IP addresses are static, so the IP address and DNS name won't change over the lifetime of the application gateway.
@@ -131,7 +131,7 @@ sections:
131
131
132
132
- question: Is Application Gateway v1 SKU supported?
133
133
answer: |
134
-
Yes. The Application Gateway v1 SKU continues to be supported. However, it is strongly recommended to move to v2 to take advantage of the feature updates in that SKU. For more information on the differences between v1 and v2 features, see [Autoscaling and Zone-redundant Application Gateway v2](application-gateway-autoscaling-zone-redundant.md). You can manually migrate Application Gateway v1 sku deployments to v2 by following our [v1-v2 migration document](migrate-v1-v2.md).
134
+
Yes. The Application Gateway v1 SKU continues to be supported. However, it's strongly recommended to move to v2 to take advantage of the feature updates in that SKU. For more information on the differences between v1 and v2 features, see [Autoscaling and Zone-redundant Application Gateway v2](application-gateway-autoscaling-zone-redundant.md). You can manually migrate Application Gateway v1 sku deployments to v2 by following our [v1-v2 migration document](migrate-v1-v2.md).
135
135
136
136
- question: Does Application Gateway V2 support proxying requests with NTLM authentication?
137
137
answer: No. Application Gateway V2 doesn't support proxying requests with NTLM authentication.
@@ -192,7 +192,7 @@ sections:
192
192
193
193
- question: Can I change the virtual network or subnet for an existing Application Gateway?
194
194
answer: |
195
-
You can move an Application Gateway across subnets within the same virtual network only. It is supported with V1 with public and private frontend, and V2 with public frontend only. It is also important to note that the Application Gateway should be in a *Stopped* state to perform this action. Keep in mind that stopping/starting V1 changes the public IP. This operation can only be done using Azure PowerShell and Azure CLI by running the following commands:
195
+
You can move an Application Gateway across subnets within the same virtual network only. It's supported with V1 with public and private frontend, and V2 with public frontend only. It's also important to note that the Application Gateway should be in a *Stopped* state to perform this action. Keep in mind that stopping/starting V1 changes the public IP. This operation can only be done using Azure PowerShell and Azure CLI by running the following commands:
0 commit comments