🔄 ¿Qué es un servidor proxy?

Servidor Proxy (Proxy Server) es un servidor intermedio que actúa como mediador entre un cliente (su dispositivo) y el servidor de destino. Cuando utiliza un proxy, sus solicitudes no van directamente al sitio web, sino que pasan primero por el servidor proxy, que luego las reenvía al destino.

Concepto básico de funcionamiento

SIN PROXY (conexión directa):
┌──────────┐                                    ┌──────────┐
│  Cliente │ ────────── solicitud directa ──────→│  Servidor│
│   (Usted)│ ←───────── respuesta directa ────────│  (Sitio) │
└──────────┘                                    └──────────┘
   IP: 192.168.1.10                                IP: 93.184.216.34

CON PROXY (a través de intermediario):
┌──────────┐           ┌──────────┐           ┌──────────┐
│  Cliente │ ─────────→│  Servidor│ ─────────→│  Servidor│
│   (Usted)│           │   Proxy  │           │  (Sitio) │
│          │ ←─────────│          │ ←─────────│          │
└──────────┘           └──────────┘           └──────────┘
   IP: 192.168.1.10      IP: 203.0.113.45       IP: 93.184.216.34

¡El servidor ve la IP del proxy (203.0.113.45), no su IP!

¿Para qué sirve un servidor proxy?

🔒 Seguridad y anonimato

Oculta su dirección IP real de los servidores de destino, haciéndole anónimo en internet.

🌍 Evitar geobloqueos

Permite acceder a contenido restringido geográficamente.

⚡ Rendimiento

El almacenamiento en caché del contenido solicitado frecuentemente reduce la carga y acelera la carga.

🛡️ Filtrado de tráfico

Los proxies corporativos bloquean contenido no deseado y protegen contra amenazas.

⚖️ Balanceo de carga

Distribuye las solicitudes entrantes entre varios servidores para aumentar la fiabilidad.

🔍 Monitoreo y registro

Rastrea todas las solicitudes para análisis, seguridad o cumplimiento de políticas.

💡 Diferencia clave con VPN

El proxy opera a nivel de aplicación (ej. solo el navegador), mientras que la VPN cifra todo el tráfico del dispositivo a nivel de red. El proxy es más rápido y flexible, la VPN es más segura para todo el tráfico.

🎭 El rol del proxy como intermediario

El servidor proxy actúa como un intermediario inteligente entre el cliente y el servidor. No solo reenvía datos, sino que procesa activamente las solicitudes y respuestas, tomando decisiones sobre cómo manejarlas.

Funciones del proxy como intermediario

1. Modificación de solicitudes

El proxy puede alterar las cabeceras HTTP antes de enviar la solicitud al servidor de destino:

User-Agent: Cambia la información del navegador (puede simular ser Chrome en lugar de Firefox)
X-Forwarded-For: Añade información sobre la IP real del cliente
Accept-Language: Modifica el idioma preferido del contenido
Referer: Oculta o sustituye la fuente de la visita

2. Verificación de políticas de acceso

El proxy comprueba si el acceso al recurso solicitado está permitido basándose en:

Dirección IP del cliente (listas blancas/negras)
Autenticación (inicio de sesión/contraseña, tokens)
Hora del día (acceso a redes sociales solo fuera del horario laboral)
Categoría de contenido (bloqueo de juegos, pornografía, torrents)

3. Almacenamiento en caché de contenido

El proxy guarda copias de recursos solicitados frecuentemente (imágenes, CSS, JavaScript) y los entrega desde la caché, sin contactar al servidor. Esto ahorra tráfico y acelera la carga entre un 50% y un 90%.

4. Modificación de respuestas

El proxy puede modificar el contenido antes de enviarlo al cliente:

Compresión de contenido (gzip, brotli) para ahorrar tráfico
Bloqueo de anuncios y rastreadores
Inyección/eliminación de cabeceras de seguridad
Inyección de scripts (ej. para analíticas corporativas)

5. Registro y analíticas

El proxy registra información sobre cada solicitud: quién, cuándo, a dónde se dirigió, cuántos datos se transfirieron. Esto se utiliza para:

Monitoreo del uso de tráfico
Detección de anomalías y ataques
Cumplimiento de políticas corporativas
Depuración y diagnóstico de problemas

⚙️ Tres modos de operación del proxy

🔵 Passthrough (Modo de paso)

El proxy simplemente reenvía los datos sin modificaciones. Mínimo procesamiento, máxima velocidad.

🟢 Intercepting (Modo de intercepción)

El proxy analiza y modifica activamente las solicitudes/respuestas. Se utiliza para filtrado, optimización y seguridad.

🟡 Hybrid (Modo híbrido)

El proxy decide para cada solicitud si pasarla tal cual o procesarla. Por ejemplo, cachear solo estáticos y pasar APIs directamente.

🔄 Esquema de solicitud-respuesta a través del proxy

Analicemos en detalle qué sucede en cada etapa cuando solicita una página web a través de un servidor proxy.

Esquema paso a paso del funcionamiento del proxy

Paso 1: El cliente envía la solicitud al proxy

GET http://example.com/page.html HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
Proxy-Authorization: Basic dXNlcjpwYXNz
Connection: keep-alive

↓ La solicitud va al servidor proxy (no directamente a example.com)

El cliente está configurado para usar el proxy, por lo que la conexión se establece con el proxy incluso para la solicitud a example.com.

Paso 2: El proxy recibe y verifica la solicitud

El servidor proxy realiza una serie de comprobaciones:

✅ Autenticación: Verifica el usuario/contraseña en la cabecera Proxy-Authorization
✅ Autorización: ¿Tiene este usuario permiso para acceder a example.com?
✅ Filtrado: ¿Está el dominio example.com bloqueado por alguna política?
✅ Caché: ¿Hay una copia válida de /page.html en la caché?

Paso 3A: Si está en caché, lo devuelve inmediatamente

✅ CACHE HIT — ¡Encontrado en caché!

HTTP/1.1 200 OK
Content-Type: text/html
Age: 120
X-Cache: HIT from proxy-server

<html>...contenido de la página...</html>

↑ El proxy devuelve el contenido desde la caché (¡muy rápido!)

La cabecera Age: 120 significa que el contenido lleva 120 segundos en caché.

Paso 3B: Si no está en caché, solicita al servidor

❌ CACHE MISS — No está en caché, solicitud al servidor

El proxy modifica las cabeceras:

GET /page.html HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
X-Forwarded-For: 192.168.1.10      ← Añade su IP real
Via: 1.1 proxy-server              ← Indica que la solicitud pasa por un proxy
Connection: keep-alive

↓ El proxy envía la solicitud a example.com desde su IP

Paso 4: El servidor de destino procesa la solicitud

El servidor example.com recibe la solicitud del proxy y ve:

🌐 IP de origen: 203.0.113.45 (IP del proxy, no su 192.168.1.10)
📋 X-Forwarded-For: 192.168.1.10 (opcional, si el proxy es transparente)
🔗 Via: 1.1 proxy-server (información sobre el proxy)

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 12345
Cache-Control: max-age=3600
Last-Modified: Wed, 13 Jan 2025 10:00:00 GMT

<html>...contenido de la página...</html>

Paso 5: El proxy procesa la respuesta

El proxy recibe la respuesta y realiza acciones:

💾 Caché: Guarda el contenido en caché durante 3600 segundos (1 hora), según Cache-Control
🗜️ Compresión: Puede comprimir el contenido (gzip, brotli) para ahorrar tráfico
🔍 Filtrado: Comprueba el contenido en busca de virus, bloquea anuncios
📊 Registro: Escribe en el log: quién, cuándo, qué solicitó, tamaño de la respuesta

Paso 6: El proxy devuelve la respuesta al cliente

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 12345
X-Cache: MISS from proxy-server        ← Hubo una solicitud al servidor
X-Cache-Lookup: MISS from proxy-server
Via: 1.1 proxy-server

<html>...contenido de la página...</html>

↑ El cliente recibe el contenido

⚡ Rendimiento: con caché vs sin caché

Etapa	Sin caché	Con caché
Consulta DNS	50ms	0ms
Conexión TCP	100ms	0ms
TLS handshake	200ms	0ms
Procesamiento de solicitud	150ms	0ms
Transferencia de datos	300ms	50ms
TOTAL	800ms	50ms (¡16 veces más rápido!)

🏗️ Arquitectura del servidor proxy

Un servidor proxy moderno es un sistema complejo con varios componentes que trabajan juntos para garantizar rendimiento, seguridad y fiabilidad.

Componentes principales de la arquitectura

1️⃣ Connection Manager (Gestor de conexiones)

Funciones:

Acepta conexiones TCP entrantes de los clientes
Gestiona el pool de conexiones a los servidores de destino (connection pooling)
Reutiliza conexiones (HTTP Keep-Alive) para ahorrar recursos
Maneja tiempos de espera y desconexiones

Tecnologías: Arquitectura basada en eventos (epoll, kqueue), I/O asíncrono

2️⃣ Request Parser (Analizador de solicitudes)

Funciones:

Analiza las solicitudes HTTP (método, URL, cabeceras, cuerpo)
Valida la corrección de la solicitud
Extrae los parámetros de autenticación
Determina el tipo de solicitud (GET, POST, CONNECT, etc.)

3️⃣ Authentication & Authorization (Autenticación y autorización)

Métodos de autenticación:

Basic Auth: Usuario:contraseña en base64 (inseguro sin HTTPS)
IP Whitelist: Acceso solo desde direcciones IP específicas
Token Auth: Tokens de acceso (JWT, OAuth)
Certificate Auth: Certificados SSL del cliente

4️⃣ Cache Engine (Motor de caché)

Funciones:

Almacena copias de recursos en memoria/disco
Verifica la actualidad de la caché (Cache-Control, ETag, Last-Modified)
Utiliza algoritmos de expulsión (LRU, LFU) cuando el espacio es escaso
Soporta solicitudes condicionales (If-Modified-Since, If-None-Match)

Almacenamientos: Memcached, Redis, Varnish, implementaciones propias

5️⃣ Upstream Handler (Manejador de servidores upstream)

Funciones:

Selecciona el servidor de destino de una lista (balanceo de carga)
Establece la conexión con el servidor upstream
Reenvía la solicitud con cabeceras modificadas
Maneja errores y lógica de reintento (retry)

6️⃣ Response Processor (Procesador de respuestas)

Funciones:

Modifica las cabeceras de respuesta
Comprime el contenido (gzip, brotli)
Filtra/bloquea contenido no deseado
Añade cabeceras de caché y seguridad

7️⃣ Logging & Monitoring (Registro y monitoreo)

Qué se registra:

Timestamp, IP del cliente, URL solicitado
Código de respuesta, tamaño de los datos transferidos
Tiempo de procesamiento de la solicitud
Estadísticas de aciertos/fallos de caché
Errores y anomalías

↔️ Forward vs Reverse Proxy

Existen dos tipos principales de servidores proxy que cumplen roles opuestos: el Forward Proxy protege a los clientes, el Reverse Proxy protege a los servidores.

➡️ Forward Proxy

Clientes → Forward Proxy → Internet

Cliente1 ┐
Cliente2 ├─→ Forward → Servidor1
Cliente3 ┘    Proxy     Servidor2
                        Servidor3

Características:

Quién lo usa: Clientes (usuarios)
Objetivo: Ocultar a los clientes de los servidores
Ubicación: Lado del cliente
Quién conoce el proxy: Los clientes

Ejemplos de uso:

✅ Evitar bloqueos y censura
✅ Anonimato en internet
✅ Filtrado de contenido corporativo
✅ Web scraping con rotación de IP
✅ Evitar geobloqueos

Soluciones populares:

Squid, ProxyCove, Proxies Residenciales, Proxies SOCKS5

⬅️ Reverse Proxy

Internet → Reverse Proxy → Servidores

Cliente1     Reverse  ┌─→ Backend1
Cliente2  ──→ Proxy  ─┼─→ Backend2
Cliente3             └─→ Backend3

Características:

Quién lo usa: Propietarios de servidores
Objetivo: Proteger y optimizar servidores
Ubicación: Lado del servidor
Quién conoce el proxy: Los administradores

Ejemplos de uso:

✅ Balanceo de carga
✅ Terminación SSL/TLS
✅ Caché de contenido estático
✅ Protección contra DDoS
✅ Ocultar servidores reales

Soluciones populares:

Nginx, HAProxy, Cloudflare, AWS ELB, Varnish

🔍 Tabla comparativa

Parámetro	Forward Proxy	Reverse Proxy
Protege a	Clientes	Servidores
Visibilidad	Los clientes conocen el proxy	Los clientes no lo conocen
IP que ve el servidor	IP del proxy	IP del cliente (vía X-Forwarded-For)
Configuración	En el cliente	En el servidor
Caché	Para acelerar a los clientes	Para descargar a los servidores
Uso típico	Anonimato, evitar bloqueos	Balanceo de carga, seguridad

👁️ Transparent vs Explicit Proxy

Los servidores proxy también se clasifican según si el cliente conoce la existencia del proxy: Transparent (transparente) y Explicit (explícito).

👻 Transparent Proxy

Cómo funciona:

El proxy intercepta el tráfico a nivel de red (a través de un enrutador o firewall) sin configuración del cliente. El cliente cree que se conecta directamente al servidor, pero el tráfico pasa por el proxy.

El cliente cree:
GET example.com → Directamente

En realidad:
GET example.com → [Proxy Transparente] → example.com

¡El cliente no sabe del proxy!

Características:

✅ No requiere configuración en el cliente
✅ Funciona para todas las aplicaciones automáticamente
⚠️ Usa métodos GET/POST normales
⚠️ El cliente no envía Proxy-Authorization
❌ Más difícil trabajar con HTTPS (MITM)

Aplicación:

Redes corporativas (filtrado sin configuración)
Proxies de ISP (caching de contenido por el proveedor)
Wi-Fi público con filtro de contenido
Control parental

📢 Explicit Proxy

Cómo funciona:

El cliente está configurado explícitamente para usar el proxy. Todas las solicitudes se envían al servidor proxy, que luego las reenvía a los servidores de destino.

El navegador está configurado para el proxy:
Proxy: proxy.example.com:8080

Solicitud HTTP:
GET http://example.com/ HTTP/1.1
Host: example.com
Proxy-Authorization: Basic xyz123

Solicitud HTTPS:
CONNECT example.com:443 HTTP/1.1
Host: example.com:443
Proxy-Authorization: Basic xyz123

Características:

✅ El cliente conoce el proxy
✅ Soporte para autenticación
✅ Usa el método CONNECT para HTTPS
✅ Control total a nivel de aplicación
⚠️ Requiere configuración en cada aplicación

Aplicación:

Anonimato personal (ProxyCove)
Web scraping y parsing
Pruebas desde diferentes IPs
Gestión de múltiples cuentas

🔑 Diferencia clave: Método CONNECT

El proxy Transparent no recibe solicitudes CONNECT para HTTPS, ya que el navegador cree que se conecta directamente. Usa métodos GET/POST normales.

El proxy Explicit recibe solicitudes CONNECT para HTTPS, lo que permite establecer un túnel sin descifrar el tráfico (se mantiene el cifrado end-to-end).

🔌 Protocolos de servidores proxy

Los servidores proxy utilizan varios protocolos para comunicarse con los clientes. Cada protocolo tiene sus características, ventajas y limitaciones.

Protocolos principales

1. HTTP Proxy

Nivel OSI: Aplicación (Capa 7)
Qué proxy: Solo tráfico HTTP/HTTPS
Protocolos: HTTP/1.1, HTTP/2, HTTP/3
Características: Entiende cabeceras HTTP, puede modificar solicitudes
Uso: Navegadores, clientes API, web scrapers

2. HTTPS Proxy (HTTP CONNECT)

Nivel OSI: Aplicación (Capa 7)
Qué proxy: HTTPS a través de tunelización
Método: HTTP CONNECT para crear un túnel
Características: No ve el contenido HTTPS (cifrado end-to-end)
Uso: Proxy seguro para sitios HTTPS

3. SOCKS4 Proxy

Nivel OSI: Sesión (Capa 5)
Qué proxy: Solo conexiones TCP
Características: Protocolo simple, no soporta UDP ni autenticación
Uso: Obsoleto, rara vez se usa en 2025

4. SOCKS5 Proxy

Nivel OSI: Sesión (Capa 5)
Qué proxy: Tráfico TCP y UDP (cualquier protocolo)
Características: Soporte para autenticación, UDP, IPv6
Uso: Torrents, juegos, VoIP, proxy universal

📊 Comparación de protocolos

Característica	HTTP	HTTPS	SOCKS4	SOCKS5
Tráfico HTTP	✅	✅	✅	✅
Tráfico HTTPS	❌	✅	✅	✅
FTP, SMTP, POP3	❌	❌	✅	✅
Tráfico UDP	❌	❌	❌	✅
Autenticación	✅	✅	❌	✅
Velocidad	Alta	Alta	Muy alta	Muy alta
Caché	✅	✅	❌	❌

🌐 HTTP Proxy detallado

El proxy HTTP opera en la capa de aplicación y entiende la estructura del protocolo HTTP, lo que le permite analizar y modificar solicitudes.

Solicitud a través de HTTP Proxy

Solicitud HTTP normal (sin proxy)

GET /api/users HTTP/1.1
Host: api.example.com
User-Agent: Mozilla/5.0
Accept: application/json
Connection: keep-alive

→ Se envía directamente a api.example.com

Solicitud HTTP a través de proxy

GET http://api.example.com/api/users HTTP/1.1
Host: api.example.com
User-Agent: Mozilla/5.0
Accept: application/json
Proxy-Authorization: Basic dXNlcjpwYXNzd29yZA==
Proxy-Connection: keep-alive

→ Se envía al servidor proxy (¡no a api.example.com!)

Diferencias:

La URL en la primera línea es completa (con protocolo y dominio)
Se añade la cabecera Proxy-Authorization
Se usa Proxy-Connection en lugar de Connection

Qué hace el proxy con la solicitud

1. El proxy recibe la solicitud del cliente
2. Verifica Proxy-Authorization (usuario:contraseña)
3. Extrae la URL de destino: http://api.example.com/api/users
4. Modifica la solicitud para enviarla al servidor:

GET /api/users HTTP/1.1
Host: api.example.com
User-Agent: Mozilla/5.0
Accept: application/json
X-Forwarded-For: 192.168.1.100        ← Añade la IP real del cliente
Via: 1.1 proxy-server.com              ← Información sobre el proxy
X-Real-IP: 192.168.1.100               ← IP real del cliente
Connection: keep-alive

5. Envía la solicitud modificada a api.example.com
6. Recibe la respuesta de api.example.com
7. Reenvía la respuesta al cliente

🔐 Autenticación en HTTP Proxy

Basic Authentication

El usuario y la contraseña se codifican en base64 y se envían en la cabecera:

Proxy-Authorization: Basic dXNlcjpwYXNzd29yZA==

Se decodifica como: user:password

⚠️ ¡IMPORTANTE: Base64 NO es cifrado!
¡Úselo solo con proxies HTTPS!

Digest Authentication

Un método más seguro que utiliza hashing:

1. Cliente → Proxy: GET http://example.com/ HTTP/1.1
2. Proxy → Cliente: 407 Proxy Authentication Required
   Proxy-Authenticate: Digest realm="proxy", nonce="abc123"
3. El cliente calcula el hash:
   hash = MD5(username:realm:password)
   response = MD5(hash:nonce:MD5(method:uri))
4. Cliente → Proxy:
   Proxy-Authorization: Digest username="user",
                                 response="xyz789",
                                 nonce="abc123"

🔒 Método HTTP CONNECT

CONNECT es un método HTTP especial que convierte al proxy en un túnel TCP. Esto permite proxificar HTTPS sin descifrar el tráfico.

Cómo funciona CONNECT

Paso 1: El cliente solicita un túnel

CONNECT example.com:443 HTTP/1.1
Host: example.com:443
Proxy-Authorization: Basic dXNlcjpwYXNzd29yZA==
User-Agent: Mozilla/5.0

→ El cliente pide al proxy que establezca una conexión TCP a example.com:443

Importante: CONNECT se usa para el puerto 443 (HTTPS), no 80 (HTTP).

Paso 2: El proxy establece la conexión

El proxy realiza las siguientes acciones:
1. Verifica Proxy-Authorization
2. Establece una conexión TCP a example.com:443
3. Responde al cliente:

HTTP/1.1 200 Connection established

→ ¡Túnel establecido! El proxy ahora simplemente reenvía bytes.

Paso 3: El cliente inicia el TLS handshake

Cliente → Proxy → Servidor: ClientHello (inicio de TLS)
   [Versión: TLS 1.3]
   [Cipher Suites: TLS_AES_128_GCM_SHA256, ...]
   [SNI: example.com]  ← ¡DPI puede ver esto!
   [Supported Groups: x25519, secp256r1]

Servidor → Proxy → Cliente: ServerHello
   [Cipher seleccionado: TLS_AES_128_GCM_SHA256]
   [Certificado del servidor para example.com]
   [Key Share]

Cliente → Proxy → Servidor: ClientKeyExchange
   [Client Key Exchange - cifrado]
   [Change Cipher Spec]

Servidor → Proxy → Cliente: Server Finished
   [Server Finished - cifrado]

7. SESIÓN CIFRADA ESTABLECIDA
   CLIENTE ⇄ PROXY ⇄ SERVIDOR: [todos los datos posteriores están cifrados]

   GET /api/secret HTTP/1.1
   Host: example.com
   Authorization: Bearer secret_token_12345

   ↑ El proxy NO ve esta solicitud. Solo bytes cifrados.

Paso 4: Intercambio de datos cifrados

El proxy ve solo:
- Volumen de datos transferidos
- Tiempo de transferencia
- Dirección IP de destino

El proxy NO ve:
- URL de la solicitud
- Cabeceras HTTP
- Contenido de la página
- Cookies y contraseñas

📊 HTTP vs CONNECT — qué ve el proxy

Información	HTTP (puerto 80)	CONNECT (puerto 443)
Dominio	✅ Ve	✅ Ve
Ruta URL	✅ Ve completo	❌ No ve
Cabeceras HTTP	✅ Ve todas	❌ No ve
Contenido de página	✅ Ve todo el HTML	❌ Cifrado
Contraseñas y cookies	✅ Ve (¡PELIGROSO!)	❌ Cifrado
Volumen de tráfico	✅ Ve	✅ Ve

⚠️ ¡Importante para la seguridad!

NUNCA use un proxy HTTP normal para introducir contraseñas.
El proxy ve todo en texto plano. ¡Use siempre sitios HTTPS a través del método CONNECT o proveedores de proxy de confianza!

🧦 Protocolo SOCKS

SOCKS (Socket Secure) es un protocolo que opera a un nivel inferior al HTTP y puede proxificar cualquier tráfico TCP/UDP.

SOCKS5 Handshake

Etapa 1: Selección del método de autenticación

Cliente → Servidor:
┌─────┬─────┬──────────────────┐
│0x05 │0x02 │0x00 0x02         │
└─────┴─────┴──────────────────┘
  VER  NMETHODS  MÉTODOS

0x05 = Versión SOCKS 5
0x02 = 2 métodos de autenticación propuestos
0x00 = Sin autenticación
0x02 = Username/Password

Servidor → Cliente:
┌─────┬────────┐
│0x05 │0x02    │
└─────┴────────┘
  VER   MÉTODO

0x02 = Método Username/Password seleccionado

Etapa 2: Autenticación (si es requerida)

Cliente → Servidor:
┌─────┬──────┬──────────┬──────┬──────────┐
│0x01 │ ULEN │ USERNAME │ PLEN │ PASSWORD │
└─────┴──────┴──────────┴──────┴──────────┘

0x01 = Versión de subnegociación
ULEN = Longitud del username
USERNAME = Login
PLEN = Longitud de la contraseña
PASSWORD = Contraseña

Servidor → Cliente:
┌─────┬────────┐
│0x01 │0x00    │
└─────┴────────┘
  VER   ESTADO

0x00 = Autenticación exitosa

Etapa 3: Solicitud de conexión

Cliente → Servidor:
┌─────┬─────┬─────┬──────┬──────────┬──────┐
│0x05 │CMD  │0x00 │ATYP  │DST.ADDR  │PORT  │
└─────┴─────┴─────┴──────┴──────────┴──────┘

0x05 = SOCKS5
CMD:
  0x01 = CONNECT (Conexión TCP)
  0x02 = BIND (Esperar conexión entrante)
  0x03 = UDP ASSOCIATE (Reenvío UDP)
0x00 = Reservado
ATYP:
  0x01 = Dirección IPv4 (4 bytes)
  0x03 = Nombre de dominio (variable)
  0x04 = Dirección IPv6 (16 bytes)

Ejemplo para example.com:443
0x05 0x01 0x00 0x03 0x0B example.com 0x01BB

Servidor → Cliente:
┌─────┬─────┬─────┬──────┬──────────┬──────┐
│0x05 │0x00 │0x00 │0x01  │0.0.0.0   │0x0000│
└─────┴─────┴─────┴──────┴──────────┴──────┘

0x00 = Conexión establecida con éxito

Etapa 4: Transferencia de datos

Después de establecer la conexión, el proxy SOCKS actúa como un túnel TCP:

Cliente → SOCKS → Servidor: [datos de la aplicación]
Servidor → SOCKS → Cliente: [datos de la aplicación]

¡SOCKS simplemente reenvía bytes sin analizar el contenido!

Ventajas de SOCKS5

✅ Universalidad: Funciona con cualquier protocolo (HTTP, FTP, SMTP, BitTorrent, juegos)
✅ Soporte UDP: El único protocolo proxy con soporte completo para UDP
✅ Rendimiento: Baja sobrecarga, muy rápido
✅ Seguridad: No analiza el tráfico, total transparencia para las aplicaciones
✅ IPv6: Soporte nativo para direcciones IPv6

🔐 SSL/TLS Handshake a través de proxy

Comprender cómo funciona TLS a través de un proxy es fundamental para la seguridad. En 2025, TLS 1.3 es el estándar.

Proceso completo de HTTPS a través de proxy

1. CLIENTE → PROXY: TCP Handshake
   SYN → SYN-ACK → ACK (conexión con el proxy establecida)

2. CLIENTE → PROXY: HTTP CONNECT
   CONNECT example.com:443 HTTP/1.1
   Host: example.com:443
   Proxy-Authorization: Basic dXNlcjpwYXNzd29yZA==
   User-Agent: Mozilla/5.0

3. PROXY → SERVIDOR: TCP Handshake
   (el proxy establece la conexión con example.com:443)

4. PROXY → CLIENTE: 200 Connection established

5. CLIENTE → PROXY → SERVIDOR: TLS ClientHello
   [Versión: TLS 1.3]
   [Cipher Suites: TLS_AES_128_GCM_SHA256, ...]
   [SNI: example.com]  ← ¡DPI puede ver esto!
   [Supported Groups: x25519, secp256r1]

6. SERVIDOR → PROXY → CLIENTE: TLS ServerHello
   [Cipher seleccionado: TLS_AES_128_GCM_SHA256]
   [Certificado del servidor para example.com]
   [Key Share]

7. CLIENTE → PROXY → SERVIDOR: TLS Finished
   [Client Key Exchange - cifrado]
   [Change Cipher Spec]

8. SERVIDOR → PROXY → CLIENTE: TLS Finished
   [Server Finished - cifrado]

9. SESIÓN CIFRADA ESTABLECIDA
   CLIENTE ⇄ PROXY ⇄ SERVIDOR: [todos los datos posteriores están cifrados]

   GET /api/secret HTTP/1.1
   Host: example.com
   Authorization: Bearer secret_token_12345

   ↑ El proxy NO ve esta solicitud. Solo bytes cifrados.

⚠️ Qué pueden ver los sistemas DPI

Incluso a través de un túnel CONNECT, los sistemas DPI (Inspección Profunda de Paquetes) pueden extraer cierta información:

📌 SNI (Server Name Indication): El nombre de dominio en el ClientHello (transmitido en texto plano en TLS 1.2 y anteriores)
📌 Dirección IP de destino: Hacia dónde va la conexión
📌 Volumen de tráfico: Cuántos datos se transfieren
📌 Patrones de tiempo: Los patrones de actividad pueden revelar el tipo de contenido

🛡️ Protección: ECH (Encrypted Client Hello)

En 2025, los servidores modernos soportan ECH (Encrypted Client Hello), un estándar de TLS 1.3 que cifra el SNI. Esto hace imposible determinar el dominio a través de DPI.

🔓 SSL Interception (Proxy MITM)

Algunos proxies corporativos realizan SSL Interception, descifrando el tráfico HTTPS:

CLIENTE → [TLS al proxy] → PROXY → [TLS al servidor] → SERVIDOR

El proxy realiza dos TLS handshakes:
1. Con el cliente (usando su propio certificado)
2. Con el servidor (en nombre del cliente)

¡El proxy ve TODO el contenido HTTPS!

⚠️ Requiere la instalación del certificado raíz del proxy en el cliente
⚠️ El navegador mostrará una advertencia si el certificado no es de confianza

Aplicación: Redes corporativas para monitorear empleados, antivirus para escanear HTTPS en busca de virus, sistemas DLP.

📋 Cabeceras HTTP importantes para proxies

X-Forwarded-For

Contiene la dirección IP real del cliente. Añadida por el proxy.

X-Forwarded-For: 192.168.1.100

X-Real-IP

Alternativa a X-Forwarded-For, contiene una sola IP.

X-Real-IP: 192.168.1.100

Via

Muestra la cadena de proxies por la que ha pasado la solicitud.

Via: 1.1 proxy1, 1.1 proxy2

X-Forwarded-Proto

Indica el protocolo original de la solicitud (http/https).

X-Forwarded-Proto: https

X-Forwarded-Host

La cabecera Host original enviada por el cliente.

X-Forwarded-Host: example.com

Proxy-Authorization

Credenciales para la autenticación en el servidor proxy.

Proxy-Authorization: Basic xyz123

🔍 Cómo detecta el servidor al proxy

El servidor puede detectar que una solicitud proviene de un proxy por las siguientes señales:

Presencia de cabeceras X-Forwarded-*, Via
Dirección IP de una base de datos conocida de proxies
Incoherencia entre la geolocalización de la IP y otros parámetros (idioma, zona horaria)
Patrones de actividad anómalos (solicitudes demasiado rápidas)

Proxies profesionales para cualquier tarea

Ahora que entiende cómo funcionan los servidores proxy, ¡es hora de ponerlo en práctica!
ProxyCove: Infraestructura moderna con proxies en más de 195 países.
Registro con el código promocional ARTHELLO = +$1.3 de bono de inicio

Empezar con ProxyCove →

Tarifas ProxyCove 2025:

🏠 Residenciales — $2.7/GB 📱 Móviles — $3.8/GB 🏢 Centro de datos — $1.5/GB

📖 Continuación en Parte 2: Detalles técnicos — protocolos (HTTP, SOCKS), cabeceras, método CONNECT, SSL/TLS handshake a través de proxy, y funcionamiento con HTTPS.

Cómo funciona un servidor proxy — Parte 2

Detalles técnicos: protocolos HTTP y SOCKS, cabeceras, método CONNECT, SSL/TLS handshake a través de proxy, y particularidades del trabajo con HTTPS.

Actualizado: Enero 2025 | Tiempo de lectura: 17 minutos | Nivel: Avanzado

🔌 Protocolos de servidores proxy

Los servidores proxy utilizan diversos protocolos para comunicarse con los clientes. Cada protocolo tiene sus características, ventajas y limitaciones.

Protocolos principales

1. HTTP Proxy

Nivel OSI: Aplicación (Capa 7)
Qué proxy: Solo tráfico HTTP/HTTPS
Protocolos: HTTP/1.1, HTTP/2, HTTP/3
Características: Entiende cabeceras HTTP, puede modificar solicitudes
Uso: Navegadores, clientes API, web scrapers

2. HTTPS Proxy (HTTP CONNECT)

Nivel OSI: Aplicación (Capa 7)
Qué proxy: HTTPS a través de tunelización
Método: HTTP CONNECT para crear un túnel
Características: No ve el contenido HTTPS (cifrado end-to-end)
Uso: Proxy seguro para sitios HTTPS

3. SOCKS4 Proxy

Nivel OSI: Sesión (Capa 5)
Qué proxy: Solo conexiones TCP
Características: Protocolo simple, no soporta UDP ni autenticación
Uso: Obsoleto, rara vez se usa en 2025

4. SOCKS5 Proxy

Nivel OSI: Sesión (Capa 5)
Qué proxy: Tráfico TCP y UDP (cualquier protocolo)
Características: Soporte para autenticación, UDP, IPv6
Uso: Torrents, juegos, VoIP, proxy universal

📊 Comparación de protocolos

Característica	HTTP	HTTPS	SOCKS4	SOCKS5
Tráfico HTTP	✅	✅	✅	✅
Tráfico HTTPS	❌	✅	✅	✅
FTP, SMTP, POP3	❌	❌	✅	✅
Tráfico UDP	❌	❌	❌	✅
Autenticación	✅	✅	❌	✅
Velocidad	Alta	Alta	Muy alta	Muy alta
Caché	✅	✅	❌	❌

🌐 HTTP Proxy en detalle

El proxy HTTP opera en la capa de aplicación y entiende la estructura del protocolo HTTP, lo que le permite analizar y modificar solicitudes.

Solicitud a través de HTTP Proxy

Solicitud HTTP normal (sin proxy)

GET /api/users HTTP/1.1
Host: api.example.com
User-Agent: Mozilla/5.0
Accept: application/json
Connection: keep-alive

→ Se envía directamente a api.example.com

Solicitud HTTP a través de proxy

GET http://api.example.com/api/users HTTP/1.1
Host: api.example.com
User-Agent: Mozilla/5.0
Accept: application/json
Proxy-Authorization: Basic dXNlcjpwYXNzd29yZA==
Proxy-Connection: keep-alive

→ Se envía al servidor proxy (¡no a api.example.com!)

Diferencias:

La URL en la primera línea es completa (con protocolo y dominio)
Se añade la cabecera Proxy-Authorization
Se usa Proxy-Connection en lugar de Connection

Qué hace el proxy con la solicitud

1. El proxy recibe la solicitud del cliente
2. Verifica Proxy-Authorization (usuario:contraseña)
3. Extrae la URL de destino: http://api.example.com/api/users
4. Modifica la solicitud para enviarla al servidor:

GET /api/users HTTP/1.1
Host: api.example.com
User-Agent: Mozilla/5.0
Accept: application/json
X-Forwarded-For: 192.168.1.100        ← Añade la IP real del cliente
Via: 1.1 proxy-server.com              ← Información sobre el proxy
X-Real-IP: 192.168.1.100               ← IP real del cliente
Connection: keep-alive

5. Envía la solicitud modificada a api.example.com
6. Recibe la respuesta de api.example.com
7. Reenvía la respuesta al cliente

🔐 Autenticación en HTTP Proxy

Basic Authentication

El usuario y la contraseña se codifican en base64 y se envían en la cabecera:

Proxy-Authorization: Basic dXNlcjpwYXNzd29yZA==

Se decodifica como: user:password

⚠️ ¡IMPORTANTE: Base64 NO es cifrado!
¡Úselo solo con proxies HTTPS!

Digest Authentication

Un método más seguro que utiliza hashing:

1. Cliente → Proxy: GET http://example.com/ HTTP/1.1
2. Proxy → Cliente: 407 Proxy Authentication Required
   Proxy-Authenticate: Digest realm="proxy", nonce="abc123"
3. El cliente calcula el hash:
   hash = MD5(username:realm:password)
   response = MD5(hash:nonce:MD5(method:uri))
4. Cliente → Proxy:
   Proxy-Authorization: Digest username="user",
                                 response="xyz789",
                                 nonce="abc123"

🔒 Método HTTP CONNECT

CONNECT es un método HTTP especial que convierte al proxy en un túnel TCP. Esto permite proxificar HTTPS sin descifrar el tráfico.

Cómo funciona CONNECT

Paso 1: El cliente solicita un túnel

CONNECT example.com:443 HTTP/1.1
Host: example.com:443
Proxy-Authorization: Basic dXNlcjpwYXNzd29yZA==
User-Agent: Mozilla/5.0

→ El cliente pide al proxy que establezca una conexión TCP a example.com:443

Importante: CONNECT se usa para el puerto 443 (HTTPS), no 80 (HTTP).

Paso 2: El proxy establece la conexión

El proxy realiza las siguientes acciones:
1. Verifica Proxy-Authorization
2. Establece una conexión TCP a example.com:443
3. Responde al cliente:

HTTP/1.1 200 Connection established

→ ¡Túnel establecido! El proxy ahora simplemente reenvía bytes.

Paso 3: El cliente inicia el TLS handshake

Cliente → Proxy → Servidor: ClientHello (inicio de TLS)
   [Versión: TLS 1.3]
   [Cipher Suites: TLS_AES_128_GCM_SHA256, ...]
   [SNI: example.com]  ← ¡DPI puede ver esto!
   [Supported Groups: x25519, secp256r1]

Servidor → Proxy → Cliente: ServerHello
   [Cipher seleccionado: TLS_AES_128_GCM_SHA256]
   [Certificado del servidor para example.com]
   [Key Share]

Cliente → Proxy → Servidor: ClientKeyExchange
   [Client Key Exchange - cifrado]
   [Change Cipher Spec]

Servidor → Proxy → Cliente: Server Finished
   [Server Finished - cifrado]

7. SESIÓN CIFRADA ESTABLECIDA
   CLIENTE ⇄ PROXY ⇄ SERVIDOR: [todos los datos posteriores están cifrados]

   GET /api/secret HTTP/1.1
   Host: example.com
   Authorization: Bearer secret_token_12345

   ↑ El proxy NO ve esta solicitud. Solo bytes cifrados.

Paso 4: Intercambio de datos cifrados

El proxy ve solo:
- Volumen de datos transferidos
- Tiempo de transferencia
- Dirección IP de destino

El proxy NO ve:
- URL de la solicitud
- Cabeceras HTTP
- Contenido de la página
- Cookies y contraseñas

📊 HTTP vs CONNECT — qué ve el proxy

Información	HTTP (puerto 80)	CONNECT (puerto 443)
Dominio	✅ Ve	✅ Ve
Ruta URL	✅ Ve completo	❌ No ve
Cabeceras HTTP	✅ Ve todas	❌ No ve
Contenido de página	✅ Ve todo el HTML	❌ Cifrado
Contraseñas y cookies	✅ Ve (¡PELIGROSO!)	❌ Cifrado
Volumen de tráfico	✅ Ve	✅ Ve

⚠️ ¡Importante para la seguridad!

NUNCA use un proxy HTTP normal para introducir contraseñas.
El proxy ve todo en texto plano. ¡Use siempre sitios HTTPS a través del método CONNECT o proveedores de proxy de confianza!

🧦 Protocolo SOCKS

SOCKS (Socket Secure) es un protocolo que opera a un nivel inferior al HTTP y puede proxificar cualquier tráfico TCP/UDP.

SOCKS5 Handshake

Etapa 1: Selección del método de autenticación

Cliente → Servidor:
┌─────┬─────┬──────────────────┐
│0x05 │0x02 │0x00 0x02         │
└─────┴─────┴──────────────────┘
  VER  NMETHODS  MÉTODOS

0x05 = Versión SOCKS 5
0x02 = 2 métodos de autenticación propuestos
0x00 = Sin autenticación
0x02 = Username/Password

Servidor → Cliente:
┌─────┬────────┐
│0x05 │0x02    │
└─────┴────────┘
  VER   MÉTODO

0x02 = Método Username/Password seleccionado

Etapa 2: Autenticación (si es requerida)

Cliente → Servidor:
┌─────┬──────┬──────────┬──────┬──────────┐
│0x01 │ ULEN │ USERNAME │ PLEN │ PASSWORD │
└─────┴──────┴──────────┴──────┴──────────┘

0x01 = Versión de subnegociación
ULEN = Longitud del username
USERNAME = Login
PLEN = Longitud de la contraseña
PASSWORD = Contraseña

Servidor → Cliente:
┌─────┬────────┐
│0x01 │0x00    │
└─────┴────────┘
  VER   ESTADO

0x00 = Autenticación exitosa

Etapa 3: Solicitud de conexión

Cliente → Servidor:
┌─────┬─────┬─────┬──────┬──────────┬──────┐
│0x05 │CMD  │0x00 │ATYP  │DST.ADDR  │PORT  │
└─────┴─────┴─────┴──────┴──────────┴──────┘

0x05 = SOCKS5
CMD:
  0x01 = CONNECT (Conexión TCP)
  0x02 = BIND (Esperar conexión entrante)
  0x03 = UDP ASSOCIATE (Reenvío UDP)
0x00 = Reservado
ATYP:
  0x01 = Dirección IPv4 (4 bytes)
  0x03 = Nombre de dominio (variable)
  0x04 = Dirección IPv6 (16 bytes)

Ejemplo para example.com:443
0x05 0x01 0x00 0x03 0x0B example.com 0x01BB

Servidor → Cliente:
┌─────┬─────┬─────┬──────┬──────────┬──────┐
│0x05 │0x00 │0x00 │0x01  │0.0.0.0   │0x0000│
└─────┴─────┴─────┴──────┴──────────┴──────┘

0x00 = Conexión establecida con éxito

Etapa 4: Transferencia de datos

Después de establecer la conexión, el proxy SOCKS actúa como un túnel TCP:

Cliente → SOCKS → Servidor: [datos de la aplicación]
Servidor → SOCKS → Cliente: [datos de la aplicación]

¡SOCKS simplemente reenvía bytes sin analizar el contenido!

Ventajas de SOCKS5

✅ Universalidad: Funciona con cualquier protocolo (HTTP, FTP, SMTP, BitTorrent, juegos)
✅ Soporte UDP: El único protocolo proxy con soporte completo para UDP
✅ Rendimiento: Baja sobrecarga, muy rápido
✅ Seguridad: No analiza el tráfico, total transparencia para las aplicaciones
✅ IPv6: Soporte nativo para direcciones IPv6

🔐 SSL/TLS Handshake a través de proxy

Comprender cómo funciona TLS a través de un proxy es fundamental para la seguridad. En 2025, TLS 1.3 es el estándar.

Proceso completo de HTTPS a través de proxy

1. CLIENTE → PROXY: TCP Handshake
   SYN → SYN-ACK → ACK (conexión con el proxy establecida)

2. CLIENTE → PROXY: HTTP CONNECT
   CONNECT example.com:443 HTTP/1.1
   Host: example.com:443
   Proxy-Authorization: Basic dXNlcjpwYXNzd29yZA==
   User-Agent: Mozilla/5.0

3. PROXY → SERVIDOR: TCP Handshake
   (el proxy establece la conexión con example.com:443)

4. PROXY → CLIENTE: 200 Connection established

5. CLIENTE → PROXY → SERVIDOR: TLS ClientHello
   [Versión: TLS 1.3]
   [Cipher Suites: TLS_AES_128_GCM_SHA256, ...]
   [SNI: example.com]  ← ¡DPI puede ver esto!
   [Supported Groups: x25519, secp256r1]

6. SERVIDOR → PROXY → CLIENTE: TLS ServerHello
   [Cipher seleccionado: TLS_AES_128_GCM_SHA256]
   [Certificado del servidor para example.com]
   [Key Share]

7. CLIENTE → PROXY → SERVIDOR: TLS Finished
   [Client Key Exchange - cifrado]
   [Change Cipher Spec]

8. SERVIDOR → PROXY → CLIENTE: TLS Finished
   [Server Finished - cifrado]

9. SESIÓN CIFRADA ESTABLECIDA
   CLIENTE ⇄ PROXY ⇄ SERVIDOR: [todos los datos posteriores están cifrados]

   GET /api/secret HTTP/1.1
   Host: example.com
   Authorization: Bearer secret_token_12345

   ↑ El proxy NO ve esta solicitud. Solo bytes cifrados.

⚠️ Qué pueden ver los sistemas DPI

Incluso a través de un túnel CONNECT, los sistemas DPI (Inspección Profunda de Paquetes) pueden extraer cierta información:

📌 SNI (Server Name Indication): El nombre de dominio en el ClientHello (transmitido en texto plano en TLS 1.2 y anteriores)
📌 Dirección IP de destino: Hacia dónde va la conexión
📌 Volumen de tráfico: Cuántos datos se transfieren
📌 Patrones de tiempo: Los patrones de actividad pueden revelar el tipo de contenido

🛡️ Protección: ECH (Encrypted Client Hello)

En 2025, los servidores modernos soportan ECH (Encrypted Client Hello), un estándar de TLS 1.3 que cifra el SNI. Esto hace imposible determinar el dominio a través de DPI.

🔓 SSL Interception (Proxy MITM)

Algunos proxies corporativos realizan SSL Interception, descifrando el tráfico HTTPS:

CLIENTE → [TLS al proxy] → PROXY → [TLS al servidor] → SERVIDOR

El proxy realiza dos TLS handshakes:
1. Con el cliente (usando su propio certificado)
2. Con el servidor (en nombre del cliente)

¡El proxy ve TODO el contenido HTTPS!

⚠️ Requiere la instalación del certificado raíz del proxy en el cliente
⚠️ El navegador mostrará una advertencia si el certificado no es de confianza

Aplicación: Redes corporativas para monitorear empleados, antivirus para escanear HTTPS en busca de virus, sistemas DLP.

📋 Cabeceras HTTP importantes para proxies

X-Forwarded-For

Contiene la dirección IP real del cliente. Añadida por el proxy.

X-Forwarded-For: 192.168.1.100

X-Real-IP

Alternativa a X-Forwarded-For, contiene una sola IP.

X-Real-IP: 192.168.1.100

Via

Muestra la cadena de proxies por la que ha pasado la solicitud.

Via: 1.1 proxy1, 1.1 proxy2

X-Forwarded-Proto

Indica el protocolo original de la solicitud (http/https).

X-Forwarded-Proto: https

X-Forwarded-Host

La cabecera Host original enviada por el cliente.

X-Forwarded-Host: example.com

Proxy-Authorization

Credenciales para la autenticación en el servidor proxy.

Proxy-Authorization: Basic xyz123

🔍 Cómo detecta el servidor al proxy

El servidor puede detectar que una solicitud proviene de un proxy por las siguientes señales:

Presencia de cabeceras X-Forwarded-*, Via
Dirección IP de una base de datos conocida de proxies
Incoherencia entre la geolocalización de la IP y otros parámetros (idioma, zona horaria)
Patrones de actividad anómalos (solicitudes demasiado rápidas)

Proxies profesionales con soporte para todos los protocolos

¡Ahora sabe los detalles técnicos de cómo funciona un proxy: use este conocimiento con ProxyCove!
HTTP, HTTPS, SOCKS5: todos los protocolos son compatibles. 195+ países. TLS 1.3.
Registro con el código promocional ARTHELLO = +$1.3 de bono de inicio

Probar ProxyCove →

Tarifas ProxyCove 2025:

🏠 Residenciales — $2.7/GB 📱 Móviles — $3.8/GB 🏢 Centro de datos — $1.5/GB

📖 Continuación en la Parte Final: Caching, balanceo de carga, ejemplos prácticos, selección de proxy para distintas tareas, y conclusiones.

Cómo funciona un servidor proxy — Final

Caching, balanceo de carga, ejemplos prácticos, selección de proxy para distintas tareas, y conclusiones. Todo lo que necesita saber sobre proxies en 2025.

Actualizado: Enero 2025 | Tiempo de lectura: 16 minutos | Nivel: Intermedio - Avanzado

💾 Mecanismos de caché en proxies

El almacenamiento en caché es una de las funciones clave de los servidores proxy, ya que permite acelerar la carga de contenido entre un 50% y un 90% y reducir la carga en los servidores backend.

Cómo funciona el caching

Algoritmo de decisión de caché

1. Llega una solicitud al proxy
   GET /images/logo.png

2. El proxy calcula la clave de caché:
   key = hash(método + URL + cabeceras)
   key = "GET:example.com:/images/logo.png"

3. Verificación de caché:
   if (caché existe AND caché es válida):
       ✅ CACHE HIT
       - Comprobar Cache-Control: max-age
       - Comprobar cabecera Expires
       - Si es válida → devolver desde caché
       - Si está obsoleta → solicitud condicional (If-Modified-Since)
   else:
       ❌ CACHE MISS
       - Solicitar al servidor de origen
       - Guardar en caché (si es cacheable)
       - Devolver al cliente

4. Determinar si se puede cachear:
   ✅ Sí, si:
      - Método HTTP: GET o HEAD
      - Estado: 200, 301, 304, 404
      - Cache-Control: public, max-age > 0
      - NO hay cabeceras: Set-Cookie, Authorization
   ❌ No, si:
      - Cache-Control: no-store, private
      - Pragma: no-cache
      - Solicitudes POST, PUT, DELETE
      - Contenido dinámico con Set-Cookie

Cabeceras de caché

Cabecera	Valor	Acción del proxy
Cache-Control: max-age=3600	Cachear 1 hora	✅ Cachea
Cache-Control: no-cache	Verificar siempre con el servidor	⚠️ Solicitud condicional
Cache-Control: no-store	Nunca cachear	❌ No cachea
Cache-Control: public	Se puede cachear públicamente	✅ Cachea
Cache-Control: private	Solo para un cliente individual	❌ No cachea
ETag: "abc123"	Identificador de versión	✅ Para validación
Last-Modified: date	Fecha de modificación	✅ Para validación

Solicitudes condicionales (Conditional Requests)

Cuando la caché está obsoleta, el proxy puede verificar la actualidad con solicitudes condicionales:

Escenario 1: Verificación por ETag
────────────────────────────────────
Proxy → Servidor:
GET /image.jpg HTTP/1.1
If-None-Match: "abc123"

Si el archivo NO ha cambiado:
Servidor → Proxy:
HTTP/1.1 304 Not Modified
ETag: "abc123"

→ El proxy sirve desde la caché (¡ahorro de tráfico!)

Si el archivo ha cambiado:
Servidor → Proxy:
HTTP/1.1 200 OK
ETag: "xyz789"
[nuevo contenido]

→ El proxy actualiza la caché


Escenario 2: Verificación por fecha
────────────────────────────────────
Proxy → Servidor:
GET /style.css HTTP/1.1
If-Modified-Since: Wed, 13 Jan 2025 10:00:00 GMT

Servidor → Proxy:
HTTP/1.1 304 Not Modified

→ La caché es válida, la servimos desde la caché

Algoritmos de expulsión de caché

Cuando la caché se llena, el proxy debe decidir qué eliminar:

1. LRU (Least Recently Used)

Elimina los objetos a los que no se ha accedido recientemente. El algoritmo más popular.

image1.jpg (último acceso: hace 2 minutos)
style.css (último acceso: hace 10 minutos) ← Se elimina primero
logo.png (último acceso: hace 1 minuto)

2. LFU (Least Frequently Used)

Elimina los objetos que se han solicitado con menor frecuencia.

logo.png (solicitudes: 1000)
style.css (solicitudes: 50) ← Se elimina primero
image1.jpg (solicitudes: 500)

3. FIFO (First In First Out)

Elimina los objetos más antiguos en la caché. Simple, pero no siempre eficiente.

4. Algoritmos conscientes del tamaño

Tienen en cuenta el tamaño de los objetos. Por ejemplo, eliminan archivos grandes poco usados para dejar espacio a muchos archivos pequeños populares.

📊 Eficiencia del caching

Estadísticas típicas de caché de proxy web:

📈 Hit Rate: 60-80% para contenido estático (imágenes, CSS, JS)
📉 Hit Rate: 5-20% para contenido dinámico (APIs, HTML)
⚡ Aceleración: El acierto de caché se procesa en 10-50ms frente a 200-800ms de un fallo de caché
💾 Ahorro de tráfico: 40-70% de reducción del tráfico saliente al origen
🔋 Reducción de carga: 50-90% de reducción de solicitudes a servidores backend

⚖️ Balanceo de carga

El Reverse Proxy se utiliza a menudo para distribuir la carga entre varios servidores backend, garantizando alta disponibilidad y escalabilidad.

Algoritmos de balanceo de carga

1️⃣ Round Robin (Circular)

Las solicitudes se distribuyen por turnos entre los servidores.

Solicitud 1 → Servidor A
Solicitud 2 → Servidor B
Solicitud 3 → Servidor C
Solicitud 4 → Servidor A (el ciclo se repite)

✅ Ventajas: Simplicidad, distribución uniforme
❌ Desventajas: No considera la carga de los servidores

2️⃣ Least Connections (Menos conexiones)

La nueva solicitud se dirige al servidor con el menor número de conexiones activas.

Servidor A: 5 conexiones
Servidor B: 2 conexiones ← Nueva solicitud aquí
Servidor C: 8 conexiones

✅ Ventajas: Considera la carga actual
✅ Ideal para conexiones de larga duración (WebSocket, streaming)

3️⃣ IP Hash

El servidor se selecciona basándose en el hash de la dirección IP del cliente. Un cliente siempre llega al mismo servidor.

hash(192.168.1.100) % 3 = 1 → Servidor B
hash(192.168.1.200) % 3 = 0 → Servidor A
hash(192.168.1.150) % 3 = 2 → Servidor C

✅ Ventajas: Persistencia de sesión sin sticky sessions
❌ Desventajas: Distribución desigual con pocos clientes

4️⃣ Weighted Round Robin (Circular ponderado)

Se asignan pesos a los servidores según su potencia.

Servidor A (peso: 5) → recibe 5 solicitudes
Servidor B (peso: 2) → recibe 2 solicitudes
Servidor C (peso: 3) → recibe 3 solicitudes

Total de 10 solicitudes distribuidas en proporción 5:2:3

✅ Ideal para servidores heterogéneos (diferente potencia)

5️⃣ Least Response Time

Se selecciona el servidor con el menor tiempo de respuesta y el menor número de conexiones.

Servidor A: 50ms, 10 conexiones
Servidor B: 30ms, 5 conexiones ← Seleccionado
Servidor C: 100ms, 3 conexiones

✅ Rendimiento óptimo para los clientes
⚠️ Requiere monitoreo de health checks

🏥 Health Checks (Verificaciones de salud)

El Load Balancer comprueba constantemente la disponibilidad de los servidores backend:

Verificaciones Activas (Active Health Checks)

El proxy envía activamente solicitudes de prueba:

Cada 5 segundos:
GET /health HTTP/1.1
Host: backend-server

Respuesta 200 OK → Servidor sano ✅
Respuesta 5xx o timeout → Servidor no disponible ❌

Verificaciones Pasivas (Passive Health Checks)

Análisis de las solicitudes reales de los clientes:

Si en las últimas 10 solicitudes:
- 5 devolvieron errores 5xx
- 3 terminaron en timeout
→ Marcar servidor como no saludable por 30 segundos

💼 Ejemplos prácticos de uso

🕷️

Web Scraping

Tarea: Parsear 100,000 páginas sin ser baneado.

Solución:

Proxies Residenciales rotativos
Nueva IP cada 10 solicitudes
SOCKS5 para universalidad
Rate limiting: 2 req/seg por IP

Resultado: 0% de bloqueos, 95% de solicitudes exitosas

🎯

Verificación de Anuncios

Tarea: Verificar la visualización de anuncios en 50 países.

Solución:

Proxies con Geo-targeting (por país)
IPs Residenciales para realismo
Captura de pantalla vía navegador headless
Rotación de cabeceras User-Agent

Resultado: Verificación precisa de la colocación de anuncios

💰

Monitoreo de Precios

Tarea: Monitorear precios de competidores 24/7.

Solución:

Proxies de Centro de Datos (más baratos)
Solicitudes programadas cada 2 horas
Múltiples proveedores de proxies
Fallback a residenciales si hay bloqueo

Resultado: Inteligencia de precios en tiempo real

🎮

Sneaker Botting

Tarea: Comprar zapatillas de edición limitada (drop).

Solución:

Proxies Residenciales (para evadir anti-bot)
Proxies ISP para el checkout (estabilidad)
Un IP por cuenta
Baja latencia (<50ms)

Resultado: Checkout exitoso antes de agotarse

📱

Gestión de Redes Sociales

Tarea: Gestionar más de 100 cuentas de Instagram.

Solución:

Proxies Móviles (IPs 4G/5G)
Sesiones persistentes (sticky sessions de 10-30 minutos)
1 cuenta = 1 proxy (para evitar huellas digitales)
Coincidencia geográfica: cuenta y proxy del mismo país

Resultado: 0 baneos, engagement natural

🌐

SEO Rank Tracking

Tarea: Monitorear posiciones en Google por región.

Solución:

Proxies con geolocalización (ciudad/región)
Residenciales para precisión de resultados
Baja frecuencia de solicitudes (1-2/min)
Parsing de SERP con anti-captcha

Resultado: Posiciones locales precisas

🎯 Elección del tipo de proxy para su tarea

Tarea	Tipo de Proxy	Protocolo	Costo
Web Scraping	Residencial	HTTP/SOCKS5	$2.7/GB
Gestión Redes Sociales (Instagram, TikTok)	Móvil 4G/5G	HTTP/SOCKS5	$3.8/GB
Monitoreo de Precios (sitios sencillos)	Centro de Datos	HTTP	$1.5/GB
Sneaker Bots	Residencial + ISP	HTTP	$2.7/GB
Contenido Geo-restringido (Netflix)	Residencial	HTTPS/SOCKS5	$2.7/GB
SEO Rank Tracking	Residencial	HTTP	$2.7/GB
Verificación de Anuncios	Residencial	HTTP	$2.7/GB
Pruebas de API (desarrollo)	Centro de Datos	HTTP/SOCKS5	$1.5/GB

⚡ Optimización del rendimiento del proxy

Mejores prácticas 2025

✅ Connection Pooling

Reutilice conexiones TCP al proxy. HTTP Keep-Alive ahorra 100-200ms en cada solicitud.

✅ Soporte HTTP/2

Utilice HTTP/2 para multiplexar múltiples solicitudes a través de una sola conexión.

✅ Geo-proximidad

Elija proxies geográficamente cercanos al servidor de destino. Latencia = distancia.

✅ DNS Caching

Cachee las consultas DNS en el cliente. La búsqueda DNS toma 20-50ms.

✅ Retry Logic

Reintento automático en caso de errores 5xx con retroceso exponencial y cambio de proxy.

✅ Session Persistence

Para tareas con sesiones, use sticky sessions (una IP para toda la sesión).

⚠️ Qué evitar

❌ Usar proxies gratuitos (lentos, inseguros, inestables)
❌ Tasa de solicitudes (rate limit) demasiado alta (obtendrá captchas y bloqueos)
❌ Usar un solo proxy para todas las solicitudes (fingerprinting, bloqueo por IP)
❌ Ignorar cabeceras retry-after (limitación de velocidad del servidor)
❌ Usar proxies HTTP para datos confidenciales

🎓 Conclusiones

Los servidores proxy son una herramienta poderosa que en 2025 se ha convertido en una parte integral del internet moderno. Comprender su funcionamiento le da una ventaja competitiva en muchas áreas.

🔑 Puntos clave

1. Arquitectura

El proxy es un intermediario inteligente que no solo reenvía datos, sino que los procesa, cachea y optimiza activamente.

2. Protocolos

HTTP para tráfico web, SOCKS5 para universalidad, CONNECT para HTTPS: cada protocolo para su tarea.

3. Seguridad

TLS 1.3 con ECH protege contra DPI. El método CONNECT mantiene el cifrado end-to-end. Use HTTPS siempre.

4. Rendimiento

El caching acelera la carga hasta en un 50-90%. El balanceo de carga distribuye el tráfico para alta disponibilidad.

5. Elección del tipo

Residenciales para evadir bloqueos, Móviles para redes sociales, Centro de Datos para tareas sencillas. La elección correcta = éxito del proyecto.

6. Tendencias modernas

HTTP/3, QUIC, ECH (Encrypted Client Hello), enrutamiento impulsado por IA: los proxies evolucionan con internet.

🚀 Próximos pasos

Práctica: Configure un proxy en su proyecto y pruebe diferentes protocolos
Monitoreo: Rastree métricas (tasa de aciertos, latencia, tasa de errores)
Optimización: Experimente con la configuración de caché y balanceo
Seguridad: Revise los logs regularmente en busca de anomalías
Escalabilidad: Añada servidores proxy a medida que aumente la carga

💡 Recuerde: El proxy no es magia, sino una herramienta de ingeniería. Comprender su funcionamiento le permite usarlo de manera eficiente, evitar errores y lograr el máximo rendimiento. En 2025, un proxy bien configurado es una ventaja competitiva.

¿Listo para aplicar sus conocimientos en la práctica?

¡Ahora es un experto en servidores proxy! Aplique sus conocimientos con ProxyCove.
195+ países, todos los protocolos, calidad premium, 99.9% de tiempo de actividad.
Registro con el código promocional ARTHELLO = +$1.3 de bono de inicio

Empezar con ProxyCove →

Tarifas ProxyCove 2025:

🏠 Residenciales — $2.7/GB 📱 Móviles — $3.8/GB 🏢 Centro de datos — $1.5/GB

✅ HTTP, HTTPS, SOCKS5 | ✅ API + Dashboard | ✅ Soporte 24/7 | ✅ Activación instantánea

📚 ¡Guía completa sobre servidores proxy finalizada!

Ha estudiado:
Parte 1: Fundamentos, arquitectura, forward vs reverse, transparent vs explicit
Parte 2: Protocolos HTTP/SOCKS, método CONNECT, SSL/TLS handshake, cabeceras
Parte 3: Caching, balanceo de carga, ejemplos prácticos, optimización

🎉 ¡Felicidades! Ahora entiende cómo funcionan los servidores proxy en 2025.

Cómo Funciona un Servidor Proxy: Explicación Clara para Principiantes

🔄 ¿Qué es un servidor proxy?

Concepto básico de funcionamiento

¿Para qué sirve un servidor proxy?

🔒 Seguridad y anonimato

🌍 Evitar geobloqueos

⚡ Rendimiento

🛡️ Filtrado de tráfico

⚖️ Balanceo de carga

🔍 Monitoreo y registro

💡 Diferencia clave con VPN

🎭 El rol del proxy como intermediario

Funciones del proxy como intermediario

1. Modificación de solicitudes

2. Verificación de políticas de acceso

3. Almacenamiento en caché de contenido

4. Modificación de respuestas

5. Registro y analíticas

⚙️ Tres modos de operación del proxy

🔵 Passthrough (Modo de paso)

🟢 Intercepting (Modo de intercepción)

🟡 Hybrid (Modo híbrido)

🔄 Esquema de solicitud-respuesta a través del proxy

Esquema paso a paso del funcionamiento del proxy

Paso 1: El cliente envía la solicitud al proxy

Paso 2: El proxy recibe y verifica la solicitud

Paso 3A: Si está en caché, lo devuelve inmediatamente

Paso 3B: Si no está en caché, solicita al servidor

Paso 4: El servidor de destino procesa la solicitud

Paso 5: El proxy procesa la respuesta

Paso 6: El proxy devuelve la respuesta al cliente

⚡ Rendimiento: con caché vs sin caché

🏗️ Arquitectura del servidor proxy

Componentes principales de la arquitectura

1️⃣ Connection Manager (Gestor de conexiones)

2️⃣ Request Parser (Analizador de solicitudes)

3️⃣ Authentication & Authorization (Autenticación y autorización)

4️⃣ Cache Engine (Motor de caché)

5️⃣ Upstream Handler (Manejador de servidores upstream)

6️⃣ Response Processor (Procesador de respuestas)

7️⃣ Logging & Monitoring (Registro y monitoreo)

↔️ Forward vs Reverse Proxy

➡️ Forward Proxy

Características:

Ejemplos de uso:

Soluciones populares:

⬅️ Reverse Proxy

Características:

Ejemplos de uso:

Soluciones populares:

🔍 Tabla comparativa

👁️ Transparent vs Explicit Proxy

👻 Transparent Proxy

Cómo funciona:

Características:

Aplicación:

📢 Explicit Proxy

Cómo funciona:

Características:

Aplicación:

🔑 Diferencia clave: Método CONNECT

🔌 Protocolos de servidores proxy

Protocolos principales

1. HTTP Proxy

2. HTTPS Proxy (HTTP CONNECT)

3. SOCKS4 Proxy

4. SOCKS5 Proxy

📊 Comparación de protocolos

🌐 HTTP Proxy detallado

Solicitud a través de HTTP Proxy

Solicitud HTTP normal (sin proxy)

Solicitud HTTP a través de proxy

Qué hace el proxy con la solicitud

🔐 Autenticación en HTTP Proxy

Basic Authentication

Digest Authentication

🔒 Método HTTP CONNECT

Cómo funciona CONNECT

Paso 1: El cliente solicita un túnel

Paso 2: El proxy establece la conexión