Un reverse proxy es un servidor que acepta requests de clientes y los reenvía a uno o más servidores backend. A diferencia de un forward proxy que actúa en nombre de clientes (ocultando identidad del cliente), un reverse proxy actúa en nombre de servidores (ocultando detalles del servidor backend). Los clientes se comunican con el reverse proxy, sin conocimiento de los servidores reales procesando sus requests.
Los reverse proxies sirven como punto único de entrada para aplicaciones web, proporcionando balanceo de carga entre múltiples servidores backend, terminación SSL/TLS para descargar operaciones criptográficas, caching para reducir carga del backend, y filtrado de seguridad para proteger servidores origin. El reverse proxy abstrae la infraestructura backend de los clientes, permitiendo cambios de servidor sin impacto en configuraciones de cliente.
Implementaciones comunes de reverse proxy incluyen Nginx, HAProxy, Apache HTTP Server, Envoy y Traefik. Los proveedores cloud ofrecen servicios de reverse proxy gestionados mediante load balancers (AWS ALB, Google Cloud Load Balancing, Azure Application Gateway). Los Content Delivery Networks (CDNs) actúan como reverse proxies distribuidos posicionados cerca de usuarios worldwide.
Last updated: 2026-04-23
Cómo Funciona un Reverse Proxy
Un reverse proxy se ubica entre clientes (navegadores, apps móviles, otros servicios) y servidores backend (servidores de aplicación, bases de datos, microservicios). Cuando un cliente hace un request, llega primero al reverse proxy. El proxy inspecciona el request, determina qué backend debe manejarlo, reenvía el request, recibe la respuesta y la retorna al cliente.
La lógica de enrutamiento de requests varía según el caso de uso. Los algoritmos de balanceo de carga distribuyen requests entre servidores backend (round-robin, least connections, IP hash). El enrutamiento basado en path dirige requests a diferentes backends basándose en URL path (/api/* a servidores API, /* a servidores web). El enrutamiento basado en headers usa Host headers o headers personalizados para enrutar a backends apropiados.
La terminación SSL/TLS ocurre en el reverse proxy, que mantiene certificados y maneja encriptación/desencriptación HTTPS. Los servidores backend se comunican sobre HTTP en redes internas, reduciendo sobrecarga criptográfica en servidores de aplicación. Esto centraliza gestión de certificados y habilita optimización HTTP/2 y HTTP/3 en la capa de proxy.
El caching de respuestas en el reverse proxy sirve requests repetidos directamente sin contactar backends. Respuestas almacenable en cache (assets estáticos, respuestas API públicas) se almacenan con políticas TTL (time-to-live). Requests subsecuentes para contenido en cache retornan inmediatamente del proxy, reduciendo latencia y carga del backend.
Funciones del Reverse Proxy
Balanceo de Carga
Distribuir requests entrantes entre múltiples servidores backend. Los algoritmos incluyen round-robin, weighted round-robin, least connections, IP hash. Previene que un solo servidor se convierta en cuello de botella. Permite escalado horizontal agregando servidores backend transparentemente.
Terminación SSL/TLS
Manejar encriptación HTTPS en la capa de proxy. Desencriptar tráfico TLS entrante, reenviar requests no encriptados a backends sobre redes privadas. Centraliza gestión de certificados. Reduce carga de CPU en servidores de aplicación de operaciones criptográficas.
Caching
Almacenar respuestas solicitadas frecuentemente. Servir contenido en cache sin contactar backends. Reduce latencia para requests repetidos. Disminuye carga del servidor backend. Implementa headers de caching HTTP (Cache-Control, ETag, Last-Modified).
Enrutamiento de Requests
Enrutar requests a backends apropiados basándose en path, headers, query parameters. Enrutamiento basado en path (/api/v1/* a servicio API, /static/* a servidor de archivos estáticos). Enrutamiento basado en host (diferentes dominios a diferentes aplicaciones). Enrutamiento basado en headers para versionamiento de API.
Seguridad
Ocultar direcciones IP de servidores backend de clientes. Implementar rate limiting para prevenir abuso. Filtrar requests maliciosos (SQL injection, patrones XSS). IP allowlisting y blocking. Integración de Web Application Firewall (WAF) para protección avanzada contra amenazas.
Compresión
Comprimir respuestas (gzip, brotli) antes de enviar a clientes. Reduce uso de ancho de banda. Mejora tiempos de carga de página. Descarga trabajo de compresión de servidores de aplicación.
Reverse Proxy vs. Forward Proxy
| Característica | Reverse Proxy | Forward Proxy |
|---|---|---|
| Actúa en nombre de | Servidores | Clientes |
| Posición | Entre internet y servidores | Entre clientes e internet |
| ¿Clientes conscientes del proxy? | No (transparente) | Sí (configurado) |
| Caso de uso | Proteger servidores, balancear carga | Control de acceso, anonimato |
| Ejemplo | Nginx, HAProxy, Cloud CDN | Squid, proxy corporativo |
| Oculta | Detalles del servidor backend | Identidad del cliente |
Un forward proxy ayuda a clientes a acceder recursos externos (control de acceso a internet, anonimización). Un reverse proxy ayuda a servidores a manejar requests entrantes (distribución de carga, seguridad). Ambos interceptan tráfico pero sirven a partes opuestas.
Cuándo Usar un Reverse Proxy
Usa un reverse proxy cuando necesites:
- Balanceo de carga entre múltiples servidores de aplicación
- Terminación SSL/TLS para simplificar gestión de certificados
- Caching para reducir carga del servidor backend
- Enrutamiento de requests a múltiples servicios backend
- Filtrado de seguridad y protección DDoS
- Ocultar infraestructura de servidor backend de clientes
No uses un reverse proxy cuando:
- Un solo servidor maneja todo el tráfico sin requerimientos de escalabilidad
- Se requiere acceso directo al servidor para protocolos específicos
- Aplicaciones sensibles a latencia donde la sobrecarga del proxy importa
- Arquitecturas muy simples sin necesidades de balanceo de carga o enrutamiento
Señales de que Necesitas un Reverse Proxy
- Múltiples servidores de aplicación requiriendo distribución de carga
- Complejidad de gestión de certificados SSL/TLS
- Servidores backend sobrecargados con tráfico almacenable en cache
- Necesidad de ocultar infraestructura backend de internet público
- Múltiples servicios requiriendo dominio único con enrutamiento basado en path
- Ataques DDoS o tráfico malicioso requiriendo filtrado
Métricas y Medición
Métricas de Rendimiento:
- Latencia de request: Tiempo agregado por capa de proxy (objetivo: <5ms de sobrecarga)
- Throughput: Requests por segundo manejados (depende de hardware y configuración)
- Latencia de backend: Tiempo de respuesta de servidores origin (monitorear por degradación)
- Cache hit rate: Porcentaje de requests servidos desde cache (objetivo: >80% para contenido estático)
Métricas de Confiabilidad:
- Uptime: Disponibilidad del reverse proxy (objetivo: 99.99%+)
- Salud del backend: Servidores backend saludables vs. no saludables
- Errores de conexión: Conexiones fallidas a backends
- Tasa de reintentos: Porcentaje de requests requiriendo reintento a backend diferente
Métricas de Seguridad:
- Requests bloqueados: Requests filtrados por reglas de seguridad
- Violaciones de rate limit: Requests excediendo rate limits
- Fallas de handshake SSL/TLS: Negociaciones TLS fallidas
- Expiración de certificado: Días hasta que expire el certificado (monitorear proactivamente)
Según benchmarks de rendimiento de NGINX (2024), un reverse proxy bien configurado puede manejar 100,000+ conexiones concurrentes con sobrecarga de latencia mínima (1-3ms). El caching puede reducir carga del backend en 60-80% para contenido estático y 20-40% para contenido dinámico con headers de cache apropiados.
Casos de Uso Reales
Aplicaciones Web
- Balancear tráfico entre múltiples servidores web
- Terminación SSL con certificados gestionados
- Caching de assets estáticos (imágenes, CSS, JavaScript)
- Rate limiting y throttling de API
Arquitectura de Microservicios
- Enrutar requests a microservicios apropiados
- Integración con service discovery
- Implementación de circuit breaker
- Transformación de request/response
Plataformas de E-Commerce
- Manejar picos de tráfico durante eventos de venta
- SSL para seguridad de procesamiento de pagos
- Cachear catálogos de productos y contenido estático
- Balanceo de carga geográfico para alcance global
API Gateways
- Autenticación y autorización
- Rate limiting por consumidor de API
- Enrutamiento de requests a servicios backend
- Versionamiento y deprecación de API
Entrega de Contenido
- Servidores edge CDN como reverse proxies distribuidos
- Caching geográfico para rendimiento global
- Protección de servidor origin
- Aceleración de contenido dinámico
Errores Comunes y Soluciones
Error: Reverse proxy único creando punto único de falla Solución: Desplegar múltiples instancias de reverse proxy detrás de balanceo de carga DNS o usar servicios gestionados con alta disponibilidad integrada. Health checks deben remover instancias de proxy no saludables. Monitorear salud del proxy como cualquier componente crítico de infraestructura.
Error: No ajustar connection pooling y timeouts Solución: Configurar timeouts de conexión apropiados, configuraciones keepalive y tamaños de pool de conexiones. Timeouts muy cortos causan reintentos innecesarios; timeouts muy largos retrasan detección de fallas. Emparejar configuraciones con características de rendimiento del backend.
Error: Cachear contenido dinámico inapropiadamente Solución: Cachear solo respuestas con headers de cache apropiados. Evitar cachear contenido autenticado específico de usuario. Implementar estrategia de invalidación de cache para contenido actualizado. Usar headers Cache-Control para controlar comportamiento de caching.
Error: Logging e observabilidad inadecuados Solución: Loggear metadatos de request, decisiones de enrutamiento, latencia de upstream y errores. Implementar distributed tracing a través de la capa de proxy. Configurar métricas para tasa de requests, latencia, tasa de errores y rendimiento de cache. Los logs permiten troubleshooting cuando surgen problemas.
Error: Ignorar soporte HTTP/2 y HTTP/3 Solución: Habilitar HTTP/2 en reverse proxy para soportar multiplexing. Considerar HTTP/3 (QUIC) para clientes móviles en redes no confiables. Los reverse proxies modernos soportan HTTP/2 y HTTP/3. Actualizar configuraciones para mejoras de protocolo.
Error: No implementar health checks apropiados Solución: Configurar health checks activos y pasivos. Health checks activos envían probes periódicos a backends. Health checks pasivos marcan backends como no saludables basándose en fallas de request. Implementar graceful drain durante despliegues de backend para evitar descartar requests.
Preguntas Frecuentes
¿Cuál es la diferencia entre un reverse proxy y un load balancer? Un load balancer distribuye tráfico entre servidores backend—una función específica. Un reverse proxy es un concepto más amplio que incluye balanceo de carga más terminación SSL, caching, filtrado de seguridad y enrutamiento de requests. Muchos reverse proxies (Nginx, HAProxy) funcionan como load balancers. Load balancers a menudo proporcionan capacidades de reverse proxy.
¿Necesito un reverse proxy si tengo un CDN? Los CDNs son reverse proxies distribuidos posicionados globalmente. Si usas Azion u otro CDN, ya tienes capacidades de reverse proxy. Aún puedes necesitar un reverse proxy en origin para balanceo de carga del backend. Muchas arquitecturas usan ambos: CDN en edge para distribución global, reverse proxy en origin para gestión del backend.
¿Cómo maneja un reverse proxy conexiones WebSocket? Los reverse proxies reenvían WebSocket upgrade requests a backends. Configurar timeouts de WebSocket para prevenir terminación prematura de conexión. Habilitar soporte WebSocket en configuración de proxy. Los reverse proxies de CDN deben soportar WebSocket proxying para aplicaciones en tiempo real.
¿Debo usar Nginx o HAProxy para un reverse proxy? Nginx destaca en reverse proxying HTTP/HTTPS, caching y servir contenido estático. HAProxy destaca en balanceo de carga a nivel TCP con health checking avanzado. Elegir Nginx para workloads pesados en HTTP con necesidades de caching. Elegir HAProxy para balanceo de carga TCP genérico o requerimientos de health check avanzados.
¿Cómo configuro SSL/TLS en un reverse proxy? Obtener certificados de Certificate Authority (Let’s Encrypt para certificados gratuitos). Configurar reverse proxy con rutas de certificado y llave privada. Habilitar TLS 1.2 o TLS 1.3. Deshabilitar cipher suites débiles. Configurar OCSP stapling para rendimiento. Redirigir HTTP a HTTPS. Considerar renovación automática de certificados.
¿Puede un reverse proxy mejorar el rendimiento? Sí. Los reverse proxies cachean respuestas, reduciendo carga del backend. Compresión reduce ancho de banda. Terminación SSL descarga trabajo criptográfico de servidores de aplicación. Connection pooling reduce sobrecarga de conexión backend. Multiplexing HTTP/2 reduce conteo de conexiones. Distribución geográfica mediante CDN reverse proxies reduce latencia.
¿Cómo manejan los reverse proxies la autenticación? Los reverse proxies pueden validar tokens de autenticación antes de reenviar requests. Implementar validación JWT en capa de proxy. Reenviar información de usuario autenticado a backends en headers. Para OAuth 2.0, configurar reverse proxy para validar access tokens. Esto descarga auth de servidores de aplicación y centraliza seguridad.
Cómo Aplica en la Práctica
Los reverse proxies son infraestructura fundamental para aplicaciones web modernas. Casi toda arquitectura web de producción incluye un reverse proxy para balanceo de carga, terminación SSL y seguridad. La abstracción permite cambios de infraestructura backend sin impacto en cliente, escalado horizontal mediante distribución de carga y controles de seguridad centralizados.
Estrategia de Implementación:
- Desplegar reverse proxy frente a servidores de aplicación
- Configurar algoritmo de balanceo de carga basándose en patrones de tráfico
- Configurar terminación SSL/TLS con renovación automática de certificados
- Implementar caching para contenido estático y respuestas API almacenable en cache
- Configurar health checks para servidores backend
- Monitorear métricas de proxy junto con métricas de aplicación
Mejores Prácticas de Configuración:
- Usar timeouts sensatos: timeouts de connect, read, write ajustados a rendimiento del backend
- Habilitar conexiones keepalive para reducir sobrecarga
- Configurar procesos y conexiones de worker apropiados para el hardware
- Implementar graceful reload para cambios de configuración sin descartar conexiones
- Loggear request ID para distributed tracing entre servicios
- Headers de seguridad (HSTS, X-Frame-Options) en capa de proxy
Consideraciones de Alta Disponibilidad:
- Desplegar múltiples instancias de reverse proxy
- Usar balanceo de carga DNS o anycast para distribución de proxy
- Configurar servidores upstream de backup
- Implementar circuit breakers para backends fallando
- Monitorear y alertar sobre métricas de salud del proxy
- Documentar procedimientos de failover para equipo de operaciones
Reverse Proxy en Azion
Azion proporciona funcionalidad de reverse proxy mediante Edge Applications:
- Balanceo de carga entre servidores origin con health checks
- Terminación SSL/TLS con certificados gestionados
- Edge caching para contenido estático y dinámico
- Enrutamiento de requests basado en path, headers y ubicación geográfica
- Web Application Firewall para filtrado de seguridad
- Real-Time Metrics para monitoreo de rendimiento
La red global de Azion actúa como un reverse proxy distribuido posicionado cerca de usuarios worldwide. Applications terminan conexiones, aplican reglas de seguridad y enrutan requests a servidores origin óptimos.
Aprende más sobre Applications y Load Balancing.
Sources
- Mozilla Developer Network. “HTTP Caching.” https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching