หมายเหตุ
การเข้าถึงหน้านี้ต้องได้รับการอนุญาต คุณสามารถลอง ลงชื่อเข้าใช้หรือเปลี่ยนไดเรกทอรีได้
การเข้าถึงหน้านี้ต้องได้รับการอนุญาต คุณสามารถลองเปลี่ยนไดเรกทอรีได้
Note
We recommend that you use the Azure Az PowerShell module to interact with Azure. To get started, see Install Azure PowerShell. To learn how to migrate to the Az PowerShell module, see Migrate Azure PowerShell from AzureRM to Az.
A listener is a logical entity that checks for incoming connection requests by using the port, protocol, host, and IP address. When you configure the listener, you must enter values for these settings that match the corresponding values in the incoming request on the gateway.
When you create an application gateway by using the Azure portal, you also create a default listener by choosing the protocol and port for the listener. You can choose whether to enable HTTP2 support on the listener. After you create the application gateway, you can edit the settings of that default listener (appGatewayHttpListener) or create new listeners.
Listener type
When you create a new listener, you choose between basic and multi-site. The choice depends on whether routing depends on the host name in the incoming request.
| Routing depends on the host name | Listener type | Behavior |
|---|---|---|
| No | Basic | Accept and forward all requests for any domain to backend pools. Learn how to create an application gateway with a basic listener. |
| Yes | Multi-site | Forward requests to different backend pools based on the host header or host names. Application Gateway relies on HTTP 1.1 host headers to host more than one website on the same public IP address and port. To differentiate requests on the same port, you must specify a host name that matches the incoming request. |
To learn more about multi-site listeners, see hosting multiple sites using Application Gateway.
Order of processing listeners
For the v1 SKU, requests are matched according to the order of the rules and the type of listener. If a rule with a basic listener comes first in the order, it processes first and accepts any request for that port and IP combination. To avoid this behavior, configure the rules with multi-site listeners first and push the rule with the basic listener to the last in the list.
For the v2 SKU, rule priority defines the order in which listeners are processed. Define wildcard and basic listeners with a priority number greater than site-specific and multi-site listeners. This configuration ensures site-specific and multi-site listeners execute before the wildcard and basic listeners.
The following table summarizes how processing order is determined in each SKU.
| SKU | What determines the order | Recommended configuration |
|---|---|---|
| v1 | The order of the rules and the type of listener. A rule with a basic listener that comes first in the order processes first and accepts any request for that port and IP combination. | Configure the rules with multi-site listeners first, and push the rule with the basic listener to the last position in the list. |
| v2 | Rule priority. | Define wildcard and basic listeners with a priority number greater than the number used for site-specific and multi-site listeners, so that the site-specific and multi-site listeners execute first. |
Frontend IP address
Choose the frontend IP address that you plan to associate with this listener. The listener listens to incoming requests on this IP.
Choose a public frontend IP address when clients reach the application behind this listener over the internet. Choose a private frontend IP address for an internal endpoint that isn't exposed to the internet, such as an internal line-of-business application or a tier of a multitier application that still requires load distribution, session stickiness, or TLS termination. For the supported combinations, see Frontend IP address configuration.
Note
Application Gateway frontend supports dual-stack IP addresses. You can create up to four frontend IP addresses: two IPv4 addresses (public and private) and two IPv6 addresses (public and private).
Frontend port
Associate a frontend port. You can select an existing port or create a new one. Choose any value from the allowed range of ports. You can use not only well-known ports, such as 80 and 443, but any allowed custom port that's suitable. The same port can be used for public and private listeners.
Port 80 is the typical choice for an HTTP listener, and port 443 is the typical choice for an HTTPS listener. Use a custom port when your application requires one, and confirm that the value falls within the allowed range for your SKU, because the supported range differs between the v1 and v2 SKUs.
Note
When using private and public listeners with the same port number, your application gateway changes the "destination" of the inbound flow to the frontend IPs of your gateway. Hence, depending on your Network Security Group's configuration, you may need an inbound rule with Destination IP addresses as your application gateway's public and private frontend IPs.
Inbound Rule:
- Source: (as per your requirement)
- Destination IP addresses: Public and Private frontend IPs of your application gateway.
- Destination Port: (as per listener configuration)
- Protocol: TCP
Outbound Rule: (no specific requirement)
Protocol
Choose HTTP or HTTPS. Choose HTTPS when traffic between the client and the application gateway must be encrypted, which also lets the gateway offload the encryption and decryption work so that your backend servers aren't burdened by TLS computation overhead. Choose HTTP when that encryption isn't required for the traffic that this listener accepts.
If you choose HTTP, the traffic between the client and the application gateway is unencrypted.
Choose HTTPS if you want TLS termination or end-to-end TLS encryption. The traffic between the client and the application gateway is encrypted and the TLS connection will be terminated at the application gateway. If you want end-to-end TLS encryption to the backend target, you must choose HTTPS within backend HTTP setting as well. This ensures that traffic is encrypted when application gateway initiates a connection to the backend target.
To configure TLS termination, a TLS/SSL certificate must be added to the listener. This allows the Application Gateway to decrypt incoming traffic and encrypt response traffic to the client. The certificate provided to the Application Gateway must be in Personal Information Exchange (PFX) format, which contains both the private and public keys.
Note
When using a TLS certificate from Key Vault for a listener, you must ensure your Application Gateway always has access to that linked key vault resource and the certificate object within it. This enables seamless operations of TLS termination feature and maintains the overall health of your gateway resource. If an application gateway resource detects a misconfigured key vault, it automatically puts the associated HTTPS listener(s) in a disabled state. Learn more.
Supported certificates
See Overview of TLS termination and end to end TLS with Application Gateway.
Additional protocol support
HTTP/2 support
Application Gateway supports the HTTP/2 protocol for clients that connect to application gateway listeners. Communication to backend server pools always uses HTTP/1.1. By default, HTTP/2 support is disabled. The following Azure PowerShell code snippet shows how to enable this support:
$gw = Get-AzApplicationGateway -Name test -ResourceGroupName hm
$gw.EnableHttp2 = $true
Set-AzApplicationGateway -ApplicationGateway $gw
Important
When you create an application gateway resource through the Azure portal, the default option for HTTP2 is enabled. You can choose Disabled during creation, and re-enable HTTP/2 support by selecting Enabled under HTTP2 in Application gateway > Configuration in the Azure portal.
In instances where a client doesn't support HTTP/2, the connection uses HTTP/1.1. Enabling HTTP/2 doesn't disable HTTP/1.1; it allows support for both.
Note
Application Gateway only supports HTTP/2 over TLS (HTTPS listeners). Application Gateway doesn't support HTTP/2 Cleartext (h2c) protocol upgrade attempts from HTTP/1.1 and returns a 403 Forbidden error. Clients that attempt h2c upgrades should use native HTTP/2 connections over HTTPS or remain on HTTP/1.1.
HTTP/3 (QUIC) support
Important
HTTP/3 support in Azure Application Gateway is currently in preview. While in preview, functionality, availability, and other aspects of this feature might change in response to feedback.
This preview version is provided without a service level agreement, and isn't recommended for production workloads. Certain features might not be supported or can have constrained capabilities.
For more information, see Supplemental Terms of Use for Microsoft Azure Previews.
Application Gateway supports HTTP/3 only for client connections that use Basic listeners. An HTTP/3-enabled listener can also accept HTTP/1.1 or HTTP/2 traffic from clients. Communication from Application Gateway to backend server pools continues to use HTTP/1.1.
HTTP/3 support is disabled by default.
How HTTP/3 support is advertised
Application Gateway advertises HTTP/3 support by using the Alt-Svc HTTP response header. When you enable HTTP/3 on a listener, Application Gateway includes the following Alt-Svc header in responses.
Alt-Svc: h3=":<listener-port>"; ma=86400
When you disable HTTP/3, Application Gateway doesn't include the Alt-Svc header.
Clients that support HTTP/3 can use the advertised service to establish a QUIC connection on the listener port. Clients that don't support HTTP/3 continue to use HTTP/2 or HTTP/1.1 over TCP.
WebSocket support
WebSocket support is enabled by default. There's no user-configurable setting to enable or disable it. You can use WebSockets with both HTTP and HTTPS listeners.
Custom error pages
You can define custom error pages for different response codes that Application Gateway returns. You can configure error pages for the response codes 400, 403, 405, 408, 500, 502, 503, and 504. Use global-level or listener-specific error page configuration to set them granularly for each listener. For more information, see Create Application Gateway custom error pages.
Note
Application Gateway passes along an error from the backend server to the client without modifying it.
TLS policy
You can centralize TLS/SSL certificate management and reduce encryption-decryption overhead for a backend server farm. Centralized TLS handling also lets you specify a central TLS policy that suits your security requirements. You can choose a predefined or custom TLS policy.
You configure the TLS policy to control TLS protocol versions. You can configure an application gateway to use a minimum protocol version for TLS handshakes from TLS 1.0, TLS 1.1, TLS 1.2, and TLS 1.3. By default, SSL 2.0 and 3.0 are disabled and aren't configurable. For more information, see Application Gateway TLS policy overview.
After you create a listener, you associate it with a request-routing rule. That rule determines how requests that the listener receives are routed to the back end.