Proxy con Axios en Node.js: errores y reintentos

Llevo un tiempo automatizando scraping y monitorización SEO con Node.js, y si hay algo que aprendí por las malas es esto: trabajar con un proxy con Axios bien configurado marca la diferencia entre un script que funciona y uno que te despierta a las tres de la mañana con errores. Timeouts, ECONNREFUSED, respuestas 407… la experiencia puede amargarte la semana si no montas bien los reintentos. Aquí va lo esencial: cómo configurar proxies HTTP/s y SOCKSv5 en Axios, qué errores vas a encontrarte (porque te los vas a encontrar) y cómo montar un sistema de reintentos que aguante.

¿Por qué usar un proxy con Axios en tus proyectos Node.js?

Pensemos un momento. Cuando tus scripts hacen peticiones HTTP a gran escala, la IP de tu servidor se acaba convirtiendo en un cuello de botella: los sitios aplican rate limiting, los buscadores bloquean peticiones repetitivas y los proveedores de datos huelen el patrón automatizado a kilómetros. Un proxy dedicado resuelve esto enrutando cada petición por una IP distinta y estable. Y si trabajas con el mercado español, tiene aún más sentido: necesitas IPs españolas reales para verificar SERPs locales, precios geolocalizados o anuncios regionales.

¿Dónde se usa esto en la práctica? Los casos más habituales:

• Scraping SEO: auditar posiciones en Google.es sin disparar captchas cada dos peticiones.
• Monitorización de competidores: consultar catálogos y precios de forma periódica sin levantar sospechas.
• Agentes de IA con soporte MCP: los agentes que ejecutan herramientas de búsqueda necesitan IPs limpias; si no, sus respuestas salen sesgadas por contenido bloqueado o mal regionalizado.
• Testing geográfico: comprobar cómo se renderiza tu web desde España frente a otros mercados.

Con proxies dedicados, como los que ofrece ProxySEO (HTTP/s y SOCKSv5, tráfico ilimitado y anónimos), nadie más comparte tu IP. Y eso reduce bastante los baneos colaterales, esos que llegan porque otro hizo algo estúpido desde la misma IP.

Configuración básica: HTTP/s y SOCKSv5 en Axios

Para proxies HTTP/s, Axios lo trae de fábrica. Basta con el objeto proxy en la configuración de la petición:

Con SOCKSv5 la cosa cambia. Axios no lo soporta de forma nativa, así que necesitarás los paquetes socks-proxy-agent y https-proxy-agent:

Un consejo que me costó un susto aprender: si tu proxy tiene autenticación y usas HTTPS, no pases credenciales por la URL en producción. Variables de entorno y agentes dedicados. Así no acaban filtradas en los logs (y créeme, acaban filtradas en los logs).

Errores comunes al usar proxy con Axios y cómo identificarlos

Los fallos con proxies siguen patrones bastante reconocibles. Saber leerlos te ahorra horas de depuración a ciegas:

• ECONNREFUSED: el host o puerto del proxy están mal, o el proxy directamente está caído. Prueba conectividad con curl -x antes de culpar a tu código.
• ETIMEDOUT: la IP de destino bloquea el proxy, o el proxy va demasiado lento. Sube el timeout en Axios y valora rotar de IP.
• 407 Proxy Authentication Required: credenciales mal formadas. Ojo con SOCKSv5: el formato usuario:contraseña en la URL no es lo mismo que la autenticación por cabecera de los proxies HTTP. Esta distinción confunde a más de uno.
• HTTP 403 o 429 constantes: la IP del proxy está quemada o el sitio detecta tu fingerprint. Con proxies dedicados de calidad es raro; si te pasa, revisa headers como el User-Agent.
• SELF_SIGNED_CERT_IN_CHAIN: algunos proxies HTTPS hacen MITM con certificados propios. Nunca desactives la verificación TLS, salvo en entornos de prueba controlados. Nunca.

Y un truco de diagnóstico que uso siempre: al inicializar tu pool de proxies, lanza una petición de prueba a un servicio tipo ipify. Si la IP que te devuelve no coincide con la esperada, descarta ese nodo antes de lanzar el trabajo real. Cinco segundos que evitan horas de resultados basura.

Implementación de reintentos con backoff exponencial

Digámoslo claro: aunque el pool de proxies esté bien montado, los errores 429, los 502 y los timeouts van a aparecer. Es cuestión de tiempo. El truco no está en reintentar como un poseso, sino en backoff exponencial, es decir, esperar cada vez más entre intento e intento. Así no machacas el servidor de destino ni quemas la IP.

Axios, por sí solo, no reintenta peticiones salvo que uses su opción httpAgent junto a librerías complementarias. Lo más limpio que he encontrado es montar un wrapper con axios-retry:

Un ejemplo práctico:

1. Instala la dependencia: npm install axios-retry.
2. Configura el reintento con axiosRetry(axios, { retries: 5, retryDelay: axiosRetry.exponentialDelay, retryCondition: (error) => error.response?.status === 429 || error.response?.status >= 502 }).
3. Añade un factor aleatorio (jitter) para que varios workers no reintenten todos a la vez: retryDelay: (retryCount) => Math.random() * 1000 * Math.pow(2, retryCount).

Un detalle que se suele pasar por alto: al reintentar, ¿reutilizas el mismo proxy o rotas? Para errores de red, rota. Para un 429, rota siempre. La IP actual ya está limitada y poco vas a conseguir con ella.

Rotación de IPs y mejores prácticas para scraping y SEO

En proyectos de SEO y scraping a gran escala, la rotación de IPs pesa casi tanto como el manejo de errores. Un pool bien gestionado con proxies dedicados españoles, como los de ProxySEO, permite repartir la carga sin llamar la atención.

Patrones de rotación recomendados

• Rotación por petición: cada request sale por una IP distinta. Perfecto para SERPs y monitorización de rankings.
• Rotación por sesión (sticky): mantienes la misma IP durante toda una sesión. Imprescindible si el sitio usa cookies o flujos de login.
• Rotación ponderada: los proxies con buen historial reciente reciben más tráfico; los que fallan, menos.

Para una rotación simple basta con mantener un array de agentes HTTP y elegir uno al azar en cada petición: const agent = new HttpsProxyAgent(proxies[Math.floor(Math.random() * proxies.length)]). Eso sí, en producción te conviene envolver esa lógica en una clase Pool con health-checks periódicos.

Buenas prácticas adicionales

• Respeta el robots.txt y no te confíes: aplica throttling. Peticiones demasiado rápidas generan bans aunque estés rotando IPs.
• Rota también los User-Agent y las cabeceras, y hazlo en coherencia con la IP asignada.
• Registra qué proxy produjo cada error. Los patrones por subred se detectan así, no de otra manera.
• Si trabajas con agentes de IA o automatizaciones sobre modelos de lenguaje, ten en cuenta que ProxySEO ofrece soporte MCP, con lo que puedes integrar el pool de proxies en tus flujos de agentes sin desarrollo extra.

Conclusión: proxies robustos y fiables con ProxySEO

Dominar el uso de un proxy con Axios no es cuestión de añadir una URL al objeto de configuración y santas pascuas. Hay que gestionar autenticación, timeouts, verificación TLS, reintentos con backoff exponencial y una estrategia de rotación que encaje con cada caso. Como hemos ido viendo, la diferencia entre un scraper que se cae a la primera oleada de 429 y otro que funciona 24/7 sin supervisión está en estos detalles de implementación.

Elegir bien la infraestructura simplifica mucho ese trabajo. Los proxies HTTP/s y SOCKSv5 dedicados y anónimos de ProxySEO, con IPs españolas y tráfico ilimitado, te dan nodos estables que no compartes con nadie. Los errores de origen se reducen, y mucho. A ello se suma un soporte técnico que habla tu idioma y la integración vía MCP para agentes IA, muy útil si tus flujos de datos dependen de automatización inteligente.

En definitiva: construye tu capa de reintentos, monitoriza cada proxy del pool y apóyate en proxies dedicados de calidad. Con una base sólida como la que ofrece ProxySEO, tus proyectos de scraping, SEO y automatización dejarán de ser frágiles para convertirse en sistemas fiables y escalables.