--- title: "Configuración de Proxy" description: "Configuración de Proxy para Consultas" type: "docs" category: "doc" tags: [] authors: [Anonymous] date: "2026-08-27" last_update: "2026-08-21" time_minutes: 7 draft: false unlisted: false url: "https://www.stage.apigateway.cl/docs/tutoriales/proxy" --- # Configuración de Proxy para Consultas Un **proxy** es un servidor intermediario que actúa como puente entre tu aplicación y los servicios externos. En el contexto de API Gateway, utilizamos proxies para distribuir las consultas, por ejemplo al SII (Servicio de Impuestos Internos), desde diferentes direcciones IP, evitando así posibles restricciones y limitaciones de uso. > [!INFO] Importante > > Cuando cada empresa gestiona sus consultas al SII a través de su propio proxy y dirección IP, se entiende que está haciendo un uso legítimo y responsable de nuestra API. Promovemos y respaldamos la **automatización de consultas tributarias como un derecho fundamental de las empresas** que buscan asegurar el cumplimiento de sus obligaciones fiscales de manera eficiente y transparente. ## Riesgo al no utilizar un proxy El SII puede implementar límites de uso basados en direcciones IP para controlar el acceso a sus servicios. Debido a que API Gateway es la plataforma líder en Chile que ofrece servicios web que el SII no proporciona directamente, debemos procesar un alto volumen de consultas, lo que puede provocar restricciones impuestas por el SII. Cuando el SII restringe o limita las consultas desde una IP específica, el riesgo es que afecte a múltiples usuarios. Esto se muestra en el siguiente diagrama: {.w-75 .mx-auto} ![Proxy](https://www.apigateway.cl/img/diagrams/content/docs/tutoriales/proxy/sin-proxy.svg) ## Funcionamiento del Proxy Con el proxy, se busca mitigar este problema permitiendo que las consultas se realicen desde direcciones IP diferentes, una por cada empresa/RUT que realiza consultas al SII. Con esto, se distribuye la carga y se minimiza el impacto de las restricciones. El proxy funciona como un intermediario en la comunicación entre aplicaciones, evitando que una sola dirección IP sea restringida y afecte a múltiples usuarios. Esto se muestra en el siguiente diagrama: {.w-75 .mx-auto} ![Proxy](https://www.apigateway.cl/img/diagrams/content/docs/tutoriales/proxy/con-proxy.svg) **Beneficios del uso de proxy:** - **Aislamiento de restricciones**: Si una IP es limitada, solo afecta a los usuarios de ese proxy específico. - **Mayor disponibilidad**: Si la IP principal está restringida, los proxies permiten continuar operando. - **Distribución de carga**: Reduce la presión sobre una sola dirección IP. ## Configuración del Proxy El proxy debe estar ubicado en una red pública accesible desde API Gateway. En este tutorial utilizaremos **Squid**, un proxy HTTP/HTTPS robusto y ampliamente utilizado, pero puedes implementar cualquier solución compatible. **Opciones de despliegue:** - **Servidores propios**: Infraestructura on-premise. - **Servicios en la nube**: Google Cloud Platform (tiene región en Chile), AWS, Azure, etc. - **Proveedores locales**: Otros servicios con presencia en Chile. ### 1. Archivo Docker Compose Utilizaremos Docker Compose para simplificar la implementación del proxy Squid. Crea un directorio para tu proyecto y dentro de este crea un archivo `docker-compose.yml` con la siguiente configuración: ```yaml services: squid: image: ubuntu/squid:latest container_name: squid restart: unless-stopped volumes: - "./squid.conf:/etc/squid/squid.conf:ro" - "./passwords:/etc/squid/passwords:ro" ports: - "3128:3128" ``` > [!NOTE] Nota importante > >El puerto 3128 es el puerto estándar de Squid. Si necesitas usar un puerto diferente, asegúrate de modificarlo tanto en el `docker-compose.yml` como en el archivo de configuración `squid.conf`. Este puerto debe ser accesible desde Internet o al menos desde los servidores de API Gateway. ### 2. Configuración de Squid Crea el archivo `squid.conf` en el mismo directorio de `docker-compose.yml` con la siguiente configuración: ``` # Configuración de autenticación. auth_param basic program /usr/lib/squid/basic_ncsa_auth /etc/squid/passwords auth_param basic realm Proxy # Definir ACL para usuarios autenticados. acl authenticated proxy_auth REQUIRED # Definir ACL para dominios del SII (recomendado para seguridad). acl sii_domains dstdomain .sii.cl # AWS API Gateway (usado por eboleta) acl eboleta_aws_api dstdomain .amazonaws.com # Previred acl previred_domains dstdomain .previred.com # Permitir acceso solo a usuarios autenticados y solo a dominios del SII. http_access allow authenticated sii_domains http_access allow authenticated eboleta_aws_api http_access allow authenticated previred_domains # Denegar todas las demás solicitudes. http_access deny all # Escuchar en el puerto 3128. http_port 3128 ``` > [!NOTE] Nota de seguridad > > La configuración anterior incluye una restricción que limita el uso del proxy únicamente a dominios del SII (`.sii.cl`), Previred (`.previred.com`) y eBoleta (`.amazonaws.com`). Esto es altamente recomendado para evitar el uso no autorizado del proxy para otros fines. Si necesitas acceder a otros dominios a través del proxy, puedes modificar o eliminar la línea `acl sii_domains dstdomain .sii.cl` y cambiar `http_access allow authenticated sii_domains` por `http_access allow authenticated`. ### 3. Creación de Credenciales Genera el archivo de contraseñas usando el comando `htpasswd`: ```bash htpasswd -c passwords ``` **Ejemplo:** ```bash htpasswd -c passwords admin mi_contraseña_segura ``` **Recomendaciones de seguridad:** - Usa contraseñas fuertes (mínimo 12 caracteres). - Combina mayúsculas, minúsculas, números y símbolos. - Evita información personal en las credenciales. ### 4. Iniciar el Servicio Ejecuta el siguiente comando para iniciar el proxy: ```bash docker compose up -d ``` Verifica que el servicio esté funcionando correctamente: ```bash docker compose ps ``` ## Habilitación en API Gateway Una vez que tu proxy esté funcionando, necesitas configurarlo en API Gateway. Acá hay 2 formas de hacerlo dependiendo de qué versión de API Gateway estés usando: - **Versión V2**: Acceder a la [configuración de la conexión](https://app.apigateway.cl/dashboard). Recuerda que en la versión 2 la configuración del proxy se debe realizar por cada conexión que tengas activa. - **Versión Legacy (V1)**: Acceder a la [configuración de tu perfil](https://legacy.apigateway.cl/dashboard#profile:updateProfile). Independientemente de la versión de API Gateway que estés usando, debes configurar el proxy indicando su URL, la cual tendrá el siguiente formato: ``` http://:@:3128 ``` Donde los parámetros son: - ``: El usuario que creaste con `htpasswd`. - ``: La contraseña correspondiente. - ``: La dirección IP pública de tu servidor proxy. - `3128`: El puerto de Squid (cambia si usaste uno diferente). ### Realización de pruebas Después de guardar la configuración, API Gateway comenzará a utilizar tu proxy para todas las consultas. Esto significa que las consultas se realizarán desde la IP de tu proxy en lugar de la IP principal de API Gateway. Para verificar que la configuración es correcta, realiza una consulta a la API y revisa la cabecera `X-Stats-HttpClientProxy` en la respuesta. Si su valor es `1`, significa que el proxy está siendo utilizado. Si el valor es `0`, el proxy no se está usando; en ese caso, revisa la sección de problemas comunes a continuación. ### Problemas Comunes **1. Error de autenticación** - Verifica que las credenciales en API Gateway coincidan con las del archivo `passwords`. - Confirma que el archivo `passwords` esté correctamente montado en el contenedor. **2. Proxy no accesible** - Verifica que el puerto 3128 esté abierto en el firewall. - Confirma que la IP del proxy sea accesible desde Internet. - Revisa los logs de Docker: `docker compose logs squid`. **3. Consultas lentas** - Monitorea el uso de recursos del servidor proxy. - Considera aumentar los recursos asignados al contenedor. - Verifica la latencia de red entre API Gateway y tu proxy. --- Last updated on 21/08/2026