¿Qué es un proxy?

Un proxy es un servidor intermediario que se encuentra entre un cliente (como la aplicación) y un servidor de destino (como una API de back-end). Cuando la aplicación envía una solicitud, el proxy lo recibe primero. A continuación, el proxy puede reenviar la solicitud al servidor de destino, modificarla, bloquearla o devolver una respuesta directamente.

En resumen, un proxy actúa en nombre del cliente o del servidor para mediar la comunicación.

Funcionamiento de un proxy

Los servidores proxy funcionan en el nivel HTTP (u otros protocolos de aplicación) mediante la recepción de solicitudes entrantes y la realización de una o varias de las siguientes acciones:

  • Reenviar la solicitud al servidor de destino y, a continuación, retransmitir la respuesta al cliente.
  • Modificar encabezados, direcciones URL o cargas antes de reenviar.
  • interceptar y responder a la solicitud localmente sin ponerse en contacto con el servidor de destino.
  • Rechazar la solicitud basada en reglas o directivas de acceso.

Desde la perspectiva del cliente, simplemente envía una solicitud a una dirección URL. El proxy controla todo lo demás en segundo plano. El patrón es de cliente a proxy a servidor de destino.

Este patrón introduce una capa de control y abstracción que puede usar para mejorar la seguridad, la observabilidad, el rendimiento y la capacidad de prueba.

Tipos de servidores proxy

Hay diferentes tipos de proxies. Cada uno de ellos se adapta a funciones específicas en la arquitectura de sistemas.

Proxy de reenvío

Un proxy de reenvío se encuentra delante del cliente. Cuando la aplicación realiza una solicitud, pasa por el proxy, que decide si y cómo reenviarlo. Los servidores proxy de reenvío se suelen usar para:

  • Controlar el acceso a recursos externos.
  • Anonimizar el tráfico de cliente.
  • Registre el tráfico saliente para la supervisión.
  • Aplicar filtrado o transformación de contenido.

Proxy inverso

Un proxy inverso se encuentra delante del servidor . Los clientes desconocen la infraestructura de back-end subyacente. El proxy inverso recibe las solicitudes entrantes y las reenvía a uno de varios servidores back-end. Los servidores proxy inversos se usan normalmente para:

  • Equilibrar la carga del tráfico entre varios servicios.
  • Entregue respuestas almacenadas en caché para reducir la carga de back-end.
  • Finalice las conexiones TLS/SSL.
  • Ocultar los detalles del servicio interno de la red pública de Internet.

Proxy transparente

Un proxy transparente intercepta el tráfico sin que el cliente se configure explícitamente para usarlo. Este tipo se utiliza en entornos corporativos o de proveedores de servicios de Internet para aplicar políticas o supervisar el uso.

¿Por qué importan los servidores proxy a los desarrolladores de aplicaciones?

A menudo, los equipos de infraestructura o red administran servidores proxy. Sin embargo, los proxies afectan directamente al comportamiento de la aplicación, especialmente en entornos de desarrollo y pruebas. Aquí hay algunas formas prácticas en que afectan su trabajo diario.

Depuración y observabilidad

Los servidores proxy pueden capturar e inspeccionar el tráfico HTTP. Herramientas como Dev Proxy, Fiddler, Proxyman, Charles Proxy o mitmproxy actúan como servidores proxy de reenvío locales. Puede ejecutar la aplicación a través de ellas para analizar solicitudes y respuestas, detectar errores y comprobar encabezados o tokens de autenticación.

Puerta de enlace de API y enrutamiento

En muchos sistemas de producción, el tráfico al back-end de la aplicación se enruta a través de una puerta de enlace de API o un proxy inverso, como NGINX, o un servicio nativo de la nube como Azure API Management. Estos servidores proxy controlan el enrutamiento, la autenticación, la limitación de velocidad y mucho más.

Al diseñar la API o compilar servicios distribuidos, debe comprender cómo afectan los servidores proxy a los encabezados (como X-Forwarded-For), los tiempos de espera y los límites de tamaño de solicitud.

CORS y desarrollo local

Durante el desarrollo local, especialmente en aplicaciones web, es posible que encuentre restricciones de uso compartido de recursos entre orígenes (CORS) al llamar a las API desde el explorador. Un proxy de desarrollo puede reenviar sus solicitudes a la API de destino mientras reescribe los encabezados para omitir las limitaciones de CORS. Ejemplos comunes de herramientas de desarrollo que reescriben solicitudes CORS son vite, webpack-dev-servero middleware proxy personalizado en marcos como Express o ASP.NET Core.

Virtualización y pruebas de servicios

Los proxies pueden simular las API de back-end. Esta capacidad es útil cuando el servicio real no está disponible, es inestable o es costoso de usar durante las pruebas. Al interceptar y simular respuestas, puede probar el comportamiento de la aplicación en diferentes escenarios, como tiempos de espera, errores o datos con formato incorrecto.

Herramientas como Dev Proxy o implementaciones de proxy personalizadas se usan comúnmente para este propósito en la integración y las pruebas de extremo a extremo.

Autenticación y seguridad

Los servidores proxy suelen ser la primera línea de defensa en la protección de aplicaciones. Pueden aplicar controles de acceso, inyectar encabezados de autenticación o finalizar conexiones TLS/SSL. Como desarrollador, es importante tener en cuenta cómo se comporta la aplicación cuando se encuentra detrás de un proxy y cómo acceder a los encabezados que llevan la autenticación o la información de identidad.

Consideraciones comunes sobre encabezados y servidores proxy

Cuando una solicitud pasa a través de un proxy, se agregan o modifican determinados encabezados para conservar metadatos importantes. Por ejemplo:

  • X-Forwarded-For: indica la dirección IP original del cliente.
  • X-Forwarded-Proto: indica el protocolo original (HTTP o HTTPS).
  • X-Forwarded-Host: indica el host original solicitado por el cliente.

Cuando la aplicación se ejecute detrás de un proxy inverso, asegúrese de que el marco o la plataforma estén configurados para confiar en estos encabezados e interpretarlos correctamente.

Usar un proxy para probar cómo controla la aplicación los errores de API.

Dado que un proxy de reenvío ve todas las solicitudes que envía la aplicación, también puede responder a algunas de ellas con un error en lugar de reenviarlas: un 500, un 429 Too Many Requests con un encabezado Retry-After o una respuesta que tarda 8 segundos. La aplicación sigue llamando a las direcciones URL de API reales, por lo que prueba la aplicación a medida que se ejecuta en producción, incluido su cliente HTTP, el SDK y la directiva de reintento.

En comparación con otras formas de probar errores de API:

Approach Lo que encuentras Lo que te pierdes
Esperar a que entre en producción Fallos reales Todo, hasta que un usuario lo pulse
Simula la API en tus pruebas o deja que el agente de codificación escriba el simulacro Si se ejecutan las ramas de error Los códigos de estado reales, los encabezados y los cuerpos de error de la API, y la directiva de reintento de tu SDK. La aplicación también necesita una opción de solo prueba para acceder al simulador de prueba.
Llama a la API real y espera que falle Comportamiento real No se puede desencadenar un fallo a petición
Ejecuta tu aplicación a través de un proxy que simula errores Errores, limitación de velocidad y latencia en las direcciones URL reales, a petición Tu código de forma aislada. Reserve las pruebas unitarias para eso.

Proxy de desarrollo como proxy de reenvío para desarrollo y pruebas

Dev Proxy es un proxy de reenvío que ejecuta en su máquina o en CI para interceptar y modificar solicitudes de su aplicación a las API que usted elija. Con Dev Proxy, puedes hacer lo siguiente:

  • Vea cómo responde la aplicación a los errores de API.
  • Compruebe cómo gestiona su aplicación los límites y los límites de velocidad de API.
  • Vea cómo la aplicación controla las API lentas.
  • Crea mock API sin escribir una línea de código.
  • Obtenga instrucciones contextuales sobre cómo usar las API.

Para probarlo en la API a la que llama la aplicación, descargue un valor preestablecido e inicie Dev Proxy con él. Por ejemplo, para GitHub:

devproxy config get github-rate-limiting
devproxy --config-file "~dataFolder/configs/github-rate-limiting/.devproxy/devproxyrc.json"

Los valores preestablecidos también están disponibles para los puntos de conexión de OpenAI (openai-throttling), Anthropic (anthropic-throttling) y Microsoft Graph OneDrive y SharePoint (microsoft-graph-rate-limiting).

Pruebe por sí mismo

Elija un escenario que coincida con lo que está creando:

Paso siguiente

Introducción

  • Se actualizó por última vez el