API Gateway:FAQ

Does Cloud-native API Gateway support IPv6?

Yes, Cloud-native API Gateway supports IPv6.

Does Cloud-native API Gateway support the x-forwarded-for request header?

Yes, Cloud-native API Gateway supports the x-forwarded-for request header.

If an original request carries the x-forwarded-for header, the gateway appends the previous-hop IP address to the request header. If the original request does not carry the x-forwarded-for header, the gateway adds the header to the request and writes the previous-hop IP address to the request header.

What do I do if "upstream connect error or disconnect/reset header" is reported when my Cloud-native API Gateway instance forwards a request?

The issue occurs because the security group of the backend service does not allow your gateway instance to access the service port.

You can fix this issue by adding a security group rule that allows your instance to forward requests to the corresponding Container Service for Kubernetes (ACK) pod. To add a security group rule, go to the Overview page of your instance, click the Security Group Authorization tab and then click Add Security Group Rule. Bear in mind that you must open the port required by the pod in the security group rule.

How do I use a header to match my domain name?

You can add a header matching rule when you create a route.

When you configure the rule, set the header name field to authority and set the header value to the domain name that you want to match.

What do I do if an error that indicates a request body is too large is reported?

This issue occurs because the size of the gateway's connection buffer is too small. You can resolve this issue by increasing the buffer size:

• If the protocol is HTTP 1.x, increase the value of the DownstreamConnectionBufferLimits parameter in the console.

• If the protocol is HTTP 2.0, increase the values of the DownstreamConnectionBufferLimits and InitialStreamWindowSize parameters in the console.

How many sources can I use to create services in Cloud-native API Gateway?

• A single gateway instance can be associated with up to three ACK clusters.

• A single gateway instance can be associated with only one Nacos instance.

Why am I unable to select an existing Nacos instance or ACK cluster as the source to create a service?

Only Nacos instances or ACK clusters from the same virtual private cloud (VPC) as your gateway instance can be selected as service sources.

Does Cloud-native API Gateway support HTTPS certificates that I prepared by myself?

Cloud-native API Gateway does not host certificates. Instead, it pulls certificates from Alibaba Cloud Certificate Management Service. You can upload your certificate to Certificate Management Service and configure the certificate in the domain name settings of your gateway instance.

How do parameter changes in the console affect my existing business?

• The change of XffTrustedNum takes effect after you restart your gateway instance.

• The change of UpstreamIdleTimeout causes upstream connections to disconnect and then reconnect.

• The change of DownstreamIdleTime causes downstream connections to disconnect and then reconnect.

What do I do if the health status of my created backend service is abnormal?

To allow a gateway instance to forward a request to a backend service, you must make sure that the gateway instance is connected to the backend service. If the health status of the backend service is abnormal, perform the following operations to troubleshoot the issue:

• For an internal-facing service in a VPC, check whether the security group of the backend service allows the gateway instance to access the relevant port. For more information about how to configure security group rules, see Configure security group rules.

• For an Internet-facing service, check whether your VPC can access the Internet. Try to enable the secure network address translation (SNAT) feature of an Internet NAT gateway to access the Internet. For more information, see Use the SNAT feature of an Internet NAT gateway to access the Internet.

• For HTTP health checks, check whether the request path and request domain are correctly configured.

• For HTTP health checks, if the health check interface of the backend service needs to be accessed over HTTPS, enable one-way Transport Layer Security (TLS) for the backend service in Policies.

• For HTTP health checks, if the preceding configurations are all correct, the issue may be caused by a health check interval that is the same as the duration for which a backend connection is held. In this case, you can try increasing the health check interval.

How do I determine the cause of a request error?

• Check whether the response contains the x-envoy-upstream-service-time header. If the response contains the x-envoy-upstream-service-time header, the gateway instance has forwarded the request to the backend service for processing, and the error can be attributable to the logic of the backend service.

• Check whether the upstream_service_time field is empty in the access log of your gateway instance. If the upstream_service_time field is not empty, your gateway instance has forwarded the request to the backend service for processing, and the error can be attributable to the logic of the backend service.

What do I do if my updated HTTPS certificate in Cloud-native API Gateway does not take effect?

This issue occurs because an HTTPS certificate is configured for the previous node that is connected to your gateway instance. Such a node can be an instance of the Classic Load Balancer (CLB), Dynamic Content Delivery Network (DCDN), Web Application Firewall (WAF) instance, or Anti-DDoS Proxy service. Check whether the HTTPS certificate on the connected node is updated. Based on best practices, we recommend that you configure an HTTPS certificate only on one node. If DCDN or WAF is connected to your gateway instance, configure an HTTPS certificate only on DCDN or WAF and use HTTP for your gateway instance.

How are routes prioritized in Cloud-native API Gateway?

On the Route Settings page of your gateway instance, routes are listed in descending order of priority. The matching priorities are determined based on domain names or routing rules. Precise domain names are higher in priority than wildcard domain names. For example, test.example.com enjoys a higher priority than *.example.com. For paths that belong to the same domain name, exact matches are higher in priority than prefix matches, which in turn are higher in priority than regular expression matches. If requests have the same domain name and path, those with more matching conditions are prioritized over those with fewer matching conditions. Matching conditions are contained in the Herder and Query sections of requests.

Why does an HTTPS request fail when DCDN precedes Cloud-native API Gateway?

This issue occurs because DCDN does not carry a Server Name Indication (SNI) in back-to-origin requests that are sent to the gateway. In this case, add an SNI to the back-to-origin configuration of DCDN.

Why does an HTTPS request fail when WAF precedes Cloud-native API Gateway?

This issue occurs because WAF does not carry an SNI in back-to-origin requests that are sent to the gateway. If you add a website to WAF in Canonical Name (CNAME) record mode, select Enable Origin SNI in the Enter Your Website Information step.

Does Cloud-native API Gateway support WebSocket?

Yes, WebSocket is supported by and enabled by default in Cloud-native API Gateway.

Does Cloud-native API Gateway support gRPC?

Yes, Cloud-native API Gateway supports gRPC. gRPC uses HTTP/2 to transmit data. Confirm that the EnableHttp2 = true configuration is specified on the Parameter Settings page.

Does Cloud-native API Gateway support GZIP decompression?

Yes, Cloud-native API Gateway supports GZIP decompression. Confirm that the EnableGzip = true configuration is specified on the Parameter Settings page. The compression algorithms gzip and Brotli are supported. You can specify the ZipAlgorithm parameter to configure the compression algorithm. By default, the ZipAlgorithm parameter is set to gzip.

Does Cloud-native API Gateway support the retaining of case status in request and response headers?

Yes, uppercase and lowercase letters can be kept as are in request and response headers. Confirm that the PreserveHeaderFormat = true configuration is specified on the Parameter Settings page of the gateway instance. The PreserveHeaderFormat parameter takes effect only when HTTP 1.0 or 1.1 is used. The HTTP/2 protocol requires that all request and response headers be in lowercase.

Does Cloud-native API Gateway support HTTP/3?

Yes, Cloud-native API Gateway supports HTTP/3. Confirm that the EnableHttp3 = true configuration is specified on the Parameter Settings page of the gateway instance.

Why do all request and response headers turn into lowercase letters after requests and responses are passed to Cloud-native API Gateway?

By default, Cloud-native API Gateway converts all request and response headers into lowercase letters. If you want to keep the original case status, specify the PreserveHeaderFormat = true configuration on the Parameter Settings page.

Why is my Cloud-native API Gateway instance unable to access the Internet after I configured a DNS domain name for my instance?

If the configured Domain Name System (DNS) domain name is a public domain name, enable SNAT of a NAT gateway to allow the gateway to access the Internet. By default, the gateway cannot access the Internet.

Tracing Analysis is enabled in Cloud-native API Gateway but I get no results from trace information searches in the ARMS console. Why is that?

Check your gateway configurations whether EnableGenerateRequestId is set to true. If it is false, you must add a compliant x-request-id header to your request. Otherwise, the gateway instance cannot report trace information due to the lack of the request-id information.

Why is a 400 error returned for requests?

This issue may be caused by the following reasons:

• A protocol error occurred when the client sent the request. View the access log of your gateway instance. If response_flags = DPE is found in the log, the issue is caused by a protocol error.

• The status code 400 was returned by the backend service. View the access log of your gateway instance. If response_flags is empty but upstream_host has a value, the status code 400 was returned by the backend service, and the backend IP address in the request forwarded by your gateway instance is the IP address specified in upstream_host.

Why is a 401 error returned for requests?

This issue may be caused by the following reasons:

• The necessary access credential is missing. In this case, the error is returned by Cloud-native API Gateway. Check whether the authentication feature or WebAssembly plug-in is enabled.

• The error may also be returned by a backend service. Check the access log of the gateway instance. If response_flags is empty but upstream_host has a value, the status code 401 was returned by the backend service, and the backend IP address in the request forwarded by the gateway is the IP address specified in upstream_host.

Why is a 403 error returned for requests?

This issue may be caused by the following reasons:

• The client lacks the required permissions. In this case, the error is returned by Cloud-native API Gateway. Check whether the IP address blacklist or whitelist, authentication feature, or the WebAssembly plug-in is enabled.

• The error may also be returned by the backend service. View the access log of the gateway. If response_flags is empty and upstream_host has a value, the status code 403 is returned by the backend service, and the backend IP address in the request forwarded by the gateway is the IP address specified in upstream_host.

Why is a 404 error returned for requests?

This issue may be caused by the following reasons:

• No corresponding routing rule is configured in Cloud-native API Gateway. View the access log of the gateway. If response_flags = NR is found in the log, no routing rule is configured.

• The error may also be returned by the backend service. View the access log of the gateway. If response_flags is empty but upstream_host has a value, the status code 404 is returned by the backend service, and the backend IP address in the request forwarded by the gateway is the IP address specified in upstream_host.

Why is a 405 error returned for requests?

If WAF protection is enabled and the request hits a WAF protection rule, the status code is returned by WAF.

Why is a 413 error returned for requests?

This issue may be caused by the following reasons:

• The request size exceeds the size of the connection cache of the gateway instance. In this case, you must increase the value of the DownstreamConnectionBufferLimits parameter on the Parameter Settings page.

• The error may also be returned by the backend service. View the access log of the gateway. If response_flags is empty but upstream_host has a value, the status code 413 is returned by the backend service, and the backend IP address in the request forwarded by the gateway is the IP address specified in upstream_host.

Why is a 429 error returned for requests?

A throttling rule is triggered for the gateway instance. View the access log of the gateway. If response_flags = RL is found in the log, check the throttling rule of the gateway instance.

Why is a 502 error returned for requests?

This issue may be caused by the following reasons:

• A request protocol error returned by the backend service. View the access log of the gateway. If response_flags = UPE is found in the log, the most common cause is that the header returned by the backend service contains duplicate Transfer-Encoding fields. In this case, check the backend service.

• A status code 502 returned by the backend service. View the access log of the gateway. If response_flags is empty but upstream_host has a value, the status code 502 is returned by the backend service, and the backend IP address in the request forwarded by the gateway is the IP address specified in upstream_host.

Why is a 503 error returned for requests?

This issue may be caused by the following reasons:

• The destination service specified in the routing rule of the gateway instance does not have a healthy IP address. View the access log of the gateway. If response_flags = UH is found in the log, no healthy IP address is available for the destination service.

• The connection is closed by the backend service when the gateway instance forwards the request. View the access log of the gateway. If response_flags = UC is found in the log, the idle timeout value of the backend service is less than the value of UpstreamIdleTimeout specified for the gateway. In this case, set UpstreamIdleTimeout to a smaller value on the Parameter Settings page of the gateway instance.

• The IP address of the backend service is not accessible from the gateway. View the access log of the gateway. If response_flags = UF or response_flags = URX is found in the log, the security group of the backend service does not allow access from the gateway. Check whether the security group of the backend service allows the gateway to access the port. For more information about how to configure security group rules, see Configure security group rules.

• The gateway instance is not associated with the backend service. View the access log of the gateway. If response_flags = NC is found in the log, the issue may be caused by the following reasons:

  • The service no longer exists.

  • A dynamic port of the backend service is selected. If the backend service has multiple ports, you must select a fixed port rather than a dynamic port when you select a destination service for route settings.

  • A fixed port is selected by the backend service, but the service port is changed.

• The status code 503 was returned by the backend service. If the response_flags in the log is null but the upstream_host is not null, the backend service returns 503, and the specific backend IP address forwarded by the gateway is the upstream_host content.

What do I do if the response_code value in the log is 0?

If the response_code value is 0, the client did not receive the response code.

This issue may be caused by the following reasons:

• The client had closed the connection before the response code was received. This issue occurs in scenarios such as weak network signals and slow response at the backend. You can check in logs whether the value of the response_flags field is DC.

• The HTTPS request does not carry a Server Name Indication (SNI) and no HTTPS certificate is configured for the wildcard domain name that starts with an asterisk (*). SNI is an extension of the Transport Layer Security (TLS) protocol and is used to carry domain name information. You can check in logs whether the requested_server_name field is empty.