IP & Network

Vérificateur de ports TCP

Teste la disponibilité des ports TCP d'un hôte, un ou en lot.

Host or IP, ports Public addresses only. Up to 100 ports.

Try example.com cloudflare.com 1.1.1.1

Common ports web (80, 443, 8080, 8443) mail (25, 465, 587, 993, 995, 110, 143) remote (22, 23, 3389, 5900) database (3306, 5432, 6379, 27017, 1433)

À propos de cet outil

Une vérification de port est la question la plus simple "le service écoute-t-il réellement" que vous pouvez poser à l'internet public. Notre vérificateur de port ouvre une véritable connexion TCP depuis notre serveur de Francfort vers l'hôte et les ports que vous spécifiez, avec un délai d'attente de 3 secondes par port. Si la poignée de main se termine, le port est ouvert ; si l'hôte refuse activement, le port est fermé ; s'il y a silence, le port est filtré — généralement un pare-feu qui rejette le paquet SYN sans réponse.

Vous pouvez sonder jusqu'à 100 ports par exécution — un seul port (80), une liste séparée par des virgules (80,443,22), ou une petite plage (20-25). Chaque résultat affiche le numéro de port, notre verdict, le temps qu'a pris l'appel, et une supposition de nom de service basée sur les attributions de style IANA (22 → ssh, 5432 → postgresql, etc.). Le verdict se met à jour ligne par ligne au fur et à mesure des appels — pas besoin d'attendre le port le plus lent pour connaître les rapides.

Ce que vous pouvez en faire

Vérifier un déploiement sans se connecter en SSH. Si votre service devrait être sur le port 5432 et que le vérificateur dit filtré, l'écouteur ne s'est jamais lié ou le pare-feu est sur le chemin — corrections différentes, mais la vérification de port vous dit laquelle.
Auditer l'exposition externe. Exécutez le preset des ports populaires contre votre serveur. Tout ce qui est ouvert que vous ne reconnaissez pas est votre devoir. fermé et filtré sont tous deux acceptables pour l'internet public.
Diagnostiquer les arguments "le pare-feu doit être faux". filtré sur chaque port depuis nous — mais joignable depuis votre ordinateur portable — est une preuve concrète que le pare-feu de l'hôte a une liste blanche d'IP source, pas un problème de port.

Lecture du résultat

"Ouvert" est sans ambiguïté : un écouteur TCP nous a acceptés. "Fermé" signifie que l'hôte est vivant et que le noyau a envoyé RST ; le port n'est pas utilisé. "Filtré" est le cas intéressant : un pare-feu a rejeté notre paquet sans réponse, la route est cassée, ou l'écouteur est surchargé. La colonne temps-d'appel aide à désambiguïser — ouvert et fermé répondent en millisecondes à un chiffre ; filtré reste toujours au délai d'attente complet de 3 secondes. De nombreux services basés sur UDP (DNS sur 53, SNMP sur 161) acceptent aussi TCP, mais sinon, attendez-vous à filtré — c'est normal, pas un bug.

Questions fréquentes

Quelle est la différence entre "fermé" et "filtré" ?

Fermé signifie que le noyau de l'hôte a répondu activement avec un RST TCP — l'hôte est joignable, aucun écouteur n'est sur ce port. Filtré signifie que nous n'avons rien reçu en retour dans les 3 secondes — généralement un pare-feu rejetant notre SYN, parfois un hôte surchargé. Les deux sont courants ; seul "ouvert" garantit qu'un véritable service écoute.

Pourquoi tout est-il "filtré" depuis votre serveur mais fonctionne pour moi ?

Une liste blanche d'IP source sur le pare-feu de l'hôte. Le service va bien et est joignable depuis l'IP de votre ordinateur portable, mais l'IP de notre serveur de Francfort n'est pas sur la liste d'autorisation. C'est le résultat attendu pour les hôtes de saut, les panneaux d'administration internes et tout service qui ne devrait pas être exposé à l'internet public — exactement ce que vous configureriez délibérément.

Puis-je scanner des IP privées ou mon propre LAN ?

Non. Les plages privées RFC 1918, loopback, link-local (169.254/16), CGN (100.64/10) et les points de terminaison de métadonnées cloud sont refusés — même politique SSRF que le reste de nos outils. Pour scanner votre LAN, utilisez nmap ou un outil local similaire. Les services publics ne devraient sonder que l'internet public.

Combien de ports puis-je vérifier en une seule exécution ?

Jusqu'à 100 ports uniques par exécution. Une plage comme 1-100 compte pour 100 ; les listes sont dédupliquées avant le comptage. Les entrées au-dessus de la limite renvoient un 422 — divisez votre scan en lots. Nous avons choisi 100 car le pire cas (tous les ports filtrés) prend 100 × 3 s = 5 minutes ; en autoriser davantage immobiliserait le worker au-delà d'un temps de réponse raisonnable.

Pourquoi le nom "service" est-il une supposition ?

Les numéros de port TCP n'identifient pas réellement les services — n'importe qui peut exécuter n'importe quoi sur n'importe quel port. Nous mappons les attributions IANA bien connues (22 → ssh, 443 → https) afin que le résultat soit lisible pour le cas courant, mais si quelqu'un exécute PostgreSQL sur le port 80, il indiquera toujours "http". Pour savoir ce qui parle réellement sur un port, notre outil Server Check récupère la bannière réelle de la poignée de main.