API Gateway:Frequently asked questions

¿Cloud-native API Gateway es compatible con IPv6?

Sí.

¿Cloud-native API Gateway admite el encabezado de solicitud x-forwarded-for?

Sí.

Si una solicitud ya incluye el encabezado x-forwarded-for, la puerta de enlace agrega la dirección IP del salto anterior. De lo contrario, añade el encabezado con dicha dirección IP.

Solución de errores "upstream connect error or disconnect/reset header"

Este error indica que el security group del servicio backend está bloqueando el acceso desde la instancia de la puerta de enlace.

Para resolverlo, vaya a la página Overview de su instancia de puerta de enlace, haga clic en la pestaña Security Group Authorizations y luego haga clic en Add Security Group Rule para agregar una configuración de security group. La puerta de enlace reenvía las solicitudes directamente a la dirección IP del Pod en ACK, por lo que debe abrir el puerto que utiliza el pod en la regla del security group.

Uso de un encabezado para coincidir con un nombre de dominio

Agregue una regla de coincidencia de encabezados de solicitud al crear una ruta.

Establezca el nombre del campo de encabezado como :authority y el valor del encabezado como el nombre de dominio específico.

Solución de fallos en solicitudes por un cuerpo demasiado grande

Este problema ocurre porque el búfer de conexión de la puerta de enlace es demasiado pequeño. Puede aumentar el tamaño del búfer:

• Si usa HTTP/1.x: Ajuste el parámetro DownstreamConnectionBufferLimits en la consola.

• Si usa HTTP/2: Ajuste los parámetros DownstreamConnectionBufferLimits y InitialStreamWindowSize en la consola.

Límites al agregar orígenes de servicio

• Una sola instancia de puerta de enlace se puede asociar con hasta tres clústeres de ACK.

• Una sola instancia de puerta de enlace se puede asociar únicamente con una instancia de Nacos.

No se puede seleccionar un origen de servicio existente de Nacos o ACK

Cloud-native API Gateway solo permite agregar instancias de Nacos o clústeres de ACK que se encuentren en la misma VPC.

¿Cloud-native API Gateway admite certificados HTTPS personalizados?

Cloud-native API Gateway no aloja certificados directamente; en su lugar, los obtiene del Certificate Management Service de Alibaba Cloud. Cargue su certificado en Certificate Management Service y luego configúrelo para el nombre de dominio en la puerta de enlace.

Efectos de cambiar parámetros en el tráfico existente

• Los cambios en XffTrustedNum requieren reiniciar la puerta de enlace para surtir efecto.

• Los cambios en UpstreamIdleTimeout provocan que las conexiones upstream se desconecten y reconecten.

• Los cambios en DownstreamIdleTime provocan que las conexiones downstream se desconecten y reconecten.

Estado anómalo de comprobación de salud de un servicio backend

Un estado anómalo en la comprobación de salud puede deberse a varias causas:

• Para un servicio privado dentro de una VPC, compruebe si el security group del servicio backend permite que la puerta de enlace acceda al puerto requerido. Para más información, consulte Add a security group rule.

• Para un servicio público, verifique si la VPC tiene acceso a Internet. Puede usar la función SNAT de una puerta de enlace NAT de Internet para acceder a Internet. Para más información, consulte Use the SNAT feature of an Internet NAT gateway to access the Internet.

• En comprobaciones de salud basadas en HTTP, asegúrese de que la ruta y el dominio de la solicitud estén configurados correctamente.

• En comprobaciones de salud basadas en HTTP, si el endpoint de comprobación de salud del servicio backend debe accederse mediante HTTPS, establezca la directiva del servicio en modo TLS dentro de Policy Configuration.

• En comprobaciones de salud basadas en HTTP, si todas las configuraciones anteriores son correctas, el problema podría ser que el intervalo de comprobación de salud coincide con el tiempo de keep-alive de la conexión del servicio backend. Intente aumentar el intervalo de comprobación de salud.

Determinación de la causa de un error de solicitud

• Compruebe si el encabezado de respuesta contiene x-envoy-upstream-service-time. Si es así, la puerta de enlace ya reenvió la solicitud al servicio backend. Es probable que el error se origine en dicho servicio.

• Verifique si el campo upstream_service_time en el registro de acceso de la puerta de enlace está vacío. Si no lo está, la puerta de enlace ya reenvió la solicitud al servicio backend. Es probable que el error se origine en dicho servicio.

El certificado HTTPS actualizado no surte efecto

Este problema suele ocurrir cuando también hay un certificado HTTPS configurado en un servicio upstream de la puerta de enlace, como CLB, DCDN, WAF o Anti-DDoS Proxy. Verifique si el certificado del servicio upstream también se actualizó. Como práctica recomendada, configure los certificados HTTPS en un solo lugar. Si DCDN o WAF están desplegados upstream, puede configurar HTTPS únicamente en DCDN o WAF y usar HTTP para las solicitudes back-to-origin hacia la puerta de enlace.

Priorización de rutas

En la página Route Settings de una instancia de puerta de enlace, el orden de las rutas en la lista representa su prioridad de coincidencia, de mayor a menor. La prioridad se determina según el dominio y las reglas de ruta. La prioridad de coincidencia de dominios es exact domain name > wildcard domain name. Por ejemplo, test.example.com tiene mayor prioridad que *.example.com. Para el mismo dominio, la prioridad de coincidencia de ruta es Exact Match>Prefix Match>Match Regular Expression. Para el mismo dominio y ruta, las reglas con more matching conditions tienen mayor prioridad que aquellas con fewer matching conditions (las condiciones de coincidencia incluyen parámetros Header y Query).

Fallos en solicitudes HTTPS con DCDN

Este problema suele ocurrir porque DCDN no incluye una indicación de nombre de servidor (SNI) en sus solicitudes back-to-origin hacia la puerta de enlace. Para resolverlo, configure el SNI back-to-origin en la configuración de DCDN.

Fallos en solicitudes HTTPS con WAF

Este problema suele ocurrir porque WAF no incluye una indicación de nombre de servidor (SNI) en sus solicitudes back-to-origin hacia la puerta de enlace. Si utiliza el modo de acceso CNAME en WAF, modifique la configuración del dominio correspondiente. En el paso Enter Your Website Information, seleccione Enable Origin SNI.

¿Cloud-native API Gateway es compatible con WebSocket?

Sí, WebSocket es compatible y está habilitado de forma predeterminada.

¿Cloud-native API Gateway es compatible con gRPC?

Sí. gRPC utiliza el protocolo HTTP/2 para el transporte. Asegúrese de que EnableHttp2 = true esté establecido en la página Parameter Settings de la puerta de enlace.

¿Cloud-native API Gateway admite la descompresión GZIP?

Sí. Asegúrese de que EnableGzip = true esté establecido en la página Parameter Settings de la puerta de enlace. Los algoritmos admitidos son Gzip y Brotli, configurables mediante el parámetro ZipAlgorithm. El valor predeterminado es Gzip.

Conservación del formato de mayúsculas y minúsculas en encabezados

Sí. Asegúrese de que PreserveHeaderFormat = true esté establecido en la página Parameter Settings de la puerta de enlace. Este parámetro aplica únicamente a HTTP/1.0 y HTTP/1.1. La especificación del protocolo HTTP/2 requiere que todos los encabezados de solicitud y respuesta estén en minúsculas.

¿Cloud-native API Gateway es compatible con HTTP/3?

Sí. Asegúrese de que EnableHttp3 = true esté establecido en la página Parameter Settings de la puerta de enlace.

Los encabezados se convierten a minúsculas

De forma predeterminada, la puerta de enlace convierte todos los encabezados de solicitud y respuesta a minúsculas. Para conservar el formato original, establezca PreserveHeaderFormat = true en la página Parameter Settings de la puerta de enlace.

Fallos en solicitudes a un servicio de dominio DNS

Si el dominio DNS configurado es público, debe configurar SNAT en una puerta de enlace NAT de Internet para habilitar el acceso a Internet. De forma predeterminada, una instancia de puerta de enlace no tiene acceso a Internet.

Información de rastreo faltante en la consola de ARMS

Compruebe si el parámetro EnableGenerateRequestId está establecido en true en la configuración de la puerta de enlace. Si está en false, debe incluir un encabezado x-request-id válido en sus solicitudes. De lo contrario, la puerta de enlace no podrá reportar la información de rastreo.

Recepción de un error 400

Este error generalmente se debe a una de las siguientes razones:

• El cliente envió una solicitud con un error de protocolo. Revise el registro de acceso de la puerta de enlace buscando response_flags = DPE.

• El servicio backend devolvió un error 400. Consulte el registro de acceso de la puerta de enlace. Si el campo response_flags está vacío y el campo upstream_host tiene un valor, esto indica que el servicio backend devolvió el error 400. El valor de upstream_host corresponde a la dirección IP del servicio backend que recibió la solicitud.

Recepción de un error 401

Este error generalmente se debe a una de las siguientes razones:

• La puerta de enlace devolvió el error, lo que indica que faltan credenciales de acceso. Compruebe si ha habilitado autenticación, autorización o un complemento de WebAssembly.

• El servicio backend devolvió un error 401. Consulte el registro de acceso de la puerta de enlace. Si el campo response_flags está vacío y el campo upstream_host tiene un valor, esto indica que el servicio backend devolvió el error 401. El valor de upstream_host corresponde a la dirección IP del servicio backend que recibió la solicitud.

Recepción de un error 403

Este error generalmente se debe a una de las siguientes razones:

• La puerta de enlace devolvió el error, lo que indica permisos de acceso insuficientes. Compruebe si ha habilitado una lista de bloqueados o de permitidos de direcciones IP, autenticación, autorización o un complemento de WebAssembly.

• El servicio backend devolvió un error 403. Consulte el registro de acceso de la puerta de enlace. Si el campo response_flags está vacío y el campo upstream_host tiene un valor, esto indica que el servicio backend devolvió el error 403. El valor de upstream_host corresponde a la dirección IP del servicio backend que recibió la solicitud.

Recepción de un error 404

Este error generalmente se debe a una de las siguientes razones:

• No hay ninguna regla de ruta coincidente configurada en la puerta de enlace. Consulte el registro de acceso de la puerta de enlace. Si el registro contiene response_flags = NR, indica que no se encontró ninguna ruta.

• El servicio backend devolvió un error 404. Consulte el registro de acceso de la puerta de enlace. Si el campo response_flags está vacío y el campo upstream_host tiene un valor, esto indica que el servicio backend devolvió el error 404. El valor de upstream_host corresponde a la dirección IP del servicio backend que recibió la solicitud.

Recepción de un error 405

Si la protección de WAF está habilitada, es posible que la solicitud haya activado una regla de protección de WAF. En este caso, WAF devuelve el código de estado 405.

Recepción de un error 413

Este error generalmente se debe a una de las siguientes razones:

• El tamaño de la solicitud excede el límite del búfer de conexión de la puerta de enlace. Aumente el valor del parámetro DownstreamConnectionBufferLimits en la página Parameter Settings.

• El servicio backend devolvió un error 413. Consulte el registro de acceso de la puerta de enlace. Si el campo response_flags está vacío y el campo upstream_host tiene un valor, esto indica que el servicio backend devolvió el error 413. El valor de upstream_host corresponde a la dirección IP del servicio backend que recibió la solicitud.

Recepción de un error 429

Se activó una regla de limitación de la puerta de enlace. Consulte el registro de acceso de la puerta de enlace. Si el registro contiene response_flags = RL, revise su regla de limitación de la puerta de enlace.

Recepción de un error 502

Este error generalmente se debe a una de las siguientes razones:

• El servicio backend devolvió una respuesta con un error de protocolo. Consulte el registro de acceso de la puerta de enlace. Si el registro contiene response_flags = UPE, la causa más común es un campo Transfer-Encoding duplicado en el encabezado de respuesta del servicio backend. Revise su servicio backend.

• El servicio backend devolvió un error 502. Consulte el registro de acceso de la puerta de enlace. Si el campo response_flags está vacío y el campo upstream_host tiene un valor, esto indica que el servicio backend devolvió el error 502. El valor de upstream_host corresponde a la dirección IP del servicio backend que recibió la solicitud.

Recepción de un error 503

Este error puede deberse a las siguientes razones:

• El servicio destino especificado en la regla de ruta no tiene direcciones IP saludables. Consulte el registro de acceso de la puerta de enlace. Esta situación se indica mediante response_flags = UH.

• El servicio backend cerró la conexión mientras la puerta de enlace reenviaba la solicitud. Consulte el registro de acceso de la puerta de enlace. Esta situación se indica mediante response_flags = UC. Esto suele ocurrir porque el idle timeout de conexión del servicio backend es menor que el valor de UpstreamIdleTimeout de la puerta de enlace. Disminuya el valor de UpstreamIdleTimeout en la página Parameter Settings de la puerta de enlace.

• La puerta de enlace no puede conectarse a la dirección IP del servicio backend. Consulte el registro de acceso de la puerta de enlace. Esta situación se indica mediante response_flags = UF o response_flags = URX. Esto suele ocurrir porque el security group del servicio backend bloquea el acceso desde la puerta de enlace. Compruebe si el security group del servicio backend se ha configurado para permitir que la puerta de enlace acceda al puerto. Para más información, consulte Add a security group rule.

• El servicio backend no existe en la configuración de la puerta de enlace. Consulte el registro de acceso de la puerta de enlace. Esta situación se indica mediante response_flags = NC. Esto puede suceder por varias razones:

  • El servicio correspondiente ya no existe.

  • Si el servicio backend tiene varios puertos, debe seleccionar un puerto fijo, no uno dinámico, al configurar el servicio destino en la ruta.

  • Se seleccionó un puerto fijo para el servicio backend, pero el puerto del servicio ha cambiado.

• El servicio backend devolvió un error 503. Si el campo response_flags en el registro está vacío y el campo upstream_host no está vacío, esto indica que el servicio backend devolvió el error 503. El valor de upstream_host corresponde a la dirección IP del servicio backend que recibió la solicitud.

response_code es 0 en el registro de acceso

Un response_code de 0 indica que el cliente no recibió respuesta.

Esto suele ocurrir por una de dos razones:

• El cliente cerró la conexión prematuramente, por ejemplo, debido a una red móvil débil o a una respuesta lenta del backend. Esto se indica mediante response_flags = "DC" en el registro de acceso.

• Se envió una solicitud HTTPS sin indicación de nombre de servidor (SNI) y no se configuró ningún certificado HTTPS para un dominio comodín. SNI es una extensión de TLS que transporta información del nombre de dominio. Esto se indica mediante un campo requested_server_name vacío en el registro de acceso.

Consumo de tráfico público por solicitudes de ruta no coincidentes

Sí. Todas las solicitudes que pasan por la puerta de enlace consumen tráfico público, incluidas aquellas que no coinciden con ninguna ruta. La puerta de enlace utiliza tráfico para recibir la solicitud y enviar una respuesta.

Puede verificar el consumo de tráfico en el registro de acceso de la puerta de enlace mediante los siguientes campos:

• bytes_received: El tamaño del cuerpo de la solicitud, que representa el tráfico entrante.

• bytes_sent: El tamaño del cuerpo de la respuesta, que representa el tráfico saliente.

Las solicitudes que no coinciden con ninguna ruta se identifican en el registro de acceso con un valor response_code_details de route_not_found y un valor response_flags de NR.

Rastreo del origen de solicitudes de ruta no coincidentes

Después de habilitar la entrega de registros para la puerta de enlace, puede buscar solicitudes no coincidentes en Log Service y usar los campos del registro para identificar la dirección IP de origen. El registro de acceso registra todas las solicitudes, incluidas las fallidas. La dirección IP de origen se encuentra en el campo downstream_remote_address.

En Log Service, ejecute la siguiente consulta para filtrar las solicitudes no coincidentes:

response_code_details: "route_not_found"

En los resultados de la consulta, revise los siguientes campos para identificar el origen de la solicitud:

• downstream_remote_address: La dirección del cliente que se conectó a la puerta de enlace.

• x-forwarded-for: El campo x-forwarded-for del encabezado de solicitud HTTP, que indica la dirección IP de origen original de la solicitud. Si la solicitud pasa por proxies, este campo puede contener varias direcciones IP. La última dirección IP corresponde al salto anterior a la puerta de enlace.

Para calcular el consumo de tráfico de estas solicitudes anómalas, ejecute la siguiente consulta en Log Service:

response_code_details: "route_not_found" | SELECT sum(bytes_sent + bytes_received) AS total_bytes

¿Cómo agrego el encabezado Referer del cliente a los registros de solicitudes de Cloud-native API Gateway?

El encabezado Referer no se registra en los registros de acceso de la puerta de enlace de forma predeterminada. Para capturarlo, habilite la función de entrega de registros y configure una regla de coincidencia de encabezados personalizados en la consola de la puerta de enlace para incluir Referer como un campo de encabezado personalizado en la salida del registro.

Para más información sobre la función de entrega de registros, consulte Enable log delivery for a gateway.