HTTPX 0.28.1 usa proxy=, no el argumento eliminado proxies=. Usa mounts= cuando los destinos HTTP y HTTPS necesitan diferentes transportes.
Un Client o AsyncClient persistente es generalmente mejor que llamadas repetidas de nivel superior. Los clientes reutilizan conexiones, centralizan los tiempos de espera y tienen un límite explícito de limpieza.
Las URL de proxy autenticadas deben codificar el nombre de usuario y la contraseña. Los caracteres reservados como espacios, @ y : cambian el análisis de la URL.
HTTPX lee HTTP_PROXY, HTTPS_PROXY, ALL_PROXY y NO_PROXY por defecto. Establece trust_env=False cuando la configuración de la aplicación debe ignorar los ajustes de proxy a nivel de máquina.
La rotación de proxies necesita un grupo de clientes limitado y verificaciones de aceptación. La selección aleatoria por sí sola no detecta una ruta muerta, una página de error con estado 200 o datos inesperados.
¿Qué es un proxy HTTPX?
Un proxy HTTPX es un intermediario configurado en el cliente Python HTTPX para que las solicitudes lleguen a un destino a través de otro punto final de red. La documentación oficial del proxy HTTPX admite un solo proxy a través de y enrutamiento avanzado a través de un diccionario de transportes montados.
HTTPX es un cliente HTTP de propósito general en Python con APIs sincrónicas y asincrónicas. La configuración de proxies cambia la ruta de red; HTTPX sigue gestionando el agrupamiento de conexiones, los tiempos de espera, las redirecciones, la validación de TLS, la transmisión de respuestas y el manejo de estados. Una ruta gestionada como Nstdata Residential Prime Proxies se puede adjuntar a través de la configuración estándar de HTTPX sin cambiar la lógica de análisis o de negocio que consume la respuesta.
Usa un proxy HTTPX para monitorear precios autorizados, chequeos de localización, pruebas de páginas públicas, salida corporativa controlada o aislando trabajos independientes. Un proxy no autoriza el acceso a un destino, corrige un selector inválido o prueba que la respuesta contenga el contenido previsto.
Cambios en la API del Proxy HTTPX que Debes Conocer
HTTPX 0.28 eliminó el argumento obsoleto proxies=, por lo que el código actual debe usar proxy= o mounts=. La historia de lanzamientos oficial de HTTPX identifica 0.28.1 como la última versión en el momento de las pruebas y registra la eliminación en la línea 0.28.
Usa estas equivalencias al actualizar ejemplos más antiguos:
Patrón antiguo
Patrón HTTPX 0.28.1
Caso de uso
httpx.Client(proxies=proxy_url)
httpx.Client(proxy=proxy_url)
Un punto final para todas las solicitudes
httpx.get(url, proxies=...)
httpx.get(url, proxy=...)
Una solicitud aislada
Diccionario de proxy pasado como proxies=
mounts={"http://": HTTPTransport(...), ...}
Diferente enrutamiento por esquema de destino
El esquema en una clave de montaje describe la URL de destino. El esquema dentro de la URL del proxy describe la conexión al proxy. Para muchos gateways HTTP, ambos montajes de destino http:// y https:// usan correctamente un punto final http://proxy-host:port porque los objetivos HTTPS se tunelan con CONNECT.
Requisitos Previos
Los ejemplos se ejecutaron con Python 3.12.13 y HTTPX 0.28.1. Instala la versión fijada en un entorno virtual:
python -m pip installhttpx==0.28.1
Prepara un objetivo autorizado y mantén los secretos del proxy en una configuración de tiempo de ejecución protegida. Los ejemplos utilizan PROXY_URL, TARGET_URL, PROXY_USERNAME, PROXY_PASSWORD y PROXY_URLS. No cometas una URL completa con credenciales o incluyas esto en los registros de la aplicación.
Cada ejemplo establece un tiempo de espera explícito. HTTPX distingue entre tiempos de espera de conexión, lectura, escritura y agrupamiento; ajústalos según la latencia observada en lugar de eliminar el límite. Mantén la verificación de TLS habilitada e instala un certificado CA aprobado cuando un proxy de inspección legítimo lo requiera.
Rote solicitudes HTTPX a través de Nstdata
```
Crea un endpoint autenticado, adjúntalo a un cliente HTTPX y verifica la ruta devuelta.
Puedes usar HTTPX con proxies a través de cinco patrones actuales: un endpoint a nivel de cliente, autenticación codificada, un grupo de clientes asíncronos, variables de entorno o transportes montados. Todos los bloques de Python a continuación se ejecutaron contra endpoints locales construidos para tal propósito. Las respuestas devolvieron marcadores de ruta no secretos, lo que verificó que el tráfico cruzó el proxy previsto en lugar de confirmar meramente que HTTPX devolvió una respuesta.
Método 1: Usar Un Proxy con un Cliente Sincrónico
Usa un Cliente sincrónico cuando las solicitudes secuenciales compartan un endpoint. trust_env=False hace que la ruta explícita sea autoritativa, mientras que el administrador de contexto cierra las conexiones agrupadas después del trabajo.
La prueba imprimió ruta: basic-18480 y preservó la URL absoluta de destino recibida por el proxy. Reemplaza el valor de ruta fija con un marcador que tu endpoint de diagnóstico o sesión de proveedor pueda verificar.
La llamada de nivel superior httpx.get(..., proxy=...) es válida para una llamada única, pero las llamadas repetidas de nivel superior no pueden reutilizar un grupo de clientes. Prefiere un cliente para trabajos de múltiples páginas. La guía del proyecto de raspado web en Python de Nstdata explica dónde encaja la validación de respuesta en un pipeline de extracción más amplio.
Método 2: Configurar un Proxy HTTPX Autenticado
Usa un proxy autenticado codificando cada componente de credencial antes de construir la URL. La codificación previene que los caracteres reservados sean interpretados como delimitadores.
La verificación en vivo utilizó un nombre de usuario que contenía un espacio y una contraseña que contenía @ y :. El proxy rechazó las credenciales faltantes con 407, luego devolvió authenticated: True y la ruta auth-18481 después de que HTTPX proporcionara los valores codificados.
No imprima proxy_url: contiene credenciales recuperables. En su lugar, registre un ID de ruta, estado, latencia y clase de falla. Un 407 repetido es un fallo de configuración, no una razón para un bucle de reintentos ilimitado.
Método 3: Rotar Instancias Reusables de AsyncClient
Utilice un grupo de AsyncClient limitado cuando las solicitudes independientes puedan ejecutarse a través de múltiples puntos finales. Un cliente por punto final preserva la reutilización de conexiones y hace explícita la relación ruta-cliente.
import asyncio
import itertools
import os
import httpx
asyncdeffetch(client: httpx.AsyncClient, target_url:str)->dict: response =await client.get(target_url) response.raise_for_status() data = response.json()if"route"notin data:raise ValueError("La respuesta no contenía un marcador de ruta")return data
asyncdefmain()->None: proxy_urls =[value.strip()for value in os.environ["PROXY_URLS"].split(",")if value.strip()]iflen(proxy_urls)<2:raise ValueError("PROXY_URLS debe contener al menos dos puntos finales") clients =[ httpx.AsyncClient(proxy=proxy_url, timeout=10.0, trust_env=False)for proxy_url in proxy_urls
]try: client_cycle = itertools.cycle(clients) tasks =[fetch(next(client_cycle), os.environ["TARGET_URL"])for _ inrange(4)] results =await asyncio.gather(*tasks)print([result["route"]for result in results])finally:await asyncio.gather(*(client.aclose()for client in clients))asyncio.run(main())
La salida alternó basic-18480, rotate-18482, basic-18480, y rotate-18482. La selección en ronda es observable y evita elecciones repetidas accidentales, pero no es una política de salud. Agregue un límite de concurrencia, un contador de fallas, un tiempo de espera y un presupuesto máximo de reintentos antes de usar un grupo más grande. La guía de rotación de proxy en Python cubre la selección de puntos finales a un nivel de aplicación más amplio.
No reproduzca automáticamente una solicitud que cambia el estado a través de otra ruta a menos que la operación sea idempotente o lleve una clave de idempotencia de aplicación. Para la navegación con estado, mantenga el mismo cliente, cookies y ruta pegajosa juntos.
Método 4: Utilizar Variables de Entorno de Proxy
HTTPX lee las variables de entorno de proxy por defecto, lo cual es útil para el enrutamiento gestionado por la plataforma. La documentación oficial de variables de entorno de HTTPX define HTTP_PROXY, HTTPS_PROXY, ALL_PROXY y NO_PROXY.
El programa ejecutado devolvió basic-18480 sin un argumento de proxy en Python. Verifique NO_PROXY cuando un destino va directamente de manera inesperada. Si el programa debe ignorar la configuración del host, construya un cliente con trust_env=False; esa opción también ignora otra configuración derivada del entorno, como las rutas de certificados.
Método 5: Enrutamiento con Montajes de HTTPTransport
Utilice mounts= cuando el enrutamiento dependa del esquema de destino o de un subconjunto de URLs. Este es el reemplazo actual para los antiguos diccionarios de proxy.
El montaje HTTP produjo basic-18480 en la ejecución local. Mantenga las claves del montaje específicas y pruebe cada esquema que use la aplicación. HTTPX también ofrece soporte opcional SOCKS a través de la extensión httpx[socks]; instale esa extensión y use la URL SOCKS documentada solo cuando el punto final realmente hable SOCKS.
Cómo Verificar un Proxy de HTTPX
Verifique un proxy de HTTPX en tres capas: ruta de red, semántica de respuesta y salida extraída. Comience con un IP de reflexión autorizada o un punto final de diagnóstico y confirme el marcador de salida o sesión observado. Luego exija un estado aceptable, tipo de contenido y campo de página reconocible. Finalmente valide los registros que su aplicación pretende conservar.
raise_for_status() rechaza respuestas 4xx y 5xx, pero un HTTP 200 aún puede contener una página de error de proxy, pantalla de consentimiento, página de inicio de sesión o un locale alternativo. Prueba campos semánticos estables y rechaza un resultado vacío o implausible. La jerarquía oficial de excepciones de HTTPX ayuda a separar timeouts, fallos de transporte, errores de proxy y fallos de estado para reglas de reintento limitadas.
Los reintentos deben dirigirse a errores transitorios de conexión, timeout y puerta de enlace. No reintentes 401, 403, 407 o contenido inválido indefinidamente. La guía de errores del servidor proxy de Nstdata proporciona una taxonomía práctica para la solución de problemas a nivel de ruta.
Elegir una Ruta de Nstdata para HTTPX
Los Proxies Residenciales Prime de Nstdata proporcionan puntos finales autenticados estándar para cargas de trabajo de HTTPX que necesitan enrutamiento residencial, ubicaciones seleccionables y sesiones rotativas o fijas en la superficie actual del producto. El ajuste es más fuerte cuando tu código Python ya maneja solicitudes HTTP y validación mientras que la ruta de red debe seguir siendo configurable fuera de la lógica de la aplicación. Los modelos de facturación por paquete y por uso permiten que los equipos elijan un modelo operativo después de medir el tráfico aceptado en lugar de reescribir la integración de HTTPX. Usa el producto para verificaciones de localización autorizadas, monitoreo de precios, verificación de anuncios y flujos de datos públicos; prueba el comportamiento exacto del objetivo y la sesión antes de aumentar el volumen.
Integración del cliente estándar: Adjunta el punto final generado a través de proxy= o un HTTPTransport montado; no se requiere SDK específico de proveedor para el enrutamiento básico.
Enrutamiento consciente de sesiones: Elige un comportamiento rotativo para solicitudes independientes o una sesión fija para flujos dependientes de cookies.
El enrutamiento por proxy no realiza análisis, deduplicación o validación de esquemas. Mantén esas reglas de aceptación en la aplicación y supervisa el costo por registro aceptado en lugar del conteo de solicitudes solo.
Errores Comunes de Proxy en HTTPX y Soluciones
Síntoma
Causa probable
Solución práctica
TypeError menciona proxies
El código apunta a una API de HTTPX más antigua
Reemplaza un punto final con proxy=; usa mounts= para enrutamiento avanzado.
407 Proxy Authentication Required
Credenciales faltantes o mal formadas
Codifica el nombre de usuario/contraseña por separado y verifica el host y el puerto sin registrar la URL.
ProxyError o ConnectTimeout
El punto final no es accesible o utiliza el protocolo incorrecto
Confirma esquema, DNS, puerto y disponibilidad de la red; reintenta solo fallos transitorios.
Aparece IP directa
NO_PROXY coincidió o no se utilizó el cliente explícito
Inspecciona las variables de entorno y establece trust_env=False cuando la configuración explícita debe prevalecer.
HTTPS falla a través de un proxy HTTP
CONNECT o la confianza en CA están mal configurados
Confirma que la puerta de enlace admite tunelización e instala la CA aprobada; no deshabilites las verificaciones TLS.
Sockets asíncronos se acumulan
Los clientes se crean sin limpieza
Reutiliza clientes limitados y siempre llama a aclose() o usa async with.
Estado 200 pero datos incorrectos
La respuesta es una página alternativa o de error suave
Valida el tipo de contenido, un marcador estable y el esquema final extraído.
Conclusión
Una configuración de proxy HTTPX en producción utiliza la moderna API proxy= o mounts=, credenciales protegidas, timeouts explícitos, clientes reutilizables y pruebas de aceptación de respuestas. Usa un cliente sincrónico para una ruta estable, codifica puntos finales autenticados cuidadosamente y rota un conjunto limitado de instancias de AsyncClient solo cuando el trabajo independiente requiera múltiples rutas.
Comienza con un objetivo autorizado y verifica su ruta y respuesta semántica. Agrega rotación después de que los fallos sean clasificados y la limpieza esté comprobada; considera el Administrador de Proxy de Nstdata más adelante si la salud del punto final, los grupos y las reglas de enrutamiento superan la selección a nivel de aplicación.
Experimenta Nstdata — Comienza tu Prueba Gratuita Hoy
No. HTTPX 0.28 eliminó proxies=; usa proxy= para un punto final y mounts= con transportes de proxy para enrutamiento más complejo.
Q: ¿Puede HTTPX usar un proxy con AsyncClient?
Sí. Pasa proxy= a httpx.AsyncClient, reutiliza el cliente para su punto final asignado y ciérralo con async with o aclose().
Q: ¿Por qué una URL de proxy HTTP todavía comienza con http:// para un objetivo HTTPS?
El esquema de URL del proxy describe la conexión al proxy, mientras que el destino utiliza HTTPS a través de un túnel CONNECT. Por lo tanto, un gateway HTTP puede servir destinos HTTPS sin una URL de proxy https://.
P: ¿Cómo deshabilito la configuración del proxy de entorno en HTTPX?
Crea un Client o AsyncClient con trust_env=False. HTTPX ignorará la configuración de proxy y relacionada heredada del entorno del proceso.
P: ¿Debo crear un nuevo AsyncClient para cada solicitud?
No. Reutiliza un conjunto limitado de clientes para que HTTPX pueda agrupar las conexiones y asociar cada cliente con un punto final o una política de sesión.
P: ¿Puede HTTPX usar proxies SOCKS5?
Sí. Instala la dependencia opcional oficial con httpx[socks] y configura una URL SOCKS soportada socks5:// para un punto final que realmente implemente ese protocolo.
Marcus Chen
Aug. 20th 2026
110M+ IP reales con 99.9% de acceso exitoso
Respuesta media ultrarrapida ~0.5s para tareas de alta concurrencia
Desde solo $0.1/GB
Acceso inmediato a pools premium de proxies residenciales, datacenter, IPv6 e ISP.
