407 Proxy Authorization Required: Guía técnica de solución

Inicias un perfil en AdsPower, Dolphin Anty, GoLogin, Multilogin o Hidemyacc. El proxy se ve bien en la configuración del perfil. Facebook Ads Manager no carga, TikTok Business Center se detiene, o tu scraper muere antes de la primera solicitud. Entonces lo ves: 407 Proxy Authorization Required.

Ese error desperdicia horas cuando depuras la capa equivocada. La mayoría de los operadores primero culpan al objetivo. Piensan que Facebook bloqueó la cuenta, el cloaker se rompió, o el scraper chocó con un muro anti-bot. Generalmente no es eso. Un 407 significa que el tráfico se detuvo en la puerta del proxy antes de que la solicitud se moviera correctamente hacia adelante.

Si ejecutas campañas geo-dirigidas, configuraciones de farming de cuentas o stacks de scraping en múltiples entornos, esa distinción importa. La solución no es simplemente "ingresar la contraseña de nuevo". Necesitas saber si el problema está en el navegador antidetect, el runtime del script, la capa de proxy del sistema operativo, o un método de autenticación del proxy que el cliente no soporta.

Tabla de contenidos

• Qué es realmente un error 407 Proxy Authorization Required
  • La forma rápida de pensarlo
  • Qué inspeccionar primero
• Causas comunes clasificadas por probabilidad
  • La lista corta que soluciona la mayoría de los casos
  • Las fallas menos obvias
• Configuración de proxies en navegadores antidetect
  • Qué se rompe dentro de los perfiles antidetect
  • Verificaciones de configuración de perfil que realmente importan
  • Alineación geográfica y de identidad
• Autenticación para scripts y herramientas de automatización
  • Comienza con curl antes de tocar el código
  • Patrones de Python y Node
  • Trampas a nivel de entorno
• Autenticación avanzada y depuración
  • Ajusta la solución al entorno
  • Qué verificar cuando el cliente debería soportar autenticación
  • Separa las fallas de autenticación de las fallas de túnel SSL
  • Compromisos que importan en operaciones en vivo
• Medidas preventivas para operaciones de alto volumen
  • Construye alrededor del fallo en lugar de reaccionar a él
  • Donde los equipos aún se descuidan

Qué es realmente un error 407 Proxy Authorization Required

Un error 407 Proxy Authorization Required es una falla de autenticación del proxy. No es un error del sitio de origen. MDN establece que la respuesta significa que la solicitud carece de credenciales válidas para el servidor proxy, y el cliente puede reintentar con un encabezado Proxy-Authorization nuevo o reemplazado después de recibir un desafío Proxy-Authenticate, como se documenta en la referencia de estado 407 de MDN.

La forma rápida de pensarlo

Trata el proxy como un punto de control de seguridad. Tu navegador, perfil antidetect, bot o scraper envía una solicitud. El proxy la intercepta y pide prueba de que tienes permiso para usar ese punto de salida. Si la prueba está ausente, vencida, mal formada o no es compatible, el proxy devuelve 407.

Por eso la gente pierde tiempo confundiendo esto con un 401 o 403. Un 401 se trata de autenticarse con el recurso de destino. Un 403 significa que el destino entendió la solicitud y aún así la rechazó. Un 407 significa que ni siquiera pasaste la capa del proxy.

Si estás comparando configuraciones, la categoría de proxy puede afectar qué tan frecuentemente esto aparece operacionalmente. Los proxies residenciales, móviles, de datacenter e IPv6 se comportan diferente bajo carga, estilo de autenticación y tolerancia del objetivo. Esto importa más en el trabajo de cuentas publicitarias que en navegación casual. Un repaso rápido de tipos de proxy y dónde encajan ayuda cuando estás ajustando infraestructura a Facebook, TikTok, flujos de cloaking o tareas de scraping.

Qué inspeccionar primero

El encabezado que importa es Proxy-Authenticate. Eso te dice qué esquema espera el proxy. Tu cliente entonces tiene que responder con un encabezado Proxy-Authorization coincidente.

Regla práctica: Si no sabes qué método de autenticación pidió el proxy, todavía estás adivinando.

Tres verificaciones cortan el ruido rápidamente:

1. Confirma que el tráfico está usando un proxy. Muchos 407 "misteriosos" ocurren porque el tráfico fue enrutado a través de una ruta de proxy autenticado por configuraciones del sistema, una política del navegador o un dispositivo de borde de la red.
2. Verifica si el proxy devolvió un encabezado de desafío. Si lo hizo, lee el esquema en lugar de asumir que solo el nombre de usuario y contraseña lo resolverán.
3. Reintenta con credenciales en el lugar correcto. En algunas herramientas eso significa campos de proxy a nivel de perfil. En otras significa variables de entorno, configuración de runtime o encabezados de solicitud explícitos.

El tráfico mal enrutado también puede disparar un 407 cuando las solicitudes pasan involuntariamente por una ruta de proxy corporativo o administrado autenticado. Por eso este error aparece en lugares donde los operadores juran que "no están usando un proxy", incluso cuando su máquina o red claramente sí lo está.

Causas comunes clasificadas por probabilidad

El código 407 pertenece a los estándares de autenticación HTTP y es la respuesta correcta cuando un proxy rechaza credenciales. HTTP/1.1 formalizó este mecanismo, que no estaba presente en HTTP/1.0, como se señala en la discusión de implementación de Tinyproxy sobre soporte 407. En términos simples, esto no es un bug extraño específico del proveedor. Es la respuesta normal del protocolo cuando la autenticación del proxy falla.

La lista corta que soluciona la mayoría de los casos

La mayoría de los incidentes 407 en media buying y scraping provienen de errores de configuración aburridos, no de bloqueos exóticos.

• Formateo incorrecto de credenciales: El nombre de usuario o contraseña es correcto en teoría pero incorrecto en el campo real. Los errores comunes incluyen pegar host:port:user:pass en un cliente que espera campos separados, o dejar caer un carácter especial en un formato de URL sin codificarlo.
• Protocolo incorrecto en el puerto elegido: El perfil dice HTTP mientras el endpoint espera SOCKS5, o viceversa. Los navegadores antidetect a menudo te permiten elegir el protocolo manualmente, lo cual es útil hasta que se configura mal.
• Desajuste en la lista blanca: Los flujos de datacenter y algunos ISP a menudo usan autorización por IP en lugar de o junto con autenticación de usuario/contraseña. Si tu IP de oficina, IP de salida del servidor o cloud runner cambió, el proxy puede rechazar el acceso incluso cuando tu configuración local se ve limpia.
• Credenciales obsoletas en caché en el cliente: Esto sucede después de cambios de contraseña, traspasos de equipo, perfiles copiados o sesiones de larga duración reutilizadas en lotes de cuentas publicitarias.

Si construyes tu propio relay o caja de prueba, configurar un servidor proxy correctamente también importa. Una capa de proxy local descuidada puede crear síntomas falsos que parecen fallas de autenticación del proveedor.

Las fallas menos obvias

Los casos más complicados están fuera de la aplicación misma.

Un proxy transparente o corporativo puede interceptar tráfico e inyectar su propio requerimiento de autenticación. En ese caso, tus detalles de proxy residencial o móvil pueden estar bien, pero la máquina aún recibe un 407 porque la red quiere credenciales separadas. Esto es común en laptops administrados, asientos de oficina rentados y algunos entornos de coworking.

Los stacks de automatización también se rompen después de cambios en el entorno. Una actualización del navegador, herencia de runtime .NET, un nuevo archivo PAC o una regla de proxy del sistema cambiada puede anular lo que tu aplicación cree que está haciendo. Los operadores ven esto mucho cuando un script funcionaba ayer, luego falla después de una actualización del sistema operativo o después de mover la carga de trabajo a una plantilla VPS diferente.

Si el mismo proxy funciona en un entorno y arroja 407 en otro, deja de culpar al proxy primero. Compara los entornos.

Un patrón de campo más importa en operaciones de cuentas. La ruta de endpoint incorrecta puede poner tráfico en una ruta autenticada que no tenías intención de usar. Eso aparece cuando los equipos clonan perfiles entre lotes de cuentas de Facebook y TikTok, mezclan plantillas de proxy o reutilizan contenedores de navegador de cloaking antiguos sin limpiar configuraciones de red heredadas.

Configuración de proxies en navegadores antidetect

Los navegadores antidetect fallan de manera diferente que los scripts porque tienen más partes móviles. No solo estás autenticando un proxy. Estás vinculando un proxy a un perfil con huella digital, una zona horaria, configuraciones de idioma, cookies y a menudo un flujo de trabajo específico de plataforma para cuentas publicitarias de Facebook, cuentas publicitarias de TikTok, páginas de cloaking o secuencias de farming de cuentas.

La orientación de soporte para runtimes administrados muestra que los errores 407 a menudo aparecen después de actualizaciones o cambios de configuración, y la causa raíz puede ser herencia de proxy del sistema, direcciones PAC incorrectas o delegación de credenciales en lugar de los campos de proxy visibles de la aplicación, como se describe en la nota de solución de problemas 407 de Optimizely. Ese mismo patrón aparece en configuraciones antidetect todo el tiempo.

Qué se rompe dentro de los perfiles antidetect

AdsPower, Dolphin Anty, GoLogin, Multilogin e Hidemyacc todos te permiten asignar proxies a nivel de perfil. Eso es conveniente, pero crea una falsa sensación de aislamiento. Los operadores asumen que la configuración del perfil es lo único que importa. No lo es.

Los puntos de ruptura típicos se ven así:

Herramienta	Disparador común de 407	Qué suele solucionarlo
AdsPower	Protocolo incorrecto seleccionado para el endpoint importado	Ajusta el protocolo del perfil al tipo de endpoint, luego ejecuta la verificación integrada
Dolphin Anty	Cadena de proxy importada dividida en campos incorrectos	Vuelve a ingresar host, puerto, login y contraseña manualmente
GoLogin	Capa del sistema operativo o extensión aún heredando otra ruta de proxy	Desactiva el comportamiento heredado del proxy del sistema y vuelve a probar
Multilogin	Clon de perfil antiguo que lleva autenticación obsoleta o configuraciones de región	Crea un perfil nuevo y prueba el proxy antes de importar cookies
Hidemyacc	Huella digital y configuración geográfica no coinciden con la ubicación del proxy	Alinea zona horaria, locale y comportamiento WebRTC con el país del proxy

Un proxy que "se guarda" en la UI no es lo mismo que un proxy que autentica limpiamente.

Si usas herramientas antidetect Afina Browser o sistemas similares basados en perfiles, aplica la misma regla. Valida la ruta de red antes de importar cookies envejecidas, adjuntar cuentas publicitarias o calentar un farm.

Verificaciones de configuración de perfil que realmente importan

No solo pegues un proxy y hagas clic en lanzar. Usa este orden:

• Ingresa el proxy en el formato que la herramienta espera: Algunas herramientas quieren una cadena. Otras quieren campos separados de host, puerto, nombre de usuario y contraseña.
• Ejecuta la verificación de proxy integrada antes de abrir el perfil: Esto atrapa autenticación incorrecta temprano, antes de que el navegador cree ruido extra con cookies, pestañas de inicio y tráfico de extensiones.
• Prueba un perfil nuevo si uno antiguo sigue fallando: Los clones de perfil a menudo llevan basura oculta. Autenticación en caché, estado de extensión antiguo y configuraciones de red heredadas pueden sobrevivir a la duplicación.
• Observa la herencia de PAC y proxy del sistema: Si el navegador antidetect tiene un proxy de perfil válido pero la máquina anfitriona aún enruta tráfico a través de un proxy administrado, seguirás persiguiendo fantasmas.

Muchos equipos empeoran esto al importar masivamente cientos de perfiles con formatos de endpoint mezclados. Así es como terminas con algunos administradores de negocios de Facebook abriéndose limpiamente mientras otros arrojan 407 en la misma máquina.

Aquí hay un recurso de tutorial para equipos que quieren una referencia visual de configuración antes de desplegar perfiles a escala:

Alineación geográfica y de identidad

Para operaciones publicitarias, la autenticación no es la única capa que importa. Si el proxy autentica pero el perfil anuncia una región, zona horaria o paquete de idioma diferente, las plataformas aún pueden marcar la sesión.

Los proxies residenciales funcionan bien cuando necesitas comportamiento de enrutamiento de consumidor normal para trabajo de cuentas de Facebook o TikTok. Los proxies móviles son útiles cuando los objetivos toleran mejor la rotación de IP de operador que sesiones de aspecto estático. Los proxies de datacenter son rápidos y simples para herramientas internas, pre-verificaciones y algunos flujos de trabajo de farm, pero son más fáciles de clasificar para las plataformas. IPv6 puede ser práctico donde los objetivos lo soportan limpiamente, pero muchos endpoints de ad-tech y legacy aún se comportan inconsistentemente, así que necesitas probar plataforma por plataforma.

Para campañas geo-dirigidas, los operadores obtienen resultados más limpios cuando alinean región del proxy, locale del navegador, zona horaria e historial de sesión desde el inicio en lugar de intentar corregir señales de desajuste después.

Autenticación para scripts y herramientas de automatización

Los scripts fallan con menos teatro que los navegadores antidetect. Usualmente solo lanzan una excepción, reintentan mal y queman tiempo. La solución también es más limpia. Reduce el problema hasta que sepas si las credenciales funcionan fuera de tu código.

La secuencia de solución de problemas más confiable incluye verificar configuraciones de proxy del sistema, revisar variables de entorno como http_proxy, agregar excepciones no-proxy para destinos internos y probar con curl -v, como se describe en la guía de solución de problemas de SIP y proxy de Kolmisoft.

Comienza con curl antes de tocar el código

Usa curl -v primero. Te dice si el problema está en las credenciales del proxy o en tu lógica de aplicación.

Un flujo de prueba simple:

• Configura el endpoint de proxy exacto que estás usando en producción: No sustituyas uno "similar".
• Ejecuta curl -v a través de ese proxy: La salida detallada te ayuda a ver si el proxy responde con un desafío de autenticación o si la solicitud está muriendo en otro lugar.
• Verifica si las credenciales se están enviando como se espera: Si curl funciona y tu script no, el problema es usualmente tu configuración de biblioteca, manejo de autenticación o configuraciones de entorno heredadas.
• Agrega reglas no-proxy para destinos internos cuando sea necesario: APIs internas, URLs de callback y paneles de control locales a menudo no deberían atravesar la ruta de proxy autenticado en absoluto.

curl -v es la fuente de verdad más rápida cuando un scraper, verificador o bot de cuenta arroja un 407 y los logs son vagos.

Patrones de Python y Node

En requests de Python, el enfoque limpio es definir proxies explícitamente en la sesión en lugar de esperar que el runtime herede los valores correctos. En aiohttp, ten cuidado con el manejo de conector y autenticación porque los stacks asíncronos pueden ocultar errores detrás de bucles de reintento.

En Node con axios, muchos equipos rompen la autenticación al mezclar variables de entorno con configuración de proxy por solicitud. En Puppeteer o puppeteer-extra, los argumentos de lanzamiento del navegador y la navegación a nivel de página pueden comportarse diferente de los clientes HTTP simples, especialmente si un plugin stealth, extensión o capa MITM local cambia la ruta.

Un flujo de trabajo práctico se ve así:

1. Prueba el endpoint con curl.
2. Replica el mismo formato de endpoint en el script.
3. Desactiva la herencia de proxy ambiental mientras pruebas.
4. Registra los primeros encabezados de respuesta.
5. Solo entonces agrega reintentos, rotación o lógica de cuenta.

Si estás ejecutando web crawlers a escala, esta disciplina importa más que wrappers de reintento sofisticados. Los equipos que hacen web crawling con Python usando proxies usualmente obtienen mejor estabilidad validando la ruta de red antes de agregar lógica de parser, automatización de navegador o trabajadores de cola.

Trampas a nivel de entorno

Los operadores avanzados aún son cortados aquí.

Un trabajo cron puede heredar un proxy env diferente que tu shell. Un contenedor Docker puede recibir http_proxy del host o pipeline CI sin que lo notes. Un runner de Windows puede empujar tráfico a través de un proxy corporativo predeterminado incluso cuando la configuración de la aplicación apunta a otro lugar. Las herramientas de administración internas pueden fallar porque deberían haber omitido el proxy por completo.

Para farming de cuentas, verificaciones de cloaking, verificación de anuncios y flotas de scraper, eso significa que un worker puede autenticar limpiamente mientras otro devuelve 407 usando el mismo código base. El código no siempre es la variable. El runtime a menudo lo es.

Las herramientas SIP muestran una versión paralela del mismo problema. Un 407 allí significa que el agente de usuario debe autenticarse con el proxy antes de que la solicitud sea aceptada, y las soluciones de campo a menudo implican usar el modo de autenticación basado en cuenta correcto y verificar el par nombre de usuario/contraseña. La lección se traslada: la autenticación tiene que coincidir con el entorno exacto y la forma de identidad que el proxy espera.

Autenticación avanzada y depuración

Un 407 que sobrevive las verificaciones básicas usualmente apunta a una de tres cosas. El cliente respondió al proxy con el esquema de autenticación incorrecto, la solicitud tomó una ruta de red diferente a la esperada, o el proxy desafió un túnel CONNECT que tu herramienta nunca completó correctamente.

El lado del protocolo es directo. El proxy envía un encabezado Proxy-Authenticate, y el cliente tiene que responder con un método Proxy-Authorization coincidente. La explicación de http.dev del 407 cubre el flujo de encabezados, pero el problema de campo es usualmente soporte del cliente, no teoría.

Ajusta la solución al entorno

Los navegadores antidetect y scripts de automatización fallan de manera diferente.

En navegadores antidetect, usualmente veo 407 vinculado a errores a nivel de perfil. Un proxy funciona en un perfil, luego falla en otro porque el navegador almacenó credenciales antiguas, el perfil importó una plantilla de proxy obsoleta, o una extensión interceptó tráfico antes de que el navegador enviara el encabezado de autenticación. Los wrappers de navegador también ocultan detalles de handshake de bajo nivel, así que el error parece aleatorio incluso cuando la causa raíz es consistente.

En scripts, la falla es más mecánica. La biblioteca puede no soportar el esquema de autenticación del proxy, puede ignorar credenciales en HTTPS CONNECT, o puede enrutar tráfico a través de un objeto de sesión que difiere del que probaste. Las ejecuciones headless también exponen problemas que nunca ves en un navegador de escritorio, especialmente cuando variables de entorno o configuraciones de contenedor anulan la configuración del proxy.

Esa división importa porque la ruta de depuración cambia.

Qué verificar cuando el cliente debería soportar autenticación

Comienza con el modo de autenticación exacto que el proxy espera.

• Autenticación básica: Usualmente está bien para flotas de scraper, operaciones publicitarias basadas en perfiles y pools residenciales o móviles rotatorios.
• Digest o NTLM: Común en entornos empresariales administrados. A menudo no soportado o manejado inconsistentemente en bibliotecas de automatización y wrappers de navegador.
• Autenticación por IP: Más limpia en salida fija de servidor, pero frágil cuando runners, conexiones domésticas o instancias en la nube cambian IPs salientes.

Si un perfil de navegador falla y el mismo proxy funciona en cURL o un cliente HTTP raw, el proxy probablemente está bien. El stack del navegador es el problema. Verifica credenciales guardadas, conflictos de extensiones, herencia de proxy por perfil, y si la herramienta soporta autenticación tanto en solicitudes HTTP como en solicitudes HTTPS CONNECT.

Si un script falla mientras el navegador funciona, inspecciona primero el comportamiento de la biblioteca. Algunos clientes envían credenciales solo después del primer desafío. Otros necesitan la URL del proxy formateada exactamente como http://user:pass@host:port. Algunos se rompen una vez que entran redirecciones, reintentos o pooling de sesiones en la imagen.

Separa las fallas de autenticación de las fallas de túnel SSL

Los proxies HTTPS agregan otra capa de confusión. Un mal handshake CONNECT puede parecer un problema de autenticación porque el cliente reporta solo el 407 final o falla de túnel genérica. Si estás rastreando tráfico HTTPS, este desglose de un servidor proxy SSL y manejo de CONNECT ayuda a distinguir problemas de certificado y túnel de fallas de credenciales reales.

Una secuencia de prueba rápida funciona mejor que prueba y error amplio:

1. Prueba el proxy con un cliente mínimo como cURL.
2. Confirma el mismo host, puerto, nombre de usuario y contraseña en la herramienta que falla.
3. Prueba una solicitud HTTP simple.
4. Prueba una solicitud HTTPS a través de CONNECT.
5. Captura encabezados de solicitud y respuesta si la herramienta lo permite.
6. Desactiva extensiones, reintentos, lógica de rotación y extras de perfil hasta que el handshake tenga éxito.

Ese orden ahorra tiempo en configuraciones de scraping y media buying donde varias capas pueden mutar la solicitud antes de que llegue al proxy.

Compromisos que importan en operaciones en vivo

La autenticación usuario/contraseña es flexible, especialmente para pools rotatorios, equipos remotos y perfiles antidetect pasados entre operadores. También crea más puntos de falla. Las credenciales expiran, se copian mal o se quedan en una plantilla antigua mucho después de que el endpoint del proxy cambió.

El whitelisting de IP elimina esa capa de credenciales, por lo que lo prefiero para trabajos de backend estables y salida de oficina fija. El compromiso es rigidez operacional. Si la IP de origen cambia, los workers comienzan a fallar inmediatamente, y los equipos a menudo interpretan mal la interrupción como un bug de la aplicación.

La autenticación empresarial se sienta en el peor punto medio para trabajo multiplataforma. Puede estar bien dentro de un entorno Windows administrado y dolorosa en cualquier otro lugar. Esa es una razón por la cual un proxy puede funcionar en un navegador en una laptop de empresa y fallar en un contenedor Linux ejecutando el mismo flujo de trabajo objetivo.

La buena depuración depende de logs, no de conjeturas. Quieres saber si la solicitud llegó al proxy, qué esquema de autenticación se solicitó, si se intentó CONNECT, y qué ruta de origen usó el proceso.

Elimina el enlace de afiliado, ignora la copia de marketing y lee el handshake. Ahí es usualmente donde se resuelve el 407.

Medidas preventivas para operaciones de alto volumen

A escala, los errores 407 no son una molestia única. Son un problema de operaciones. Cada verificación de inicio de sesión fallida, worker de scraper muerto y lanzamiento de perfil roto agrega fricción a la gestión de cuentas, QA de cloaking, pruebas de región y despliegue de gasto.

Construye alrededor del fallo en lugar de reaccionar a él

Los mejores equipos diseñan sus stacks para que la autenticación del proxy pueda fallar sin derribar todo el flujo de trabajo.

• Centraliza el almacenamiento de credenciales: No dejes logins de proxy dispersos en hojas de cálculo, notas de navegador y configuraciones de bot clonadas.
• Separa plantillas de perfil por tipo de proxy: Residencial, móvil, datacenter e IPv6 no deberían compartir todos las mismas suposiciones.
• Valida antes de lanzar: Prueba proxies antes de abrir perfiles calentados de Facebook o TikTok, antes de ejecutar acciones de farm y antes de iniciar lotes de scraping.
• Mantén las reglas de bypass explícitas: Herramientas internas, servicios de callback y paneles de administración a menudo necesitan excepciones no-proxy en lugar de enrutamiento forzado.

Para farming de cuentas, esto importa aún más. Una sola plantilla incorrecta puede clonar una falla 407 en todo un lote de perfiles. Entonces el equipo culpa al stack anti-detect, la puntuación de confianza de la cuenta publicitaria o la plataforma objetivo, cuando la falla comenzó en una plantilla de proxy sucia.

Donde los equipos aún se descuidan

Los equipos usualmente conocen lo básico. Aún toman atajos en el proceso.

Un operador cambia credenciales y no le dice al equipo de scraper. Otro actualiza la ruta PAC en dispositivos administrados pero no en la flota VPS. Alguien clona perfiles de GoLogin de un lote de TikTok a un lote de Facebook sin reiniciar suposiciones de región. Un verificador de cloaking hereda un proxy del sistema que nunca debería haber tocado.

Esas son fallas evitables.

La autenticación de proxy estable no es glamorosa. Gana porque mantiene el resto del stack predecible.

Si administras tráfico de alto volumen, haz que la prevención del 407 sea parte de tu lista de verificación de despliegue. Trata la autenticación del proxy de la misma manera que tratas las cookies de cuenta, huellas digitales del navegador, límites de gasto y lógica de failover. Los operadores que hacen eso pierden menos tiempo con falsos "problemas de plataforma" y mantienen las campañas en movimiento.

---

Si necesitas infraestructura de proxy construida para scraping, gestión de cuentas publicitarias, navegadores antidetect, campañas geo-dirigidas y operaciones multi-cuenta, echa un vistazo a Sota Proxy. Cubre casos de uso residenciales, móviles, ISP, datacenter e IPv6, y si ya refieres herramientas o infraestructura a otros operadores, su programa de socios ofrece hasta 40% de comisión.