Cada día, su sitio web es atacado por cientos de bots: algunos roban precios y contenido, otros sobrecargan el servidor con solicitudes, y otros buscan vulnerabilidades. Si usted es propietario de una tienda en línea en Wildberries o Ozon, gestiona landing pages para campañas publicitarias en Facebook Ads o administra sitios web de clientes, este problema le afecta directamente. Un proxy inverso (reverse proxy) es la primera línea de defensa que se puede configurar sin profundos conocimientos técnicos.
Qué es un proxy inverso y en qué se diferencia de uno normal
La mayoría de las personas conocen los proxies como herramientas para cambiar la dirección IP: se conecta a un servidor proxy y los sitios ven su dirección en lugar de la suya. Esto se llama proxy directo (forward proxy) — protege al usuario.
Un proxy inverso (reverse proxy) trabaja del otro lado. Se sitúa frente a su servidor y acepta todas las solicitudes entrantes en lugar de él. El visitante piensa que está interactuando directamente con su sitio, pero en realidad primero llega al servidor proxy, que verifica la solicitud, filtra la actividad sospechosa y solo luego pasa el tráfico legítimo a su servidor real.
Una analogía simple:
Imagine que su sitio es un almacén. Un proxy directo es su mensajero, que recoge productos de los proveedores de forma anónima. Un proxy inverso es el guardia en la entrada del almacén: verifica a cada persona que quiere entrar, deja pasar a los clientes y detiene a los ladrones antes de que lleguen a los productos.
La diferencia clave con respecto a un proxy normal es que su dirección IP real del servidor permanece oculta. Los atacantes y bots no saben dónde se encuentra físicamente su sitio — solo ven la dirección del proxy inverso. Esto por sí mismo corta una parte significativa de los ataques.
Para los propietarios de tiendas en línea, especialistas en marketing y arbitrajistas que gestionan decenas de landing pages, esto es críticamente importante: los competidores no podrán encontrar su verdadero hosting y atacarlo directamente, eludiendo la protección.
Por qué los bots y escáneres son peligrosos para su negocio
Muchos propietarios de sitios subestiman la amenaza de los bots, considerándola un "problema técnico". En realidad, esto se traduce en pérdidas directas para el negocio. Analicemos escenarios específicos con los que se enfrentan nuestros lectores.
Raspado de precios por competidores
Si vende en marketplaces o tiene su propia tienda en línea, los competidores pueden lanzar un raspador que cada 15-30 minutos extrae sus precios y automáticamente establece los suyos un 1-2% más bajos. Pierde ventas sin entender por qué. Los bots raspadores también sobrecargan el servidor: cientos de solicitudes por minuto ralentizan el sitio para los compradores reales, lo que afecta directamente la conversión.
Click fraud (fraude de clics)
Los arbitrajistas y especialistas en marketing que trabajan con Facebook Ads y Google Ads se enfrentan regularmente a la manipulación de clics. Los bots clicadores hacen clic en sus anuncios, quemando el presupuesto sin ninguna conversión. Según investigaciones, hasta el 20-30% del tráfico publicitario en algunos nichos proviene de bots. Un proxy inverso con las reglas adecuadas ayuda a identificar y bloquear tales fuentes.
Escáneres de vulnerabilidades
Escáneres automáticos como Shodan, Masscan y cientos de herramientas menos conocidas recorren constantemente toda la web en busca de sitios no protegidos. Verifican versiones obsoletas de CMS, puertos abiertos, contraseñas estándar. Si su sitio está en WordPress o en cualquier otra plataforma popular, seguramente ya está en sus bases de datos. Sin protección, es solo cuestión de tiempo antes de que encuentren una vulnerabilidad.
Ataques DDoS y sobrecarga del servidor
Los competidores o simplemente los malintencionados pueden organizar un ataque que derribe su sitio en el peor momento posible — por ejemplo, durante una venta o una campaña publicitaria activa. Incluso un pequeño DDoS de unos pocos miles de solicitudes por segundo puede "caer" un hosting barato.
Estadísticas reales:
Según Imperva, más del 47% de todo el tráfico de internet es generado por bots. De ellos, alrededor del 30% son bots maliciosos. Si su sitio recibe 1000 visitantes al día, alrededor de 300 de ellos son scripts automáticos que sobrecargan el servidor y distorsionan la analítica.
Cómo un proxy inverso protege el sitio: mecanismo de funcionamiento
Un proxy inverso protege el sitio en varios niveles. Comprender estos niveles le ayudará a configurar correctamente el sistema y no perder pasos importantes.
Nivel 1 — Ocultación de la IP real
Una vez que dirige el tráfico a través de un proxy inverso, la dirección IP real de su servidor deja de ser pública. Los bots y atacantes no pueden acceder al servidor directamente — se topan con el proxy. Esto es especialmente importante para la protección contra DDoS: incluso si el atacante conoce el dominio de su sitio, no podrá atacar el servidor eludiendo la protección.
Nivel 2 — Análisis y filtrado de solicitudes
Cada solicitud entrante pasa por una verificación en varios parámetros: User-Agent (qué navegador/bot hace la solicitud), frecuencia de solicitudes desde una IP, geolocalización, patrones de comportamiento. Los bots, por lo general, hacen solicitudes demasiado rápido, utilizan cadenas de User-Agent no estándar o provienen de direcciones IP conocidas de centros de datos. Un proxy inverso puede rastrear y bloquear todo esto.
Nivel 3 — Limitación de tasa (rate limiting)
Una persona real no puede navegar por 500 páginas de un sitio en un minuto. Un proxy inverso permite establecer límites: por ejemplo, no más de 60 solicitudes por minuto desde una IP. Si alguien excede el límite, recibe un bloqueo temporal o una verificación CAPTCHA. Esto detiene eficazmente a la mayoría de los raspadores y escáneres sin perjudicar a los visitantes normales.
Nivel 4 — Caché y reducción de carga
Un proxy inverso almacena en caché contenido estático (imágenes, CSS, JavaScript) y lo entrega directamente, sin acceder a su servidor. Como resultado, incluso si los bots logran eludir los filtros, obtienen páginas en caché — la carga en el servidor real es mínima. Además, esto acelera el sitio para los visitantes reales, lo que impacta positivamente en el SEO y la conversión.
Nivel 5 — Terminación SSL/TLS
Un proxy inverso se encarga del cifrado del tráfico. Su servidor funciona más rápido, ya que no gasta recursos en cifrar cada solicitud. Y los visitantes ven una conexión segura HTTPS — esto es importante tanto para la confianza como para el ranking en Google.
Resumen de soluciones: Cloudflare, Nginx, Caddy — qué elegir
Existen varias soluciones populares para organizar un proxy inverso. La elección depende de su nivel técnico, presupuesto y la magnitud de la tarea.
| Solución | Dificultad | Costo | Para quién | Protección contra bots |
|---|---|---|---|---|
| Cloudflare | Baja | Gratis / desde $20/mes | Todos, especialmente principiantes | ⭐⭐⭐⭐⭐ |
| Nginx | Media | Gratis (se necesita servidor) | Usuarios técnicos | ⭐⭐⭐⭐ |
| Caddy | Baja-media | Gratis (se necesita servidor) | Desarrolladores, startups | ⭐⭐⭐ |
| AWS CloudFront | Alta | Por uso | Segmento corporativo | ⭐⭐⭐⭐⭐ |
| HAProxy | Alta | Gratis (se necesita servidor) | Proyectos de alta carga | ⭐⭐⭐⭐ |
Para la mayoría de los propietarios de sitios, especialistas en marketing y arbitrajistas que no quieren lidiar con configuraciones de servidor, Cloudflare es la opción óptima. El plan gratuito cubre el 90% de las tareas de protección contra bots y escáneres. Con esto comenzaremos la guía paso a paso.
Configuración de Cloudflare como proxy inverso: paso a paso
Cloudflare es un servicio en la nube que se convierte en un proxy inverso para su sitio después de un simple cambio de servidores DNS. No se requiere programación, ni acceso al servidor — solo configuraciones en el navegador.
Paso 1 — Registro y adición del sitio
Visite cloudflare.com y cree una cuenta. Después de iniciar sesión, haga clic en el botón "Add a Site" e ingrese el dominio de su sitio (por ejemplo, myshop.ru). Seleccione el plan gratuito Free — para comenzar, es más que suficiente.
Cloudflare escaneará automáticamente sus registros DNS y mostrará la lista. Verifique que todos los registros estén en su lugar (normalmente es un registro A con la IP del servidor y registros MX para correo). Haga clic en "Continue".
Paso 2 — Cambio de servidores DNS en el registrador de dominio
Cloudflare le proporcionará dos direcciones de nameserver — algo como alex.ns.cloudflare.com y diana.ns.cloudflare.com. Ingrese al panel de control de su registrador de dominio (RU-CENTER, Reg.ru, Namecheap, etc.) y reemplace los nameservers actuales por estas dos direcciones.
La actualización de DNS toma de 15 minutos a 48 horas. Una vez que todo se actualice, todo el tráfico hacia su sitio comenzará a pasar por los servidores de Cloudflare — el proxy inverso funcionará automáticamente.
Paso 3 — Activación del modo "Under Attack" si es necesario
En el panel de Cloudflare, vaya a la sección Security → Overview. Aquí verá el nivel de protección (Security Level). Para la mayoría de los sitios, el nivel "Medium" es adecuado. Si su sitio está bajo un ataque activo, cambie temporalmente a "Under Attack Mode": todos los visitantes pasarán por una verificación JS, que los bots generalmente no superan.
Paso 4 — Configuración del Modo de Lucha contra Bots
Vaya a Security → Bots. Active el interruptor "Bot Fight Mode" — esta es una protección básica contra bots automáticos, disponible de forma gratuita. Cloudflare identifica y bloquea automáticamente el tráfico de bots maliciosos conocidos, utilizando una base de datos de miles de millones de solicitudes.
En los planes de pago (Pro y superiores) está disponible el Super Bot Fight Mode con configuraciones más detalladas: se puede configurar el comportamiento para bots de búsqueda (Googlebot, Yandexbot deben ser permitidos), para bots verificados (monitoreo de uptime) y para solicitudes automáticas sospechosas.
Paso 5 — Creación de reglas de firewall (Firewall Rules)
Vaya a Security → WAF → Firewall Rules y cree reglas para sus tareas. Aquí hay algunos ejemplos de reglas que debe agregar de inmediato:
Ejemplo de regla 1 — Bloqueo de User-Agent vacíos:
Condición: http.user_agent eq "" → Acción: Block. Los navegadores reales siempre envían User-Agent. Un User-Agent vacío es casi siempre un bot.
Ejemplo de regla 2 — Bloqueo de escáneres conocidos:
Condición: http.user_agent contains "sqlmap" or http.user_agent contains "nikto" or http.user_agent contains "nmap" → Acción: Block. Estas son herramientas de búsqueda de vulnerabilidades.
Ejemplo de regla 3 — Geobloqueo (si es necesario):
Condición: ip.geoip.country in {"CN" "KP" "IR"} → Acción: Challenge (CAPTCHA). Si su negocio opera solo en Rusia, puede bloquear países desde donde provienen la mayoría de los ataques.
Paso 6 — Configuración de Limitación de Tasa
En la sección Security → WAF → Rate limiting rules, cree una regla de limitación de la frecuencia de solicitudes. Por ejemplo: no más de 100 solicitudes por 1 minuto desde una dirección IP. Si se supera el límite, muestre CAPTCHA o bloquee temporalmente. Esto detiene a la mayoría de los raspadores que intentan recopilar rápidamente todas las páginas de su sitio.
Configuración de Nginx como proxy inverso: configuración básica
Si tiene su propio servidor VPS (por ejemplo, en Timeweb, Selectel o DigitalOcean), puede configurar Nginx como un proxy inverso. Esto proporciona más control y flexibilidad, aunque requiere habilidades básicas para trabajar con la línea de comandos.
Esquema típico: tiene un servidor principal con una aplicación (por ejemplo, una tienda en línea en el puerto 8080), y un servidor separado o el mismo servidor con Nginx en el puerto 80/443, que acepta todo el tráfico y lo pasa a la aplicación.
La configuración básica de Nginx como proxy inverso con protección contra bots se ve así:
server {
listen 80;
server_name mysite.ru www.mysite.ru;
# Redirección a HTTPS
return 301 https://$host$request_uri;
}
server {
listen 443 ssl;
server_name mysite.ru www.mysite.ru;
ssl_certificate /etc/letsencrypt/live/mysite.ru/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/mysite.ru/privkey.pem;
# Bloqueo de User-Agent vacíos (bots sin UA)
if ($http_user_agent = "") {
return 403;
}
# Bloqueo de escáneres conocidos por User-Agent
if ($http_user_agent ~* (sqlmap|nikto|nmap|masscan|zgrab|python-requests)) {
return 403;
}
# Limitación de tasa — aplicamos la zona de restricciones
limit_req zone=one burst=20 nodelay;
# Pasar solicitudes al servidor real
location / {
proxy_pass http://127.0.0.1:8080;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
# Ocultar información sobre el servidor real
proxy_hide_header X-Powered-By;
proxy_hide_header Server;
}
}
# Definición de la zona de Limitación de Tasa (agregar en el bloque http)
# limit_req_zone $binary_remote_addr zone=one:10m rate=60r/m;
Preste atención a la directiva proxy_hide_header — oculta los encabezados que revelan información sobre su servidor real y CMS. Esto dificulta el trabajo de los escáneres de vulnerabilidades: no saben qué buscar exactamente.
La zona limit_req_zone limita cada dirección IP a 60 solicitudes por minuto. El parámetro burst=20 permite picos temporales (un usuario real puede abrir rápidamente varias páginas), pero una carga alta prolongada se bloquea.
Importante para arbitrajistas y especialistas en marketing:
Si utiliza proxies residenciales para verificar cómo se ven sus landing pages desde diferentes regiones, asegúrese de que sus proxies no sean bloqueados. Agregue las direcciones IP de sus servidores proxy a la lista blanca (whitelist) en la configuración de Cloudflare o Nginx.
Reglas para bloquear bots y escáneres: lista de verificación
Después de la configuración básica del proxy inverso, utilice esta lista de verificación para asegurarse de que la protección esté configurada de manera integral. Cada punto es un vector de ataque separado que debe cerrarse.
✅ Protección básica (obligatoria para todos)
- Modo de Lucha contra Bots activado en Cloudflare (o su equivalente en otra solución)
- Limitación de tasa configurada: no más de 60-100 solicitudes por minuto desde una IP
- Bloqueadas las solicitudes con User-Agent vacío
- Bloqueados escáneres conocidos: sqlmap, nikto, nmap, masscan
- Ocultados los encabezados Server y X-Powered-By (no mostramos la versión del servidor y CMS)
- HTTPS configurado, HTTP redirige automáticamente a HTTPS
- La IP real del servidor no aparece en bases de datos públicas (Shodan, Censys)
✅ Protección avanzada (para sitios activamente atacados)
- Honeypot configurado — página oculta que solo ven los bots (los usuarios reales no acceden). Las IP que visitan el honeypot se bloquean automáticamente
- Verificación de integridad del navegador activada (Browser Integrity Check en Cloudflare)
- CAPTCHA configurado para tráfico sospechoso (no para todos — solo para sospechosos)
- Geobloqueo de países de donde no se espera tráfico legítimo
- Monitoreo de registros: alertas configuradas para un aumento brusco de errores 403/429
- Bloqueo de rangos de IP de grandes proveedores de nube (AWS, Azure, GCP) — la mayoría de los bots operan desde la nube
- Archivo robots.txt configurado con prohibiciones para bots agresivos
✅ Protección de páginas específicas
- Página de inicio de sesión (/admin, /wp-admin, /login) — limitación de tasa estricta (5-10 intentos por minuto) y autenticación de dos factores
- Puntos finales de API — autorización obligatoria a través de clave API o token
- Páginas de precios — verificaciones adicionales para solicitudes frecuentes (protección contra raspado)
- Formulario de registro/suscripción — CAPTCHA o trampa honeypot invisible para bots
¡No bloquee bots útiles!
Googlebot y Yandexbot deben ser permitidos — indexan su sitio. En Cloudflare, se clasifican automáticamente como "Verified Bots" y no se bloquean con configuraciones adecuadas. Verifique esto en la sección Security → Bots → Bot Analytics.
Proxy para monitoreo: cómo verificar la protección de su sitio
Después de configurar un proxy inverso, es importante asegurarse de que la protección funcione correctamente y no bloquee a los usuarios reales. Aquí es donde entran los proxies comunes — desde el otro lado: usted se convierte en un "usuario externo" y verifica el comportamiento del sitio.
Por qué los especialistas en marketing y arbitrajistas deben verificar sus sitios a través de proxies
Imagine la situación: ha configurado la protección contra bots, activó el geobloqueo, y de repente nota que la conversión ha caído. Es posible que haya bloqueado accidentalmente a usuarios reales de ciertas regiones o dispositivos. Puede verificar esto accediendo al sitio a través de un proxy desde diferentes países y con diferentes tipos de conexiones.
Para estas tareas, los proxies móviles son ideales — simulan la conexión desde un dispositivo móvil real a través de un operador de telefonía. Si sus reglas de bloqueo permiten el tráfico móvil correctamente, significa que los usuarios normales con smartphones no se han visto afectados por la protección.
Escenarios prácticos de verificación
Escenario 1 — Verificación de geodisponibilidad. Ha lanzado publicidad en Facebook Ads a una audiencia de varias regiones de Rusia. A través de un proxy con IP de Novosibirsk, Ekaterimburgo y Krasnodar, verifique que la landing page se abra correctamente, no muestre CAPTCHA y se cargue rápidamente.
Escenario 2 — Prueba de Limitación de Tasa. Abra varias pestañas a través de un proxy y navegue rápidamente entre las páginas. Si recibe un bloqueo con un comportamiento normal, el umbral es demasiado bajo y debe aumentarse.
Escenario 3 — Verificación desde diferentes tipos de IP. Intente acceder a través de un proxy de centro de datos (simulación de un bot/servidor) — si su protección funciona, tal solicitud debería recibir CAPTCHA o un bloqueo. Luego, acceda a través de un proxy residencial (simulación de un usuario doméstico normal) — el acceso debe ser libre.
Escenario 4 — Verificación por competidores. Si desea comprobar cuán difícil es raspar su sitio, intente hacerlo usted mismo a través de una herramienta simple. Si el raspador recibe un bloqueo después de 10-20 solicitudes, la protección funciona. Si recopila datos sin problemas, es necesario endurecer las reglas.
Monitoreo de la efectividad de la protección
En Cloudflare, dirígete a la sección Security → Overview — aquí verá gráficos de solicitudes bloqueadas, tipos de amenazas y geografía de los ataques. Preste atención a:
- Aumento brusco de solicitudes bloqueadas — signo de un ataque activo o raspado
- Alto porcentaje de tráfico de un solo país — puede que valga la pena agregar geobloqueo
- Aumento de errores 403/429 en los registros — verifique si no se están bloqueando usuarios reales
- Solicitudes regulares a /admin, /wp-login.php — intentos de hackeo, refuerce la protección de estos caminos
Conclusión: un proxy inverso no es una opción, es una necesidad
Un proxy inverso ha dejado de ser una herramienta solo para grandes corporaciones. Hoy en día, incluso una pequeña tienda en línea, una landing page para una campaña de arbitraje o un sitio de una agencia SMM necesita una protección básica contra bots, escáneres y raspadores de competidores.
Conclusiones clave de esta guía: Cloudflare es el inicio más rápido sin conocimientos técnicos, Nginx ofrece el máximo control si tiene su propio servidor. En ambos casos, la protección básica se configura en 30-60 minutos y cubre el 80-90% de las amenazas típicas. No olvide verificar que los bots útiles (Googlebot, Yandexbot) permanezcan en la lista blanca y que los usuarios reales no sufran por reglas demasiado agresivas.
Un punto aparte para aquellos que utilizan proxies en su trabajo: si está verificando campañas publicitarias, monitoreando competidores o probando la disponibilidad de sus sitios desde diferentes regiones, para estas tareas, los proxies residenciales son los más adecuados. Tienen direcciones IP de usuarios domésticos reales, por lo que pasan a través de la mayoría de los sistemas de protección como visitantes normales y ofrecen una imagen objetiva de lo que ve su audiencia.