Ya has abierto el sitio en el navegador y, sin embargo, la herramienta de detección del otro lado muestra luz roja. En este momento, es fácil caer en dos juicios opuestos: o piensas que tu IP está bloqueada, o crees que la herramienta de detección no sirve para nada.
No te apresures a tomar partido. Abrir la página de inicio directamente, que un script web lea una interfaz y que un servidor remoto haga la solicitud son tres pruebas diferentes. Solo cuando el objetivo, el método de solicitud, la salida de acceso y el criterio de éxito coinciden lo suficiente, los resultados son directamente comparables.
El propósito de investigar este tipo de problemas no es intentar poner la tarjeta en verde, sino determinar en qué paso ocurre el fallo y si afectará a lo que realmente quieres hacer.
Primero pregunta a la herramienta de detección: ¿qué segmento estás probando?
La "conectividad" no es un estado que cubra todas las funciones. Un acceso puede pasar al menos por la resolución de nombres de dominio, la conexión de red, la conexión segura y el procesamiento de la aplicación, mientras que los permisos de cuenta son otro nivel de evaluación.
Elemento de comprobación | Qué indica cuando tiene éxito | Qué no se puede concluir de ello |
|---|---|---|
Resolución DNS | La ruta de resolución seleccionada devolvió el registro del dominio | Que la dirección correspondiente sea accesible |
Conexión TCP | Desde la ubicación de prueba se puede conectar a la dirección y puerto destino | Que el certificado HTTPS o las funciones de la página sean normales |
Negociación TLS | Esta conexión completó la negociación de seguridad correspondiente | Que el inicio de sesión y las interfaces de negocio estén disponibles |
Respuesta HTTP | El destino o un servicio intermedio devolvió una respuesta | Que el contenido de la respuesta sea la página esperada |
Uso real de la página | La sesión actual completó una operación | Que otras cuentas, protocolos y salidas sean iguales |
Que un icono, un recurso estático o una interfaz de estado responda con éxito solo demuestra que ese objetivo de detección respondió en ese momento. No puede reemplazar la verificación del inicio de sesión, la carga, el pago u otras funciones de negocio.
Del mismo modo, la falta de respuesta a un ping tampoco demuestra por sí sola que un sitio web no esté disponible. ICMP utiliza un protocolo diferente al empleado para acceder a páginas web; una red puede no responder al primero y, aun así, permitir conexiones HTTPS normales.
Primer caso: la página se abre, pero el script de detección no puede leer el resultado
En este tipo de problemas conviene considerar primero las restricciones de origen cruzado.
Supongamos que la página de detección se ejecuta en el sitio A y su script intenta leer la respuesta del sitio B. El navegador comprueba si el sitio B permite que ese origen lea los datos; no se trata del mismo problema de permisos que cuando un usuario abre directamente el sitio B en la barra de direcciones.
La guía de CORS de MDN explica que las solicitudes de origen cruzado están sujetas a los mecanismos de seguridad del navegador. Es posible que la solicitud llegue al destino, pero la respuesta no se ponga a disposición del script; también puede que no se obtenga permiso para continuar con la solicitud durante la fase de verificación previa.
Más complicado aún es que el error que recibe el script suele ser poco específico. No siempre permite distinguir entre restricciones de origen cruzado, problemas de conexión y otras causas de fallo. Si una herramienta de detección muestra todos estos casos como «inaccesible», es fácil que un «no se puede verificar» se confunda con un «definitivamente inalcanzable».
Un usuario normal puede comprobar si el acceso directo es estable y si la página funciona correctamente, y conservar el mensaje de error de la detección. Un desarrollador debería revisar la consola del navegador y el registro de red para confirmar si existen errores de CORS o de verificación previa, en lugar de sacar conclusiones sobre una IP basándose únicamente en una excepción genérica.
No desactives la protección de seguridad del navegador para verificar la conexión. El entorno resultante se alejaría del entorno normal del usuario y, además, no solucionaría la política de origen cruzado del servicio de destino.
Segundo caso: diferencias en el método de solicitud, la ruta o el estado de inicio de sesión
Algunos programas de detección utilizan solicitudes HEAD para reducir el tráfico. Según la documentación de MDN sobre HEAD, este método se emplea para obtener las cabeceras de respuesta pertinentes, sin devolver el cuerpo de la respuesta.
Sin embargo, un sitio web concreto puede aplicar reglas diferentes para HEAD, GET y las interfaces de negocio. Por ejemplo, una ruta puede no admitir HEAD, mientras que un GET realizado por el usuario desde el navegador sí devuelve la página correctamente. En ese caso, hay que examinar el método de solicitud y la ruta de destino, sin generalizar un fallo en una sola ruta como si todo el sitio estuviera inactivo.
El estado de inicio de sesión también puede provocar diferencias. Cuando abres directamente el sitio web, es posible que el navegador ya tenga una sesión válida guardada; el script de detección no siempre dispone de las mismas cookies, tokens de acceso u otro contexto. A la inversa, que la página de inicio responda con normalidad no significa que una función interna que requiere inicio de sesión haya superado la prueba.
Para este tipo de problemas, conviene definir primero criterios de éxito claros: ¿se trata de poder abrir la página de inicio, de iniciar sesión en tu cuenta o de completar una operación normal? Una vez definidos los criterios, elige el método de verificación correspondiente.
Tercer caso: se recibe una respuesta, pero no es la que se esperaba
403: una solicitud rechazada no demuestra que la IP esté bloqueada de forma permanente
La documentación de Cloudflare sobre el error 403 enumera causas relacionadas con permisos y reglas de seguridad. En el procesamiento de la solicitud pueden intervenir el servidor de origen, una CDN o las políticas de seguridad.
En algunos casos, la página de error proporciona un identificador de solicitud, pistas sobre las reglas o canales de soporte a los que acudir. Conservar esta información es más útil para localizar el problema que limitarse a decir al servicio de atención al cliente «mi IP no funciona».
No obstante, no atribuyas automáticamente toda la responsabilidad a una marca que aparezca en la página de error. Para determinar quién debe gestionar el problema, hay que tener en cuenta los servicios por los que pasa la solicitud y la configuración del sitio web.
429: primero reduce las solicitudes; no trates la actualización continua como una forma de diagnóstico
El código 429 suele indicar que se ha limitado la frecuencia de solicitudes. La limitación puede aplicarse a la IP, pero también a la cuenta, las credenciales, las cookies o un recurso concreto; no todos los servicios cuentan de la misma manera.
El RFC 6585 no exige que el servidor identifique al solicitante de una forma determinada; la documentación de MDN sobre el 429 también explica distintos métodos de limitación y la posible cabecera Retry-After con una indicación de espera.
Cuando veas una limitación de frecuencia, deja de actualizar continuamente y de reintentar en lotes, y respeta el tiempo de espera indicado por el servicio. Utilizar más solicitudes para verificar un resultado de limitación puede hacer que el diagnóstico siga afectado por dicha limitación.
Tiempo de espera agotado: examina primero el umbral de la prueba y la fase en la que falla
Un tiempo de espera agotado solo indica que la detección no se completó dentro del plazo establecido. El fallo puede producirse en la resolución, la conexión, la negociación de seguridad o la espera de respuesta, y también puede estar relacionado con la cola del navegador, la carga del dispositivo o las detecciones simultáneas.
El «tiempo de detección» tampoco equivale necesariamente a la latencia de ida y vuelta de la red. El resultado de una comprobación HTTP puede incluir el tiempo de procesamiento del servicio y de transferencia de recursos, por lo que no debe compararse directamente con las cifras de ping.
Si el tiempo de espera es breve, conviene repetir la prueba después de un intervalo normal; si es persistente, hay que conservar la fase en la que se produjo el fallo. No concluyas que una dirección no está disponible a largo plazo basándote en un único exceso del umbral.
Cuarto caso: dos pruebas no se realizan desde la misma salida
Los proxies del navegador, del sistema y las VPN pueden afectar a aplicaciones y protocolos distintos. Si el dispositivo dispone a la vez de IPv4 e IPv6, las solicitudes de cada versión también pueden seguir rutas diferentes.
Hay otra situación que se suele pasar por alto: la herramienta de detección utiliza un servidor remoto para solicitar el destino. En ese caso, refleja la accesibilidad desde esa ubicación de prueba, no la capacidad de acceso de la IP pública que tú estás utilizando.
Si tu pregunta es «¿puede mi IP acceder a esta aplicación?», la evidencia principal debe proceder del acceso real desde el dispositivo y la red actuales. Una comprobación remota puede ayudar a confirmar si el servidor presenta un fallo generalizado, pero no sustituye a la verificación desde tu propia salida local.
Por lo tanto, al comparar resultados, al menos debes verificar la fuente de la prueba, la familia de direcciones, el estado del proxy y la dirección de destino. Escribir solo “ambos prueban el mismo sitio web” no basta para demostrar que las condiciones de prueba son idénticas.
Cambia solo una condición a la vez y la localización será mucho más rápida
Primero, usa la Consulta de IP para registrar la dirección pública actual y luego compárala con el acceso normal mediante la Pruebas de acceso a servicios. A continuación, revisa los elementos según los síntomas reales.
En la misma red y el mismo navegador, confirma si la página o función objetivo es estable y utilizable.
Revisa el objetivo de la detección y el motivo devuelto, distinguiendo restricciones de origen cruzado, códigos de estado, fallos de resolución y tiempos de espera.
Usa un perfil de navegador limpio temporal como control, registra las diferencias en extensiones, sesiones y permisos, y no te apresures a borrar el entorno original.
Verifica IPv4, IPv6 y la ruta del proxy; si cambias de red, úsala solo como evidencia comparativa y no deduzcas de inmediato que la IP original está bloqueada.
Si es necesario, complementa con una Consulta de registros DNS o una Comprobación de HTTP y TLS, y registra las ubicaciones de prueba utilizadas por estas herramientas para evitar confundir las fuentes de observación.
Cambiar de red altera simultáneamente la dirección, la ruta de resolución y parte de las políticas de red. «Si funciona al cambiar» reduce el alcance del problema, pero no puede indicar por sí solo cuál de estos factores fue el causante.
En caso de errores de certificado, tampoco declares el problema resuelto ignorando las advertencias de certificado. Debes verificar la hora del sistema, la cadena de certificados, el dominio de destino y la configuración de red autorizada; en dispositivos corporativos, el administrador debe confirmar la política correspondiente.
¿Qué debes proporcionar al personal de soporte para recibir una respuesta eficaz?
Puedes describir el problema como un registro reproducible: en qué momento, en qué red y navegador, a qué ruta pública accediste, qué operación normal realizaste y qué resultado obtuviste; cuál era el objetivo, método y error de la herramienta de detección.
Si hay un identificador de solicitud o un código de estado de respuesta, inclúyelo. La IP pública solo debe entregarse a través de un canal de soporte confiable cuando sea realmente necesaria para la resolución. Las contraseñas de cuenta, cookies, cabeceras Authorization y URL completas con tokens de acceso no deben pegarse en tickets públicos o capturas de pantalla.
Una conclusión útil debe ser lo suficientemente específica, como “la página de inicio se abre, pero los scripts de origen cruzado no pueden leer el resultado” o “una solicitud desde el punto de salida actual está limitada por frecuencia”. Esto se acerca más a una solución que “la red no funciona” y demuestra mejor la disponibilidad real que una página de detección completamente verde.
Dos casos comparativos de fallos por capas: diferentes puntos de fallo de DNS a TLS
Supón que el mismo dominio se resuelve correctamente en un entorno, pero la conexión TCP falla. Obtener un registro A o AAAA solo indica que se devolvió un registro en ese momento, no que la dirección correspondiente sea alcanzable. El fallo puede ocurrir en el firewall local, las políticas del operador, el puerto de destino cerrado o los dispositivos en la ruta. Si en este punto afirmas directamente que la IP está bloqueada, estás omitiendo evidencia intermedia. Una descripción más precisa sería “la conexión TCP al puerto de la dirección de destino no se estableció desde la red actual”.
Otro caso ilustrativo es que el handshake TLS se complete y luego HTTP devuelva 403, lo que indica que la conexión ha entrado en el procesamiento de la capa de aplicación, pero aún debes verificar si el cliente habilitó la validación de certificados. Solo si la validación está habilitada y es exitosa puedes afirmar que la confianza del certificado y la verificación del nombre de host pasaron; una prueba que omite la verificación no tiene esta prueba. Un 403 generalmente indica que la solicitud fue rechazada, posiblemente por ruta, identidad, permisos o política de seguridad, y no puede probar por sí solo que la cuenta está congelada.
La diferencia entre estos dos casos radica en el nivel de fallo. El fallo TCP ocurre en la fase de conexión de transporte, mientras que el fallo HTTP después de TLS ocurre en la fase de procesamiento de la aplicación. Escribir claramente el nivel evita confundir “conexión inalcanzable” con “solicitud rechazada”. Por ejemplo, si un nodo de detección remoto muestra un fallo TCP, solo significa que la salida de ese nodo no pudo establecer la conexión, no se puede deducir directamente que tu máquina local también falló. Y viceversa.
Primero conserva el error original: tiempo de espera significa que la fase correspondiente no se completó dentro del tiempo especificado; restablecimiento de conexión significa que la conexión fue terminada activamente, pero ambos pueden provenir del extremo de destino, los dispositivos de ruta o el entorno del cliente, y no se puede localizar el firewall solo por la palabra del error. Si ya has recibido un HTTP 403, conserva el método de solicitud, la ruta, la hora y el identificador de solicitud, y pide al proveedor del servicio que verifique las reglas. Solo cuando se aclara la fase de fallo, la comparación posterior tiene un objetivo.
El juicio por capas también afecta las acciones posteriores. En caso de fallo TCP, cambiar de red, cambiar de familia de direcciones o verificar el proxy puede tener sentido; ante un 403 después de TLS, debes reducir los reintentos inútiles y verificar el método y la ruta de la solicitud, o confirmar si se activó una política de seguridad. Usar un resultado único para generalizar el estado de todo el sitio o de toda la cuenta sobreestima el alcance de la evidencia.
Escribe un registro de ticket reproducible: hora, objetivo, punto de observación y fase
Un ticket eficaz no es una captura de pantalla de un error rojo, sino un registro que se pueda reproducir desde un punto de observación. Se recomienda incluir la hora y la zona horaria del incidente, la URL de destino accedida, el navegador o cliente utilizado, el tipo de red del dispositivo y la ubicación de ejecución de la herramienta de detección. El punto de observación es especialmente importante: ¿es el navegador local, un nodo de detección remoto o una solicitud activa desde el servidor? Los fallos desde diferentes puntos de observación tienen significados distintos.
También debes indicar la fase de fallo. Si es posible, distingue entre DNS, TCP, TLS, HTTP y las funciones posteriores al inicio de sesión. El error original debe conservar el texto o el código de estado, por ejemplo, tiempo de espera de conexión, ID de solicitud en una página 403, código de error de certificado. La información sensible debe ser anonimizada: no pegues contraseñas, cookies, cabeceras Authorization o URL completas con tokens de acceso en el ticket. La IP pública solo debe proporcionarse a través de un canal confiable cuando sea realmente necesario.
No afirmes que «todas las regiones tienen tiempo de espera» o que «no se puede acceder en todo el país». Solo conoces el punto de observación que probaste. Puedes escribir «desde la red actual, se produjeron tres tiempos de espera TCP consecutivos desde cierta hora», lo cual es más creíble que «toda la red está caída». Los resultados de detección remota pueden servir como evidencia circunstancial, pero debes anotar su ubicación real de prueba y la hora de la prueba.
Si deseas citar evidencia de red como RDAP, ASN o BGP, puedes consultar la idea de RDAP, ASN, BGP y RPKI: cómo interpretar una consulta de IP: primero usa RDAP para confirmar la titularidad de la dirección y luego usa BGP o datos de enrutamiento para explicar los cambios de ruta. Pero la titularidad no equivale a malicia, ni el cambio de ASN equivale a un fallo. La evidencia debe respaldar la conclusión, no usarse para crear pánico.
Para la resolución de problemas relacionados con listas negras de IP o fenómenos de captcha, IP en una lista negra o CAPTCHA constante: qué hacer ofrece una dirección más específica. En el ticket debes indicar si encontraste un captcha o un rechazo explícito, y si está relacionado con el estado de inicio de sesión. El captcha puede ser solo un control de frecuencia o una advertencia de riesgo, no equivale a una cuenta congelada.
Finalmente, no tomes el umbral de tiempo de espera de una sola herramienta como un estándar universal para toda la plataforma. Diferentes productos de detección tienen diferentes políticas de tiempo de espera, reintentos y concurrencia; el umbral solo se aplica a la prueba de esa herramienta en ese momento. Por lo tanto, en el ticket debes especificar la herramienta utilizada y su configuración. Un registro reproducible permitirá al personal de soporte localizar la fase, en lugar de inferir el problema a partir de la conclusión.
