All Products
Search

This Product

    Global Accelerator:Global Accelerator FAQ

    Document Center

    Global Accelerator:Global Accelerator FAQ

    Last Updated:Sep 21, 2026

    This topic provides answers to frequently asked questions about Global Accelerator (GA).

    What are the main use cases for GA?

    GA can be used to accelerate access to Office Automation (OA) systems, internet applications, and game servers. For more information, see Scenarios.

    Can GA accelerate access to backend services deployed in another Alibaba Cloud account?

    Not directly.

    If your backend service is deployed on Alibaba Cloud by using an Alibaba Cloud account that is different from the one that you use to activate GA, you can still use GA. When you configure GA, note the following:

    • The account used for GA must have an active enhanced or premium acceleration bandwidth plan.

    • When you configure the endpoint group, specify that the backend service is not deployed on Alibaba Cloud.

    Can clients directly use the CNAME of a GA instance to access backend services?

    No.

    The GA CNAME is used only to identify the origin server of the backend service and does not have an ICP filing. Clients cannot use the GA CNAME to directly accelerate access to the backend service.

    If you want to use the GA CNAME to accelerate access to a backend service, you can add a CNAME record on your DNS platform to map the domain name of the backend service to the GA CNAME. For more information, see Accelerate access to backend services that are associated with a specific domain name.

    Does the CNAME of a GA instance support region-specific DNS resolution?

    Yes.

    You can configure a CNAME record on your DNS platform to map the domain name to the GA CNAME. When a client accesses the backend service by using the domain name, GA automatically resolves the domain name to the accelerated IP address corresponding to the client's region.

    How are GA accelerated IP addresses allocated, and how should clients connect?

    If you select Elastic IP Address (EIP) as the accelerated IP address type, GA allocates accelerated IP addresses separately for each acceleration region. Different regions use different IP addresses. We recommend that you add a CNAME record for your business domain name and point it to the CNAME provided by GA. This allows GA to perform DNS-based traffic routing and reduces the effort required to maintain IP addresses for individual regions. You can also use A records to connect to GA, but you must maintain these records and manage failover yourself. Using a CNAME does not guarantee that configuration changes have no impact on access. DNS caches, time-to-live (TTL) values, and existing connections can affect how changes take effect.

    If your application requires a common set of IP addresses worldwide and automatic access through nearby access points, select Anycast Elastic IP Address (Anycast EIP) as the accelerated IP address type. GA provides two Anycast EIPs, and you do not need to configure acceleration areas. Access points in the Chinese mainland are currently not supported. Clients in the Chinese mainland connect through Hong Kong, China. If clients must hardcode IP addresses or configure IP allowlists, check whether the relevant IP addresses will be retained and assess the impact before changing the instance or acceleration region configuration.

    How long does it take for DNS record changes to take effect in GA?

    When an endpoint uses a custom domain name, the time for DNS record changes to take effect depends on the following two factors:

    • DNS server cache duration: the TTL configured for the DNS record.

    • GA cache duration: GA retrieves DNS records every 15 seconds by default.

    Does GA support processing fragmented TCP and UDP packets?

    No.

    Can I use ICMP ping or TCPing to test the acceleration performance of a UDP or TCP listener?

    No.

    GA supports the proxy response mechanism. ICMP Ping and TCPing requests are responded to and closed in the acceleration region and are not passed to the backend servers. ICMP Ping and TCPing can be used to test the network connectivity between the client and the acceleration region, but cannot be used to test the latency.

    For instructions on testing acceleration performance, see Test the acceleration performance of GA.

    How many GA instances can I create with a single Alibaba Cloud account?

    By default, you can create up to 10 standard GA instances. On the Quota Management page, request a quota increase.

    No quota is imposed on basic GA instances.

    Can I use GA if my client cannot access the internet?

    No.

    To connect to GA, clients must have access to the internet.

    What is the minimum bandwidth that I can allocate to a single GA acceleration region?

    • If the accelerated IP address type is Elastic IP Address: 2 Mbps.

    • If the accelerated IP address type is Anycast Elastic IP Address: 200 Mbps.

    Does GA have a caching mechanism?

    No.

    Why can clients not access backend services after I configure a basic GA instance?

    How do I verify that the IPv6 translation feature of GA works?

    If a web service uses the GA IPv6 Translation Service, you can run the curl command on an IPv6 client to access the backend IPv4 web service and verify that the IPv6 Translation Service works. The following steps describe how to perform the test:

    Note

    This topic uses Alibaba Cloud Linux 2 as an example. Test commands may vary based on the operating system. For more information, see the documentation of your operating system.

    1. In the GA acceleration area, open the command-line interface (CLI) of the IPv6 client.

    2. Run the following command to test whether the IPv6 client can access the backend IPv4 web service.

      curl -6 -g http://[<GA-accelerated-IP>]

      The test result indicates that the IPv6 client can access the backend IPv4 web service through the accelerated IP address.

      
[root@iZ2xxx ~]# curl -6 -g http://[2408:4xxx2]
This is ipv6 access ipv4 web test.
[root@iZ2xxx ~]#

    Why does the IPv6 translation feature of GA fail to take effect?

    The GA IPv6 Translation Service may fail for several reasons. Check the following:

    • Check whether the Global Accelerator configuration is complete.

      A complete configuration must include an acceleration area, a listener (for standard GA instances), an endpoint group, and an endpoint.

    • Check whether the client supports IPv6 access over the internet.

      You can run the ping command to test the accelerated IP address over IPv6. If the client does not support IPv6 access over the internet, enable IPv6 on the client and make sure that it has IPv6 internet connectivity.

    • If you provide services by using a domain name, check whether DNS resolution is configured for the domain name.

      You can run a command such as dig to check the DNS resolution information. Check whether an AAAA record or a CNAME record is added. An AAAA record specifies an IPv6 accelerated IP address. A CNAME record specifies a CNAME for acceleration. For more information, see Configure DNS settings.

    • If you add a CNAME record for DNS resolution, check whether the client region is included in the acceleration area.

      The CNAME of a GA instance is region-specific and affected by the acceleration area configuration. Cross-region access may fail. For example, if the acceleration area includes only regions in the Chinese mainland, the CNAME cannot be resolved from outside the Chinese mainland. We recommend that you add an acceleration area outside the Chinese mainland or switch to an AAAA record.

    • Check whether security policies or firewalls are configured for your website.

      If security policies are configured on your origin server, make sure that they allow traffic from the egress public IP addresses of GA endpoints.

    • Due to varying DNS synchronization times and detection mechanisms, some third-party IPv6 detection websites may fail. In this case, you can access the website from an IPv6 client to check whether IPv6 works as expected.

    Why can clients not access backend services after I configure a standard GA instance?

    If your application cannot connect to a backend service through GA after configuration, check the following:

    • Check whether the backend service is working as expected.

      Access your backend service directly. If you cannot access the backend service, troubleshoot the origin server.

    • If you use a CNAME record for DNS resolution, check whether the client region is added as a GA acceleration area.

      The CNAME of a GA instance is region-specific and depends on the acceleration area configuration. Cross-region access may fail.

      For example, if the acceleration area includes only regions outside the Chinese mainland (excluding Hong Kong (China)), the CNAME record cannot take effect in the Chinese mainland, which causes access failures for clients in the Chinese mainland. You can use one of the following solutions:

      • Solution 1: Configure intelligent DNS resolution based on client locations. Resolve traffic from outside the Chinese mainland to the GA CNAME, and resolve traffic from the Chinese mainland directly to the origin server.

        In this case, traffic from outside the Chinese mainland enters GA through the accelerated IP address of the acceleration area outside the Chinese mainland. Traffic from the Chinese mainland connects directly to the origin server, which may cause latency and packet loss due to ISP and international link limitations.

      • Solution 2: Add an acceleration area in the Chinese mainland to the GA instance, and use the default DNS line to resolve requests to the GA CNAME.

        GA automatically allocates an accelerated IP address based on the region from which a request is initiated. Traffic from outside the Chinese mainland is routed to GA through accelerated IP addresses in acceleration areas outside the Chinese mainland, and traffic from the Chinese mainland is routed to GA through accelerated IP addresses in the Chinese mainland.

        Note: If the acceleration area includes the Chinese mainland and your service traffic is HTTP or HTTPS, you must obtain an ICP filing for your domain name. Otherwise, acceleration will fail.

    • Check security policies along the traffic path.

      For public backend connections, allow traffic from GA endpoint egress public IP addresses and CIDR blocks to reach backend service ports through origin-side security groups, firewalls, and access controls. View the applicable backend connection addresses on the Listener Details tab. For private connections, allow the source addresses or CIDR blocks required by the applicable GA private connection method. We recommend allowing the required CIDR blocks. Do not reuse a public egress IP allowlist. Client-side security devices, such as SSL VPNs or firewalls, must allow access to GA accelerated IP addresses on listener ports and the corresponding return traffic. If client IP preservation is enabled, also check the preservation method and the source addresses observed by each security device.

    • Check whether the required service port is added to the GA listener.

      For example, a web application uses both port 80 and port 443. You must add both ports to the GA listener. Otherwise, if you use a port that is not in the listener to access the GA instance, access will fail.

    • If your origin server is not deployed on Alibaba Cloud, check whether the Preserve Client IP feature is enabled.

      The Preserve Client IP feature requires the origin server to support the Proxy Protocol. Otherwise, access will fail. We recommend that you disable the Preserve Client IP feature and try to access the service again.

    • Check whether the traffic exceeds the bandwidth peak of the acceleration area.

      • You can go to the Monitoring Chart tab to view the number of connections and bandwidth usage. Traffic spikes may indicate DDoS attacks. To view instance metrics, see View instance metrics.

      • You can modify the bandwidth peak of an acceleration area. For more information, see Modify an acceleration area.

    • Check whether GA has Access control enabled and whether the client IP address is in the access control allowlist.

    • Check whether the DNS resolution of the domain name is correctly configured to resolve to the GA CNAME or accelerated IP address.

      You can use a command such as dig to check. For more information about how to configure a CNAME record, see Configure a CNAME record.

    • Check the health check target and probe settings.

      If health checks are enabled, make sure that the health check protocol and port match the target service. For HTTP or HTTPS health checks, also verify the domain name and request path. The health check port can be the application service port or a dedicated health check port. If the GA endpoint is a load balancer such as CLB, check the health check settings for the connection from GA to the load balancer and for the connection from the load balancer to its backend servers separately. GA must probe a valid port exposed by the load balancer; do not simply use the service port of an ECS instance behind the load balancer. Verify application port mappings and health check ports separately.

    How do I troubleshoot 502 errors after I configure GA?

    If requests return HTTP 502 after you configure GA, first identify the request path and error source, and then check backend connection settings and services:

    1. Identify the request path and error source: Check the DNS resolution results for your business domain name to verify that requests pass through the intended GA instance. CNAME-based access is recommended, but A records pointing to GA accelerated IP addresses are also supported. Compare GA, origin server, and application logs to identify which component generated the 502 response. A TCP listener forwards traffic and does not generate HTTP 502 responses.

    2. Check health status and backend logs: If health checks are enabled, check the health status of the endpoints and verify the health check settings. A successful health check does not guarantee that all application requests succeed. Verify that the backend is running and check for unexpected connection closures or invalid responses.

    3. Distinguish frontend TLS failures from backend connection failures: Certificate validation or TLS handshake failures between the client and GA typically appear as connection errors. If the client has received HTTP 502 over HTTPS, first check the connection from GA to the backend service. If GA uses HTTPS to connect to the backend, check TLS protocol compatibility, certificate configuration, and TLS handshake results on the backend.

    4. Check the backend protocol, ports, and security policies: Verify the endpoint address, backend protocol, service port, and port mapping. For an HTTPS listener, the protocol used between the client and GA can differ from the protocol used between GA and the backend. Configure the backend protocol based on the protocols that the backend service actually supports. Check security groups, firewalls, and access controls for the applicable public or private connection type.

    5. Use diagnostic tools: Review instance diagnostic results. If the instance meets the requirements for origin probing, including the supported instance specifications and listener protocols, you can create an origin probing task to help locate the issue.

    Can GA automatically adjust client access bandwidth and Alibaba Cloud internal network bandwidth during traffic bursts?

    Automatic adjustment of client access and transmission bandwidth depends on the GA instance's billing method:

    • Pay-as-you-go: Bandwidth is automatically scaled based on traffic, up to the bandwidth peak of the acceleration area.

    • Subscription: Auto scaling is not supported. Bandwidth is limited by the bandwidth of the basic bandwidth plan and the maximum bandwidth capacity of the GA instance specification.

    How do I troubleshoot packet loss on cross-border networks?

    If clients experience packet loss or access failures when connecting to an Alibaba Cloud ECS instance across borders, use MTR or PathPing to gather network evidence and correlate it with application requests and packet captures:

    1. Collect probe results from the client

      Run the following commands on the client. Replace the placeholder with the actual public IP address of the ECS instance, without angle brackets:

      • Linux: mtr -rwc 100 <ECS-public-IP>

      • Windows: pathping -n -q 100 <ECS-public-IP>

      For MTR, -r enables report mode, -w enables wide reports to avoid truncating hostnames, and -c 100 runs 100 probe cycles. For PathPing, -n disables hostname resolution and -q 100 sends 100 queries to each router along the path. Repeat tests during the incident and retain results from healthy periods for comparison.

      MTR uses ICMP by default, and ICMP probe loss does not necessarily indicate application packet loss. To probe the actual application port with TCP, use a command such as mtr -rwc 100 -T -P 443 <ECS-public-IP>. Intermediate hops in TCP mode still typically rely on ICMP Time Exceeded replies. TCP MTR does not validate TLS handshakes or HTTP requests, so also test actual application requests.

    2. Interpret MTR output to identify areas to investigate

      • Loss%: Probe loss percentage for the hop

      • Snt: Number of probes sent to the hop

      • Last: Latest round-trip time (ms)

      • Avg: Average round-trip time (ms)

      • Best: Minimum round-trip time (ms)

      • Wrst: Maximum round-trip time (ms)

      Focus on whether loss persists through subsequent hops to the destination. High loss or 100% loss at an intermediate hop, followed by healthy downstream hops and a healthy destination, usually indicates missing, filtered, or rate-limited probe replies. It does not establish application packet loss at that hop. Loss that starts at one hop and persists to the destination identifies an area to investigate, but MTR alone cannot pinpoint the exact device or direction of packet loss.

    3. Collect reverse-direction results from the ECS instance

      Trace the route from the ECS instance to the client public IP address: mtr -r -c 100 <client-public-IP>.

      Tests from both ends help investigate path differences, but different loss hop numbers do not prove that traffic traverses different international links. Probe statistics are affected by both the outgoing probes and their reply paths. Correlate routes in both directions with packet captures and application behavior.

      NAT or firewalls can restrict reverse probes, so a nonresponsive final hop does not necessarily indicate application packet loss. TCP probes still require a reachable client-side service and any necessary NAT mapping. Repeating a forward test can provide additional evidence but does not replace a reverse test.

    4. Correlate other evidence to locate the issue

      Analyze application request failure rates, TCP retransmissions, packet captures from both ends, autonomous system number (ASN) data, and ISP information together to identify the affected part of the network. whois and IP geolocation provide supporting clues; they cannot independently establish router locations or congestion at an international gateway.

    5. Evaluate cross-border acceleration

      If evidence points to cross-border public network quality, evaluate Global Accelerator (GA) and compare application success rates, latency, and packet loss before and after adoption. Before using a China Unicom cross-border dedicated line, verify instance and region eligibility and complete the required qualification and compliance procedures.

    How do I troubleshoot timeouts or connection resets affecting specific ISPs in the Chinese mainland?

    If clients using specific ISPs or located in particular regions of the Chinese mainland experience timeouts or connection resets when accessing services accelerated by GA, record the time, client region and ISP, business domain, destination accelerated IP address, port, and error message. Distinguish DNS failures, connection timeouts, TLS handshake failures, and TCP resets. Failures affecting a particular ISP, region, or accelerated IP address do not by themselves establish that an ISP policy is responsible.

    Use network probing tools to compare access results across regions, ISPs, and accelerated IP addresses while keeping the business domain, protocol, port, and request path consistent. For HTTPS, use the business domain name in the Host header and Server Name Indication (SNI); using an IP address as the URL hostname can introduce certificate or routing differences. Check DNS, listeners, access controls, backend health, security policies on both the client and the origin server, and packet captures or logs to identify the failure stage. If failures persist for a specific ISP or accelerated IP address, provide Alibaba Cloud technical support with successful and failed test results, timestamps, and packet captures. Coordinate with the ISP if necessary. For probing instructions, see Test the acceleration performance of GA.