Proxy inverso (reverse proxy)
Un servidor que se sitúa delante de uno o varios servidores web y les reenvía las solicitudes entrantes de los clientes, ocultando el backend al cliente.
Un proxy inverso es un servidor que recibe solicitudes de los clientes en nombre de uno o varios servidores backend, luego reenvía cada solicitud al backend apropiado y devuelve la respuesta. Desde el punto de vista del cliente, el proxy inverso es el sitio web - los servidores reales detrás están ocultos.
Es la imagen espejo de un proxy directo. Un proxy directo trabaja en nombre de los clientes para alcanzar internet (ocultando al cliente). Un proxy inverso trabaja en nombre de los servidores para recibir tráfico de internet (ocultando los servidores). El mismo concepto de intermediario, en dirección opuesta.
Los proxies inversos son infraestructura web fundamental. Se encargan del balanceo de carga (repartir el tráfico entre varios backends), la terminación SSL/TLS (descifrar HTTPS para que los backends no tengan que hacerlo), el caché (servir respuestas repetidas sin llegar al backend) y el filtrado de seguridad (bloquear solicitudes maliciosas antes de que lleguen a la aplicación). Nginx, HAProxy y Cloudflare son proxies inversos comunes.
Para quien hace web scraping, los proxies inversos importan porque a menudo es donde viven los sistemas antibot. Cloudflare, Akamai y servicios similares actúan como proxies inversos delante de los sitios objetivo, inspeccionando las solicitudes entrantes y desafiando o bloqueando las que parecen automatizadas. Entender esto explica por qué las solicitudes se bloquean antes de llegar al servidor real.
The proxy that belongs to the website
A forward proxy acts for the client. A reverse proxy acts for the server: it sits in front of an origin, accepts connections from the public, and decides what to do with them before anything reaches the application behind it.
Reverse proxies handle TLS termination, caching, load balancing and, most relevantly here, filtering. Cloudflare, Fastly and similar services are reverse proxies operated as a product, which is why so many of the blocks you meet come from infrastructure rather than from the site itself.
This is why two different sites can block you in exactly the same way, with the same challenge page and the same signals. You are not meeting their rules, you are meeting their vendor's.
What this means for your setup
When the block comes from a reverse proxy, the fix is about signals rather than the site:
Recognising the layer
Challenge page from a known vendor -> you are being scored, not banned
Same block pattern across sites -> shared vendor, shared ruleset
Server header naming a CDN -> a reverse proxy is in front
curl -I https://example.com | grep -i 'server\|cf-ray'- A vendor scoring system weighs address class, TLS fingerprint and behaviour. Improving one moves the score, and the address is the one we sell.
- Because rules are shared across customers, a setup that clears one site often clears others using the same vendor.
- Rate limits are frequently enforced at this layer too, which is why they feel identical across unrelated sites.
- None of this is defeated by rotating addresses alone if your client announces itself in the handshake.
Forward and reverse mixed up
A reverse proxy is not something you buy from us
We sell forward proxies. A reverse proxy protects a site you do not own.
It is not the site's own decision
The vendor's default rules block a great deal that the site owner never considered.
Bypassing it is not a product feature
Anyone selling a guaranteed bypass is selling something that stops working the week the vendor updates.
It does explain identical blocks
Meeting the same challenge on unrelated sites means one vendor, not a coordinated ban.
Términos relacionados
Ver esto en práctica
¿Listo para usar proxy inverso (reverse proxy)?
SotaProxy te da acceso a proxies residenciales rotativos, móviles, de centro de datos e ISP. Sin compromiso mínimo.
Empezar