Reenvío avanzado
Descripción general
Las políticas de reenvío avanzadas solo están disponibles para balanceadores de carga dedicados. Si ha habilitado Advanced Forwarding, puede agregar políticas de reenvío avanzadas a los oyentes HTTP y HTTPS de balanceadores de carga dedicados.
Puede agregar políticas de reenvío avanzadas a oyentes HTTP o HTTPS para reenviar solicitudes a diferentes grupos de servidores backend según el método de solicitud HTTP, el encabezado HTTP, la cadena de consulta o el bloque CIDR, además de nombres de dominio y direcciones URL. Tabla 1 describe las reglas y acciones que puede configurar para el reenvío de solicitudes.

A continuación se describe cómo funciona una política de reenvío avanzada:
- El cliente envía una solicitud al balanceador de carga.
- El balanceador de carga coincide con la solicitud según la regla de reenvío que configure.
- El balanceador de carga reenvía la solicitud al servidor backend correspondiente o devuelve una respuesta fija al cliente basada en la acción que configure.
- El balanceador de carga envía una respuesta al cliente.
Política de reenvío |
Descripción |
---|---|
Regla de reenvío |
Hay seis tipos de reglas de reenvío: nombre de dominio, URL, método de solicitud HTTP, encabezado HTTP, cadena de consulta y bloque CIDR Para obtener más información, véase Regla de reenvío. |
Acción |
Se admiten las siguientes acciones: reenviar a un grupo de servidores backend, redirigir a otro oyente, redirigir a otro URL y devolver un cuerpo de respuesta específico. Para obtener más información, véase Tipos de acción. |
Cómo se comparan las solicitudes
Después de agregar un oyente HTTP o HTTPS a un balanceador de carga, se genera una política de reenvío predeterminada. Esta política utiliza el protocolo y el puerto especificados para que el oyente coincida con las solicitudes y reenvíe las solicitudes al grupo de servidores de backend que especificó al agregar el oyente.
La política de reenvío predeterminada tiene la prioridad más baja y no se incluye al ordenar las políticas de reenvío. Se puede editar pero no se puede eliminar.
Cada solicitud se hace coincidir basándose en la prioridad de la política de reenvío (un valor más pequeño indica una prioridad más alta). Una vez coincidente una política de reenvío, la solicitud se reenvía según esta política de reenvío.
- Si la solicitud coincide con cualquier política de reenvío del oyente, se reenvía según esta política de reenvío.
- Si la solicitud no coincide con ninguna política de reenvío, se reenvía según la política de reenvío predeterminada.
Regla de reenvío
Las políticas de reenvío avanzadas admiten los siguientes tipos de reglas de reenvío: nombre de dominio, URL, método de solicitud HTTP, encabezado HTTP, consulta de string y bloque CIDR (direcciones IP de origen).
Regla de reenvío |
Descripción |
---|---|
Nombre de dominio |
Example Request URL: https://www.example.com/login.php?locale=en-us=#videos Domain name in the forwarding rule: www.example.com |
URL |
Para obtener más información acerca de las reglas de coincidencia de direcciones URL, consulte URL coincidente. Example Request URL: https://www.example.com/login.php?locale=en-us#videos URL in the forwarding rule: /login.php |
Cadena de consulta |
Solicitudes de ruta basadas en la consulta de string.
Una consulta de string consta de una clave y uno o más valores. Es necesario establecer la clave y los valores por separado.
Example Request URL: https://www.example.com/login.php?locale=en-us#videos A query string needs to be configured for the forwarding rule: Key: locale Value: en-us |
Método de solicitud de HTTP |
Enrutar solicitudes basadas en el método de HTTP.
Example GET |
Encabezado HTTP |
Solicitudes de ruta basadas en el encabezado HTTP.
Un encabezado HTTP consta de una clave y uno o más valores. Es necesario configurar la clave y los valores por separado.
Example Key: Accept-Language Value: en-us |
Bloque CIDR |
Enrute las solicitudes basadas en las direcciones IP de origen desde donde se originan las solicitudes. Example 192.168.1.0/24 or 2020:50::44/127 |
Tipos de acción
Las políticas de reenvío avanzadas admiten las siguientes acciones: reenviar a un grupo de servidores backend, redirigir a otro oyente, redirigir a otro URL y devolver un cuerpo de respuesta específico.
Acción |
Descripción |
---|---|
Reenvío a un grupo de servidores backend |
Las solicitudes se reenvían al grupo de servidores backend especificado. |
Redirigir a otro oyente |
Las solicitudes son redirigidas a otro oyente, que luego enruta las solicitudes a su grupo de servidores backend asociado.
NOTA:
Si selecciona Redirect to another oyente y crea una redirección para el oyente, redirigirá las solicitudes al oyente de HTTPS especificado, pero el control de acceso configurado para el oyente seguirá teniendo efecto. Por ejemplo, si configura una redirección para un oyente de HTTP, las solicitudes de HTTP para acceder a una página web serán redirigidas al oyente HTTPS que seleccione y manejadas por los servidores backend asociados con el oyente HTTPS. Como resultado, los clientes acceden a la página web a través de HTTPS. La configuración del HTTP oyente no será válida. |
Redirigir a otro URL |
Las solicitudes se redirigen al URL configurado. Cuando los clientes acceden al sitio web A, el balanceador de carga devuelve 302 o cualquier otro código de estado 3xx y redirige automáticamente a los clientes al sitio web B. Puede personalizar el URL de redirección que se devolverá a los clientes.
Configure al menos uno de los siguientes componentes:
Example URL for redirection: http://www.example1.com/index.html?locale=en-us#videos Protocol: HTTP Domain name: www.example1.com Port: 8081 Path: /index.html Query String: locale=en-us HTTP Status Code: 301 |
Devolver un cuerpo de respuesta específico |
Los balanceadores de carga devuelven una respuesta fija a los clientes. Puede personalizar el código de estado y el cuerpo de respuesta que los balanceadores de carga devuelven directamente a los clientes sin necesidad de enrutar las solicitudes a los servidores backend.
Configure los siguientes componentes:
Ejemplo text/plain Sorry, the language is not supported. text/css <head><style type="text/css">div {background-color:red}#div {font-size:15px;color:red}</style></head> text/html <form action="/" method="post" enctype="multipart/form-data"><input type="text" name="description" value="some text"><input type="file" name="myFile"><button type="submit">Submit</button></form> application/javascript String.prototype.trim = function() {var reExtraSpace = /^\s*(.*?)\s+$/;return this.replace(reExtraSpace, "$1")} application/json { "publicip": { "type": "5_bgp","ip_version": 4},"bandwidth": {"name": "bandwidth123","size": 10,"share_type": "PER"}}
NOTA:
Asegúrese de que el cuerpo de la respuesta no contiene caracteres de retorno de carro. De lo contrario, no se puede guardar. |
URL coincidente
Tabla 4 muestra cómo los URL configurados en las políticas de reenvío coinciden con los URL de las solicitudes.
URL de solicitud |
Política de reenvío |
URL en la política de reenvío |
Modo de coincidencia |
Prioridad de la política de reenvío |
Grupo de servidores backend de destino |
---|---|---|---|---|---|
/elb/abc.html |
Política de reenvío 01 |
/elb/abc.html |
Coincidencia de prefijos |
1 |
Grupo de servidores backend 01 |
Política de reenvío 02 |
/elb |
Coincidencia de prefijos |
2 |
Grupo de servidores backend 02 |
|
/exa/index.html |
Política de reenvío 03 |
/exa[^\s]* |
Coincidencia de expresiones regulares |
3 |
Grupo de servidores backend 03 |
Política de reenvío 04 |
/exa/index.html |
Coincidencia de expresiones regulares |
4 |
Grupo de servidores backend 04 |
|
/mpl/index.html |
Política de reenvío 05 |
/mpl/index.html |
Coincidencia exacta |
5 |
Grupo de servidores backend 05 |
Los URL se coinciden de la siguiente manera:
- Cuando el URL de solicitud es /elb/abc.html, coincide con la política de reenvío 01 y la política de reenvío 02. Sin embargo, la prioridad de la política de reenvío 01 es mayor que la de la política de reenvío 02. Se utiliza la política de reenvío 01, y las solicitudes se reenvían al grupo de servidores backend 01.
- Cuando la URL de solicitud es /exa/index.html, coincide con la política de reenvío 03 y la política de reenvío 04. Sin embargo, la prioridad de la política de reenvío 03 es mayor que la de la política de reenvío 04. Se utiliza la política de reenvío 03, y las solicitudes se reenvían al grupo de servidores backend 03.
- Si la URL de solicitud es /mpl/index.html, coincide exactamente con la política de reenvío 05, y las solicitudes se reenvían al grupo de servidores backend 05.
Coincidencia de URL basada en expresiones regulares
Una ruta puede contener letras, dígitos y caracteres especiales _~';@^-%#&$.*+?,=!:|\/()[]{} y debe comenzar con una barra diagonal (/). ${path} conserva la ruta de la solicitud.
Si selecciona la coincidencia de expresiones regulares, la ruta de la solicitud se sobrescribirá con las variables que coincidan con las expresiones regulares.
Cómo se sobrescriben las rutas solicitadas
- Coincidencia de URL: el cliente envía una solicitud, y la solicitud coincide con una expresión regular en la regla de reenvío. Puede especificar una o más expresiones regulares como condiciones de coincidencia y establecer varios grupos de captura representados por paréntesis ( ) para una expresión regular.
- Extracción y sustitución: extrae el contenido de los grupos de captura.
- Ruta de destino: los escribe a $1, $2, hasta $9 configurados para la ruta.
Ejemplo
Cuando un cliente solicita acceso a /test/ELB/elb/index que coincide con la expresión regular, /test/(.*)/(.*)/index, $1 será reemplazada por ELB y $2 por elb y luego la solicitud será redirigida a /ELB/elb.
Paso de combinación |
Descripción |
||
---|---|---|---|
Regla de reenvío: URL |
Coincidencia de expresiones regulares |
|
|
Acción: Redireccionar a otro URL |
Ruta |