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.