Comprueba los puertos que importan y entiende qué demuestra cada resultado.
Comprueba solo sistemas públicos que sean tuyos o para los que tengas permiso.
Parte de una pregunta concreta sobre tu servidor, selecciona pocos puertos y conserva las pruebas con el resultado. Comprobamos desde una red externa, no desde tu dispositivo.
Ejemplo ilustrativo, no un resultado en directo
clocktools.app
80 · 443
Introduce un dominio o una IPv4 o IPv6 pública. La selección Sitio web usa 80 y 443. Las rutas y los puertos de una URL no determinan qué se prueba: utiliza el campo Puertos TCP.
Ejemplo ilustrativo, no un resultado en directo
Pulsa Comprobar puertos o Intro. Puedes cancelar. Seleccionamos una dirección DNS pública y probamos hasta 12 puertos. Cancelar o restablecer impide que un resultado tardío sustituya la pantalla.
Ejemplo ilustrativo, no un resultado en directo
443 · Respuesta HTTP
HTTP 200
Pruebas detalladas
Lee la observación antes que la duración. Las pruebas detallan método y dirección. Copia el informe o descárgalo en PNG, CSV, JSON o texto. Compartir la configuración no inicia otro escaneo automáticamente.
Así es la interfaz real de ClockTools, desde la selección de puertos hasta un análisis terminado. Estas capturas guardadas muestran nuestro propio sitio. No son resultados de tu equipo ni una predicción de lo que mostrará tu próximo análisis.
Comprueba 80 y 443 de tu dominio después de cambiar alojamiento o DNS. Una respuesta HTTP puede venir de un proxy, incluso con 403 o 502. Nuestro comprobador de disponibilidad web revisa la página: una conexión no garantiza que funcione.
Si SSH debe estar accesible públicamente, comprueba 22 en tu servidor. Un rechazo no equivale a un tiempo agotado. Revisa la dirección de escucha y la lista de permitidos; no reduzcas la protección solo para conseguir un resultado verde.
Comprueba solo los puertos que utilizas. Una conexión a 3306, 5432 o 6379 merece revisar las reglas de acceso, no declarar una vulnerabilidad automáticamente. Las redes privadas quedan fuera del alcance.
Incluye host, puertos, hora y pruebas. Compara comprobaciones del mismo host y de la misma IP después de un cambio autorizado. Una observación distinta aporta una pista, pero no demuestra causalidad.
Un puerto no es un agujero numerado en un ordenador. Es una forma de distinguir conversaciones. Un servidor puede ofrecer varios servicios en una misma dirección IP porque el sistema operativo dirige cada conexión entrante a la aplicación que la espera. El cliente también tiene su propio extremo de conexión. Juntos, ambos extremos permiten distinguir una conexión de otras conversaciones simultáneas.
La especificación de TCP de septiembre de 1981, RFC 793, ya describía esta relación entre puertos, sockets y procesos. Los servicios habituales podían usar extremos conocidos, mientras que otros intercambios podían descubrirlos de forma dinámica. Era parte del diseño de TCP, no una invención de la web actual. Por eso un puerto de destino y un puerto temporal del cliente cumplen funciones diferentes, aunque ambos aparezcan como números.
Las convenciones compartidas hicieron útiles esos números entre equipos y programas distintos. RFC 6335, publicado en agosto de 2011, documentó los procedimientos para registrar nombres de servicio y números de puerto. El registro coordina usos; no inspecciona tu servidor. Cuando nuestro escáner asocia el puerto 22 con SSH, ofrece una referencia habitual. No identifica el programa que realmente está escuchando ni certifica su protección.
La especificación principal de TCP se consolidó en RFC 9293 en agosto de 2022. Sus fundamentos siguen siendo importantes detrás de proxies inversos y balanceadores de carga. Una conexión puede alcanzar la entrada de un servicio aunque la aplicación situada detrás no esté disponible. Queremos ayudarte a plantear la siguiente pregunta útil, sin confundir un extremo accesible con una evaluación completa de funcionamiento o seguridad.
1981
RFC 793 describe cómo los puertos y los sockets distinguen las conversaciones entre aplicaciones. Un equipo puede mantener varias conexiones TCP simultáneas.
2011
RFC 6335 establece los procedimientos de registro y tres rangos de puertos. Un nombre asignado no certifica el software ni su seguridad.
2022
RFC 9293 sustituye a RFC 793. Establecer una conexión sigue siendo distinto de comprobar una aplicación o revisar su seguridad.
Imagina que administras un servidor cuyo servicio SSH debe aceptar conexiones autorizadas por TCP 22. Las observaciones siguientes forman un ejemplo ficticio de diagnóstico: no son mediciones de ClockTools ni una indicación para exponer un servicio privado.
Paso 1 · TCP 22
Un rechazo explícito indica que se rechazó el intento. En un sistema que administras, comprueba si el servicio está activo y escucha en la dirección prevista. Una regla de acceso también puede rechazar conexiones. El resultado por sí solo no revela qué ajuste debes revisar.
Paso 2 · TCP 22
Que un intento posterior agote el tiempo no implica una mejora ni demuestra un bloqueo del cortafuegos. Revisa la dirección pública, las rutas y la política de acceso prevista. Compara desde una red autorizada y anota si cambia la IP comprobada. Modifica un solo ajuste relevante cada vez.
Paso 3 · TCP 22
Una conexión TCP permite concluir menos que un inicio de sesión SSH correcto. Verifica la identidad del servidor, la autenticación y los permisos mediante tu procedimiento habitual de administración. No incluyas credenciales en informes compartidos. El acceso público no siempre es el resultado deseado.
Un registro útil del antes y el después conserva el host, la dirección comprobada, el puerto, la hora y las notas del cambio. Nuestra comparación destaca observaciones diferentes, pero no establece su causa. Si cambia la IP o la red de comprobación, son puntos de vista distintos, no un experimento controlado.
La IP identifica un extremo y el puerto TCP indica dónde debe llegar la conexión. Se necesita un servicio a la escucha, una ruta operativa y permiso de acceso. Servicio habitual describe una convención, no software detectado. Incluso 443 puede utilizarse para algo distinto de la web.
El registro de servicios de IANA proporciona un vocabulario común. “Se aceptó una conexión TCP en 22” es una observación; una versión concreta de SSH no se ha identificado. No intentamos iniciar sesión, leer banners ni explotar vulnerabilidades.
Las redes necesitan distinguir conversaciones en una misma dirección. RFC 6335 define puertos de sistema 0–1023, puertos de usuario 1024–49151 y puertos dinámicos o privados 49152–65535. Aquí aceptamos destinos del 1 al 65535, pero no el 0.
Son intervalos de asignación, no niveles de seguridad. Un puerto alto no es automáticamente privado. Los puertos locales temporales del navegador también son distintos de los destinos que introduces. Anota siempre el transporte: TCP 53 y UDP 53 son comprobaciones diferentes. Solo probamos TCP.
La especificación TCP describe tres mensajes: SYN, SYN-ACK y ACK. Establecer la conexión es un primer paso, no una prueba de funcionamiento de la aplicación. Todavía puede haber problemas de certificado, autenticación o componentes internos. Cerramos la conexión de prueba sin usar la aplicación.
Respuesta HTTP significa que un extremo web respondió. 404 sigue siendo una respuesta, 403 puede ser una regla de acceso y 502 un error de pasarela. Ninguno verifica el puerto del servidor de origen. La duración no es un ping ni una medición de tu conexión doméstica.
Una aplicación local puede escuchar solo en la interfaz de bucle local, carecer de una redirección en el router o aplicar una lista de permitidos. NAT y NAT de operador complican las conexiones entrantes. Revisa la dirección visible con Cuál es mi IP y la red que administras con nuestra calculadora de subredes IP.
Un dominio puede devolver varias IPv4 e IPv6. Seleccionamos una dirección pública validada para TCP, no todos los servidores. Un proxy puede responder sin revelar el origen. La guía de estados de puertos de Nmap también trata los estados como observaciones de una prueba concreta. Un tiempo agotado deja varias explicaciones abiertas; conserva las horas de las comparaciones autorizadas.
Nuestro escáner valida hosts públicos y una lista limitada de puertos TCP decimales. Selecciona una dirección DNS segura y distingue conexión, rechazo explícito, tiempo agotado, verificación no disponible y respuesta HTTP. Los servicios habituales son orientaciones, no identificación de software.
Comunica una observación discutida desde nuestra página de contacto con host público, puertos, hora y pruebas. Incluye la configuración esperada y una comparación autorizada, nunca contraseñas ni detalles de redes privadas. Revisamos errores reproducibles de clasificación o presentación; no convertimos condiciones cambiantes en hechos permanentes.
No. Comprueba si ese acceso público es intencionado y revisa autenticación, actualizaciones y reglas de acceso con tu proceso de seguridad habitual. Este escáner no identifica versiones ni prueba exploits.
Puedes probar la dirección pública y el puerto de un sistema que controlas. Servicio, redirección y cortafuegos deben permitir la conexión. Un tiempo agotado no identifica la capa que falla; no comprobamos direcciones privadas.
Este servicio no prueba el puerto 25. Indicamos esa limitación en vez de declararlo cerrado. Los puertos 587, 993 y 995 pueden servir para clientes de correo, pero no sustituyen una prueba de entrega SMTP en 25.
No. Probamos puertos TCP seleccionados en una dirección DNS pública. TCP 53 no es una prueba DNS por UDP. Una conexión no garantiza respuestas DNS correctas, entrega de correo ni todos los servidores del dominio.
Una restricción o un fallo ambiguo no demuestra un rechazo. Distinguimos rechazo explícito, tiempo agotado y respuesta HTTP. No verificado significa que el estado TCP real es desconocido.
Se guardan localmente hasta cinco observaciones terminadas si el almacenamiento está disponible. Borrar historial elimina esa lista. El enlace contiene host y puertos y no inicia la prueba; los informes incluyen la observación y sus límites.