Configuración de proxy del navegador: guía de SOCKS5, HTTP y HTTPS

BotBrowser puede configurar el extremo proxy del navegador, aceptar credenciales en una URL de proxy y derivar zona horaria, locale e idioma desde la IP pública del proxy. No controla el enrutamiento ni la autenticación del proveedor, el DNS ascendente ni las políticas del destino. Trátalos como límites operativos separados y usa el procedimiento de verificación de salida del proxy de Launcher para registrar lo que observaron dos endpoints controlados.

TL;DR

• Elige SOCKS5H cuando el DNS deba resolverse a través del proxy; usa HTTP o HTTPS si el proveedor lo requiere.
• Usa protocol://username:password@host:port y codifica en URL los caracteres reservados.
• Verifica la IP pública, zona horaria y locale observados. Sobrescribe valores del navegador solo con expectativas documentadas.
• Si el proxy falla, detén el flujo; no recurras silenciosamente a una conexión directa.

Contenido

• Introducción
• Impacto en la privacidad
• Contexto técnico
• Configuración y uso
• Conclusión práctica

Introducción

Un perfil de huella digital por sí solo no es suficiente para una identidad de navegador consistente. Tu dirección IP, comportamiento DNS y metadatos geográficos deben alinearse con la identidad que tu perfil presenta. Si tu perfil dice "usuario de Windows en Berlín" pero tu IP se resuelve a un centro de datos en Virginia, la inconsistencia es obvia.

BotBrowser proporciona soporte mejorado de proxy integrado directamente en el motor del navegador. A diferencia de Chromium estándar, BotBrowser acepta credenciales integradas en las URL de proxy, deriva automáticamente configuraciones geográficas desde la IP de tu proxy y admite SOCKS5, SOCKS5H, HTTP, HTTPS y QUIC cuando el navegador/cliente, el contexto autorizado y el proveedor de proxy lo admiten. La compatibilidad con QUIC no garantiza que HTTP/3 tenga éxito, no ofrece una recuperación mediante conexión directa ni controla la ruta ascendente del proveedor.

Impacto en la privacidad

Sin un proxy configurado correctamente, tu dirección IP real es visible para cada sitio que visitas. Las direcciones IP revelan tu ISP, ubicación física aproximada y pueden correlacionarse entre sesiones para construir un perfil de rastreo persistente.

Incluso al usar un proxy, las malas configuraciones pueden socavar tu privacidad. Las consultas DNS pueden filtrarse fuera del túnel del proxy, revelando tu actividad de navegación a tu ISP. Los candidatos ICE de WebRTC pueden exponer tu IP real a través de solicitudes STUN que viajan fuera de la ruta del proxy. Las discrepancias de zona horaria y locale entre tu identidad declarada y la geolocalización de tu IP crean inconsistencias que los sistemas de rastreo pueden marcar.

--proxy-server configura la ruta proxy solicitada por el navegador; no verifica DNS, WebRTC, la política del proveedor ni la autorización del destino. Si la detección de IP pública funciona, BotBrowser puede derivar zona horaria, locale e idioma de esa IP. Compara esos valores visibles en la página con el registro de ruta del proveedor; no prueban una ubicación física.

Contexto técnico

Cómo funciona el proxy del navegador

Cuando un navegador usa un proxy, el tráfico HTTP y HTTPS se reenvía a través del servidor proxy en lugar de conectarse directamente al destino. El destino ve la dirección IP del proxy, no la tuya.

El endpoint elegido queda en --proxy-server; eso no identifica por sí solo qué resolvedor respondió la consulta DNS.

Diferentes protocolos de proxy manejan esto de forma diferente:

SOCKS5 reenvía conexiones a través de un proxy. Que DNS se resuelva localmente o en el proxy depende del cliente y del esquema; verifica la ruta del resolvedor con la prueba aprobada por el proveedor, no a partir de una carga de página correcta.

Proxies HTTP usan el método CONNECT para establecer un túnel para tráfico HTTPS. El proxy ve el nombre de host de destino pero no el contenido cifrado. Los proxies HTTP no manejan tráfico UDP.

Proxies HTTPS cifran la conexión entre tu navegador y el servidor proxy mismo. Esto previene que tu ISP vea qué comandos de proxy envías, añadiendo una capa de confidencialidad a la conexión proxy.

Manejo de credenciales en Chromium estándar vs. BotBrowser

El flag --proxy-server de Chromium estándar acepta solo la dirección del proxy sin credenciales. La autenticación requiere manejo separado a través de prompts del sistema o API específicas del framework como page.authenticate(). Esto es inconveniente y puede interferir con la detección geográfica automática de BotBrowser.

BotBrowser extiende --proxy-server para aceptar credenciales integradas directamente en la URL:

protocol://username:password@host:port

Esto puede evitar un aviso de autenticación separado al mantener el extremo proxy y las credenciales en un único valor URL.

Tipos de proxy soportados y configuración

BotBrowser soporta cinco protocolos de proxy a través del flag --proxy-server:

Protocolo	Formato URL	Caso de uso
SOCKS5	socks5://user:pass@host:port	Propósito general, tráfico TCP
SOCKS5H	socks5h://user:pass@host:port	Resolución DNS dentro del túnel
HTTP	http://user:pass@host:port	Ampliamente disponible, tráfico HTTP/HTTPS
HTTPS	https://user:pass@host:port	Conexión proxy cifrada
QUIC	quic://user:pass@host:port	Solo si el cliente y el proveedor soportan QUIC

La ruta quic:// solo está disponible cuando el navegador/cliente y el proveedor de proxy soportan las operaciones QUIC necesarias. BotBrowser no proporciona un servicio QUIC automáticamente, no puede forzar a un origen a usar HTTP/3 ni controla la ruta ascendente del proveedor.

SOCKS5 vs. SOCKS5H

La diferencia entre socks5:// y socks5h:// es importante. Con socks5://, la resolución DNS ocurre localmente en tu máquina antes de que la conexión se envíe a través del proxy. Con socks5h://, el nombre de host se envía al servidor proxy, que resuelve DNS en tu nombre. Para privacidad, socks5h:// es la mejor opción porque previene que las consultas DNS se filtren a tu resolver local.

Nombres de usuario estructurados en proxy

Algunos proveedores de proxy codifican instrucciones de enrutamiento dentro del nombre de usuario usando separadores como comas o pipes. BotBrowser soporta estos nombres de usuario estructurados:

--proxy-server=socks5://user_abc,type_mobile,country_GB,session_1234:[email protected]:1080

Esto es común con proveedores de proxy residencial que enrutan tráfico basado en parámetros integrados en las credenciales.

Enfoque de BotBrowser para la integración de proxy

Alineación geográfica automática

Cuando BotBrowser se conecta a través de un proxy, detecta la IP pública del proxy y configura automáticamente:

• Zona horaria: derivada de la geolocalización de la IP
• Locale: coincidente con el país del proxy
• Idiomas: establecidos basándose en la región del proxy
• Geolocalización: coordenadas aproximadas desde la IP

Esto significa que un lanzamiento básico con solo --proxy-server ya produce una identidad geográficamente consistente:

chrome --bot-profile="path/to/profile.enc" \
       --proxy-server=socks5://user:pass@de-proxy:1080

BotBrowser detectará la IP alemana y establecerá zona horaria a Europe/Berlin, locale a de-DE e idiomas a de-DE,de,en automáticamente.

Anulaciones geográficas manuales

Cuando necesites configuraciones geográficas específicas que difieran de lo que la IP sugiere, usa los flags de anulación:

chrome --bot-profile="path/to/profile.enc" \
       --proxy-server=socks5://user:pass@proxy:1080 \
       --bot-timezone=America/New_York \
       --bot-locale=en-US \
       --bot-languages=en-US,en \
       --bot-location=40.7128,-74.0060

Los flags CLI tienen la máxima prioridad de configuración y anulan tanto la configuración del perfil como los valores auto-detectados.

Omitir la búsqueda de IP con --proxy-ip

Si ya conoces la IP pública de tu proxy, puedes omitir la búsqueda automática de IP en la primera navegación con el flag --proxy-ip (ENT Tier1):

chrome --bot-profile="path/to/profile.enc" \
       --proxy-server=socks5://user:pass@proxy:1080 \
       --proxy-ip="203.0.113.1"

--proxy-ip acepta IPv4, IPv6 o un par IPv4 e IPv6 separado por comas. Usa un par cuando el proxy tenga identidades de salida IPv4 e IPv6 independientes:

--proxy-ip="203.0.113.1,2001:db8::1009"

Esto elimina la solicitud de detección de IP en la primera navegación y mejora la velocidad de inicio.

Límites de ruta y comportamiento de cierre seguro

Mantén el tráfico previsto del navegador en la ruta proxy configurada salvo que una política de red aprobada defina otra. La configuración debe conservar ese límite de control. Si el proxy no está disponible, registra el fallo y detén el flujo en lugar de recurrir a una conexión directa.

Configuración y uso

Configuración básica con Playwright

const { chromium } = require('playwright-core');

(async () => {
  const browser = await chromium.launch({
    executablePath: 'path/to/botbrowser/chrome',
    args: ['--bot-profile=path/to/profile.enc', '--proxy-server=socks5://user:pass@proxy-host:1080'],
    headless: true,
  });

  const context = await browser.newContext();
  const page = await context.newPage();
  await page.goto('https://example.com');
  await browser.close();
})();

Configuración con Puppeteer y anulaciones geográficas

const puppeteer = require('puppeteer-core');

(async () => {
  const browser = await puppeteer.launch({
    executablePath: 'path/to/botbrowser/chrome',
    args: [
      '--bot-profile=path/to/profile.enc',
      '--proxy-server=socks5://user:pass@de-proxy:1080',
      '--bot-timezone=Europe/Berlin',
      '--bot-locale=de-DE',
      '--bot-languages=de-DE,de,en',
    ],
    headless: true,
    defaultViewport: null,
  });

  const page = await browser.newPage();
  await page.goto('https://example.com');
  await browser.close();
})();

Configuraciones comunes por región

Región	Zona horaria	Locale	Idiomas
Este de EE.UU.	America/New_York	en-US	en-US,en
Oeste de EE.UU.	America/Los_Angeles	en-US	en-US,en
Reino Unido	Europe/London	en-GB	en-GB,en
Alemania	Europe/Berlin	de-DE	de-DE,de,en
Japón	Asia/Tokyo	ja-JP	ja,en
Brasil	America/Sao_Paulo	pt-BR	pt-BR,pt,en
Corea del Sur	Asia/Seoul	ko-KR	ko-KR,ko,en

Servicio de detección de IP personalizado

Si ejecutas tu propio endpoint de detección de IP, configúralo con --bot-ip-service:

chrome --bot-profile="path/to/profile.enc" \
       --proxy-server=socks5://user:pass@proxy:1080 \
       --bot-ip-service="https://ip.example.com"

Puedes proporcionar múltiples endpoints como lista separada por comas. BotBrowser los ejecuta en paralelo y usa la respuesta más rápida:

--bot-ip-service="https://ip1.example.com,https://ip2.example.com"

Verificación

Después de lanzar BotBrowser con un proxy, verifica tu configuración:

const page = await context.newPage();

// Verificar IP pública
await page.goto('https://httpbin.org/ip');
const ipData = await page.textContent('body');
console.log('Public IP:', ipData);

// Verificar zona horaria
const tz = await page.evaluate(() => Intl.DateTimeFormat().resolvedOptions().timeZone);
console.log('Timezone:', tz);

// Verificar idioma
const lang = await page.evaluate(() => navigator.language);
console.log('Language:', lang);

// Verificar locale
const locale = await page.evaluate(() => Intl.NumberFormat().resolvedOptions().locale);
console.log('Locale:', locale);

Confirma que:

1. La IP coincide con la dirección esperada de tu proxy
2. La zona horaria se alinea con la región geográfica del proxy
3. El idioma y locale son consistentes con la zona horaria
4. No hay fugas DNS visibles; compruébalo con la prueba DNS aprobada por el proveedor.

Elige el siguiente diagnóstico según la observación que falló. Un resultado visible en el navegador acota la pregunta, pero cada capa de red necesita su propia comprobación.

Observación	Qué demuestra	Siguiente comprobación
La IP de salida difiere del registro de ruta	El endpoint observado y la ruta esperada no coinciden	Compara el proxy configurado, la familia de direcciones y la sesión del proveedor
La IP coincide, pero la zona horaria o locale difiere	Los valores visibles del navegador no coinciden con el perfil esperado	Inspecciona las anulaciones --bot-timezone y --bot-locale
La página carga, pero no se conoce quién resuelve DNS	La solicitud devolvió contenido; la ruta del resolvedor sigue sin verificarse	Ejecuta la prueba DNS aprobada por el proveedor y registra el resolvedor
CONNECT funciona, pero TLS falla	El túnel proxy respondió; TLS del destino sigue fallando	Comprueba por separado el certificado y la política TLS del destino

Lectura del límite de red

El proxy cambia la ruta solicitada por el navegador, pero no demuestra la política del proveedor ni del destino. Separa la IP observada, el resolvedor DNS y el resultado de la aplicación en tus verificaciones. Para un tema relacionado con los límites de red, consulta Protección contra el sondeo de puertos del navegador en localhost.

La elección de DNS también tiene un límite claro: con socks5://, el resolvedor local puede traducir el nombre antes de entrar al proxy; con socks5h://, el nombre se envía al proxy para su resolución. --bot-local-dns selecciona el manejo DNS local de BotBrowser; no convierte socks5:// en socks5h:// ni controla el resolvedor ascendente del proveedor.

WebRTC puede recopilar candidatos ICE mediante servicios de red adicionales. Una comprobación de página muestra lo que esa página ve, pero no certifica todos los hosts, VPN o equipos del proveedor. CORS pertenece a otra capa: el navegador puede bloquear la exposición de una respuesta aunque el proxy haya llegado al servidor. Registra origen, destino, método y resultado antes de cambiar una ruta.

En HTTPS, separa el túnel navegador-proxy de la conexión proxy-destino. Una respuesta CONNECT demuestra alcance y autenticación para esa solicitud, no la validez del certificado del destino ni su política TLS. Las credenciales incrustadas en la URL son una comodidad de configuración: redacta contraseñas de los registros y rótalas con el proveedor.

La verificación solo describe lo observado en una prueba. Una IP de salida no prueba autorización de cuenta, una zona horaria no prueba presencia física y una carga correcta no prueba que todas las solicitudes usaran la misma ruta. Conserva navegador, protocolo, IP, resolvedor, zona horaria, locale, hora y resultado visible, sujetos a la política del proveedor y a la prueba realizada.

Mejores prácticas

1. Elige explícitamente la ruta DNS. socks5h:// solicita la resolución del nombre en el proxy; --bot-local-dns selecciona el manejo DNS local de BotBrowser, pero no controla el resolvedor ascendente del proveedor.

2. Verifica la geografía derivada. Compara zona horaria y locale visibles en la página con el registro del proveedor antes de depender de esos valores.

3. Codifica en URL los caracteres especiales en contraseñas. Caracteres como @, # y % deben codificarse. Por ejemplo, p@ss se convierte en p%40ss.

4. Declara quién resuelve DNS. --bot-local-dns selecciona el manejo local de BotBrowser; ningún flag controla el resolvedor ascendente del proveedor.

5. Prueba con curl primero. Antes de configurar BotBrowser, verifica la conectividad del proxy: curl --proxy socks5://user:pass@host:port https://httpbin.org/ip.

6. Usa --proxy-ip cuando la IP sea conocida. Esto elimina la sobrecarga de búsqueda por página y acelera la navegación.

Preguntas frecuentes

¿Qué protocolo de proxy debería usar?

SOCKS5H es recomendado para la mayoría de los casos de uso. Soporta tráfico TCP, maneja la resolución DNS a través del proxy y funciona con la más amplia variedad de proveedores de proxy.

¿Puedo usar un proxy que requiera lista blanca de IP?

Sí. Verifica con el proveedor que la IP de tu máquina esté en la lista blanca y usa la URL sin credenciales solo si autentica por IP.

¿BotBrowser soporta encadenamiento de proxies?

BotBrowser se conecta al proxy especificado en --proxy-server. Si necesitas encadenamiento de proxies, configúralo en el lado de la infraestructura del proxy.

¿Por qué mi zona horaria no coincide con la ubicación de mi proxy? Si estableciste --bot-timezone manualmente, anula la detección automática. Elimina la anulación manual para dejar que BotBrowser derive la zona horaria desde la IP del proxy.

¿Puedo usar diferentes proxies para diferentes pestañas? Sí. Usa browser.newContext({ proxy: ... }) de Playwright para asignar diferentes proxies por contexto. Consulta la guía de cambio dinámico de proxy para más detalles.

¿Qué pasa si la conexión del proxy falla? BotBrowser no recurrirá a una conexión directa. Si el proxy es inalcanzable, las cargas de páginas fallarán, lo cual es el comportamiento más seguro para la privacidad.

¿Cómo manejo la rotación de proxy? Crea un nuevo contexto del navegador para cada rotación de proxy. Cerrar el contexto antiguo y abrir uno nuevo con un servidor proxy diferente es el enfoque más limpio; registra el cambio de ruta.

Lo que BotBrowser proporciona

BotBrowser integra las credenciales del servidor proxy directamente en el flag --proxy-server y configura automáticamente la zona horaria, locale e idioma desde la dirección IP pública del servidor proxy, eliminando la necesidad de APIs de autenticación separadas y configuración geográfica manual. Sin embargo, BotBrowser no puede controlar cómo el proveedor del servidor proxy enruta el tráfico, verificar la precisión de la base de datos IP-a-ubicación del proveedor, autenticar credenciales en la infraestructura del proveedor, o gestionar el comportamiento de DNS y WebRTC fuera del túnel navegador-servidor proxy. La detección automática de geografía depende completamente de la precisión de la base de datos IP del proveedor; si la detección falla o no coincide con tu identidad prevista, se requieren anulaciones geográficas manuales usando los flags --bot-timezone, --bot-locale y --bot-languages.

Fuentes públicas

• W3C: WebRTC
• MDN: servidores proxy y túneles
• MDN: encabezado Proxy-Authorization

Conclusión práctica

La configuración de proxy es una parte de la coherencia de identidad del navegador. BotBrowser simplifica las credenciales, ofrece señales de alineación geográfica y admite SOCKS5, SOCKS5H, HTTP, HTTPS y QUIC cuando el navegador/cliente, el contexto autorizado y el proveedor de proxy lo admiten. La compatibilidad con QUIC no garantiza que HTTP/3 tenga éxito, no ofrece una recuperación mediante conexión directa ni controla la ruta ascendente del proveedor. Junto con un perfil documentado y verificaciones del proveedor, ayuda a mantener alineados IP, zona horaria, locale e idioma; el resultado depende del proveedor y de las pruebas realizadas.

Para flujos de trabajo multi-proxy, consulta Cambio dinámico de proxy. Aplica por separado las políticas documentadas para DNS y WebRTC.