# Los servidores proxy son tan antiguos como la Web: una breve historia de lo que realmente hacen
Un ingeniero del CERN y otro de Intel publicaron el primer artículo en el que se describía un proxy de la World Wide Web en abril de 1994 ([Luotonen y Altis, *World-Wide Web Proxies*](https://www.w3.org/History/1994/WWW/Proxies/), 1994). La propia Web tenía entonces tres años. Los servidores proxy no son una solución improvisada añadida a Internet a posteriori. Surgieron al mismo tiempo que esta.
Merece la pena conocer esa historia, ya que su función apenas ha cambiado en treinta años. **Un proxy** es un equipo que realiza una solicitud en nombre de otra parte y devuelve el resultado. Todo lo que ha surgido desde 1994 —las jerarquías de almacenamiento en caché, las redes de distribución de contenidos, las pasarelas corporativas, las redes de dispositivos que alimentan hoy en día los sistemas de inteligencia artificial— no es más que esa única idea aplicada a una escala cada vez mayor.
> **Puntos clave**
> - El primer artículo sobre proxies web se publicó en abril de 1994, procedente del CERN, y ya abordaba el cruce de cortafuegos y el almacenamiento en caché como una única tarea (Luotonen y Altis, 1994).
> - SOCKS cumple treinta y cuatro años este año. Sigue siendo un protocolo compatible.
> - Cloudflare informó el 1 de julio de 2026 que, a fecha de junio de 2026, más del 50 % del tráfico de Internet no es humano.
> - Los proxies inversos, las CDN, los equilibradores de carga y las pasarelas de API son el mismo mecanismo con diferentes nombres.
## ¿De dónde surgió realmente el proxy web?
En abril de 1994, Ari Luotonen, del CERN, y Kevin Altis, de Intel, publicaron *World-Wide Web Proxies*, en el que describían un servidor que permitía a los usuarios de subredes cerradas acceder a la web a través de un cortafuegos ([archivo del W3C](https://www.w3.org/History/1994/WWW/Proxies/), 1994). El artículo se publicó posteriormente en *Computer Networks and ISDN Systems*. El problema que resolvía era muy sencillo: los empleados que se encontraban detrás de un cortafuegos corporativo no podían acceder a la web exterior, y alguien tenía que interponerse entre ambos.
Esa es la idea fundamental, y no ha cambiado. Un proxy es un equipo que realiza una solicitud en su nombre. La implementación del CERN, `cern_httpd`, era compatible con HTTP, Gopher, WAIS y FTP, lo que da una idea de lo temprano que fue todo esto.
El caso de uso original era el acceso, no la elusión. Una empresa quería que su personal pudiera acceder a la web sin tener que abrir un agujero en el cortafuegos para cada estación de trabajo. El proxy era ese agujero, único, supervisado y registrado.
Esta es la parte que se suele pasar por alto. El artículo de 1994 trata el almacenamiento en caché y el control de acceso como un mismo conjunto de funciones, proporcionadas por el mismo dispositivo. Todos los debates que seguimos manteniendo en 2026 —sobre quién puede recuperar qué, con qué frecuencia y si el servidor de origen debe asumir el coste— ya se podían vislumbrar en un artículo escrito antes de que existiera la mayor parte de la web.
Para conocer las diferencias prácticas entre los tipos de red, consulte [comparación entre proxies residenciales y de centros de datos](https://joinmassive.com/blog/residential-vs-datacenter-proxies-for-ai-agents), o comience por [qué es un proxy residencial](https://joinmassive.com/blog/what-is-a-residential-proxy).
## ¿Por qué la web de los primeros tiempos necesitaba proxies para sobrevivir?
El ancho de banda era la limitación principal, y los proxies de almacenamiento en caché fueron la solución. Squid, que aún hoy se utiliza ampliamente como proxy de almacenamiento en caché, lanzó la versión 1.0.0 en julio de 1996, una bifurcación realizada por Duane Wessels a partir de la caché de objetos Harvest desarrollada en la Universidad de Colorado en Boulder ([Proyecto Squid Web Cache](https://wiki.squid-cache.org/SquidFaq/AboutSquid), consultado el 31 de agosto de 2026).
En 1996, una universidad pagaba por su conexión por megabyte. Si cuatro mil estudiantes accedían cada uno a la misma página de inicio, la institución pagaba cuatro mil veces por un mismo documento. Un proxy de almacenamiento en caché permitía realizar una única solicitud. Las cachés de Harvest podían organizarse en jerarquías y comunicarse entre sí a través del Protocolo de Caché de Internet, de modo que, si se producía una falta de acierto en un campus, la solicitud podía ser atendida por un servidor vecino en lugar de por el servidor de origen.
Hitos espaciados uniformemente, sin escala. Fuentes: Archivo del W3C (1994), USENIX (1992), RFC 1928 de la IETF (1996), proyecto Squid Web Cache, proyecto Tor, Cloudflare (2026).
Los proxies de almacenamiento en caché son la razón por la que la web de la década de los 90 se cargaba en absoluto. No se trata de una cuestión de seguridad ni de privacidad. Es una cuestión económica, y los aspectos económicos han vuelto a cobrar relevancia.
## ¿Qué problema resolvía SOCKS en 1992?
SOCKS es anterior en dos años al artículo sobre los proxies web. En septiembre de 1992, David Koblas y Michelle R. Koblas presentaron *SOCKS* en el tercer Simposio de Seguridad de UNIX de USENIX celebrado en Baltimore ([actas de USENIX](https://www.usenix.org/conference/sec92/socks), 1992), y a partir de ahí el protocolo quedó a disposición del público. La versión 5 se normalizó como [RFC 1928](https://www.rfc-editor.org/rfc/rfc1928.html) en marzo de 1996, en la que se describe un marco para que las aplicaciones cliente-servidor «utilicen de forma cómoda y segura los servicios de un cortafuegos de red».
Vuelva a leer esa frase. La propia formulación de la IETF, en 1996, hace hincapié en la seguridad y la comodidad. No en el anonimato.
El mismo patrón se repite a lo largo de toda la trayectoria. Cada hito que se indica a continuación resolvió un problema operativo específico, y todos y cada uno de esos problemas siguen existiendo:
| Año | Hito | El problema que resolvió |
|---|---|---|
| 1992 | Presentación de SOCKS en USENIX | Permitir que aplicaciones TCP arbitrarias, y no solo navegadores web, atravesaran un cortafuegos |
| 1994 | Artículo del CERN *World-Wide Web Proxies* | Proporcionar al personal de una subred cerrada acceso a la web exterior |
| 1995 | Comienzan los trabajos sobre el enrutamiento en cebolla (onion routing) en el NRL | Mantener el origen del tráfico gubernamental sensible sin que pueda atribuirse a nadie |
| 1996 | El RFC 1928 estandariza SOCKS5 | Incorporar la autenticación y el protocolo UDP al paso a través del cortafuegos |
| 1996 | Lanzamiento de Squid 1.0.0 | Reducción de la factura de ancho de banda al evitar la descarga repetida del mismo documento |
| 2002 | Se pone en marcha la red Tor | Convertir la investigación del NRL en una red pública de anonimato |
| 2026 | La mayor parte del tráfico deja de ser humano | Decidir de dónde deben proceder miles de millones de solicitudes de máquinas |
Tor es el que la gente recuerda, y llegó una década después que los demás. Fue el octavo acto de esta historia, no el primero.
SOCKS5 no es una reliquia de museo. Es un protocolo compatible con la red residencial de Massive en 2026, junto con HTTP y HTTPS. Un protocolo estandarizado hace treinta años sigue figurando en la lista de características de un producto comercial porque resolvió su problema adecuadamente desde el primer momento.
El enrutamiento en cebolla, antecesor de Tor, surgió de la misma época y de un entorno institucional similar. En 1995, David Goldschlag, Michael Reed y Paul Syverson, del Laboratorio de Investigación Naval de EE. UU., comenzaron a plantearse si era posible establecer conexiones a Internet sin revelar quién se comunicaba con quién. Ese trabajo dio lugar a los primeros diseños y prototipos de enrutamiento en cebolla, y su objetivo era proteger las comunicaciones gubernamentales enviadas a través de redes públicas ([Historia del Proyecto Tor](https://www.torproject.org/about/history/), consultado el 31 de agosto de 2026). La tecnología que más tarde se convertiría en sinónimo de la «dark web» fue financiada por la Armada de los Estados Unidos para evitar que el tráfico de inteligencia pudiera atribuirse fácilmente.
## ¿En qué situaciones se utilizan los proxies en el día a día?
En la mayoría de ellas. **Un proxy inverso** es el mismo servidor orientado en sentido contrario, que trabaja para el propietario del sitio web en lugar de para el solicitante, y hay uno situado delante de casi todas las páginas web que ha visitado hoy. Las redes de distribución de contenidos son proxies de almacenamiento en caché distribuidos en el perímetro. Los equilibradores de carga son proxies. La rescisión TLS situada delante de un servidor de aplicaciones es un proxy. Las pasarelas de salida corporativas, los filtros de contenido de colegios y bibliotecas, las pasarelas de API, las mallas de servicios: todos ellos son proxies que hacen exactamente lo mismo que hacía el servidor del CERN en 1994.
Lo interesante es el vocabulario. Cuando el intermediario trabaja para el propietario del sitio web, el sector lo denomina «infraestructura» y lo incluye en el diagrama de arquitectura. Cuando trabaja para la parte que realiza la solicitud, el sector lo denomina «proxy». La misma máquina, la misma posición en la ruta de la solicitud. Solo ha cambiado la dirección de la flecha y, con ella, la palabra.
Vale la pena saberlo, aunque solo sea para que el diagrama de arquitectura y la lista de proveedores dejen de parecer dos tecnologías diferentes.
## ¿Por qué la web necesita ahora más que nunca los proxies?
Porque la web ha dejado de estar compuesta principalmente por seres humanos. En un informe publicado el 1 de julio de 2026, Cloudflare reveló que, en junio de 2026, más del 50 % del tráfico en Internet no era de origen humano, y que el 52 % de las solicitudes de los rastreadores se destinan al entrenamiento de la IA, frente al 22 % registrado en la primavera de 2025 ([Cloudflare, *Content Independence Day, one year on*](https://blog.cloudflare.com/agentic-internet-bot-report/), 1 de julio de 2026).
Fuente: Cloudflare, «Content Independence Day, one year on», 1 de julio de 2026.
En ese mismo informe de 2026, Cloudflare también constató que, por cada hora dedicada a buscar información en línea, solo se pasan quince minutos en la web abierta, y que algunas de las categorías más rastreadas han registrado una disminución del tráfico humano de hasta un 40 % en menos de un año ([Cloudflare](https://blog.cloudflare.com/agentic-internet-bot-report/), 1 de julio de 2026).
Fuente: Cloudflare, «Content Independence Day», un año después, 1 de julio de 2026.
Si se comparan estos dos hallazgos, se hace evidente la naturaleza del problema. Las máquinas se encargan de la mayor parte de las recuperaciones de datos, las personas pasan la mayor parte de su tiempo en los motores de búsqueda y la web abierta se consulta más que nunca, aunque se visite menos que nunca. Cada una de esas consultas realizadas por máquinas tiene que tener su origen en algún lugar. Esa es una cuestión derivada, y ahora es la cuestión central.
## ¿Cómo se construye una red de dispositivos moderna?
Basada en el consentimiento. Massive comenzó como un producto de monetización de aplicaciones, en el que los usuarios cedían una parte de su capacidad de procesamiento ociosa a cambio de funciones premium, y cada dirección IP se inscribe voluntariamente a través del SDK de Massive. Esto genera más de un millón de dispositivos residenciales verificados en más de 195 países, con auditoría SOC 2, cumplimiento del RGPD, certificación AppEsteem y un registro de auditoría completo desde el origen hasta la solicitud. El operador puede determinar de qué conexión procedía una solicitud concreta.
No se trata de una obligación nueva. El proxy del CERN registraba todas las solicitudes que pasaban por él, ya que un administrador del sistema debía poder dar cuenta del tráfico. Una red de dispositivos responde a la misma pregunta un nivel más abajo: no solo qué se solicitó, sino qué conexión la transmitió y en qué condiciones se acordó su transmisión.
Hay dos preguntas que vale la pena plantear a cualquier red de dispositivos: ¿puede indicar las condiciones que aceptó el propietario del dispositivo? y ¿puede rastrear una solicitud hasta su origen? Ambas han tenido buenas respuestas desde 1994. La escala ha cambiado, pero la cuestión de la auditoría no.
Sobre esa red se asienta una capa de representación que devuelve HTML limpio o Markdown desde cualquier fuente pública, en cualquier ubicación. Se trata de la formulación del problema de 1994: acceder a la web pública desde cualquier lugar desde el que realmente se necesite hacerlo, con los formatos de salida que espera un canal de 2026.
Para un análisis más exhaustivo del consentimiento en las redes de dispositivos, consulte [cómo se aplica el consentimiento en el uso compartido de ancho de banda](https://joinmassive.com/blog/what-does-consent-look-like-in-bandwidth-sharing).
[Lea la documentación](https://docs.joinmassive.com) [Póngase en contacto con nosotros](https://joinmassive.com/contact)
## Preguntas frecuentes
### ¿Para qué se utilizan realmente los proxies?
Para atravesar cortafuegos, almacenamiento en caché, equilibrio de carga, terminación TLS, distribución de contenidos, pasarelas de API, salida de datos corporativos, recopilación de datos con precisión geográfica y, cada vez más, para generar tráfico de recuperación de IA. El primer uso documentado, en el artículo del CERN de abril de 1994, consistía en proporcionar al personal situado detrás de un cortafuegos acceso a la web exterior.
### ¿Cuál fue el primer proxy web?
`cern_httpd`, descrito en *World-Wide Web Proxies*, de Ari Luotonen y Kevin Altis, en abril de 1994. Permitía a los usuarios de subredes cerradas acceder a HTTP, Gopher, WAIS y FTP a través de un cortafuegos, y almacenaba en caché las respuestas para que las solicitudes repetidas no llegaran dos veces al servidor de origen.
### ¿Es una CDN un proxy?
Sí. Una red de distribución de contenidos es un proxy inverso de almacenamiento en caché distribuido. Desempeña las mismas dos funciones que describía el artículo del CERN de 1994: interpone entre la solicitud y el destino, y almacena el resultado en caché, con la flecha apuntando hacia el propietario del sitio en lugar de hacia el solicitante.
### ¿Por qué está aumentando el tráfico de proxy en 2026?
Porque la mayor parte del tráfico web ya no es humano. Cloudflare informó el 1 de julio de 2026 de que, a fecha de junio de 2026, el tráfico no humano había superado el 50 % y que el 52 % de las solicitudes de los rastreadores estaban destinadas al entrenamiento de la IA, frente al 22 % registrado en la primavera de 2025. El entrenamiento de modelos, la recuperación de datos y los flujos de trabajo de los agentes se realizan a escala de máquina.
### ¿Cómo funciona el consentimiento en una red residencial?
El propietario del dispositivo da su consentimiento por adelantado, normalmente a cambio de algo concreto, como funciones premium de una aplicación, y puede retirarlo. La certificación independiente (SOC 2, RGPD, AppEsteem) es lo que distingue una política declarada de una auditada.
## La misma función, a una escala mucho mayor
Los servidores proxy resolvieron un problema real en 1994 y resuelven una versión más amplia del mismo en 2026, por la misma razón en ambos casos. Alguien necesita acceder a un recurso al que no puede acceder directamente, y algo tiene que interponerse en medio y hacerlo bien.
Lo que ha cambiado es la escala y quién realiza la solicitud. El servidor del CERN prestaba servicio a un laboratorio protegido por un cortafuegos. La tarea equivalente hoy en día consiste en generar tráfico de máquinas que ya supera al tráfico humano en Internet, procedente de los lugares adecuados y a través de dispositivos cuyos propietarios han aceptado llevarlos consigo.
Treinta y dos años después, sigue siendo una máquina intermedia la que realiza una solicitud en nombre de alguien y mantiene un registro de la misma.
Para más información sobre cómo está cambiando la economía, véase [El bloqueo de rastreadores de IA, el pago por rastreo y lo que esto significa para los agentes](https://joinmassive.com/blog/the-closing-web-ai-crawler-blocking-pay-per-crawl-and-what-it-means-for-agents).
## Fuentes
- Luotonen, A. y Altis, K., *World-Wide Web Proxies*, CERN e Intel, abril de 1994. Consultado el 31 de agosto de 2026. https://www.w3.org/History/1994/WWW/Proxies/
- Koblas, D. y Koblas, M. R., *SOCKS*, III Simposio de Seguridad de UNIX, Asociación USENIX, Baltimore, septiembre de 1992, pp. 77-83. Consultado el 31 de agosto de 2026. https://www.usenix.org/conference/sec92/socks
- IETF, *RFC 1928: Protocolo SOCKS, versión 5*, marzo de 1996. Consultado el 31 de agosto de 2026. https://www.rfc-editor.org/rfc/rfc1928.html
- Proyecto Squid Web Cache, *¿Qué es Squid?*. Consultado el 31 de agosto de 2026. https://wiki.squid-cache.org/SquidFaq/AboutSquid
- Proyecto Tor, *Historia*. Consultado el 31 de agosto de 2026. https://www.torproject.org/about/history/
- Cloudflare, *El Día de la Independencia de los Contenidos, un año después: la creación del modelo de negocio para una Internet autónoma*, 1 de julio de 2026. Consultado el 31 de agosto de 2026. https://blog.cloudflare.com/agentic-internet-bot-report/