FAQ about cloud-native gateways - Microservices Engine - Alibaba Cloud Documentation Center

This topic answers frequently asked questions (FAQs) about using MSE cloud-native gateways.

Do MSE cloud-native gateways support IPv6?

Yes, they do. The traffic ingress of a gateway is a Classic Load Balancer (CLB) or Network Load Balancer (NLB) instance. On the Overview page, you can click the Gateway Ingress tab and attach a CLB or NLB instance that has IPv6 enabled.

Do cloud-native gateways support the x-real-ip request header?

No, they do not support this header by default. The x-real-ip header is specific to Nginx. To use it, you must enable the gateway's http-real-ip plugin. This plugin extracts the client IP address according to its configuration and writes it to the x-real-ip request header.

Do cloud-native gateways support the x-forwarded-for request header?

Yes, they do. If an original request contains the x-forwarded-for header, the gateway appends the IP address of the previous hop to the end of the header. If the original request does not contain the x-forwarded-for header, the gateway adds the header and includes the IP address of the previous hop.

Note

The built-in Tomcat of Spring Boot deletes the last address in the x-forwarded-for header by default. To prevent this deletion, add the server.forward-headers-strategy=none configuration to Spring Boot.

Request headers added by the cloud-native gateway when forwarding requests

Request header	Description
`x-request-id`	The unique ID that the cloud-native gateway generates for each request.
`x-forwarded-proto`	The communication protocol that the client uses to send requests to the cloud-native gateway.
`req-start-time`	The UNIX timestamp in milliseconds that indicates when the cloud-native gateway received the request.
`x-forwarded-for`	The original IP address of a client that connects to a web server through a proxy server.
`x-envoy-original-host`	The host header that the client uses to send requests to the cloud-native gateway.
`original-host`	The host header that the client uses to send requests to the cloud-native gateway.
`host`	The host header that the cloud-native gateway uses to send requests to the backend service.
`x-envoy-attempt-count`	This header is sent to the upstream to indicate the attempt number of the current request in a series of retries. The value is "1" for the initial request and is incremented by 1 for each retry.
`x-envoy-external-address`	The original address of the external client that sends a request to the cloud-native gateway. For more information, see x-envoy-external-address.
`tracestate`	A header that is generated when Tracing Analysis is enabled. This is a W3C protocol header.
`ot-traceid`	A header that is generated when Tracing Analysis is enabled. This is the trace ID of the W3C protocol.
`traceparent`	A header that is generated when Tracing Analysis is enabled. This is a W3C protocol header.
`x-envoy-decorator-operation`	A header that is generated when Tracing Analysis is enabled. This is the server span name generated by the trace.
`x-envoy-expected-rq-timeout-ms`	The request timeout period in milliseconds that is set for the route.

What do I do if the "upstream connect error or disconnect/reset header" message appears when the cloud-native gateway forwards a request?

This issue occurs because the security group of the backend service does not allow the gateway to access the service port. On the Overview page of the gateway instance, click the Security Group Authorization tab. Then, click Authorize Security Group to add a security group rule. The gateway forwards requests directly to the pod IP address of the ACK cluster. You must open the port used by the pod in the security group authorization.

How do I use a header to match a domain name in a cloud-native gateway?

When you create a route, you can add a request header matching rule. For the header name, enter :authority. For the header value, enter the specific domain name.

What do I do if I cannot view the plugin logs of the cloud-native gateway?

This issue may occur for the following reasons:

The logs are not printed because the current log level is set to Trace or Debug. By default, the plugin only prints logs at the Info level or higher.
The plugin did not start as expected because of a compilation issue. In this case, clear the default log search statement to view the error logs generated during plugin startup. Compile the plugin code as instructed in the plugin development documentation. Then, debug the plugin locally using the docker compose mode to validate the plugin. After validation, you can upload the plugin to the cloud-native gateway.

What do I do if an error is reported because the request body is too large?

This issue occurs because the gateway connection buffer is too small. You can increase the buffer size:

If the protocol is HTTP/1.x, adjust the DownstreamConnectionBufferLimits parameter in the console.
If the protocol is HTTP/2, adjust the DownstreamConnectionBufferLimits and InitialStreamWindowSize parameters in the console.

What are the limits on adding a service source to a cloud-native gateway?

A single gateway instance can be associated with a maximum of three ACK container services.
A single gateway instance can be associated with a maximum of three Nacos instances.

Why am I unable to select an existing Nacos or ACK instance when I add a service source to my cloud-native gateway?

Cloud-native gateways can only add Nacos or ACK instances that are in the same VPC. Service sources cannot be added across different VPCs.

Do cloud-native gateways support custom HTTPS certificates?

Cloud-native gateways do not host certificates. They retrieve certificates from Alibaba Cloud SSL Certificate Service. You can upload your own certificate in the SSL Certificate Service console and then configure it for the gateway domain name.

Do parameter changes in the cloud-native gateway console affect existing traffic?

After you modify the XffTrustedNum parameter, you must restart the gateway for the change to take effect.
After you modify the UpstreamIdleTimeout parameter, the upstream connection is closed and then re-established.
After you modify the DownstreamIdleTime parameter, the downstream connection is closed and then re-established.

What do I do if the health check status of port 443 on the CLB instance is abnormal?

The health check status for port 443 is abnormal because the gateway does not listen on this port if no HTTPS domain name is configured. To resolve this, you must configure an HTTPS domain name on the gateway. For more information, see Create a domain name. If you use an Ingress, see K8s Ingress.

What do I do if the health check status of a service is abnormal after the service is created on the cloud-native gateway?

For a gateway to forward requests to a backend service, it must be able to connect to the backend service over the network. If the health check status of a service is abnormal, the cause is usually one of the following:

For a private service in a VPC, check whether the security group of the backend service is configured to allow the gateway to access the corresponding port. For more information, see Set security group rules.
For a service on the Internet, check whether the VPC can access the Internet. You can use the 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 an HTTP health check, make sure that the request path and request domain name are correctly set.
For an HTTP health check, if the health check interface of the backend service must be accessed over HTTPS, set the mode to One-way TLS in the Policy Configuration of the service.
For an HTTP health check, if the issue persists after you perform the preceding steps, the health check interval may be the same as the connection keep-alive time of the backend service. You can try to increase the health check interval.

How do I identify the cause of a request error?

Check whether the response header contains the x-envoy-upstream-service-time header. If the response contains the x-envoy-upstream-service-time header, the gateway has forwarded the request to the backend service for processing. In this case, subsequent request errors are likely caused by the backend service logic.
Check whether the upstream_service_time field in the access log of the gateway is empty. If the upstream_service_time field in the access log is not empty, the gateway has forwarded the request to the backend service for processing. In this case, subsequent request errors are likely caused by the backend service logic.

What do I do if an HTTPS certificate does not take effect after it is updated in a cloud-native gateway?

This issue usually occurs because an HTTPS certificate is also configured on an upstream node, such as a CLB, DCDN, WAF, or Anti-DDoS Pro and Anti-DDoS Premium instance. Check whether the HTTPS certificate on the upstream node is also updated. The best practice is to configure the HTTPS certificate in only one place. If DCDN or WAF is connected upstream of the gateway, you can configure HTTPS only on DCDN or WAF and use HTTP for the backend gateway.

What do I do if the parameter configuration changes on the cloud-native gateway do not take effect?

This issue usually occurs because an MSE Ingress is used. The MseIngressConfig contains related configuration items. The MSE Ingress automatically synchronizes the configuration items in the MseIngressConfig to the MSE gateway console. If you modify the configuration items in the console, the modifications may be overwritten by the information synchronized from the MSE Ingress. We recommend that you modify configuration items only in the MSE Ingress.

How are the routing priorities of a cloud-native gateway sorted?

The order of the route configurations on the Route Settings page of the gateway instance determines the route matching priority. The list is sorted in descending order of priority. Matching priority depends on the domain name and routing rule. For domain names, an exact-match domain name has a higher priority than a wildcard domain name. For example, test.example.com has a higher priority than *.example.com. For routing rules with the same domain name, the path priority is exact match > prefix match > regular expression match. For routing rules with the same domain name and path, the priority is more matching conditions > fewer matching conditions. Matching conditions include Header and Query parameters.

Why do HTTPS requests fail when the cloud-native gateway is connected to DCDN?

This issue usually occurs because DCDN does not include an SNI when it sends origin fetch requests to the gateway. You can set the origin SNI in the DCDN origin fetch configuration.

Why do HTTPS requests fail when the cloud-native gateway is connected to WAF?

This issue usually occurs because WAF does not include an SNI when it sends origin fetch requests to the gateway. If you use the CNAME record mode to add a domain name to WAF, you must modify the domain name settings. In Forwarding Settings, select Enable Origin SNI.

Do cloud-native gateways support Websocket?

Yes, they do. Support for the WebSocket protocol is enabled by default.

Do cloud-native gateways support gRPC?

Yes, they do. gRPC uses the HTTP/2 protocol for transmission. On the Parameter Settings page of the gateway, confirm that EnableHttp2 = true.

Do cloud-native gateways support GZIP decompression?

Yes, they do. On the Parameter Settings page of the gateway, confirm that EnableGzip = true. The Gzip and Brotli compression algorithms are supported. You can configure the algorithm using the ZipAlgorithm parameter. The default value is Gzip.

Do cloud-native gateways support preserving the case of request and response headers?

Yes, they do. On the Parameter Settings page of the gateway, confirm that PreserveHeaderFormat = true. This parameter takes effect only for HTTP/1.0 or HTTP/1.1. According to the specification, the HTTP/2 protocol requires all request and response headers to be in lowercase.

Do cloud-native gateways support HTTP/3?

Yes, they do. On the Parameter Settings page of the gateway, confirm that EnableHttp3 = true.

Do cloud-native gateways support custom listener ports?

Yes, they do. Cloud-native gateways support HTTP (port 80) and HTTPS (port 443). In the CLB console, you can add a listener port, such as TCP port 8080, and assign port 80 to the same vServer group to process HTTP requests.

Why do all request and response headers become lowercase after requests pass through the gateway?

By default, the gateway converts all request and response headers to lowercase. To preserve the case, on the Parameter Settings page of the gateway, set PreserveHeaderFormat = true.

Why does access fail after I create a DNS domain name service on the cloud-native gateway?

If the configured DNS domain name is an Internet domain name, you must configure SNAT in the NAT Gateway console to allow the gateway to access the Internet. By default, the gateway cannot access the Internet.