El servidor proxy no responde: diagnóstico paso a paso de tiempos de espera, puertos y firewall

Introducción: qué obtendrás de esta guía

La situación le resulta familiar a cualquiera que trabaje con proxies: ayer todo volaba y hoy el navegador gira sin parar, el script de scraping se cuelga en la primera solicitud y el navegador antidetect dice que el servidor proxy no responde. Sin mensajes claros, solo espera y silencio. Dan ganas de escribir de inmediato al soporte o cambiar de proveedor, pero en la mayoría de los casos la causa está de tu lado y se soluciona en diez minutos.

Esta guía práctica te ayudará a recorrer el camino desde "nada funciona" hasta "la conexión es estable" sin adivinar. Analizaremos los tres culpables de red más comunes: los tiempos de espera, los puertos cerrados o incorrectos y el firewall. Aprenderás a determinar dónde se rompe exactamente la cadena entre tu computadora y el proxy, y obtendrás un conjunto de comandos que en un minuto muestran el origen del problema.

Límite importante: aquí hablamos solo de causas de red, cuando la conexión no se establece en absoluto o se cuelga. Las situaciones en las que el proxy responde pero devuelve un código de error como 407 o 502 son un tema aparte, y no lo abordamos aquí. Si ves un código HTTP concreto en la respuesta, significa que el proxy está vivo y tu caso no corresponde a este artículo.

Para quién es esta guía

• Especialistas en marketing y redes sociales que gestionan varias cuentas a través de proxies móviles y se encontraron con que el navegador no conecta.
• Especialistas en arbitraje cuyas configuraciones dejaron de funcionar de repente y los paneles publicitarios no abren a través del proxy.
• Desarrolladores cuyos scripts en Python, Node.js o Go reciben un tiempo de espera agotado en lugar de una respuesta.
• Dueños de negocios que configuraron proxies para sus empleados y quieren entender por qué a uno le funciona todo y a otro no.

Qué necesitas saber de antemano

Prácticamente nada especial. Basta con saber abrir la línea de comandos o la terminal, copiar comandos y leer lo que muestran. Explicaremos todos los términos sobre la marcha. Si nunca abriste la terminal, no te preocupes: cada acción está descrita hasta el nivel de "presiona esta tecla, escribe este texto".

Cuánto tiempo tomará

El diagnóstico completo con todos los pasos toma de 30 a 60 minutos. La mayoría de las veces el problema se detecta en el primer o segundo paso, y entonces te tomará 10-15 minutos. El bloque avanzado del final puedes estudiarlo por separado cuando la conexión básica ya esté restaurada.

Preparación previa: herramientas y datos

Antes de empezar, reúne todo lo necesario en un solo lugar. Esto ahorrará tiempo y evitarás saltar entre pestañas en el momento menos oportuno.

Datos de tu proxy

Abre el panel de tu proveedor y anota en un archivo de texto los siguientes parámetros. Los necesitarás casi en cada paso.

1. Dirección del servidor (host). Es un nombre de dominio como proxy.example.net o una dirección IP como 185.10.20.30.
2. Puerto para conexión HTTP. En los proxies móviles suele ser un número de cinco cifras, por ejemplo 30001 o 51234.
3. Puerto para SOCKS5, si el proveedor lo entrega por separado. A veces difiere del puerto HTTP en una unidad o en varios miles.
4. Usuario y contraseña para la autorización, si usas autenticación por credenciales.
5. Lista de IP permitidas, si tienes activada la autorización por dirección IP. Verifica qué dirección está registrada allí.
6. Enlace para cambiar la IP e información sobre el modo de rotación: por horario, por enlace o en cada solicitud.

Consejo: guarda estos datos no solo en el gestor de contraseñas, sino también en un archivo de texto normal durante el diagnóstico. Los pegarás en comandos decenas de veces, y el cambio constante entre ventanas resulta agotador.

Herramientas que ya tienes en tu sistema

Buenas noticias: casi todo lo necesario está integrado en el sistema operativo. No tendrás que comprar nada.

• Windows 10 y 11: PowerShell (búscalo en el menú Inicio) y la línea de comandos cmd. En PowerShell existe el comando Test-NetConnection, que reemplazará utilidades separadas.
• macOS: la aplicación Terminal (Programas, carpeta Utilidades). Las utilidades nc y curl ya están instaladas.
• Linux (Ubuntu, Debian, Fedora): cualquier terminal. Puede que necesites instalar los paquetes curl, netcat y mtr mediante el gestor de paquetes de tu sistema.

Qué conviene instalar adicionalmente

1. curl para Windows. En Windows 10 versión 1803 y posteriores, y también en Windows 11, curl ya está incluido. Verifica: abre cmd y escribe curl --version. Si ves un número de versión, todo está bien.
2. Un segundo dispositivo para comparar: un smartphone, una segunda laptop o una máquina virtual. No es un programa, pero es una herramienta muy útil de la que hablaremos en el primer paso.
3. Acceso a la configuración del router: la dirección del panel (casi siempre 192.168.0.1 o 192.168.1.1) y la contraseña del administrador. Se necesitará en el quinto paso.

Copias de seguridad antes de empezar

Vamos a modificar la configuración del firewall y, posiblemente, del router. Antes de eso, haz dos cosas para poder volver siempre al estado original.

1. En Windows crea un punto de restauración: abre la búsqueda, escribe "Crear un punto de restauración", haz clic en el botón Crear y dale un nombre claro, por ejemplo "Antes de configurar el proxy".
2. Exporta las reglas actuales del firewall de Windows. Abre PowerShell como administrador y ejecuta el comando netsh advfirewall export "C:/firewall-backup.wfw". El archivo aparecerá en la raíz del disco C.
3. En el panel del router busca una sección como "Sistema", "Mantenimiento" o "Copia de seguridad" y guarda el archivo de configuración en tu computadora.

Atención: no desactives el firewall por completo "por si acaso" ni lo dejes desactivado. Durante el diagnóstico apagaremos la protección como máximo dos minutos para probar una hipótesis, y luego lo devolveremos todo y crearemos una regla puntual.

Conceptos básicos: qué ocurre cuando el proxy no responde

Para que el diagnóstico tenga sentido y no sea una revisión caótica, es importante entender cómo está estructurada la cadena de conexión. Entonces cada paso de la guía verificará un tramo específico de esa cadena.

El recorrido de la solicitud desde ti hasta el sitio

Cuando trabajas a través de un proxy móvil, la solicitud recorre el siguiente camino. Primero tu aplicación (navegador, script, antidetect) envía los datos al sistema operativo. El sistema los pasa por su firewall y los transmite al router. El router entrega el tráfico a tu proveedor de internet. El proveedor entrega los paquetes al servidor proxy. El servidor proxy redirige la solicitud a través de un módem móvil con tarjeta SIM a la red del operador celular. Y solo entonces la solicitud sale hacia el sitio objetivo. La respuesta recorre el mismo camino en orden inverso.

La interrupción puede ocurrir en cualquiera de estos tramos. La frase "el servidor proxy no responde" en realidad significa solo una cosa: la respuesta no llegó a tu aplicación en el tiempo asignado. Dónde exactamente se perdió es lo que hay que averiguar.

Puerto: la puerta al servidor

Cualquier servidor tiene una sola dirección IP, pero múltiples puertos, numerados del 1 al 65535. Imagina un edificio de varios pisos con una sola dirección y miles de departamentos. El servicio proxy "vive" en un departamento concreto, es decir, escucha en un puerto concreto. Si tocas en otro puerto, nadie abrirá y esperarás hasta que se agote el tiempo de espera. Además, el servidor está absolutamente intacto.

Los puertos pueden estar abiertos, cerrados y filtrados. Un puerto abierto responde a la tentativa de conexión con aceptación. Un puerto cerrado responde de inmediato con rechazo, y recibes un error instantáneo como "connection refused". Un puerto filtrado guarda silencio: tus paquetes son descartados en el camino y no recibes nada. Precisamente el filtrado produce el cuadro clásico de colgado sin respuesta, y casi siempre el culpable es algún firewall.

Tiempo de espera: cuánto aguardar antes de rendirse

El tiempo de espera es el límite tras el cual la aplicación detiene el intento y reporta un error. Existen varios tiempos de espera, y no conviene confundirlos.

• Tiempo de espera de conexión (connect timeout). Cuánto aguardar a que el servidor acepte establecer la conexión. Si se agota, significa que no lograste llegar al puerto del proxy en absoluto.
• Tiempo de espera de lectura (read timeout). Cuánto aguardar datos después de que la conexión se estableció. Si se agota, significa que el proxy te aceptó, pero el sitio objetivo o la red móvil respondían demasiado lento.
• Tiempo de espera general de la solicitud. El límite superior para todo en conjunto.

Los proxies móviles funcionan a través de la red celular, donde las demoras son naturalmente mayores que en los datacenters. Si tu software está configurado con un tiempo de espera de 5 segundos, puede fallar en un proxy móvil perfectamente funcional solo porque la respuesta llegó en el sexto segundo.

Firewall: el filtro que decide qué dejar pasar

El firewall (cortafuegos) es un programa o dispositivo que examina los paquetes de red y decide si dejarlos pasar o descartarlos. En tu cadena puede haber tres o cuatro firewalls: integrado en Windows o macOS, incluido en el antivirus, en el router y en el administrador corporativo. Cualquiera de ellos puede descartar silenciosamente paquetes hacia un puerto no estándar, y tú solo verás un cuelgue.

Autorización por IP: firewall invisible del lado del proxy

Muchos proveedores de proxies móviles tienen un modo en el que, en lugar de usuario y contraseña, se usa una lista blanca de direcciones IP. El servidor acepta conexiones solo desde direcciones de la lista, y las demás tentativas puede simplemente ignorarlas. Si tu IP doméstica cambió (esto ocurre al reiniciar el router en la mayoría de los proveedores), el proxy dejará de reconocerte. Exteriormente esto se ve exactamente igual que un puerto bloqueado.

Ahora que el panorama está claro, pasemos a la práctica. Cada paso siguiente verifica un tramo de la cadena y, o bien lo libera de sospecha, o bien encuentra al culpable.

Paso 1: Determinamos dónde se rompe la conexión

Objetivo de la etapa: entender en cinco minutos si el problema está de tu lado, del lado de la red o del lado del proxy. Este es el paso más importante, porque descarta la mitad de las posibles causas de inmediato.

Verificamos el internet sin proxy

1. Abre el navegador y desactiva temporalmente el proxy en su configuración. En Chrome es Configuración, sección Sistema, opción "Abrir la configuración de proxy de la computadora". En el navegador antidetect crea un perfil sin proxy o selecciona el modo "Sin proxy" en la configuración del perfil.
2. Abre cualquier sitio grande, por ejemplo la página de un buscador. Debe cargar en uno o dos segundos.
3. Si el sitio no abre ni siquiera sin proxy, el problema no está en el proxy. Reinicia el router, revisa el cable o el Wi-Fi y regresa a esta guía más tarde.

Verificamos el proxy desde otro dispositivo

1. Toma un smartphone y desactiva el Wi-Fi para que funcione a través de internet móvil. Así estarás en una red completamente distinta, evitando tu router y tu proveedor.
2. Instala en el teléfono cualquier navegador con soporte de proxy o usa la configuración del sistema: en Android en las propiedades del punto de acceso esto se hace a través de APN, pero es más simple instalar una aplicación de navegador con ingreso manual del proxy.
3. Ingresa la dirección, el puerto, el usuario y la contraseña de tu proxy y abre cualquier sitio que muestre tu dirección IP.
4. Si el proxy funciona desde el teléfono, significa que el proxy mismo está vivo y el problema está entre tu computadora e internet: firewall, router o configuración del software. Ve a los pasos 2, 3, 4 y 5.
5. Si desde el teléfono tampoco funciona, el problema está en el propio proxy o en su configuración de autorización. Pasa al paso 6 y luego al soporte.

Consejo: si no tienes un segundo dispositivo, intenta conectar la computadora al punto de acceso móvil del teléfono. El cambio de red dará el mismo efecto que una verificación desde otro dispositivo.

Verificamos el estado del proxy en el panel

1. Inicia sesión en el panel del proveedor de proxies móviles.
2. Encuentra la tarjeta de tu proxy y mira el indicador de estado. En la mayoría de los servicios muestra si el módem está en línea y cuándo fue la última actividad.
3. Si el indicador muestra que el proxy está desconectado o el módem no está en línea, ya no hay que diagnosticar más: la causa está del lado del equipo y la resuelve el soporte.

Verificación: al final de este paso debes tener respuesta a una pregunta: ¿el proxy funciona al menos desde algún lugar o no funciona desde ninguno? Anota esta conclusión. Ella determina qué pasos serán los principales a continuación.

Posibles problemas en este paso

A veces el proxy funciona desde el teléfono y un minuto después deja de hacerlo. Esto puede ser rotación de IP en el proxy o red celular inestable en el módem. Repite la verificación dos o tres veces con un intervalo de un minuto para no sacar conclusiones falsas de un solo intento.

Paso 2: Verificamos la dirección y el puerto del proxy

Objetivo de la etapa: asegurarte de que el puerto del proxy está abierto y accesible precisamente desde tu computadora. Esta es la verificación clave: si el puerto no responde, todo lo demás carece de sentido.

Por qué el ping no sirve

El primer pensamiento de muchos: hacer ping al servidor. Pero el ping verifica solo la disponibilidad de la dirección IP por el protocolo ICMP, no la apertura de un puerto concreto. Muchos servidores proxy no responden ping en absoluto por razones de seguridad. Así que un ping exitoso no garantiza nada, y uno fallido no significa nada. Necesitamos verificar precisamente el puerto TCP.

Verificación del puerto en Windows

1. Presiona la tecla Windows, escribe PowerShell y ábrelo.
2. Escribe el comando, sustituyendo tu dirección y puerto:

   Test-NetConnection -ComputerName proxy.example.net -Port 30001

3. Presiona Enter y espera. El comando puede tardar hasta 20 segundos.
4. Encuentra en la salida la línea TcpTestSucceeded. El valor True significa que el puerto está abierto y acepta conexiones. El valor False significa que no se logró llegar al puerto.
5. Presta atención a la línea PingSucceeded. Si es False y TcpTestSucceeded es True, todo está bien: el servidor simplemente no responde a ping.

Verificación del puerto en macOS y Linux

1. Abre la Terminal.
2. Escribe el comando:

   nc -zv proxy.example.net 30001

3. La opción -z indica a la utilidad que no envíe datos, sino que solo verifique la conexión. La opción -v activa la salida detallada.
4. Una respuesta como succeeded o Connection to ... port 30001 succeeded! significa éxito. La respuesta Connection refused significa que el puerto está cerrado y el servidor rechazó de inmediato. Si el comando se queda colgado sin respuesta y luego escribe timed out, el puerto está siendo filtrado en algún punto del camino.

Verificación con curl en cualquier sistema

curl puede no solo verificar el puerto, sino también hacer una solicitud a través del proxy. Este es el siguiente nivel de verificación.

1. Escribe el comando, sustituyendo tus datos:

   curl -x http://login:password@proxy.example.net:30001 --connect-timeout 15 -v https://api.ipify.org

2. La opción -x define el proxy. La opción -v muestra todas las etapas de la conexión. La opción --connect-timeout limita la espera de establecimiento de la conexión a 15 segundos.
3. Lee la salida de arriba a abajo. La línea Connected to proxy.example.net significa que el puerto está abierto. La línea CONNECT api.ipify.org:443 muestra que curl pidió al proxy establecer un túnel. Si después de esto llegó la respuesta 200 y al final ves la dirección IP, el proxy funciona por completo.
4. Si la salida se detuvo en la línea Trying 185.10.20.30:30001... y tras 15 segundos apareció Connection timed out, el puerto no está disponible desde tu computadora.

Consejo: si en la contraseña hay caracteres especiales como @ o #, curl puede interpretar mal la dirección. Usa la opción -U por separado para las credenciales: curl -x http://proxy.example.net:30001 -U login:password ... Así la contraseña no se mezclará con la dirección.

Verificamos el protocolo y el puerto SOCKS5

Error frecuente: indicar el puerto HTTP donde el software espera SOCKS5, o al revés. La conexión se establecerá, pero los datos no fluirán y la aplicación puede dar un tiempo de espera agotado.

1. Verifica en el panel del proveedor qué puertos te dieron para HTTP y para SOCKS5.
2. Realiza la verificación con curl con el protocolo SOCKS5:

   curl -x socks5://login:password@proxy.example.net:30002 --connect-timeout 15 https://api.ipify.org

3. Asegúrate de que en tu aplicación esté seleccionado el mismo protocolo que en el comando curl exitoso.

Verificación: después de este paso sabes exactamente una de tres cosas: el puerto está abierto y el proxy responde a través de curl (entonces el problema está en la configuración de tu aplicación, pasa al paso 3); el puerto está abierto, pero la solicitud a través del proxy se cuelga (problema con la autorización o del lado del proxy, paso 6); el puerto no responde (problema en el firewall o la red, pasos 4 y 5).

Posibles problemas en este paso

Si Test-NetConnection da un error de resolución de nombre, significa que la computadora no puede convertir el nombre de dominio en dirección IP. Intenta sustituir el nombre por la dirección IP del panel. Si con la IP funciona y con el nombre no, tienes un problema de DNS: cambia el servidor DNS en la configuración del adaptador de red a uno público y repite.

Paso 3: Entendemos los tiempos de espera en tu software

Objetivo de la etapa: asegurarte de que la aplicación da al proxy móvil suficiente tiempo para responder y aprender a distinguir el tiempo de espera de conexión del de lectura.

Medimos el tiempo real de respuesta

1. Ejecuta el comando curl con salida de tiempos:

   curl -x http://login:password@proxy.example.net:30001 -o /dev/null -s -w "connect: %{time_connect}s total: %{time_total}s" https://api.ipify.org

   En Windows, en lugar de /dev/null usa NUL.
2. El valor connect muestra en cuánto se estableció la conexión TCP con el proxy. Normal para proxies móviles: de 0,05 a 0,5 segundos.
3. El valor total muestra el tiempo de toda la solicitud. Para proxies móviles es normal ver 1-4 segundos, y en horas pico de carga de la red celular hasta 6-8 segundos.
4. Repite el comando cinco veces y anota la dispersión. Si connect es establemente bajo y total a veces salta a 10 segundos, tu software debe estar preparado para tales demoras.

Configuramos los tiempos de espera en herramientas populares

Python y la biblioteca requests

El parámetro timeout acepta una tupla de dos valores: tiempo de espera de conexión y tiempo de espera de lectura. Valores recomendados para proxies móviles: 10 segundos para conexión y 30 segundos para lectura.

proxies = {"http": "http://login:password@proxy.example.net:30001", "https": "http://login:password@proxy.example.net:30001"}
response = requests.get("https://api.ipify.org", proxies=proxies, timeout=(10, 30))

Si indicas un solo número, por ejemplo timeout=5, se aplica a ambos tiempos de espera, y esta es una causa frecuente de mensajes falsos de que el servidor proxy no responde.

Node.js y axios

En axios el parámetro timeout es uno y general. Establécelo en no menos de 30000 milisegundos. Para el proxy usa un agente, por ejemplo del paquete https-proxy-agent, y pásalo al parámetro httpsAgent.

Navegadores antidetect

1. Abre la configuración del perfil, sección con proxy.
2. Busca el botón de verificación de conexión. Está en prácticamente todos los antidetect modernos.
3. Presta atención en cuánto tiempo llega el resultado. Si la verificación dura más de 10 segundos y termina en fallo, y curl al mismo tiempo funciona, revisa en la configuración general del navegador el parámetro de tiempo de espera del proxy y auméntalo.
4. Asegúrate de que en el campo de protocolo esté seleccionado precisamente HTTP o SOCKS5 de acuerdo con el puerto que pasó la verificación en el paso 2.

Herramientas para scraping y automatización

En Scrapy responde el parámetro DOWNLOAD_TIMEOUT, por defecto 180 segundos, y rara vez es el problema. En Puppeteer y Playwright el tiempo de espera de navegación por defecto es 30 segundos, pero al trabajar a través de una red celular lenta las páginas pesadas pueden no alcanzar: auméntalo a 60 segundos mediante el parámetro timeout en el método goto.

Consejo: no pongas tiempos de espera demasiado grandes. 30-60 segundos para lectura es un límite razonable. Si pones 300 segundos, tu script se quedará colgado durante horas en conexiones muertas en lugar de repetir la solicitud rápidamente.

Distinguimos el tiempo de espera de conexión del de lectura

Esto es importante, porque se tratan de manera diferente.

• Tiempo de espera de conexión en curl se ve como "Connection timed out after 15001 milliseconds" justo después de la línea Trying. En Python requests es la excepción ConnectTimeout. Tratamiento: pasos 4, 5 y 6, porque no lograste llegar al puerto.
• Tiempo de espera de lectura en curl se ve como "Operation timed out after 30000 milliseconds with 0 bytes received" ya después de la línea Connected. En Python es ReadTimeout. Tratamiento: aumentar el tiempo de espera de lectura, verificar si en ese momento hay rotación de IP en el proxy y asegurarte de que el sitio objetivo esté disponible en general.

Verificación: después de este paso el tiempo de respuesta del proxy a través de curl cabe en los tiempos de espera de tu aplicación con un margen de al menos el doble. Si curl responde en 3 segundos, en el software debe haber no menos de 10 segundos para lectura.

Paso 4: Verificamos el firewall y el antivirus en tu dispositivo

Objetivo de la etapa: asegurarte de que el software de protección en la computadora no bloquea las conexiones salientes al puerto del proxy y, si es necesario, crear una regla de permiso puntual.

Prueba rápida: desactivación temporal

Antes de hurgar en las reglas, probemos la hipótesis de la manera más simple. Desactivamos la protección por un minuto, repetimos la verificación del puerto, la activamos de nuevo.

1. En Windows abre la búsqueda, escribe "Firewall de Windows Defender" y ábrelo.
2. A la izquierda haz clic en "Activar o desactivar el Firewall de Windows Defender".
3. Para el perfil de red actualmente activo (normalmente es Red privada o Red pública) selecciona "Desactivar" y haz clic en Aceptar.
4. Inmediatamente ejecuta Test-NetConnection del paso 2.
5. De inmediato devuelve el interruptor a la posición "Activar" y haz clic en Aceptar.

Atención: no trabajes con el firewall desactivado más tiempo del necesario para una verificación. Un comando toma segundos, y un sistema abierto en la red es un riesgo real. Si olvidaste activarlo de nuevo, Windows te lo recordará con una notificación, pero mejor no confiar en eso.

Si con el firewall desactivado el puerto se volvió accesible, el culpable está encontrado. Si no, verificamos el antivirus de la misma manera: la mayoría de los productos tienen la opción "Pausar la protección durante 5 minutos" en el menú contextual del icono en la bandeja del sistema. Repite la verificación del puerto y devuelve la protección.

Creamos una regla de permiso en el firewall de Windows

No se puede desactivar el firewall para siempre. En lugar de eso crearemos una regla que permita precisamente a tu aplicación las conexiones salientes.

1. Abre "Firewall de Windows Defender" y a la izquierda haz clic en "Configuración avanzada". Se abrirá una ventana con configuraciones avanzadas.
2. En la columna izquierda selecciona "Reglas de salida".
3. En la columna derecha haz clic en "Nueva regla".
4. Selecciona el tipo "Para un programa" y haz clic en Siguiente.
5. Selecciona "Ruta del programa" y mediante el botón Examinar indica el archivo ejecutable de tu aplicación: navegador, antidetect o intérprete de Python. Haz clic en Siguiente.
6. Selecciona "Permitir la conexión" y haz clic en Siguiente.
7. Marca los tres perfiles: Dominio, Privada, Pública. Haz clic en Siguiente.
8. Dale a la regla un nombre claro, por ejemplo "Permitir proxy para navegador antidetect", y haz clic en Finalizar.

Variante alternativa, si hay muchas aplicaciones: crear una regla del tipo "Para un puerto", seleccionar el protocolo TCP, indicar el puerto remoto concreto del proxy y permitirlo para todos los programas. Para ello, en el cuarto punto selecciona "Personalizada", en la sección "Protocolo y puertos" indica TCP y en el campo "Puerto remoto" escribe el número de puerto del proxy.

Verificamos si hay una regla de bloqueo

A veces el problema no es la ausencia de permiso, sino la presencia de una prohibición creada por el antivirus o una política corporativa.

1. En la misma ventana de configuración avanzada abre "Reglas de salida".
2. Haz clic en el encabezado de la columna "Acción" para ordenar la lista. Las reglas con acción "Bloquear" quedarán juntas.
3. Revísalas. Si ves una regla que bloquea tu aplicación o un rango de puertos en el que cae el puerto del proxy, haz clic derecho sobre ella y selecciona "Deshabilitar regla".
4. Repite la verificación del puerto.

Firewall en macOS

1. Abre Configuración del Sistema, sección Red, luego Firewall.
2. Si el firewall está activado, haz clic en Opciones.
3. Asegúrate de que tu aplicación en la lista tenga el estado "Permitir conexiones entrantes". Aunque nos interesan las salientes, algunas aplicaciones abren un puerto local para trabajar con el proxy.
4. Desmarca la casilla "Bloquear todas las conexiones entrantes", si está marcada, y repite la verificación.

Verifica por separado utilidades de terceros como Little Snitch o LuLu: controlan precisamente el tráfico saliente y en algún momento pudieron haber recordado tu negativa a una solicitud de permiso. Encuentra tu aplicación en su lista de reglas y permite las conexiones a la dirección del proxy.

Firewall en Linux

1. Verifica el estado de ufw con el comando sudo ufw status verbose. Presta atención a la línea Default: si para outgoing dice deny, las conexiones salientes se bloquean por defecto.
2. Permite la conexión saliente al puerto del proxy:

   sudo ufw allow out to 185.10.20.30 port 30001 proto tcp

3. Si usas iptables directamente, mira las reglas con el comando sudo iptables -L OUTPUT -n -v y busca las líneas con DROP o REJECT en las que cae tu tráfico.
4. En servidores con Docker recuerda que los contenedores usan un subsistema de red aparte. Verifica la disponibilidad del puerto desde dentro del contenedor, no solo desde el host.

Consejo: anota la hora exacta en que modificaste las reglas del firewall. Si en una semana algo se rompe, recordarás rápidamente qué cambio pudo ser la causa y lo revertirás a través del archivo exportado en la etapa de preparación.

Verificación: después de este paso Test-NetConnection o nc muestran una conexión exitosa con el firewall activado y el antivirus activo. Si el puerto sigue sin estar disponible, y con la protección desactivada tampoco se abría, el problema está más arriba, a nivel del router o la red. Pasa al paso 5.

Paso 5: Verificamos el router, la red corporativa y el proveedor

Objetivo de la etapa: averiguar si el equipo entre tu computadora y el servidor proxy está descartando tu tráfico y, si es necesario, corregir la configuración del router o cambiar de red.

Vemos dónde exactamente se pierden los paquetes

La utilidad de trazado muestra la lista de nodos por los que pasan los paquetes hasta el servidor. Si los paquetes llegan a algún nodo y luego desaparecen, ves de quién es ese nodo: tu router, el proveedor o algo más allá.

1. En Windows abre cmd y ejecuta tracert 185.10.20.30, sustituyendo la IP del proxy.
2. En macOS ejecuta traceroute 185.10.20.30. En Linux es mejor usar mtr -n 185.10.20.30: muestra estadísticas en tiempo real y pérdidas en cada nodo.
3. La primera línea es tu router. La segunda y tercera normalmente son del equipo del proveedor. Luego nodos troncales y al final el servidor proxy.
4. Si llega respuesta de todos los nodos excepto del último, esto es normal: los servidores proxy a menudo no responden a tales solicitudes. Mira las pérdidas en el medio del camino.
5. Si los asteriscos comienzan justo después del primer nodo, tu router o el proveedor no dejan pasar el tráfico a esta dirección.

Recuerda: el trazado usa ICMP o UDP, no TCP en el puerto necesario, por lo que muestra la disponibilidad general de la ruta, no la apertura del puerto. Es una herramienta adicional, no un sustituto de la verificación del paso 2.

Verificamos el router

1. Abre el navegador y escribe en la barra de direcciones la dirección del router, normalmente 192.168.0.1 o 192.168.1.1. El usuario y la contraseña están impresos en la etiqueta debajo del dispositivo, si no los cambiaste.
2. Busca la sección con un nombre como "Seguridad", "Firewall", "Filtrado" o "Control parental".
3. Mira si hay filtrado por puertos o por URL activado. Algunos routers tienen perfiles preestablecidos como "Nivel de protección alto", que bloquean todo excepto los puertos 80 y 443. Cambia a un nivel estándar.
4. Revisa la sección "Control de acceso" o "Programación": puede haber una regla que limite el internet para tu dispositivo en ciertas horas.
5. Encuentra la configuración SPI Firewall o "Protección contra DoS". A veces una protección demasiado agresiva percibe muchas conexiones paralelas a una misma dirección como un ataque y comienza a cortarlas. Si tienes decenas de hilos de scraping, intenta desactivar temporalmente esta protección y repetir la verificación.
6. Guarda los cambios y, si es necesario, reinicia el router.

Atención: no cambies la configuración del router cuyo propósito no entiendas, especialmente en las secciones WAN y DHCP. Un error allí dejará sin internet a toda la casa u oficina. Si dudas, haz una copia de seguridad de la configuración, como se describe en la preparación, y cambia solo un parámetro a la vez.

Verificamos el MTU

El MTU es el tamaño máximo de un paquete de datos. Si está configurado incorrectamente, las solicitudes pequeñas pasan y las respuestas grandes se pierden. El síntoma es característico: la conexión con el proxy se establece, las páginas pequeñas abren y las grandes se cuelgan.

1. En Windows ejecuta en cmd: ping -f -l 1472 8.8.8.8. Si los paquetes pasan, el MTU 1500 está bien. Si dice "se requiere fragmentación", reduce el número en pasos de 10 hasta que pase.
2. Encuentra en el router la configuración de MTU (normalmente en la sección WAN o Internet) y establece el valor encontrado más 28.
3. Valores típicos: 1500 para conexión por cable normal, 1492 para PPPoE, 1400-1450 para algunos canales móviles y satelitales.

Red corporativa y Wi-Fi público

Si trabajas en una oficina, coworking u hotel, entre tú e internet casi con seguridad hay una puerta de enlace corporativa con su propio firewall. Tales puertas de enlace muy a menudo permiten solo los puertos 80 y 443 y cortan todo lo demás. El puerto de cinco cifras del proxy móvil simplemente no pasa.

1. Conéctate al punto de acceso móvil del teléfono y repite la verificación del puerto. Si funcionó, el culpable es la puerta de enlace corporativa.
2. Contacta al administrador del sistema con una solicitud concreta: permitir conexiones TCP salientes a tal IP y tal puerto. Cuanto más precisa sea la solicitud, más rápido la ejecutarán.
3. Averigua con el proveedor del proxy si hay posibilidad de obtener un puerto de un rango estándar, por ejemplo 443 o 8080. En muchos servicios esto es configurable.

Proveedor doméstico

Los proveedores domésticos rara vez bloquean puertos salientes, pero algunos cortan rangos conocidos asociados a torrents o servidores de correo. Si después de todas las verificaciones el puerto no responde desde la red doméstica, pero responde a través de internet móvil, llama al soporte del proveedor y pregunta directamente si filtran conexiones salientes al puerto indicado.

Consejo: guarda la salida del trazado y de la verificación del puerto desde tu red y desde la red móvil en un solo archivo. Cuando escribas al proveedor o al administrador, adjunta ambos resultados. Esto reducirá el diálogo de una semana a un día.

Verificación: el puerto del proxy es accesible desde tu red con el comando del paso 2, el trazado no muestra pérdidas en los nodos del proveedor, y el ping con la opción -f pasa con tamaño 1472. Si se cumplen las tres condiciones y el proxy sigue sin responder, el asunto está en su propia configuración. Vamos al paso 6.

Paso 6: Verificamos la configuración del lado del proxy

Objetivo de la etapa: asegurarte de que el servidor proxy acepta precisamente a ti: tu IP está en la lista blanca, el módem está en línea, la rotación no coincide con tus solicitudes y el límite de conexiones no está excedido.

Verificamos la autorización por IP

Esta es la causa más frecuente cuando el proxy funciona desde el teléfono pero no desde la computadora, o funcionaba ayer y hoy no.

1. Averigua tu IP externa actual. Abre sin proxy cualquier sitio que muestre la IP, o ejecuta curl https://api.ipify.org en la terminal.
2. Abre el panel del proveedor del proxy, la sección con la configuración de autorización.
3. Compara la dirección de la lista blanca con tu dirección actual. Si difieren, aquí está la causa: tu proveedor asignó una nueva dirección después de reiniciar el router o por programación.
4. Actualiza la dirección en la lista blanca o cambia a autorización por usuario y contraseña. La segunda variante es más confiable si tu IP externa cambia.
5. Espera uno o dos minutos: la configuración en el servidor proxy no se aplica al instante.
6. Repite la verificación con curl del paso 2.

Consejo: si trabajas desde casa con IP dinámica, la autorización por usuario y contraseña te librará de este problema para siempre. La lista blanca es conveniente para servidores con dirección estática, no para computadoras domésticas.

Verificamos el estado del módem y la rotación

1. En el panel busca la información sobre la IP actual del proxy y la hora del último cambio.
2. Si tienes configurada rotación automática cada pocos minutos, presta atención: en el momento del cambio de IP el módem se reconecta a la red celular, y durante 5-20 segundos el proxy realmente no responde. Este es un comportamiento normal, no una avería.
3. Si tus solicitudes regularmente capturan el tiempo de espera agotado justo en el momento de la rotación, aumenta el intervalo de rotación o cambia a cambio de IP por enlace, para controlar el momento de la reconexión tú mismo.
4. Intenta forzar el cambio de IP a través del enlace del panel. Si después del cambio el proxy funcionó, el problema estaba en una IP concreta o en una conexión colgada del módem.

Verificamos el límite de conexiones simultáneas

Los proxies móviles tienen una restricción en la cantidad de conexiones paralelas desde un puerto. Si tu parser abrió cien hilos y el límite es cincuenta, las conexiones sobrantes quedarán en cola y caerán por tiempo de espera.

1. Averigua el límite en la descripción del plan o en el panel.
2. Cierra todas las aplicaciones que usan el proxy y ejecuta una solicitud única con curl. Si la solicitud única pasa, y bajo carga comienzan los tiempos de espera, estás chocando con el límite.
3. Reduce el número de hilos en la configuración del parser o del antidetect a un valor inferior al límite. Para proxies móviles un inicio razonable: 5-10 conexiones paralelas por puerto.

Verificamos las zonas horarias y la red celular

El módem del proxy está físicamente en una ciudad concreta y conectado a un operador concreto. En las horas de la tarde, cuando las redes celulares están sobrecargadas, las demoras crecen varias veces. Si los tiempos de espera aparecen solo entre las 19 y las 23 horas según la zona horaria de la región del proxy, es la red celular, no tu configuración. Solución: aumentar los tiempos de espera en ese horario o distribuir la carga en otras horas.

Verificación: tu IP actual coincide con la lista blanca o se usa autorización por contraseña, el módem en el panel muestra el estado "en línea", la solicitud única con curl pasa, y el número de hilos en el software no excede el límite. Si todo esto se cumple y el servidor proxy no responde, es momento de escribir al soporte del proveedor adjuntando los resultados de los seis pasos.

Verificación del resultado: lista de control de una conexión estable

Has pasado por todos los pasos. Ahora asegurémonos de que el resultado se alcanzó no por casualidad ni por un minuto. Recorre la lista de control y marca cada punto.

Lista de control

• Test-NetConnection o nc muestran una conexión TCP exitosa con el puerto del proxy con el firewall y el antivirus activados.
• curl a través del proxy devuelve la dirección IP del operador móvil en no más de 5 segundos en cinco intentos seguidos.
• El tiempo de espera de conexión en tu software no es menor a 10 segundos, el tiempo de espera de lectura no es menor a 30 segundos.
• El protocolo en la aplicación (HTTP o SOCKS5) coincide con el puerto que pasó la verificación con curl.
• En el firewall se creó una regla de permiso puntual, y no se desactivó la protección por completo.
• Tu IP externa coincide con la lista blanca o se usa autorización por contraseña.
• El número de conexiones paralelas en la aplicación es menor al límite del plan.
• Las copias de seguridad de la configuración del firewall y del router están guardadas por si hay que revertir.

Prueba de carga

Una solicitud única es una cosa, y el trabajo real son decenas de solicitudes seguidas. Hagamos una prueba corta.

1. Ejecuta en la terminal un ciclo de 20 solicitudes. En macOS y Linux:

   for i in $(seq 1 20); do curl -x http://login:password@proxy.example.net:30001 -s -o /dev/null -w "%{http_code} %{time_total}\n" https://api.ipify.org; done

   En PowerShell usa el ciclo 1..20 | ForEach-Object con el mismo comando curl dentro.
2. En la salida verás 20 líneas con el código de respuesta y el tiempo. Todos los códigos deben ser 200, y el tiempo no debe exceder los 5-6 segundos.
3. Si una o dos solicitudes de veinte tomaron más, esto es aceptable para la red móvil. Si cada tercera solicitud cae en tiempo de espera agotado, regresa al paso 6 y verifica el límite de conexiones y la rotación.

Prueba en una aplicación real

1. Abre el perfil del navegador antidetect con el proxy configurado y haz clic en verificación de conexión. El resultado debe llegar en 2-4 segundos y mostrar la IP del operador móvil.
2. Abre una página pesada, por ejemplo el feed de una red social. Debe cargar por completo en 10-15 segundos.
3. Deja la pestaña abierta durante 10 minutos y actualiza la página. Si cargó, la conexión sobrevive las pausas y no se rompe por inactividad.
4. Para scripts: ejecuta una tarea de trabajo de 50-100 solicitudes y mira el porcentaje de exitosas. Indicador de éxito: no menos del 95 por ciento sin repeticiones.

Indicadores de éxito: el puerto está accesible, el tiempo de respuesta es predecible, la aplicación no se queja de tiempos de espera durante 30 minutos de trabajo, y sabes exactamente cuál de los seis pasos fue la causa del problema. Esto último es especialmente valioso: la próxima vez comenzarás el diagnóstico precisamente por ahí.

Errores típicos y sus soluciones

Aquí se reúnen las situaciones que los usuarios de proxies móviles enfrentan con más frecuencia. Formato: qué ves, por qué ocurre, qué hacer.

El proxy funciona desde el teléfono pero no desde la computadora

Causa: el firewall o el antivirus en la computadora bloquea la conexión saliente a un puerto no estándar, o tu IP doméstica no coincide con la lista blanca, y el teléfono se autoriza de otra manera.

Solución: realiza la prueba rápida desactivando el firewall del paso 4. Si no ayudó, compara la IP externa de la computadora con la lista blanca según las instrucciones del paso 6.

La conexión se establece, pero la página no carga

Causa: indicaste el puerto HTTP donde la aplicación espera SOCKS5, o al revés. La conexión se abre, pero la aplicación y el proxy hablan idiomas distintos y los datos no fluyen.

Solución: verifica ambos protocolos con curl con las opciones http:// y socks5:// y establece en la aplicación el que funcionó.

Funcionó una semana y luego dejó de funcionar sin cambios de tu parte

Causa: cambió la IP externa de tu proveedor de internet, y en el panel del proxy está configurada la autorización por IP. Segunda variante: una actualización del antivirus agregó una nueva regla de bloqueo.

Solución: actualiza la lista blanca o cambia a autorización por contraseña. Verifica la lista de reglas de bloqueo en el firewall según las instrucciones del paso 4.

Tiempos de espera solo en horario vespertino

Causa: sobrecarga de la red celular en la región donde está el módem del proxy. Es una particularidad del internet móvil, no una avería.

Solución: aumenta el tiempo de espera de lectura a 45-60 segundos en las horas de la tarde, agrega repeticiones de solicitudes y, si es posible, traslada las tareas pesadas a la mañana.

Cada décima solicitud falla por tiempo de espera agotado

Causa: coincidencia de las solicitudes con el momento de la rotación automática de IP, o exceso del límite de conexiones paralelas.

Solución: cambia la rotación a cambio por enlace y llámalo entre lotes de solicitudes. Reduce el número de hilos a 5-10.

En la oficina no funciona, en casa sí

Causa: la puerta de enlace corporativa deja pasar solo los puertos 80 y 443.

Solución: solicita al administrador permiso para una IP y un puerto concretos, u obtén del proveedor del proxy un puerto de un rango estándar.

Test-NetConnection muestra True, pero el navegador sigue colgado

Causa: el puerto está abierto, pero en el navegador está configurado otro puerto, otra dirección o hay activada una excepción del sistema por la que el tráfico va por fuera del proxy. También es posible que una extensión para proxy entre en conflicto con la configuración del sistema.

Solución: compara carácter por carácter la dirección y el puerto en el navegador con lo que verificaste por comando. Desactiva todas las extensiones relacionadas con proxy y configura el proxy de una sola manera.

Las páginas pequeñas abren, las grandes se cuelgan

Causa: MTU incorrecto en el router o en el proveedor. Los paquetes grandes no pasan.

Solución: selecciona el MTU con el comando ping con la opción -f del paso 5 y establécelo en el router.

Funciones adicionales para usuarios avanzados

Si la conexión básica está restaurada y quieres más control, esta sección es para ti. Aquí hay herramientas y enfoques que convierten un diagnóstico puntual en un monitoreo constante.

Observamos los paquetes: Wireshark y tcpdump

Cuando los comandos de los pasos principales no dan una respuesta inequívoca, se puede mirar el tráfico de red directamente.

1. En Linux o macOS ejecuta:

   sudo tcpdump -i any host 185.10.20.30 and port 30001 -nn

   En Windows instala Wireshark y en el filtro de visualización escribe ip.addr == 185.10.20.30 and tcp.port == 30001.
2. Lanza la verificación del puerto del paso 2 y observa los paquetes capturados.
3. Si ves paquetes salientes con la bandera SYN, pero no hay SYN-ACK de respuesta, tus paquetes salen pero la respuesta no regresa. El bloqueo está en algún punto fuera de la computadora.
4. Si no hay paquetes SYN en absoluto, los descarta el firewall local antes incluso de salir a la red.
5. Si en respuesta llega RST, el puerto en el servidor está cerrado o el servidor te rechaza precisamente a ti.

Repeticiones automáticas con pausa creciente

La red móvil es inestable por naturaleza. En lugar de caer en el primer tiempo de espera agotado, configura repeticiones con retraso exponencial: primer intento a 1 segundo, segundo a 2, tercero a 4. En Python esto se hace mediante un adaptador con la clase Retry de urllib3, en Node.js a través del paquete axios-retry. Tres repeticiones con este esquema eliminan el 90 por ciento de los tiempos de espera aleatorios sin pérdida de datos.

Conexiones persistentes y pools

Cada nueva conexión TCP a través de un proxy móvil cuesta 100-500 milisegundos en establecerse. Si tu script abre una nueva conexión para cada solicitud, pierdes tiempo y chocas más rápido con el límite. Usa sesiones: en Python requests.Session, en Node.js un agente con keepAlive: true. Una conexión se reutilizará para decenas de solicitudes.

Monitoreo de disponibilidad

Configura una verificación simple cada minuto: el script hace una solicitud a través del proxy y registra el tiempo de respuesta y el código. En una semana obtendrás un panorama de en qué horas el proxy es más rápido y cuándo captura tiempos de espera. Esto permitirá planificar la carga y ver la degradación de antemano, en lugar de enterarte por tareas rotas.

*/1 * * * * curl -x http://login:password@proxy.example.net:30001 -s -o /dev/null -m 20 -w "$(date +%H:%M) %{http_code} %{time_total}\n" https://api.ipify.org >> /var/log/proxy-check.log

DNS a través del proxy

Por defecto, algunas aplicaciones resuelven los nombres de dominio localmente, no a través del proxy. Esto puede provocar fugas de información y situaciones en las que el DNS local devuelve una dirección inaccesible desde la red móvil. En la configuración de navegadores y antidetects busca la opción "DNS a través del proxy" o usa el protocolo socks5h en lugar de socks5 en curl y Python: la letra h significa que los nombres los resolverá el propio proxy.

Cambio de puerto a uno estándar

Si trabajas frecuentemente desde distintas redes, averigua con el proveedor la posibilidad de asignar al proxy el puerto 443 o 8080. Tales puertos están abiertos en casi todas partes y no tendrás que pelear cada vez con los firewalls corporativos.

Configuración fina de la rotación

Escenario avanzado: vincular el cambio de IP con la lógica de la aplicación. Antes de comenzar un nuevo lote de solicitudes, el script llama al enlace de cambio de IP, espera 10-15 segundos, verifica a través de api.ipify.org que la dirección realmente cambió, y solo entonces comienza el trabajo. Así excluyes por completo los tiempos de espera por coincidencia aleatoria de la solicitud con la rotación.

Consejo: agrega al log de cada solicitud no solo la hora, sino también la IP actual del proxy. Cuando dentro de un mes analices por qué cayeron los indicadores, la correlación entre IP concretas y tiempos de espera te dirá de inmediato qué direcciones del operador fueron problemáticas.

FAQ: preguntas frecuentes sobre el diagnóstico

El servidor proxy no responde, pero el ping pasa. ¿Qué significa?

El ping verifica solo la disponibilidad de la IP por el protocolo ICMP, no la apertura del puerto. El servidor puede estar vivo y responder al ping, pero el puerto del proxy está siendo filtrado por un firewall o el servicio en él no está iniciado. Verifica siempre precisamente el puerto TCP con los comandos del paso 2.

¿Cuánto esperar antes de considerar que el proxy no responde?

Para establecer conexión con un proxy móvil es normal hasta 1 segundo, el límite es 10 segundos. Para recibir datos es normal hasta 5 segundos, el límite es 30-45 segundos. Si la conexión no se estableció en 10 segundos, esperar más no tiene sentido: la respuesta no llegará.

¿Se puede simplemente desactivar el firewall y trabajar así?

No. Desactivar la protección es aceptable solo por un minuto para probar una hipótesis. Después de eso, crea una regla puntual para la aplicación o el puerto concreto, como se describe en el paso 4, y vuelve a activar el firewall. Una computadora sin protección en la red es un riesgo para tus cuentas y datos.

¿Por qué el proxy funciona en un navegador y no funciona en otro?

Normalmente porque un navegador usa la configuración del sistema de proxy y el otro la suya propia, y en ellos están indicados datos diferentes. Segunda variante: el firewall permitió un archivo ejecutable y no permitió el otro. Revisa la configuración de ambos navegadores y la lista de reglas del firewall.

¿Cómo entender que el asunto está en la rotación de IP y no en mi configuración?

Anota la hora de cada tiempo de espera agotado durante una hora y compárala con el intervalo de rotación del panel. Si los tiempos de espera llegan con la misma periodicidad que el cambio de IP, es la rotación. Cambia al cambio por enlace y el problema desaparecerá.

¿Es obligatorio usar la terminal? ¿No hay herramientas gráficas?

La terminal es más rápida y precisa, pero hay alternativas. En los navegadores antidetect está integrada la verificación de proxy con salida del tiempo de respuesta. Hay programas de escritorio para verificar listas de proxies con indicación de puertos abiertos. Sin embargo, para encontrar la causa precisamente en tu caso, la terminal es insustituible: muestra en qué etapa se detuvo la conexión.

¿Qué hacer si se pasaron los seis pasos y el problema sigue?

Escribe al soporte del proveedor del proxy y adjunta: la salida de Test-NetConnection o nc, la salida de curl con la opción -v, el resultado del trazado, tu IP externa, la hora de los intentos y la información sobre si el proxy funciona desde otra red. Con tales datos, un especialista encontrará la causa en una sola respuesta, y no en cinco preguntas de aclaración.

¿Hay que reiniciar la computadora después de cambiar las reglas del firewall?

No, las reglas del firewall de Windows, macOS y Linux se aplican al instante. El reinicio solo es necesario para el router después de cambiar el MTU o los perfiles de seguridad, y ni siquiera en todos los modelos.

¿Se puede usar el mismo enfoque para proxies de datacenter?

Sí, los pasos del 1 al 5 son universales para cualquier tipo de proxy. El paso 3 difiere: los proxies de datacenter responden más rápido, y los tiempos de espera se pueden poner más cortos. Y el paso 6: los de datacenter no tienen rotación por reconexión del módem, por lo que no habrá pausas en el momento del cambio de IP.

Conclusión

Resumamos. Aprendiste a no entrar en pánico ante el mensaje de que el servidor proxy no responde, sino a analizar la situación por la cadena. Primero determinaste si el proxy funciona al menos desde algún lugar. Luego verificaste si el puerto está abierto precisamente desde tu dispositivo. Entendiste los tiempos de espera y comprendiste la diferencia entre el tiempo de espera de conexión y el de lectura. Verificaste el firewall y el antivirus y creaste una regla puntual en lugar de desactivar la protección. Estudiaste el router, el MTU y la puerta de enlace corporativa. Y finalmente, te aseguraste de que el propio proxy acepta precisamente a ti: lista blanca, módem, rotación, límites.

El resultado principal ni siquiera es que la conexión está restaurada. Está en que ahora tienes un método. La próxima vez que algo se cuelgue, no adivinarás ni revisarás la configuración al azar. Abrirás la terminal, ejecutarás dos comandos y en un minuto sabrás en qué tramo de la cadena está la interrupción.

Qué hacer después

1. Guarda el archivo con los comandos funcionales y tus datos del proxy en un lugar conveniente. Es tu kit de primeros auxilios.
2. Pasa la autorización a usuario y contraseña, si aún usas la lista blanca desde una computadora doméstica.
3. Verifica los tiempos de espera en todas las aplicaciones que trabajan a través de proxies móviles y llévalos a los valores recomendados.
4. Configura el monitoreo por minuto de la sección avanzada al menos en un proxy, para ver dentro de una semana el panorama real de estabilidad.

Hacia dónde desarrollarse

El siguiente nivel es la automatización del manejo de fallos: repeticiones con pausa creciente, rotación gestionada, pools de conexiones y registro de cada solicitud con vinculación a la IP. Una vez que domines esto, dejarás de notar los tiempos de espera aislados por completo: tu sistema los superará solo, y tú verás únicamente las métricas finales. Buena suerte en el trabajo, y que tus proxies respondan siempre a la primera.

Sobre el autor

Roman Melnikov

Technical Writer and System Administrator

Experiencia laboral: Technical writer and DevOps engineer with 9 years of experience. Created over 50 detailed guides on system configuration and administration. His instructions helped thousands of professionals successfully solve technical tasks. Popular author on Habr and YouTube.

Formación académica: Bauman Moscow State Technical University. Information Systems and Technologies

Especialización:

Technical Documentation DevOps System Administration Linux Docker and Kubernetes CI/CD Infrastructure Automation Cloud Technologies System Monitoring Bash and Python Scripting