All Products
Search
Document Center

Microservices Engine:FAQ about cloud-native gateways

Last Updated:May 06, 2024

This topic provides answers to some frequently asked questions about cloud-native gateways of Microservices Engine (MSE).

Do MSE cloud-native gateways support IPv6?

Yes, MSE cloud-native gateways support IPv6. A Classic Load Balancer (CLB) or Network Load Balancer (NLB) instance can be used as the traffic ingress of an MSE cloud-native gateway. You only need to associate an IPv6-enabled CLB or NLB instance with the gateway on the Gateway Ingress tab of the Overview page.

Do cloud-native gateways support the X-Real-IP request header?

By default, cloud-native gateways do not support the X-Real-IP request header. X-Real-IP is an exclusive request header in NGINX Ingress gateways. You must use the http-real-ip plug-in provided by NGINX Ingress gateways to extract the client IP address based on the configuration and write the client IP address to the X-Real-IP request header.

Do cloud-native gateways support the X-Forwarded-For request header?

Yes, cloud-native gateways support the X-Forwarded-For request header. If the original request carries the X-Forwarded-For header, the gateway appends the previous-hop IP address of the gateway 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 of the gateway to the request header.

Note

By default, the built-in Tomcat of Spring Boot deletes the last address in the X-Forwarded-For header. You can add the server.forward-headers-strategy=none configuration to Spring Boot to prevent the deletion operation.

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

The 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, click the Security Group Authorization tab, and click Add Security Group Rule to add a security group rule. After the security group rule is added, the gateway can directly forward the request to the pod IP address of the Container Service for Kubernetes (ACK) cluster. You must specify the port used by the pod in the security group rule.

How do I use headers to match domain names in the cloud-native gateway?

Add a rule for matching request headers when you create a route. Specify :authority as the header name and set the header value to a specific domain name.

What do I do if I am unable to view the plug-in logs of the cloud-native gateway?

The issue may be caused by the following reasons:

  • The logs are not printed because the current log level is Trace or Debug. By default, the plug-in prints only logs of the Info level or a higher level.

  • The plug-in does not start as expected due to a compilation issue. In this case, clear the default log query statement and query the error logs that are generated during the startup of the plug-in. Correctly compile the plug-in code by following instructions in the plug-in development document, and debug the plug-in by using Docker Compose on your on-premises machine to ensure that the plug-in is valid. Then, upload the plug-in to the cloud-native gateway.

What do I do if an error is reported when the request body size exceeds the upper limit of the cloud-native gateway?

This issue occurs because the size of the gateway connection buffer is too small. Increase the buffer size based on the protocol type.

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

  • If HTTP/2 is used, increase the values of the DownstreamConnectionBufferLimits and InitialStreamWindowSize parameters in the MSE console.

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

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

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

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

Only Nacos instances or ACK clusters that are in the same virtual private cloud (VPC) as the cloud-native gateway can be added as service sources. Cross-VPC service sources are not supported.

Do cloud-native gateways support self-signed HTTPS certificates?

Cloud-native gateways do not manage certificates but pull certificates from Certificate Management Service. Upload your self-signed certificate to Certificate Management Service and configure the certificate in the domain name settings of the gateway.

Do gateway parameter changes in the MSE console affect existing traffic?

  • If you change the XffTrustedNum parameter, restart the gateway to make the change take effect.

  • If you change the UpstreamIdleTimeout parameter, the upstream connection is closed and then re-established.

  • If you change the DownstreamIdleTime parameter, the downstream connection is closed and then re-established.

What do I do if the health status of port 443 on the CLB instance associated with the cloud-native gateway is abnormal?

If no HTTPS domain name is configured on the gateway, the gateway does not listen to port 443. As a result, the health status of port 443 on the Classic Load Balancer (CLB) instance is abnormal. To resolve the issue, configure an HTTPS domain name for the gateway. For more information, see Associate domain names with a cloud-native gateway. For more information about how to specify listening items in Ingress resource configurations, see Kubernetes Ingress.

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

To allow the gateway to forward a request to the backend service, make sure that the gateway is connected to the backend service. If the health status of the backend service is abnormal, perform the following operations for troubleshooting:

  • For an internal-facing service in the VPC, check whether the security group of the backend service allows the gateway 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 the 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 cause is not identified after you perform the preceding operations, the health check interval may be the same as the persistent connection period of the backend service. Try to increase the health check interval.

How do I identify the cause of a request error reported on the cloud-native gateway?

  • Check whether the response contains the x-envoy-upstream-service-time header. In normal cases, 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 closely related to the logic of the backend service.

  • Check whether the upstream_service_time field in the access log of the gateway is empty. In normal cases, 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 closely related to the logic of the backend service.

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

This issue occurs because an HTTPS certificate is configured for the node connected to the gateway such as a CLB instance, Dynamic Content Delivery Network (DCDN), Web Application Firewall (WAF), or Anti-DDoS Proxy. 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 the gateway, configure an HTTPS certificate only on DCDN or WAF and use HTTP for the backend gateway.

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

This issue occurs because an MseIngressConfig is used to define configurations of the cloud-native gateway. The MSE Ingress gateway automatically synchronizes configuration items in the MseIngressConfig to the MSE console. If you modify the configuration items in the MSE console, the modifications may be overwritten by the subsequent information synchronized from the MSE Ingress gateway. We recommend that you modify configuration items only by using the MseIngressConfig.

What is the sorting method of routing priorities of the cloud-native gateway?

On the Route Settings page of the cloud-native gateway, routes are listed in descending order of route matching priorities. The matching priorities are determined based on domain names or routing rules. For domain name matching, an exact domain name takes precedence over a wildcard domain name. For example, test.example.com takes precedence over *.example.com. For matching of paths of the same domain name, the order of precedence is exact match > prefix match > regular expression match. For matching of the same path of the same domain name, a matching rule that has more conditions takes precedence. The matching conditions can be headers and the Query parameter.

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

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 do HTTPS requests fail when the cloud-native gateway is connected to WAF?

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.

Do cloud-native gateways support WebSocket?

Yes. The WebSocket protocol is enabled by default.

Do cloud-native gateways support gRPC?

Yes, cloud-native gateways support gRPC. gRPC uses HTTP/2 to transmit data. Confirm that the EnableHttp2 = true configuration is specified on the Parameter Settings page.

Do cloud-native gateways support the gzip compression algorithm?

Yes, cloud-native gateways support the gzip compression algorithm. 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.

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

Yes, cloud-native gateways support case preservation of request and response headers. Confirm that the PreserveHeaderFormat = true configuration is specified on the Parameter Settings page of the gateway. 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.

Do cloud-native gateways support HTTP/3?

Yes, cloud-native gateways support HTTP/3. Confirm that the EnableHttp3 = true configuration is specified on the Parameter Settings page of the gateway.

Do cloud-native gateways support custom listener ports?

Yes, cloud-native gateways support custom listener ports. Cloud-native gateways support HTTP port 80 and HTTPS port 443. To resolve this issue, add a listener port in the CLB console. For example, you can add TCP port 8080. Then, add TCP port 8080 and HTTP port 80 to the same vServer group to allow HTTP requests.

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

By default, the gateway sets all request and response headers to lowercase. For case preservation, specify the PreserveHeaderFormat = true configuration on the Parameter Settings page.

Why does the access fail when a DNS service is created on the cloud-native gateway?

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.

Why is the status code 400 returned for a request on the cloud-native gateway?

This issue may be caused by the following reasons:

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

  • The status code 400 is 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 400 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.

We recommend that you use the AI Diagnostics feature for preliminary analysis.

Why is the status code 401 returned for a request on the cloud-native gateway?

This issue may be caused by the following reasons:

  • The information returned by the gateway indicates that no access credential is available. Check whether the authentication feature or WebAssembly plug-in is enabled.

  • The status code 401 is 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 401 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.

We recommend that you use the AI Diagnostics feature for preliminary analysis.

Why is the status code 403 returned for a request on the cloud-native gateway?

This issue may be caused by the following reasons:

  1. The information returned by the gateway indicates that the required permission is not granted. Check whether the IP address blacklist or whitelist, authentication feature, or the WebAssembly plug-in is enabled.

  2. The status code 403 is 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.

We recommend that you use the AI Diagnostics feature for preliminary analysis.

Why is the status code 404 returned for a request on the cloud-native gateway?

This issue may be caused by the following reasons:

  • No routing rule is configured for the gateway. View the access log of the gateway. If response_flags = NR is found in the log, no routing rule is configured for the gateway.

  • The status code 404 is 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 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.

We recommend that you use the AI Diagnostics feature for preliminary analysis.

Why is the status code 405 returned for a request on the cloud-native gateway?

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

Why is the status code 413 returned for a request on the cloud-native gateway?

This issue may be caused by the following reasons:

  • The request size exceeds the size of the connection cache of the gateway. Increase the value of the DownstreamConnectionBufferLimits parameter on the Parameter Settings page.

  • The status code 413 is 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 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.

We recommend that you use the AI Diagnostics feature for preliminary analysis.

Why is the status code 429 returned for a request on the cloud-native gateway?

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

We recommend that you use the AI Diagnostics feature for preliminary analysis.

Why is the status code 502 returned for a request on the cloud-native gateway?

This issue may be caused by the following reasons:

  • A request protocol error is 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.

  • The status code 502 is 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 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.

We recommend that you use the AI Diagnostics feature for preliminary analysis.

Why is the status code 503 returned for a request on the cloud-native gateway?

This issue may be caused by the following reasons:

  • The destination service specified in the routing rule of the gateway 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 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.

  • 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 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 is 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 503 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.

We recommend that you use the AI Diagnostics feature for preliminary analysis.

Why is the value of the response_code field in the log is 0?

If the value of the response_code field is 0 in the log, the client does not receive the response code.

This issue may be caused by the following reasons:

  • The client closes the connection before the response code is received. This issue occurs in scenarios such as weak network signals and slow response at the backend. Check the log. If the value of the response_flags field is DC, the client closes the connection before the response code is received.

  • 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. Check the log. If the value of the requested_server_name field in the log is empty, the HTTPS request does not carry an SNI and no HTTPS certificate is configured for the wildcard domain name that starts with an asterisk (*).

We recommend that you use the AI Diagnostics feature for preliminary analysis.