Vérifiez les ports utiles, avec des résultats qui disent ce qu’ils prouvent réellement.
Vérifiez uniquement les systèmes publics qui vous appartiennent ou que vous êtes autorisé à tester.
Partez d’une question précise sur votre serveur, choisissez peu de ports et conservez les preuves avec le résultat. Notre vérification vient d’un réseau extérieur, pas de votre appareil.
Illustration, pas un résultat en direct
clocktools.app
80 · 443
Saisissez un domaine ou une adresse IPv4 ou IPv6 publique. La sélection Site web utilise 80 et 443. Les chemins et ports présents dans une URL ne définissent pas les ports testés : utilisez le champ Ports TCP.
Illustration, pas un résultat en direct
Cliquez sur Vérifier les ports ou appuyez sur Entrée. Vous pouvez annuler. Nous échantillonnons une adresse DNS publique et testons au plus 12 ports. Après une annulation ou une réinitialisation, un résultat tardif ne remplace pas votre écran.
Illustration, pas un résultat en direct
443 · Réponse HTTP
HTTP 200
Preuves détaillées
Lisez d’abord l’observation, puis la durée. Les preuves précisent méthode et adresse. Copiez le rapport ou téléchargez-le en PNG, CSV, JSON ou texte. Le partage de configuration ne lance rien automatiquement.
Découvrez l'interface réelle de ClockTools, du choix des ports à la lecture d'un contrôle terminé. Ces captures enregistrées concernent notre propre site. Elles ne représentent ni les résultats de votre hôte ni ceux de votre prochain contrôle.
Vérifiez 80 et 443 sur votre domaine après un changement d’hébergement ou de DNS. Une réponse HTTP peut provenir d’un proxy, même pour 403 ou 502. Notre outil de disponibilité des sites examine la page ; une connexion ne suffit pas à prouver qu’elle fonctionne.
Si SSH doit être accessible publiquement, vérifiez 22 sur votre serveur. Un refus diffère d’un délai dépassé. Examinez l’adresse d’écoute et les listes d’autorisation sans assouplir vos protections pour obtenir du vert.
Vérifiez uniquement les ports que vous utilisez. Une connexion à 3306, 5432 ou 6379 mérite une revue des règles d’accès, pas un verdict automatique de vulnérabilité. Les réseaux privés restent hors périmètre.
Joignez hôte, ports, heure et preuves au rapport. Comparez deux vérifications du même hôte et de la même IP après une modification autorisée. Un changement d’observation donne une piste, sans prouver un lien de cause à effet.
Un port n'est pas une ouverture numérotée dans une machine. Il permet à l'ordinateur de distinguer plusieurs conversations. Un serveur peut proposer différents services à la même adresse IP : le système d'exploitation dirige chaque connexion entrante vers l'application qui l'attend. Le client possède lui aussi son propre point de terminaison. Ces deux extrémités distinguent une connexion des autres échanges simultanés.
La spécification TCP de septembre 1981, RFC 793, décrivait déjà cette relation entre ports, sockets et processus. Les services courants pouvaient utiliser des points de terminaison connus, tandis que d'autres échanges pouvaient les découvrir dynamiquement. Cette idée fait partie de la conception de TCP, bien avant le Web actuel. Elle explique pourquoi un port de destination et un port temporaire côté client jouent des rôles différents, même s'ils se présentent tous deux sous forme de nombres.
Des conventions communes ont rendu ces numéros compréhensibles entre ordinateurs et logiciels. RFC 6335, publié en août 2011, documente les procédures d'enregistrement des noms de service et des numéros de port. Ce registre coordonne les usages ; il n'inspecte pas votre serveur. Quand notre scanner associe le port 22 à SSH, il rappelle une convention. Il ne reconnaît ni le programme réellement à l'écoute ni la qualité de sa protection.
La spécification principale de TCP a été regroupée dans RFC 9293 en août 2022. Ses principes restent utiles derrière un proxy inverse ou un répartiteur de charge. Une connexion peut atteindre le point d'entrée alors que l'application située derrière ne fonctionne pas. Nous souhaitons vous aider à poser la prochaine question pertinente, sans confondre un point de terminaison accessible avec un bilan complet de disponibilité ou de sécurité.
1981
RFC 793 explique comment ports et sockets distinguent les échanges entre applications. Un hôte peut entretenir plusieurs connexions TCP simultanément.
2011
RFC 6335 définit les procédures d'enregistrement et trois plages de numéros de port. Un nom attribué ne certifie ni le logiciel ni sa sécurité.
2022
RFC 9293 remplace RFC 793. L'établissement d'une connexion reste distinct du fonctionnement de l'application et d'un examen de sécurité.
Imaginez un serveur que vous administrez, dont le service SSH doit accepter des connexions autorisées sur TCP 22. Les observations suivantes constituent un exemple fictif de diagnostic, pas des mesures ClockTools ni une invitation à exposer un service privé.
Étape 1 · TCP 22
Un refus explicite indique que la tentative a été rejetée. Sur un système que vous gérez, vérifiez que le service est actif et écoute sur l'adresse prévue. Une règle d'accès peut aussi refuser la connexion. Le résultat seul ne permet pas de déterminer quel réglage doit être examiné.
Étape 2 · TCP 22
Un dépassement de délai ultérieur n'est pas nécessairement un progrès ni une preuve de blocage par un pare-feu. Vérifiez l'adresse publique, le routage et les règles d'accès prévues. Comparez depuis un réseau autorisé et notez tout changement d'IP testée. Modifiez un seul réglage pertinent à la fois.
Étape 3 · TCP 22
Une connexion TCP ne prouve pas qu'une connexion SSH authentifiée réussira. Vérifiez l'identité du serveur, l'authentification et les droits par votre procédure d'administration habituelle. N'incluez aucun identifiant secret dans un rapport partagé. Un accès public n'est pas toujours le résultat souhaité.
Un bon suivi avant et après conserve ensemble l'hôte, l'adresse testée, le port, l'heure et les notes de modification. Notre comparaison signale les observations qui ont changé, sans en établir la cause. Si l'IP ou le réseau de contrôle diffère, vous comparez deux points de vue, pas les étapes d'une expérience contrôlée.
L’IP désigne une extrémité réseau ; le port TCP indique où la connexion doit arriver. Il faut un service à l’écoute, une route opérationnelle et une règle d’accès favorable. Service habituel désigne une convention, pas un logiciel détecté. Même 443 peut servir à autre chose qu’au web.
Le registre des services de l’IANA donne un vocabulaire commun. « Connexion TCP acceptée sur 22 » est une observation ; identifier une version précise de SSH ne l’est pas. Notre outil ne tente aucune authentification, ne lit pas les bannières et ne recherche pas de failles exploitables.
Un réseau doit distinguer plusieurs conversations à une même adresse. La RFC 6335 décrit les ports système 0–1023, les ports utilisateur 1024–49151 et les ports dynamiques ou privés 49152–65535. Notre saisie accepte 1–65535 comme destinations, mais pas 0.
Ces plages concernent l’attribution, pas la sécurité. Un port élevé n’est pas automatiquement privé. Les ports locaux temporaires du navigateur sont aussi différents des ports de destination saisis ici. Notez toujours le transport : TCP 53 et UDP 53 sont deux vérifications distinctes. Nous testons uniquement TCP.
La spécification TCP décrit trois messages : SYN, SYN-ACK et ACK. Une connexion établie est une première étape, pas une validation de l’application. Le service peut encore présenter une erreur de certificat, demander une connexion utilisateur ou avoir un composant défaillant. Nous refermons la connexion de test.
Réponse HTTP signifie qu’un point d’accès web a répondu. 404 reste une réponse, 403 peut refléter une règle d’accès et 502 un problème de passerelle. Aucun de ces codes ne vérifie le port du serveur d’origine. La durée de tentative n’est ni un ping ni un test de votre connexion internet.
Une application qui fonctionne localement peut n’écouter que sur une adresse de bouclage, manquer d’une redirection sur le routeur ou appliquer une liste d’autorisation. Le NAT et le NAT opérateur compliquent aussi les connexions entrantes. Vérifiez l’adresse visible avec Quelle est mon IP ? et votre réseau avec le calculateur de sous-réseau IP.
Un domaine peut renvoyer plusieurs adresses IPv4 et IPv6. Pour TCP, nous en échantillonnons une seule, après validation. Un proxy peut répondre sans dévoiler l’origine. Le guide des états de ports de Nmap traite lui aussi les états comme des observations liées à un test. Un délai dépassé laisse plusieurs explications possibles : conservez les heures de vos comparaisons autorisées.
Notre scanner valide l’hôte public et une liste limitée de ports TCP décimaux. Il échantillonne une adresse DNS sûre et distingue connexion établie, refus explicite, délai dépassé, vérification impossible et réponse HTTP. Les noms de services sont des indications, pas une identification logicielle.
Signalez une observation contestée via notre page de contact avec hôte public, ports, heure et preuves. Précisez la configuration attendue et une comparaison autorisée, sans mots de passe ni détails de réseau privé. Nous examinons les erreurs reproductibles d’interprétation ou d’affichage, sans transformer un état changeant en fait permanent.
Non. Vérifiez d’abord si cet accès public est prévu, puis l’authentification, les mises à jour et les règles d’accès selon votre procédure de sécurité. Notre outil ne détecte pas les versions et ne teste pas les exploits.
Vous pouvez tester l’adresse publique et le port de destination d’un système que vous contrôlez. Le service, la redirection et le pare-feu doivent être correctement configurés. Un délai dépassé ne désigne pas la couche fautive ; les adresses privées ne sont pas testées.
Ce service ne teste pas le port 25. Nous indiquons cette limite au lieu d’annoncer un port SMTP fermé. Les ports 587, 993 et 995 peuvent concerner un client de messagerie, sans remplacer un test de livraison SMTP sur 25.
Non. Nous testons des ports TCP sur une adresse DNS publique échantillonnée. TCP 53 n’est pas un test DNS en UDP. Une connexion ne garantit ni le contenu des réponses DNS, ni la livraison des e-mails, ni tous les serveurs du domaine.
Une restriction ou un échec ambigu ne prouve pas un refus. Nous distinguons le refus explicite, le délai dépassé et la réponse HTTP. Non vérifié signifie que l’état TCP réel reste inconnu.
Les cinq dernières observations terminées sont conservées dans ce navigateur si le stockage est disponible. Effacer l’historique supprime cette liste locale. Le lien contient l’hôte et les ports, sans lancer de test ; les rapports contiennent l’observation et ses limites.