All Products
Search
Document Center

Server Load Balancer:Add an HTTPS listener

Last Updated:Aug 14, 2025

If your application requires encrypted data transfer, you can create an HTTPS listener to forward requests that use the HTTPS protocol. This listener encrypts traffic between an Application Load Balancer (ALB) instance and clients that initiate SSL or TLS sessions.

Prerequisites

Procedure

This topic describes two methods for creating an HTTPS listener. You can choose a method based on your needs.

  • Create an HTTPS listener: This method lets you customize advanced features, such as mutual authentication.

  • Quickly create an HTTPS listener: This method lets you quickly create a listener by configuring only the listener protocol, listener port, server certificate, TLS security policy, and backend server group.

Create an HTTPS listener

Step 1: Configure the listener

  1. Log on to the Application Load Balancer (ALB) console.

  2. In the top navigation bar, select the region where the instance is deployed.

  3. Use one of the following methods to open the listener configuration wizard.

    • On the Instances page, find the target instance and click Create Listener in the Actions column.

    • On the Instances page, click the ID of the target instance. On the Listener tab, click Create Listener.

  4. In the Configure Listener wizard, set the following parameters and click Next.

    Listener Configuration

    Description

    Listener Protocol

    Select a protocol for the listener.

    In this example, HTTPS is selected.

    Listener Port

    Enter the listener port that is used to receive requests and forward them to backend servers. In this example, 443 is entered. Port 80 is the default port for HTTP and port 443 is the default port for HTTPS.

    The port number must be between 1 and 65535.

    Note

    Within the same ALB instance, listeners of the same protocol cannot use the same port. HTTP and HTTPS listeners cannot use the same port.

    Listener Name

    Enter a name for the listener.

    Tag

    Set Tag Key and Tag Value.

    After you set tags, you can filter listeners by tag on the Listener tab.

    Advanced Settings

    Click Modify to expand Advanced Configuration.

    Enable HTTP/2

    Select whether to enable HTTP/2.

    Idle Connection Timeout Period

    Specify the idle timeout period. Valid values: 1 to 600 seconds. Default value: 15 seconds. If you want to use a larger value, go to Quota Center to request a quota increase.

    If no request is received within the timeout period, Server Load Balancer temporarily breaks the current connection. A new connection is established when the next request is received.

    Note

    This feature does not take effect for HTTP/2 requests.

    Connection Request Timeout

    Specify the request timeout period. Valid values: 1 to 600 seconds. Default value: 60 seconds. If you want to use a larger value, go to Quota Center to request a quota increase.

    If no response is received from the backend server within the timeout period, Server Load Balancer gives up and returns an HTTP 504 error code to the client.

    Data Compression

    Enable this feature to compress specific file types. If this feature is disabled, no files are compressed.

    • Brotli supports all file types.

    • Gzip supports the following file types: text/xml, text/plain, text/css, application/javascript, application/x-javascript, application/rss+xml, application/atom+xml, application/xml, and application/json.

    Note
    • Data compression is triggered only when the Content-Length of the response exceeds 1024 bytes.

    • If a client request supports both Brotli and Gzip, ALB uses Brotli, which is more efficient.

    • If a client supports only Gzip and the file type is not supported by Gzip, ALB does not compress the file.

    Retrieve Client IP

    Enable this feature to allow ALB to retrieve the originating client IP address from the X-Forwarded-For header field. After you enable this feature, you must configure a list of trusted IP addresses.

    • If you set the list of trusted IP addresses to 0.0.0.0/0: Retrieves the leftmost IP address from the X-Forwarded-For request header as the originating client IP address.

    • If you set the list of trusted IP addresses to proxy1 IP;proxy2 IP;..: Retrieves the first IP address from the right that is not in this list as the originating client IP address.

    Scenarios:

    The X-Forwarded-For request header can contain multiple IP addresses, such as X-Forwarded-For: <client-ip-address>, <proxy1>, <proxy2>, …. The leftmost address is the client's IP address. To use the SourceIp matching condition and the QPS (throttling Based On Client Source IP) feature in ALB forwarding rules, enable Find Originating Client IP Address. This allows ALB to find the originating client IP address from the X-Forwarded-For header field. For more information, see Add forwarding rules.

    Note

    Only Standard and WAF-enabled ALB instances support this feature. Basic ALB instances do not.

    Add HTTP Header Fields

    Select the custom HTTP header fields that you want to add:

    • Select whether to enable the X-Forwarded-For header field to obtain the IP address of the client.

      • If you select Add X-Forwarded-For to preserve client IP addresses, ALB can add an X-Forwarded-For header to or remove the X-Forwarded-For header from the request before forwarding the request to a backend server.

        • Add (default)

          If you choose Add, ALB adds the IP address of the last hop to the X-Forwarded-For header in the request before forwarding the request to a backend server. If the request does not contain the X-Forwarded-For header, ALB creates an X-Forwarded-For header whose value is the IP address of the last hop and adds the header to the request. The X-Forwarded-For header in the request may contain multiple IP addresses which are separated by commas (,).

        • Remove

          If you choose Remove, ALB removes the X-Forwarded-For header from the request before forwarding the request to a backend server.

      • If you do not select Add X-Forwarded-For to preserve client IP addresses, ALB does nothing about the X-Forwarded-For header in the request before forwarding the request to a backend server.

      Format:

      X-Forwarded-For: <client-ip-address>, <proxy1>, <proxy2>, …

      Click to see an example about the X-Forwarded-For header in the request that is received by the backend server.

      In this example, the IP address of the last hop is 127.0.0.1.

      Request description

      Sample request

      Select Add X-Forwarded-For to preserve client IP addresses

      Not select Add X-Forwarded-For to preserve client IP addresses

      Add

      Remove

      The request received by ALB does not contain the X-Forwarded-For header.

      GET /index.html HTTP/1.1

      Host: example.com

      X-Forwarded-For: 127.0.0.1

      The X-Forwarded-For header does not exist.

      The X-Forwarded-For header does not exist.

      The request received by ALB contains the X-Forwarded-For header and a client IP address.

      GET /index.html HTTP/1.1

      Host: example.com

      X-Forwarded-For: 127.0.0.2

      X-Forwarded-For: 127.0.0.2, 127.0.0.1

      The X-Forwarded-For header does not exist.

      X-Forwarded-For: 127.0.0.2

      The request received by ALB contains the X-Forwarded-For header and multiple client IP addresses.

      GET /index.html HTTP/1.1

      Host: example.com

      X-Forwarded-For: 127.0.0.2, 127.0.0.3

      X-Forwarded-For: 127.0.0.2, 127.0.0.3, 127.0.0.1

      The X-Forwarded-For header does not exist.

      X-Forwarded-For: 127.0.0.2, 127.0.0.3

      For more information about how to enable ALB to preserve client IP addresses, see Enable ALB to preserve client IP addresses and pass them to backend servers.

    • Add the SLB-ID header field to obtain the ID of the SLB instance.

    • Add the X-Forwarded-Proto header field to obtain the listener protocol of the instance.

    • Add the X-Forwarded-Port header field to obtain the listener port of the SLB instance.

    • Add the X-Forwarded-Host header field to obtain the domain name used by the client to access the SLB instance.

    • Add the X-Forwarded-Client-srcport header field to obtain the port of the client that accesses the SLB instance.

    • Add the X-Forwarded-Clientcert-subjectdn header field to obtain the owner information of the client certificate used to access the SLB instance.

    • Add the X-Forwarded-Clientcert-issuerdn header field to obtain the issuer information of the client certificate used to access the SLB instance.

    • Add the X-Forwarded-Clientcert-fingerprint header field to obtain the fingerprint of the client certificate used to access the SLB instance.

    • Add the X-Forwarded-Clientcert-clientverify header field to obtain the verification result of the client certificate used to access the SLB instance.

    Note
    • When your backend server obtains HTTP header fields, we recommend that you follow HTTP protocol specifications and ignore the case of the keys in HTTP header fields.

      • The first letter of the X-Forwarded-For header field that ALB passes to the backend server is always uppercase.

      • For other added HTTP header fields, if a client request carries a specific header field, ALB passes it to the backend server in the format of the header field in the client request. Otherwise, ALB passes the header field to the backend server in the format shown in the preceding table.

    • When you enable X-Forwarded-Clientcert-subjectdn, X-Forwarded-Clientcert-issuerdn, X-Forwarded-Clientcert-fingerprint, and X-Forwarded-Clientcert-clientverify, you cannot set the custom HTTP header name to any of the following fields: slb-id, slb-ip, x-forwarded-for, x-forwarded-proto, x-forwarded-eip, x-forwarded-port, x-forwarded-client-srcport, x-forwarded-host, connection, upgrade, content-length, transfer-encoding, keep-alive, te, host, cookie, remoteip, or authority.

    QUIC Update

    Select whether to enable QUIC upgrade. If you enable QUIC upgrade, select a created QUIC listener from the Associated QUIC Listener drop-down list.

Step 2: Configure SSL certificates

When you create an HTTPS listener, you must configure SSL certificates to ensure that your services are encrypted and authenticated by a certificate authority (CA). The following table describes the certificates that you can configure for ALB.

Certificate

Description

Required for one-way authentication

Required for mutual authentication

Server Certificate

Verifies the identity of the server.

Your browser checks whether the certificate sent by the server is issued by a trusted CA. For more information, see What is an SSL certificate?.

Yes, it is.

You can purchase or upload a server certificate in Certificate Management Service. ALB retrieves and uses the certificate from Certificate Management Service.

Yes, it is.

You can purchase or upload a server certificate in Certificate Management Service. ALB retrieves and uses the certificate from Certificate Management Service.

CA Certificate

The server uses the CA certificate to verify the signature of the client certificate. If the verification fails, the connection is rejected.

Note

A client certificate is used to prove the identity of the client when communicating with a server. This certificate is installed only on the client.

No, it is not.

Yes, it is.

You can purchase or upload a CA certificate in Certificate Management Service. ALB retrieves and uses the certificate from Certificate Management Service.

Note
  • The upload, loading, and verification of a new certificate require some time. After a new certificate is applied to an instance that uses HTTPS, the certificate takes some time to take effect. The effective period is typically one minute and does not exceed three minutes.

  • To access multiple domain names or attach multiple server certificates, you can add an extension certificate to the HTTPS listener after it is configured.

  1. In the SSL Certificate wizard, select a server certificate.

    If no server certificates are available, click Create SSL Certificate in the drop-down list to go to the Certificate Management Service console. In the console, you can purchase or upload a server certificate.

  2. Optional: Turn on Enable Mutual Authentication and select a source for the CA certificate.

    • Set CA Certificate Source to Issued By Alibaba Cloud and select a CA certificate from the Select Default CA Certificate drop-down list.

      If no CA certificates are available, click Purchase CA Certificate in the drop-down list to create a new CA certificate.

    • Set CA Certificate Source to Not Issued By Alibaba Cloud and select a CA certificate from the Select Default CA Certificate drop-down list.

      If no self-signed CA certificates are available, click Upload Self-signed CA Certificate in the drop-down list. On the Certificate Application Repository page, create a repository and set its data source to Upload CA Certificate. Then, upload a self-signed root CA certificate or a self-signed intermediate CA certificate from the repository.

    Note
    • Only Standard and WAF-enabled ALB instances support mutual authentication. Basic ALB instances do not.

    • If you enable mutual authentication and later need to disable it, perform the following steps.

      1. On the Instances page, click the ID of the target instance.

      2. On the Listener tab, click the ID of the target HTTPS listener.

      3. On the Listener Details tab, turn off the mutual authentication switch in the SSL Certificate section.

  3. Select a TLS Security Policy and click Next.

    If no TLS security policies are available, click Create TLS Security Policy in the drop-down list.

    A TLS security policy contains the supported TLS protocol versions and cipher suites for HTTPS.

Step 3: Select a server group

In the Server Group wizard, select a server group, view the information about the backend servers, and then click Next.

Step 4: Review

On the Confirm page, review the configurations and click Submit.

Quickly create an HTTPS listener

If you choose to quickly create a listener, you need to configure only the listener protocol, listener port, server certificate, TLS security policy, and backend server group.

  1. Log on to the Application Load Balancer (ALB) console.

  2. In the top navigation bar, select the region where the ALB instance is deployed.

  3. On the Instances page, find the target instance and click its ID.

  4. Click the Listener tab, and on the Listener tab, click Quick Create Listener.

  5. In the Quick Create Listener dialog box, set the following parameters and click OK.

    Listener Configuration

    Description

    Select Listener Protocol

    Select a listener protocol. In this example, HTTPS is selected.

    Listener Port

    Specify the listener port. This is the frontend port that receives requests and forwards them to backend servers.

    You can click a common port for quick selection or enter a custom port number. The valid port range is 1 to 65535.

    Select Server Certificate

    Select a server certificate from the drop-down list.

    If no server certificates are available, click Create Certificate in the drop-down list to create a new one. For more information, see Purchase a commercial certificate and Upload an SSL certificate.

    Select Resource Group

    Select the resource group that contains the server group.

    TLS Security Policy

    If no TLS security policies are available, click Create TLS Security Policy in the drop-down list to create one. For more information, see TLS security policies.

    Server Group

    Select the server group type and the backend servers.

FAQ

What TLS protocol versions does HTTPS support?

TLS 1.0, TLS 1.1, TLS 1.2, and TLS 1.3. For more information, see TLS security policies.

Can a backend server get the protocol version of a client request to an HTTPS listener?

Yes, it can.

What is the HTTP protocol version that an HTTPS listener uses to access a backend server?

  • If the client request uses HTTP/1.1 or HTTP/2, the Layer 7 listener uses HTTP/1.1 to access the backend server.

  • If the client request uses a protocol other than HTTP/1.1 or HTTP/2, the Layer 7 listener uses HTTP/1.0 to access the backend server.

What are the rules for using a wildcard certificate for an ALB listener?

When you configure a wildcard certificate for an HTTPS listener, take note of the following limits:

  • When you select a wildcard certificate, ALB can identify certificates that contain only one wildcard (*), which must be on the leftmost side of the domain name. For example, ALB can identify *.example.com and *test.example.com, but cannot identify test*.example.com.

  • Requirements for wildcard certificates:

    • Levels of wildcard domain names: A wildcard domain name can match specific domain names that are of the same level as the wildcard domain name. For example, *.example.com can match test.example.com but cannot match test.test.example.com, which is one level lower than the wildcard domain name.

    • Internationalized domain names (IDNAs):

      • If the wildcard character is the only wildcard character and on the leftmost side of the wildcard domain name, IDNAs can match the wildcard domain name. For example, xn--fsqu00a.example.com can match *.example.com.

      • If the wildcard character is not on the leftmost side of the wildcard domain name, IDNAs cannot match the wildcard domain name. For example, xn--fsqu00atest.example.com cannot math *test.example.com.

    • Match scope: The wildcard character (*) can match digits, letters, and hyphens (-). For example, *.example.com can match test.example.com but cannot match test_test.example.com.

What is the timeout period for an HTTPS session ticket?

The timeout period for an HTTPS session ticket is 300 seconds.

References

Tutorials

API reference