Updated on 2025-09-11 GMT+08:00

Adding a QUIC Listener

Scenarios

You can add a QUIC listener to forward requests. The Quick UDP Internet Connection (QUIC) is a UDP-based protocol at the transport layer. It improves congestion control and does not depend on kernel protocols.

QUIC features low latency and avoids head-of-line blocking. It makes video and page loading faster, improving network performance and data security.

Constraints

  • QUIC listeners can be only added to application load balancers.

    QUIC listeners will be available in more regions. See details on the management console.

  • QUIC listeners can only be associated with HTTP or HTTPS backend server groups.
  • The backend server group associated with a QUIC listener does not support the source IP hash algorithm.
  • Only iQUIC (HTTP/3) is supported.
  • QUIC listeners do not support the following HTTP headers:
    • X-Forwarded-For-Port: Rewrite this header to transfer the client port.
    • X-Real-IP: Rewrite this header to transfer the client IP address.
  • QUIC listeners cannot route requests based on CIDR blocks.

Procedure

  1. Go to the load balancer list page.
  2. On the displayed page, locate the load balancer and click its name.
  3. On the Listeners tab, click Add Listener and configure parameters based on Table 1.
    Table 1 Parameters for configuring a QUIC listener

    Parameter

    Description

    Frontend Protocol

    Specifies the protocol that will be used by the load balancer to receive requests from clients.

    Select QUIC.

    Listening Port

    Specifies the port that will be used by the load balancer to receive requests from clients.

    The port number ranges from 1 to 65535.

    Name (Optional)

    Specifies the listener name.

    Transfer Client IP Address

    This option is enabled for dedicated load balancers by default.

    When you use a QUIC listener to forward requests, you can use the X-Forwarded-For header to transfer client IP addresses. The first IP address recorded in the X-Forwarded-For header is the client IP address.

    For details, see Using Dedicated Load Balancers to Transfer Client IP Address.

    Advanced Forwarding

    Specifies whether to enable advanced forwarding. This option allows you to configure advanced forwarding policies to forward requests to different backend server groups.

    For more information, see Advanced Forwarding.

    Access Control

    Specifies how access to the listener is controlled. For details, see What Is Access Control?

    All IP addresses is selected for access control by default.

    You can select Whitelist or Blacklist and choose an IP address group.
    • Whitelist: Only IP addresses in the whitelist can access the listener. Requests from the IP addresses or CIDR blocks specified in the IP address group will be forwarded by the listener.

      Access control policies only take effect for new connections, but not for existing ones. If a whitelist is configured for a listener but IP addresses that are not in the whitelist can access the backend server associated with the listener, it may be caused by a persistent connection between the client and the backend server. To deny IP addresses that are not in the whitelist from accessing the listener, the persistent connection between the client and the backend server needs to be disconnected.

    • Blacklist: IP addresses in the blacklist are not allowed to access the listener. Requests from the IP addresses or CIDR blocks specified in the IP address group will not be forwarded by the listener.

    Configure Certificate

    Server Certificate

    Specifies a server certificate that will be used to authenticate the server. One-way authentication is used by default for QUIC listeners.

    Both the certificate and private key are required. For details, see Adding a Certificate.

    SNI

    Specifies whether to enable SNI. Server Name Indication (SNI) is an extension to TLS. It allows clients to specify which domain name of a listener they are trying to connect in the first request. Once receiving the request, the load balancer searches for the certificate based on the domain name.

    The client includes the domain name in the initial SSL handshake. Once receiving the request, the load balancer searches for the certificate based on the domain name.

    If an SNI certificate is found, this certificate will be used for authentication.

    If no SNI certificates are found, the server certificate is used for authentication.

    For details, see Using SNI Certificates for Access Through Multiple Domain Names.

    SNI Certificate

    Specifies one or more certificates associated with the domain name when the frontend protocol is QUIC and SNI is enabled.

    You can only select the server certificate with SNI domain names.

    More (Optional)

    Data Compression

    Specifies whether to enable the data compression option. If you do not enable this option, files will not be compressed.

    • Brotli can compress all files.
    • Gzip can be configured to compress the following content types:

      text/xml, text/plain, text/css, application/javascript, application/x-javascript, application/rss+xml, application/atom+xml, application/xml, application/json

    NOTE:

    This option is available in certain regions. You can see which regions support this option on the console.

    Retry on Other Backend Servers

    Specifies whether to allow the load balancer to attempt to establish connections with other backend servers in the same backend server group, if it fails to connect to a backend server.

    If all four retries fail, error code 502 or 504 will be returned.

    • Connection error: If the load balancer cannot connect to a backend server due to an error, such as a failed or rejected connection, error code 502 will be returned.
    • Request timeout: If the backend server does not respond within the timeout duration, error code 504 will be returned.
      • Connection timeout: The load balancer attempts to connect to a backend server but fails within the timeout duration.
      • Response timeout: The load balancer has sent a request to a backend server but does not receive a response within the timeout duration.

    Note: If there is an error after the load balancer forwards a request using a non-idempotent request method, such as POST, PATCH, or DELETE, the load balancer will not retry the request.

    NOTE:

    This option is available in certain regions. You can see which regions support this option on the console.

    Timeout Durations

    You can configure and modify timeout durations for your listeners to meet varied demands.

    • Idle Timeout (s)

      Specifies the length of time for a connection to keep alive, in seconds. If no request is received within this period, the load balancer closes the connection and establishes a new one with the client when the next request arrives.

      The idle timeout duration ranges from 0 to 4000.

    • Request Timeout (s)

      Specifies the length of time (in seconds) that a load balancer is willing to wait for a client request to finish. The load balancer terminates the connection if a request takes too long to complete.

      The request timeout duration ranges from 1 to 300.

    • Response Timeout (s)

      Specifies the length of time (in seconds) after which the load balancer sends a 504 Gateway Timeout error to the client if the load balancer receives no response from the backend server after routing a request to the backend server and receives no response after attempting to route the same request to other backend servers.

      If sticky session is enabled and the load balancer receives no response from the backend server within the response timeout duration, the load balancer returns a 504 Gateway Timeout error to the client directly.

      The response timeout duration ranges from 1 to 300.

    Maximum New Connections per AZ

    Specifies the maximum number of new connections that a listener can handle per second in each AZ. Unlimited is selected by default. You can select Limit request to set the maximum number of new connections.

    The value ranges from 1 to 1000000. If the value is greater than the number defined in the load balancer specifications, the latter is used as the limit.

    NOTE:

    This option is available in certain regions. You can see which regions support this option on the console.

    Maximum Concurrent Connections per AZ

    Specifies the maximum number of concurrent connections that a listener can handle per second in each AZ. Unlimited is selected by default. You can select Limit request to set the maximum number of concurrent connections.

    The value ranges from 1 to 1000000. If the value is greater than the number defined in the load balancer specifications, the latter is used as the limit.

    Reducing the concurrent connection limit does not interrupt established connections.

    NOTE:

    This option is available in certain regions. You can see which regions support this option on the console.

    Tag

    Adds tags to the listener. Each tag is a key-value pair, and the tag key is unique.

    NOTE:

    If your organization has configured tag policies for ELB, add tags to load balancers based on the tag policies. If you add a tag that does not comply with the tag policies, load balancers may fail to be created. Contact your organization administrator to learn more about tag policies.

    Description

    Provides supplementary information about the listener.

    You can enter a maximum of 255 characters.

    HTTP Headers

    Select HTTP headers as needed.

    • Transferring client information
      • Rewrite X-Forwarded-Host to transfer the client domain name.
    • Transferring load balancer information
      • Rewrite X-Forwarded-Proto to transfer the listener protocol.
      • Rewrite X-Forwarded-ELB-IP to transfer the load balancer EIP.
      • Rewrite X-Forwarded-Port to transfer the listener port.
      • Rewrite X-Forwarded-ELB-ID to transfer the load balancer ID.

    For details, see HTTP Headers.

    NOTE:

    More HTTP headers are coming soon. See the available HTTP headers on the management console.

  4. Click Next: Configure Request Routing Policy.
    1. You are advised to select an existing backend server group.
    2. You can also select Create new to create a backend server group.
      1. Configure the backend server group based on Table 3.
      2. Click Next: Add Backend Server. Add backend servers and configure the health check for the backend server group.

        For details about how to add backend servers, see Backend Server Overview. For the parameters required for configuring a health check, see Table 4.

  5. Click Next: Confirm.
  6. Confirm the configuration and click Submit.