Boîte à Outils Informatique
Guide

Comment tester un port TCP avec PowerShell

Test-NetConnection permet de vérifier rapidement si un poste peut joindre un serveur sur un port TCP précis, sans installer d’outil supplémentaire.

ThématiqueRéseau informatique →
⌚ Environ 3 min de lecture
Voir mes favoris
Windows / Réseau Débutant 5 min

Test-NetConnection permet de vérifier rapidement si un poste peut joindre un serveur sur un port TCP précis, sans installer d’outil supplémentaire.

Avant de commencer : adaptez toujours les commandes et manipulations à votre environnement. Sur un système de production, prévoyez une sauvegarde ou un retour arrière lorsque l’action peut modifier la configuration.

Étapes à suivre

  1. 1

    Ouvrir PowerShell

    Lancez PowerShell sur le poste depuis lequel vous souhaitez tester le flux.

  2. 2

    Choisir la cible

    Utilisez le FQDN ou l’adresse IP réellement utilisée par l’application.

  3. 3

    Tester le port

    Exécutez Test-NetConnection avec le port concerné et relevez TcpTestSucceeded.

  4. 4

    Comparer le DNS

    Si le FQDN échoue mais l’IP fonctionne, contrôlez la résolution DNS.

  5. 5

    Documenter le résultat

    Conservez l’heure, la source, la destination, le port et le résultat pour le diagnostic firewall

Commandes utiles

Test-NetConnection serveur.exemple.local -Port 443
Test-NetConnection 192.168.1.10 -Port 445

À retenir

  • Un port fermé et un timeout ne désignent pas forcément la même cause.
  • Le test confirme la connectivité TCP, pas le bon fonctionnement de l’application derrière le port.
  • Testez depuis le vrai réseau utilisateur lorsque le problème dépend d’un VLAN ou VPN.
← Tous les guides
Complément technique

Port TCP : distinguer écoute locale et accessibilité réseau

Repères techniques

  • Un service en LISTENING prouve seulement qu’un processus écoute localement ; cela ne prouve pas que le port est accessible depuis un autre réseau.
  • Test-NetConnection teste le chemin jusqu’à l’hôte et le port ; le résultat doit être interprété avec DNS, routage et firewall.
  • 0.0.0.0:port écoute sur toutes les interfaces IPv4, alors que 127.0.0.1:port reste local à la machine.

Lecture croisée

Comparer le socket local et un test depuis un poste situé sur le chemin réellement utilisé.

Get-NetTCPConnection -State Listen
Test-NetConnection serveur -Port 443

Pièges spécifiques

  • Un ping réussi ne valide pas un port TCP.
  • Un échec distant peut venir du firewall intermédiaire alors que le service écoute correctement.

Comment valider

  • Le PID/processus attendu écoute sur la bonne adresse locale.
  • Le port est testé depuis au moins une source représentative et le résultat est cohérent avec les règles firewall.

Preuves et vérifications

Un service en LISTENING prouve seulement qu’un processus écoute localement ; cela ne prouve pas que le port est accessible depuis un autre réseau. Test-NetConnection teste le chemin jusqu’à l’hôte et le port ; le résultat doit être interprété avec DNS, routage et firewall.

Contrôle de résultat

Le PID/processus attendu écoute sur la bonne adresse locale. Le port est testé depuis au moins une source représentative et le résultat est cohérent avec les règles firewall.

Point d’attention

Un ping réussi ne valide pas un port TCP. 0.0.0.0:port écoute sur toutes les interfaces IPv4, alors que 127.0.0.1:port reste local à la machine.

Concepts liés

Référence primaire : Microsoft Learn — Test-NetConnection.

♡ 0