Traversal de cortafuegos, almacenamiento en caché, equilibrio de carga, terminación de 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, tráfico de recuperación de IA de origen. 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.
Los servidores proxy son tan antiguos como la web: una breve historia de lo que realmente hacen
Un ingeniero del CERN y un ingeniero de Intel publicaron el primer artículo en el que se describía un servidor proxy de la World Wide Web en abril de 1994 (Luotonen y Altis, Proxies de la World Wide Web, 1994). La propia web tenía tres años. Los servidores proxy no son una solución provisional añadida a Internet a posteriori. Surgieron al mismo tiempo que esta.
Vale la pena conocer esa historia, ya que el trabajo apenas ha cambiado en treinta años. Un apoderado Es una máquina que realiza una solicitud en nombre de un tercero y devuelve el resultado. Todo lo que ha sucedido 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, desde el CERN, y en él ya se abordaban la superación 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 de que, a fecha de junio de 2026, más del 50 % del tráfico de Internet no era de origen humano.
- Los proxies inversos, las redes de distribución de contenidos (CDN), los equilibradores de carga y las pasarelas de API son el mismo mecanismo con nombres distintos.
¿De dónde surgió realmente el proxy web?
En abril de 1994, Ari Luotonen, del CERN, y Kevin Altis, de Intel, publicaron Proxies de la World Wide Web, en el que se describe un servidor que permitía a los usuarios de subredes cerradas acceder a Internet a través de un cortafuegos (Archivo del W3C, 1994). El artículo se publicó posteriormente en Redes informáticas y sistemas RDSI. El problema que resolvía era muy sencillo: los empleados que se encontraban detrás del cortafuegos de la empresa no podían acceder a Internet, y alguien tenía que actuar como intermediario.
Esa es precisamente la idea, 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 los protocolos HTTP, Gopher, WAIS y FTP, lo que da una idea de lo temprano que fue todo esto.
El caso de uso inicial era el acceso, no la elusión. Una empresa deseaba que sus empleados pudieran acceder a Internet 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 funcionalidades, proporcionadas por el mismo dispositivo. Todas las discusiones 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 quedaban claramente expuestas en un artículo escrito antes de que existiera la mayor parte de la web.
Para conocer las diferencias prácticas entre los distintos tipos de red, consulte Comparación entre proxies residenciales y de centros de datos, o bien comience por Qué es un proxy residencial.
¿Por qué la Web de los primeros tiempos necesitaba servidores proxy para sobrevivir?
El ancho de banda era la limitación principal, y los servidores proxy de almacenamiento en caché fueron la solución. Squid, que sigue utilizándose ampliamente hoy en día como servidor proxy de almacenamiento en caché, lanzó la versión 1.0.0 en julio de 1996, tras un desarrollo derivado realizado por Duane Wessels a partir de la caché de objetos Harvest, creada en la Universidad de Colorado en Boulder (Proyecto «Squid Web Cache», 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 consulta. 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 campus vecino en lugar de por el servidor de origen.
Los servidores proxy de almacenamiento en caché son la razón por la que la web de los años noventa se cargaba. No se trata de una cuestión de seguridad ni de privacidad. Se trata de una cuestión económica, y los factores económicos han vuelto a cobrar importancia.
¿Qué problema resolvía SOCKS en 1992?
SOCKS es dos años anterior al artículo sobre el proxy web. En septiembre de 1992, David Koblas y Michelle R. Koblas presentaron CALCETINES en el tercer Simposio de Seguridad de UNIX de USENIX celebrado en Baltimore (Actas de USENIX, 1992), y a partir de entonces el protocolo quedó a disposición del público. La versión 5 se normalizó como RFC 1928 en marzo de 1996, en el 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. Según la propia definición de la IETF, en 1996, se trata de seguridad y comodidad. No de anonimato.
Este mismo patrón se repite a lo largo de todo el linaje. Cada hito que se indica a continuación resolvió un problema operativo concreto, y todos y cada uno de esos problemas siguen existiendo:
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.
El enrutamiento en cebolla, precursor de Tor, surgió en la misma época y en un entorno institucional similar. En 1995, David Goldschlag, Michael Reed y Paul Syverson, del Laboratorio de Investigación Naval de los Estados Unidos, 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, consultado el 31 de agosto de 2026). La tecnología que más tarde se convirtió en sinónimo de la «dark web» fue financiada por la Armada de los Estados Unidos con el fin de evitar que el tráfico de información de inteligencia pudiera atribuirse fácilmente.
¿En qué situaciones cotidianas se utilizan los poderes?
La mayoría de ellos. Un proxy inverso Es la misma máquina orientada en sentido contrario, que trabaja para el propietario del sitio en lugar de para el solicitante, y hay una situada delante de casi todos los sitios 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 terminació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 equipo del CERN en 1994.
Lo interesante es el vocabulario. Cuando el intermediario trabaja para el propietario del sitio web, en el sector se denomina «infraestructura» y se incluye en el diagrama de arquitectura. Cuando trabaja para la parte que realiza la solicitud, en el sector se denomina «proxy». Se trata de la misma máquina, en la misma posición en la ruta de la solicitud. Solo ha cambiado la dirección de la flecha y, con ella, el término.
Es importante saberlo, aunque solo sea para que el diagrama de arquitectura y la lista de proveedores dejen de parecer dos tecnologías distintas.
¿Por qué la web necesita ahora más que nunca los servidores proxy?
Porque la web dejó de estar compuesta principalmente por personas. En un informe publicado el 1 de julio de 2026, Cloudflare reveló que, en junio de 2026, más del 50 % del tráfico de Internet no era de origen humano, y que el 52 % de las solicitudes de los rastreadores estaban destinadas al entrenamiento de la inteligencia artificial, lo que supone un aumento con respecto al 22 % registrado en la primavera de 2025 (Cloudflare, El Día de la Independencia de los Contenidos: un año después, 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 Internet, solo se pasan quince minutos en la web abierta, y que algunas de las categorías más rastreadas han registrado una caída del tráfico humano de hasta un 40 % en menos de un año (Cloudflare, 1 de julio de 2026).
Si se comparan estos dos hallazgos, se perfila el problema. Las máquinas se encargan de la mayor parte de la búsqueda de información, 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 visita menos que nunca. Cada una de esas lecturas realizadas por máquinas tiene que tener su origen en algún lugar. Esa es una cuestión secundaria, y ahora se ha convertido en la principal.
¿Cómo se construye una red de dispositivos moderna?
En cuanto al consentimiento. Massive comenzó como un producto de monetización de aplicaciones, en el que los usuarios cedían una parte de su capacidad informática ociosa a cambio de funciones premium, y cada dirección IP se inscribe voluntariamente a través del SDK de Massive. Esto da como resultado 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 y certificación AppEsteem, además de un registro de auditoría completo desde el origen hasta la solicitud. El operador puede determinar qué conexión ha transmitido una solicitud determinada.
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 también a través de qué conexión se transmitió y en qué condiciones se acordó su transmisión.
Sobre esa red se asienta una capa de renderización que genera código HTML limpio o Markdown a partir de cualquier fuente pública, independientemente de su ubicación. Se trata de la formulación del problema de 1994: acceder a la web pública desde cualquier lugar desde el que sea necesario hacerlo, con los formatos de salida que espera un proceso de 2026.
Para un análisis más exhaustivo del consentimiento en las redes de dispositivos, véase Cómo se manifiesta el consentimiento en el reparto del ancho de banda.
¿Está desarrollando algo que requiera el uso de la web pública?
El mismo trabajo, pero a una escala mucho mayor
Los proxies resolvieron un problema real en 1994 y resolverán una versión más compleja 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 lo solicita. El servidor del CERN daba servicio a un único laboratorio protegido por un cortafuegos. La tarea equivalente hoy en día consiste en generar tráfico de máquinas que, en la actualidad, 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 que realiza una solicitud en nombre de alguien y lleva un registro de la misma.
Para obtener más información sobre cómo está cambiando la situación económica, consulte El bloqueo de rastreadores de IA, el pago por rastreo y lo que esto supone para los agentes.
Fuentes
- Luotonen, A. y Altis, K., Proxies de la World Wide Web, 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., CALCETINES, III Simposio sobre Seguridad en 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, Un año desde el «Día de la Independencia del Contenido»: la creación del modelo de negocio para una Internet «agente», 1 de julio de 2026. Consultado el 31 de agosto de 2026. https://blog.cloudflare.com/agentic-internet-bot-report/
Preguntas frecuentes
¿Para qué se utilizan realmente los servidores proxy?
¿Cuál fue el primer proxy web?
cern_httpd, descrito en Proxies de la World Wide Web creado por 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 se describen en el artículo del CERN de 1994: se interpone en una solicitud 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?
Esto se debe a que la mayor parte del tráfico web ya no es de origen humano. Cloudflare informó el 1 de julio de 2026 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, lo que supone un aumento respecto 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 llevan a cabo a escala de máquina.
¿Cómo funciona el consentimiento en una red doméstica?
El propietario del dispositivo da su consentimiento por adelantado, normalmente a cambio de algo concreto, como funciones premium de la aplicación, y puede retirar dicho consentimiento. La certificación independiente (SOC 2, RGPD, AppEsteem) es lo que distingue una política declarada de una auditada.