Cómo configurar una comprobación de puerto TCP (guía completa)

Url / Domain / IP

Introduce el objetivo como host:puerto, por ejemplo example.com:22 para SSH o example.com:465 para SMTPS: el puerto forma parte de la dirección, no es un campo aparte. También puedes darle al monitor un nombre corto, que es lo que aparece en las alertas, los informes y cualquier widget de estado.

Configuración principal

No hay captura de pantalla de esta sección específica para el tipo de comprobación de puerto, pero usa el mismo grupo de Configuración principal que cualquier otro tipo de comprobación, así que cada control de abajo es exactamente lo que verás en el formulario:

• Monitorización activada: pausa o reanuda la comprobación sin eliminarla.
• Calendario por intervalo / Calendario por cron: ejecuta con un intervalo fijo (el deslizador va de 1 minuto hasta 24 horas) o con una expresión cron para un patrón que la escala de intervalo no puede expresar.
• Etiquetas: etiquetas separadas por comas para filtrar y buscar en tu lista de monitores. Puramente organizativas: no afectan a la comprobación en sí.
• Registro completo: guarda cada resultado individual de la comprobación en lugar de agrupar los resultados idénticos repetidos.
• Abrir estadísticas: hace compartible la página de estadísticas y registro de este monitor con personas que no han iniciado sesión en tu cuenta.
• Monitores adjuntos - DNSBL: ejecuta una comprobación de lista negra de DNS contra el mismo dominio con su propio calendario de 12 horas, independiente del intervalo de la comprobación de puerto. Un mal estado detectado avisa según las suscripciones Down/Repeat de Suscripciones de alerta.
• Monitores adjuntos - Web Risk: ejecuta una comprobación de malware/phishing de Google Web Risk contra el dominio, también con su propio calendario. Sujeto al plan.

Configuración de la petición

• Connect over TLS/SSL: desactivado por defecto, lo que significa que la comprobación marca un socket TCP plano. Actívalo para envolver la conexión en un saludo TLS antes de leer la respuesta: la opción correcta para servicios de estilo HTTPS, SMTPS, o un listener de base de datos que exija TLS. Activarlo también revela un subgrupo TLS Handshake bajo Validación de respuesta (abajo) con políticas de validación de certificado. La nota en pantalla de este interruptor menciona "un servicio TCP (o UDP) plano", pero no hay ningún selector de protocolo en ningún sitio de este formulario: toda comprobación de puerto marca TCP. Si necesitas monitorizar un servicio UDP, este tipo de comprobación no expone esa opción por ahora.
• DNS Server Selection: el mismo desplegable usado en otros tipos de comprobación. Servidores DNS por defecto en las ubicaciones resuelve el host a través de los propios servidores DNS públicos de cada ubicación de monitorización, siguiendo la normativa local. Public DNS resuelve a través de un pool de DNS público, con una lista opcional de resolutores excluidos. Custom te deja indicar tus propias IP de servidor DNS, una por fila. En la cuenta de la que viene esta captura, Public y Custom están ambos bloqueados detrás de un aviso de mejora de plan, que es un límite de plan y no una función que falte.

Validación de respuesta

Por defecto una comprobación tiene éxito cuando se completa la conexión, y, cuando TLS/SSL está activado, cuando también se completa el saludo. Los controles de aquí te dejan exigir más que eso:

• Response Pattern: una expresión regular opcional que debe coincidir con la respuesta. Cuando se fija, la comprobación lee hasta 1 MB de la respuesta TCP (o TLS, cuando está activado) y falla cuando el patrón no coincide; déjalo vacío para juzgar solo la conexión. (La documentación antigua llamaba a esto "patrón de búsqueda de respuesta TCP"; la interfaz actual lo etiqueta como Response Pattern.) Como solo se lee el primer 1 MB, pon el texto que buscas cerca del principio de lo que envía el servicio; una línea de banner o de bienvenida funciona bien; el contenido que el servicio envíe más tarde en una respuesta larga no se verá.
• TLS Handshake (solo visible cuando Connect over TLS/SSL está activado): cuatro interruptores independientes que juzgan el propio saludo. Require valid SSL certificate chain hace fallar la comprobación ante un certificado caducado, autofirmado, con el nombre equivocado o mal encadenado. Require strong TLS protocol (1.2 or higher) hace fallar a un servidor que solo ofrece TLS 1.0/1.1 o SSL. Block weak ciphers (128-bit or lower) hace fallar la comprobación cuando el conjunto de cifrado negociado es de 128 bits o más débil. Check SSL certificate revocation hace una consulta CRL/OCSP en línea durante el saludo y falla ante un certificado revocado; es un derecho de plan aparte de los otros tres.
• Expected IPs Validation: actívalo para exigir además que el DNS resuelva tu host a una de una lista de direcciones IP que especifiques, una por fila. Si el host empieza a resolver a otro sitio (secuestro de DNS, un registro obsoleto, una migración que olvidaste actualizar aquí), la comprobación falla aunque la nueva dirección siga respondiendo.

Suscripciones de alerta

• Suscribir a todos los contactos a eventos Up/Down: suscribe a todos los contactos de tu cuenta a las alertas Up y Down de una sola vez.
• Chips Down / Up / Repeat por contacto: Down se dispara en una transición a un estado fallido, Up se dispara en la recuperación, y Repeat reenvía la notificación Down con un calendario mientras el monitor siga en Down.
• Buscar contactos: filtra la lista por nombre o dirección.

Suscripciones de informes

• Suscribir a todos los contactos a informes semanales/mensuales: suscribe a todos los contactos a ambas cadencias a la vez.
• Chips Daily / Weekly / Monthly por contacto: elige qué correo de resumen de uptime periódico recibe cada contacto, aparte de las alertas en tiempo real de arriba.

Ubicaciones de monitorización

• Árbol de ubicaciones: elige qué ubicaciones de monitorización ejecutan esta comprobación, por continente, país o todo el mundo; "Copiar ubicaciones de otra tarea" clona el conjunto de un monitor existente.
• Estrategia de reintento: cómo se confirma un cambio de estado. Por defecto es una votación por mayoría entre las ubicaciones de reintento; las alternativas son un número concreto que confirme Down (deslizador de 1 a 7, según el tamaño del conjunto de reintento), ningún reintento en absoluto, acuerdo total entre todas las ubicaciones de reintento, o acuerdo total para Down mientras que Up solo necesita mayoría.
• Si las ubicaciones seleccionadas no están disponibles: "Solo ubicaciones seleccionadas" (por defecto) espera a que vuelva una ubicación elegida; "Ubicaciones más cercanas" vuelve a ejecutar desde las disponibles más próximas; "Cualquier ubicación" recurre a cualquier sitio disponible en el mundo.

Ejemplo resuelto

Monitorizar un relé de correo SMTPS en el puerto 465: pon Url / Domain / IP a mail.example.com:465, activa Connect over TLS/SSL, y activa Require valid SSL certificate chain más Require strong TLS protocol bajo TLS Handshake para que un certificado que caduca o se degrada te avise antes de que los clientes noten correo rebotado. Deja Response Pattern vacío a menos que el servicio envíe un banner reconocible que quieras confirmar. Elige tres o cuatro ubicaciones de monitorización repartidas entre regiones, mantén la estrategia de reintento por mayoría por defecto, suscribe a tu contacto de operaciones a Down y Up con Repeat activado, y añade una suscripción de informe semanal para un resumen periódico de uptime.

Solución de problemas

• Sin opción UDP: a pesar de que el texto de ayuda de Connect over TLS/SSL menciona UDP, este formulario siempre abre una conexión TCP. Si tu servicio objetivo es solo UDP, una comprobación de puerto no es hoy la herramienta adecuada.
• El puerto es accesible pero la comprobación sigue fallando con TLS activado: revisa los interruptores de TLS Handshake uno por uno. Un certificado técnicamente válido pero autofirmado, o un servidor que todavía ofrece TLS 1.0/1.1, hará fallar Require valid SSL certificate chain o Require strong TLS protocol respectivamente aunque una conexión simple tuviera éxito.
• Response Pattern nunca coincide: recuerda que solo se lee el primer 1 MB de la respuesta. Un patrón que solo aparece en lo profundo de una respuesta larga, o un servicio que envía una carga grande antes del texto que buscas, nunca coincidirá; mantén el patrón en algo que el servicio envíe pronto.
• Puerto bloqueado en el firewall, no en el servicio: una comprobación que falla aunque el servicio funcione bien en local suele ser una regla de grupo de seguridad o de firewall que bloquea ese puerto concreto desde las ubicaciones de monitorización de HostTracker, no un problema del servicio; confirma que el puerto está abierto al tráfico externo, no solo que el proceso se está ejecutando.
• Expected IPs se queda desactualizado tras una migración: si usas Expected IPs Validation y luego mueves el servicio a un host o una IP nueva, actualiza la lista; si no, tendrás falsos Down aunque el servicio sea accesible en su nueva dirección.

Relacionado

• Monitorización de disponibilidad distribuida: la página de producto que cubre las comprobaciones de puerto TCP.
• Comprobación de puerto gratuita: prueba un par host:puerto una vez, al instante, sin crear un monitor.
• Comprobación de ping: guía completa de configuración: la comprobación de accesibilidad más simple cuando no necesitas probar un puerto o servicio concreto.
• Modo de aserciones: referencia completa de validación de respuesta: el lenguaje de reglas de validación de respuesta usado en otros tipos de comprobación.
• Cómo comprobar si un puerto está abierto: la versión puntual de esta comprobación, más los comandos nc y nmap que hay detrás.
• Todas las guías de monitorización: la guía de configuración de cada otro tipo de comprobación.