# Anycast, proxy inverso y GRE: cómo se entrega realmente la protección DDoS > Tres modelos de entrega, tres conjuntos de concesiones. Qué cambia para tu DNS, tu TLS, tu latencia y tus logs según cómo se conecte la protección. - Category: Técnico - Author: Equipo Akarguard, Ingeniería de Seguridad - Published: Jun 24, 2025 - Canonical: https://akarguard.net/es/blog/anycast-vs-proxy-inverso --- Los proveedores describen la protección en términos de capacidad, pero el número que cambia tu arquitectura no es la capacidad — es el modelo de entrega. Hay tres de uso común, y difieren en qué tienes que cambiar, qué pueden inspeccionar y qué pasa cuando fallan. ## Proxy inverso Apuntas el DNS al proveedor. Sus servidores terminan la conexión, inspeccionan la petición y reenvían el tráfico limpio a tu origen. Como el proxy habla el protocolo, puede desafiar clientes, aplicar reglas por URL y cachear. El coste es que solo protege lo que se resuelve a través de él: cualquier cosa aún alcanzable en la dirección del origen se salta todo el sistema. ## Enrutamiento anycast La misma dirección se anuncia desde muchas ubicaciones, y internet entrega cada paquete a la más cercana. Las inundaciones se reparten entre sitios en vez de concentrarse en uno, que es lo que hace sobrevivibles los ataques volumétricos muy grandes. Funciona por debajo de la capa de aplicación, así que protege cualquier protocolo — pero no puede, por sí mismo, distinguir una petición válida de una maliciosa. ## GRE y protección enrutada Tu red anuncia sus prefijos a través de un proveedor de scrubbing, que filtra el tráfico y te tuneliza de vuelta el remanente limpio. Este es el modelo para organizaciones que poseen espacio de direcciones y necesitan proteger servicios no-HTTP a escala. Requiere ingeniería de red por ambos lados y cambia cómo se comporta tu enrutamiento bajo fallo. > **Son capas, no rivales** — Los grandes despliegues suelen combinarlos: anycast para absorber volumen, un proxy para inspeccionar peticiones, y protección enrutada para los servicios que no hablan HTTP. ## Lo que te cuesta cada uno - TLS: un proxy lo termina, lo que significa que el proveedor tiene un certificado. La protección enrutada no, lo que mantiene el cifrado de extremo a extremo. - Direcciones de cliente: tras un proxy, tus logs muestran direcciones del proxy salvo que las cabeceras reenviadas se lean correctamente — una fuente común de límite de tasa roto y geolocalización errónea. - Latencia: un salto extra es un salto extra. Los edges bien ubicados suelen amortizarse con una terminación TLS más cerca del usuario, pero esto vale la pena medirlo en vez de suponerlo. - Modo de fallo: si un proxy es inalcanzable, tu sitio es inalcanzable, aunque el origen esté sano. Sabe qué hace el proveedor cuando su propio edge falla. ## Elegir Para un sitio web o una API, un proxy inverso es casi siempre el punto de partida correcto: es un cambio de DNS, inspecciona el tráfico que de verdad te amenaza y puede revertirse en minutos. Sube por la pila solo cuando tengas una razón específica — un protocolo no-HTTP, tu propio espacio de direcciones, o una regla de cumplimiento sobre quién puede terminar tu TLS. --- Source: Akarguard Security Blog (https://akarguard.net/es/blog). Akarguard provides DDoS protection: traffic is proxied through our edge, attack traffic is filtered, and clean traffic reaches your origin. Reuse of this article with attribution and a link to the canonical URL is permitted.