---
title: "Webservice Productor. Protección frente al exceso de llamadas por IP"
slug: "webservice-productor-protección-frente-al-exceso-de-llamadas-por-ip"
updated: 2026-10-14T04:37:57Z
published: 2026-10-14T04:37:57Z
canonical: "docs.gaia-soft.com/webservice-productor-protección-frente-al-exceso-de-llamadas-por-ip"
---
> ## Documentation Index
> Fetch the complete documentation index at: https://docs.gaia-soft.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Webservice Productor. Protección frente al exceso de llamadas por IP
gaProductorWebService incorpora un control de frecuencia de llamadas por IP de origen para reducir el impacto de abusos, clientes mal configurados y ataques de denegación de servicio. La protección se ejecuta antes de invocar la operación SOAP y se aplica de forma conjunta a los cuatro servicios publicados por la aplicación.
El valor inicial es de 20 solicitudes por segundo para cada IP. Cuando una IP consume su cuota, las llamadas adicionales se rechazan mediante un SOAP Fault identificable como RateLimitExceeded. La cuota vuelve a estar disponible a medida que las solicitudes abandonan la ventana deslizante de un segundo.
# **Servicios protegidos**
La protección cubre todas las operaciones públicas de los siguientes endpoints:
- OperationsServiceHost.svc
- ProduccionServiceHost.svc
- StockServiceHost.svc
- eAlbaranesServiceHost.svc
El límite es compartido. Por ejemplo, 12 llamadas a StockService y 8 llamadas a OperationsService realizadas por la misma IP dentro de la misma ventana consumen las 20 solicitudes disponibles.
Los endpoints internos de metadatos de WCF no se incluyen en el contador de operaciones SOAP.
# **Funcionamiento**
- Un ServiceHostFactory común añade el control a los cuatro hosts WCF.
Un inspector de mensajes obtiene la IP antes de ejecutar la operación solicitada.
- El contador utiliza una ventana deslizante de un segundo, evitando los picos que permitiría una ventana fija.
El acceso al contador es seguro ante llamadas concurrentes.
- Los estados de IP inactivos se eliminan periódicamente para limitar el consumo de memoria.
La cuota se mantiene en memoria y es común dentro del proceso de trabajo de IIS.
# **Configuración en web.config**
Los parámetros se encuentran en la sección appSettings del web.config desplegado. En el código fuente, App.config actúa como plantilla y se publica posteriormente como web.config.
| **Clave** | **Obligatoria** | **Descripción** |
| --- | --- | --- |
| RateLimiting.MaxRequestsPerSecond | No | Máximo conjunto de operaciones SOAP aceptadas por segundo para una IP. Debe ser un entero mayor que cero. Si falta o está vacío, se utiliza 20. |
| RateLimiting.ClientIpHeader | Solo con proxy | Nombre de la cabecera HTTP que contiene la IP original del cliente. El valor habitual es X-Forwarded-For. Debe quedar vacío en conexiones directas o NAT. |
| RateLimiting.TrustedProxyIps | Solo con proxy | IP exacta o lista de IP separadas por coma o punto y coma desde las que el proxy conecta con IIS. No admite rangos CIDR. |
**Cualquier modificación de estos valores requiere reiniciar la aplicación o reciclar el pool de IIS para que las instancias compartidas vuelvan a cargar la configuración.**
# **Escenario 1: IIS directo o firewall con NAT**
Cuando IIS recibe la conexión con la IP original del cliente, no debe confiar en ninguna cabecera enviada por la petición. Este es el caso habitual de una publicación directa y de un firewall que solo realiza NAT o port forwarding.
La IP utilizada será la dirección remota observada por IIS.
# **Escenario 2: reverse proxy, balanceador o firewall proxy**
Si el equipo perimetral termina la conexión y abre otra hacia IIS, la dirección remota será la del propio proxy. En este caso debe configurarse la cabecera en la que el proxy entrega la IP original y, de forma obligatoria, la IP interna desde la que conecta con IIS.
Si existen varios proxies autorizados:
La cabecera solo se procesa cuando la conexión llega desde una de esas IP exactas. Para cualquier otro origen se ignora, incluso si la petición incluye X-Forwarded-For. Esta validación evita que un cliente pueda cambiar arbitrariamente la identidad con la que consume la cuota.
Cuando X-Forwarded-For contiene varias direcciones, se toma la primera IP válida, que debe corresponder al cliente original según la configuración del proxy.
# **Respuesta cuando se supera el límite**
La operación de negocio no se ejecuta. WCF devuelve un SOAP Fault con el código RateLimitExceeded y el siguiente mensaje:
Se ha superado el máximo de llamadas por segundo permitido para la IP de origen.
Los clientes deben tratar esta respuesta como una limitación temporal. Se recomienda aplicar reintentos con espera incremental y evitar reintentos inmediatos en bucle.
# **Procedimiento de despliegue**
La actualización a la versión 2.14 o posterior de gaProductorWebService ya incluye de forma predeterminada un límite de 20 peticiones/segundo en web.config.
# **Validación recomendada**
- Enviar hasta 20 solicitudes dentro de un segundo desde una misma IP y confirmar que se aceptan.
Enviar una solicitud adicional dentro de la misma ventana y confirmar el Fault RateLimitExceeded.
- Repetir desde una segunda IP y confirmar que dispone de una cuota independiente.
Esperar a que finalice la ventana de un segundo y confirmar que la primera IP vuelve a ser admitida.
- En instalaciones con proxy, comprobar que dos clientes externos distintos se contabilizan con IP distintas.
Intentar enviar manualmente X-Forwarded-For desde un origen no confiable y confirmar que la cabecera se ignora.
# **Dimensionamiento y consideraciones**
El valor 20 es el punto de partida previsto. Debe ajustarse teniendo en cuenta la frecuencia normal de sincronización, el número de operaciones concurrentes de cada dispositivo y la capacidad del servidor.
- El límite se aplica por proceso de IIS. En un web garden o en varios servidores balanceados, cada proceso mantiene su propia cuota.
Esta medida protege la capa de aplicación, pero no sustituye las defensas de red, reglas del firewall, límites de IIS, WAF o protección DDoS del proveedor.
- Un valor demasiado bajo puede afectar a integraciones legítimas; un valor demasiado alto reduce la protección.
No se debe configurar ClientIpHeader sin TrustedProxyIps.
- TrustedProxyIps acepta direcciones IPv4 e IPv6 exactas, pero no subredes ni expresiones CIDR.
# **Resolución de incidencias**
| **Síntoma** | **Causa probable** | **Solución** |
| --- | --- | --- |
| Todos los usuarios comparten el límite | IIS ve únicamente la IP del proxy. | Configurar ClientIpHeader y la IP del proxy en TrustedProxyIps. |
| La aplicación no inicia | El máximo no es un entero positivo o se indicó una cabecera sin proxies confiables. | Corregir appSettings y reciclar el pool. |
| La cabecera se ignora | La IP remota no coincide exactamente con TrustedProxyIps o la cabecera no contiene una IP válida. | Verificar la IP de conexión observada por IIS y el formato de la cabecera. |
| El límite efectivo parece superior | Existen varios procesos IIS o varios servidores. | Multiplicar el límite por el número de procesos o aplicar un límite adicional en el proxy/WAF. |
| Clientes legítimos reciben RateLimitExceeded | El umbral es inferior a su patrón de ráfagas. | Analizar la frecuencia real y aumentar MaxRequestsPerSecond de forma controlada. |