Los balanceadores de carga de aplicación externos globales te permiten personalizar tus propias respuestas de error cuando se genera un código de estado de error HTTP (4xx y 5xx). Puede personalizar las respuestas de error de los errores generados tanto por el balanceador de carga como por las instancias de backend. También puedes personalizar las respuestas de error para los códigos de error que se generan cuando Google Cloud Armor deniega el tráfico.
Aquí tienes un ejemplo de una página de error personalizada en la que puedes configurar respuestas de error para tu aplicación de consumidor externa con la marca y el logotipo de tu empresa, enlaces a páginas relacionadas y mensajes personalizados.
Si usas una política de respuesta de error personalizada, puedes configurar diferentes respuestas de error para distintos códigos de estado de error HTTP, dominios de URL, rutas de URL y campos de encabezado y parámetro de solicitud HTTP.
Devolver respuestas de error personalizadas te ayuda a mejorar la experiencia de tus usuarios, ya que ofrece las siguientes ventajas:
- Proporciona una experiencia de marca coherente
- Proporciona información contextual y relevante para mejorar la usabilidad y la experiencia de usuario.
- Mitiga el impacto negativo del tiempo de inactividad y los errores del lado del cliente
- Mejora la seguridad de la red
Si no configura una política de respuesta de error personalizada, se mostrará un objeto de error genérico sin marca, como se muestra en la figura 2.
Casos prácticos
La función de respuesta de error personalizada abarca muchos casos prácticos. En esta sección se ofrecen algunos ejemplos generales.
Definir tu propia página de mantenimiento
Puedes devolver una página de error con la marca y la información de la empresa cuando tus back-ends no estén en buen estado o estén en modo de mantenimiento. Puedes crear páginas de error contextuales que contengan información útil, como números de teléfono del centro de contacto o cuándo deben volver a intentar acceder al sitio web. Puedes personalizar las páginas de error en función de las condiciones de error coincidentes, como el nombre de host y el código de error HTTP.
Definir tu propia página de error predeterminada
Puedes configurar respuestas de error personalizadas por códigos de error específicos. Por ejemplo, puedes configurar una página de error con el mensaje "Iniciar sesión o registrarse" para el código de respuesta HTTP 401 (Unauthorized). También puedes configurar una página de error predeterminada que contenga la marca de la empresa y otra información relevante para todos los demás códigos de error HTTP de las series 4xx y 5xx.
Definir respuestas de error para las reglas de seguridad
Puedes devolver una página de error personalizada para los códigos de respuesta de error que se generan cuando las políticas de seguridad de Cloud Armor deniegan el tráfico. Debes asegurarte de configurar la página de error con el mismo código de error HTTP de la serie 4xx o 5xx que hayas introducido en la regla de seguridad de Cloud Armor.
Mitigar el impacto del tiempo de inactividad
Cuando proceda, puedes configurar una respuesta de error para que devuelva un código de estado HTTP 200 (OK) y muestre una página web estática para que los usuarios vean información más contextual y útil en lugar de una página de error durante el tiempo de inactividad.
Personalizar las respuestas de error en función del tipo de solicitud del cliente
Puedes personalizar una respuesta de error en función de los encabezados y parámetros de solicitud HTTP, como el encabezado Content-Type. Al enrutar la solicitud original al servicio de errores, el enrutamiento puede tener en cuenta el encabezado Content-Type para servir una página web (en el caso de las solicitudes de navegadores) o JSON (en el caso de las solicitudes de una API web).
Cómo funcionan las políticas de respuesta de error personalizadas
Se puede definir una política de respuesta de error personalizada en tres niveles del recurso de mapa de URLs: el nivel de balanceador de carga, el nivel de dominio de URL y el nivel de ruta de URL.
Nivel del balanceador de carga. Esta política se aplica a todo el tráfico que recibe el balanceador de carga.
Nivel de dominio de la URL. La política se aplica al tráfico dirigido a un nombre de dominio o a un nombre de host específicos, como
www.example.com.Nivel de ruta de URL. La política se aplica al tráfico dirigido a una ruta específica, como
www.example.com/images/*. En este nivel, también puedes usar condiciones de coincidencia avanzadas con encabezados y parámetros de solicitudes HTTP, comoContent-Type:application/json.
En la siguiente tabla se muestra una política de respuesta de error personalizada aplicada a nivel de balanceador de carga, de dominio de URL y de ruta de URL del mapa de URLs.
| Nivel de la política | Campo de la API |
|---|---|
| Balanceador de carga | urlMaps.defaultCustomErrorResponsePolicy |
| Dominio de URL | pathMatchers[].defaultCustomErrorResponsePolicy |
| Ruta de URL |
|
Si configura una política de respuesta de error personalizada en varios niveles del recurso URLMap, se devolverá el objeto de error especificado por la política de error personalizada en el nivel más bajo del mapa de URLs. Las políticas de respuesta de error definidas en un nivel inferior del mapa de URLs son más específicas y tienen prioridad sobre las políticas de respuesta de error definidas en un nivel superior del mapa de URLs.
Por ejemplo, una política de respuesta de error personalizada a nivel del balanceador de carga solo se aplica si la política coincide con las condiciones de error y no se ha definido ninguna política coincidente para el código de error en los niveles inferiores (el dominio de la URL o la ruta de la URL). Del mismo modo, una política de respuesta de error personalizada a nivel de dominio de URL solo se aplica si la política coincide con las condiciones de error y no se ha definido ninguna política coincidente para el código de error en el nivel inferior (la ruta de URL). Para obtener más información sobre esta configuración, consulta Configurar políticas de respuesta de error personalizadas granulares para diferentes dominios, rutas y códigos de respuesta de error.
Especificar varias reglas de respuesta de error para que coincidan con los códigos de respuesta de error HTTP
En cualquier nivel de una política de respuesta de error personalizada, puede especificar varias reglas de respuesta de error. Estas reglas pueden asociar una respuesta de error HTTP con códigos de error específicos o con un intervalo de códigos de error. Si especifica una regla para un intervalo de códigos de error, así como reglas para códigos de error específicos, tendrán prioridad las reglas con códigos de error específicos.
Por ejemplo, supongamos que configura una regla para el código de error 401 (Unauthorized) y otra para todos los códigos de error de la serie 4xx. Si el servicio de backend devuelve un código de error 401, se aplica la regla que coincida con el error 401. Sin embargo, si el servicio de backend devuelve un código de error 403, se aplicará la regla de errores 4xx.
Anular el código de respuesta HTTP
Las reglas de respuesta de error te permiten modificar el código de respuesta HTTP devuelto por el balanceador de carga. Esto significa que puedes anular el código de respuesta generado por el servidor y definir cuál debe ser el código de respuesta final de la solicitud. Puedes especificar que se devuelva cualquier código de respuesta HTTP, incluidos 200 (OK), la serie 4xx o la serie 5xx de códigos de respuesta, o cualquier otro código de respuesta de tres dígitos. Para obtener más información sobre cómo anular el código de respuesta, consulta el artículo Configurar una página de error para un código de error específico de un host concreto.
Si define un código de respuesta de anulación, se registrará como un nuevo campo overrideResponseCodeServed en los registros de balanceo de carga. Este campo solo se rellena en las solicitudes en las que la política de respuesta de error personalizada aplica un código de respuesta de anulación.
El código status registrado en el campo httpRequest no se ve afectado.
Registra el código de respuesta HTTP generado por el servidor o la respuesta HTTP que devuelve el balanceador de carga. Este código de estado puede ser diferente del código real que se envía al cliente si el código de respuesta se modifica mediante una política de respuesta de error personalizada.
Almacenar en caché respuestas de error personalizadas
Se puede almacenar en caché una respuesta de error personalizada especificando una política de almacenamiento en caché negativa para el backend que ha generado el error. El motivo es aplicar un control pormenorizado sobre el almacenamiento en caché en caso de errores o redirecciones habituales. De esta forma, se puede reducir la carga de tus orígenes y mejorar la experiencia del usuario final, ya que disminuye la latencia de las respuestas.
Una política de almacenamiento en caché negativa definida para el backend que ha generado el error siempre tiene prioridad sobre los metadatos Cache-Control definidos para el objeto de error en el servicio de errores. Además, si el balanceador de carga devuelve un código de respuesta de anulación, se aplica una política de almacenamiento en caché negativa en función del valor del código de respuesta de anulación y no en función del código de respuesta original que el backend haya devuelto al balanceador de carga. Si se devuelve un código que no es de error (HTTP 200) como código de respuesta de anulación, no se aplica una política de almacenamiento en caché negativa.
Si no ha transcurrido el tiempo de vida (TTL) de la respuesta de error, el balanceador de carga sigue sirviendo contenido en caché sin enrutar la solicitud a un servicio backend o a un contenedor backend. Sin embargo, este comportamiento depende de si Cloud CDN está habilitado en tu balanceador de carga.
Cloud CDN está habilitado en el balanceador de carga
En esta sección se describe el comportamiento del balanceador de carga cuando Cloud CDN está habilitado y se usan respuestas de error personalizadas.
Cuando el balanceador de carga recibe una solicitud, comprueba la caché de Cloud CDN. Si el balanceador de carga encuentra una respuesta almacenada en caché a la solicitud del usuario, el balanceador de carga devuelve la respuesta almacenada en caché al usuario. Esta respuesta almacenada en caché puede ser el contenido solicitado por el usuario o un objeto de error personalizado.
Si no hay caché, el balanceador de carga procesa la solicitud y la envía al backend.
Si el backend sirve una respuesta sin errores, se devuelve al usuario final. Sin embargo, si una solicitud de cliente detecta un error (un código de respuesta HTTP
4xxo5xx), el balanceador de carga intenta obtener el objeto de error personalizado del servicio de errores que hayas especificado de la siguiente manera:El balanceador de carga comprueba todas las políticas de respuesta de error personalizadas y obtiene la ruta adecuada del objeto de error personalizado que corresponde al código de estado de error y a otras condiciones de coincidencia.
El balanceador de carga reenvía la solicitud del objeto de error personalizado al servicio de errores que has especificado en la política de respuesta de error personalizada. El término servicio de errores hace referencia al segmento de backend o al servicio de backend que proporciona el contenido de error personalizado.
El balanceador de carga devuelve el objeto de error personalizado al cliente que ha enviado la solicitud. También envía el objeto a Cloud CDN para que lo almacene en caché durante el periodo especificado por
cdnPolicy.negativeCachingPolicy[].ttl.
Cloud CDN está inhabilitado en el balanceador de carga
Si Cloud CDN está inhabilitado, te recomendamos que uses un backend bucket como servicio de errores y no un backend service. Esto se debe a que un servicio de backend no puede almacenar contenido en caché si Cloud CDN está inhabilitado. Sin embargo, los segmentos de backend tienen una capacidad de almacenamiento en caché integrada y pueden almacenar en caché las respuestas de error aunque Cloud CDN esté inhabilitado.
Limitaciones
Las respuestas de error personalizadas solo se admiten con el balanceador de carga de aplicación externo global. No se admiten los modos regional ni clásico.
Si no se puede obtener el objeto de error personalizado del servicio de errores (por ejemplo, si la ruta de contenido está mal configurada), se servirá un objeto de error genérico sin marca.
La política de respuesta de error personalizada no monitoriza ni filtra el objeto devuelto por el servicio de errores para detectar riesgos de seguridad. Por lo tanto, debes esforzarte por eliminar las vulnerabilidades y limitar el impacto de una posible exposición.
Las respuestas de error personalizadas solo se admiten en los contenedores de Cloud Storage de lectura pública.
Para evitar errores de configuración al usar un segmento de Cloud Storage, consulta las prácticas recomendadas de Cloud Storage.
Las respuestas de error personalizadas no funcionan si tu balanceador de carga de aplicación externo global solo tiene contenedores de backend. Además del bucket de backend, debes tener al menos un servicio de backend asociado al balanceador de carga.
Los encabezados de respuesta personalizados definidos en función de la fuente de la respuesta de error personalizada no se aplican a las respuestas salientes.
La política de respuesta de error personalizada solo se aplica a las respuestas HTTP que proceden de los back-ends. Si la respuesta procede del frontend de Google (GFE), es posible que veas otros códigos de respuesta HTTP inesperados.
Las respuestas de error personalizadas no son compatibles con los siguientes tipos de solicitudes:
- Solicitudes con cuerpos que activan una política de inyección de errores.
- Solicitudes grandes en las que el servicio de backend envía una respuesta antes de leer completamente el cuerpo.
- Solicitudes que incluyen un encabezado
Authorization. Si una solicitud incluye un encabezadoAuthorization, Cloud Storage devuelve una respuestaAuthentication Required.
Precios
No hay ningún coste adicional por usar respuestas de error personalizadas. Se aplica la tarifa estándar del balanceo de carga. Google Cloud Para obtener más información, consulta los precios.