Tester un port avec Test-NetConnection en PowerShell

Un service ne répond pas : le serveur est-il joignable, le port est-il ouvert, la route est-elle la bonne ? Test-NetConnection répond aux trois questions sans installer d'outil.

Par la rédaction de Pixelabs · 12 octobre 2026

Quand une application ne joint pas son serveur, la première question est simple : la machine répond-elle, et le port attendu accepte-t-il une connexion ? Sous Windows, la cmdlet Test-NetConnection du module NetTCPIP répond à cette question directement dans PowerShell. Selon la documentation Microsoft, elle sait faire un test ping, un test TCP, un traçage de route et un diagnostic de sélection de route.

Elle remplace avantageusement le vieux réflexe telnet serveur port, qui suppose d'installer le client Telnet, et elle donne un résultat exploitable dans un script.

Ce que la cmdlet vérifie

Test-NetConnection regroupe quatre jeux de paramètres. Chacun correspond à un test différent, et l'on ne peut en utiliser qu'un à la fois.

Le paramètre -InformationLevel s'ajoute à tous les jeux. Il accepte deux valeurs : Detailed, qui affiche davantage de propriétés, et Quiet, qui ne renvoie qu'un booléen.

Tester un port TCP

C'est l'usage le plus courant. On indique le nom DNS ou l'adresse IP de la cible avec -ComputerName, et le port avec -Port :

Test-NetConnection -ComputerName srv-web01 -Port 443

Dans le résultat, la propriété à lire est TcpTestSucceeded. Si elle vaut True, une connexion TCP a bien été établie sur ce port. Si elle vaut False, quelque chose bloque entre vous et le service : le service n'écoute pas, un pare-feu filtre, ou le nom ne pointe pas vers la bonne adresse. La ligne RemoteAddress indique l'adresse réellement jointe après la résolution DNS, ce qui permet d'écarter tout de suite une erreur de résolution.

Pour obtenir plus de contexte, ajoutez le niveau de détail :

Test-NetConnection -ComputerName srv-web01 -Port 443 -InformationLevel Detailed

Microsoft montre dans ses exemples que ce mode ajoute notamment les résultats de résolution de nom, l'interface et l'adresse source utilisées, et le prochain saut de la route (NetRoute (NextHop)). Quand une machine a plusieurs cartes réseau, cette ligne montre souvent que la connexion part par la mauvaise.

Les ports nommés

Pour quatre services courants, la cmdlet accepte un nom à la place du numéro, avec -CommonTCPPort :

• HTTP pour un serveur web ;
• RDP pour le Bureau à distance ;
• SMB pour le partage de fichiers ;
• WINRM pour la gestion à distance PowerShell.

Test-NetConnection -ComputerName srv-fic01 -CommonTCPPort SMB

C'est surtout une question de lisibilité dans un script : le nom dit ce que l'on teste. Pour tout autre service, utilisez -Port.

Un simple ping, puis un traceroute

Sans paramètre de port, la cmdlet fait un test ping. Sans même de nom de machine, elle teste un serveur par défaut de Microsoft, ce qui suffit à vérifier rapidement l'accès à Internet.

Test-NetConnection -ComputerName 192.168.10.1

Le résultat se lit dans PingSucceeded et PingReplyDetails (RTT). Attention à l'interprétation : beaucoup de serveurs et de pare-feu filtrent l'ICMP. Un ping qui échoue ne prouve pas qu'une machine est éteinte, et un ping qui réussit ne prouve pas que le service répond. Pour un service, c'est le test TCP qui fait foi.

Pour voir le chemin parcouru, ajoutez -TraceRoute, et limitez au besoin le nombre de sauts avec -Hops :

Test-NetConnection -ComputerName srv-web01 -TraceRoute -Hops 10

Le mode Quiet pour les scripts

Avec -InformationLevel Quiet, la documentation indique que la cmdlet ne renvoie qu'une valeur booléenne. C'est la forme à utiliser dans un script de contrôle ou une tâche planifiée, parce qu'on peut la tester directement :

$cibles = "srv-web01", "srv-sql01", "srv-fic01"
foreach ($c in $cibles) {
    if (Test-NetConnection -ComputerName $c -Port 443 -InformationLevel Quiet) {
        "$c : port 443 joignable"
    } else {
        "$c : port 443 injoignable"
    }
}

Adaptez le port à chaque serveur dans un vrai script, par exemple avec un tableau de paires nom et port. Pour aller plus loin dans ce type d'automatisation, la page sur les scripts PowerShell d'administration rassemble les bonnes pratiques d'écriture.

Diagnostiquer la route

Le jeu NetRouteDiagnostics ne teste pas la connexion elle-même. Il explique quelle route et quelle adresse source Windows choisit pour joindre la cible, et pourquoi.

Test-NetConnection -ComputerName srv-web01 -DiagnoseRouting -InformationLevel Detailed

Les propriétés SelectedNetRoute, RouteSelectionEvents et SourceAddressSelectionEvents détaillent le choix. -ConstrainInterface (un index d'interface) ou -ConstrainSourceAddress forcent une interface ou une adresse source, ce qui permet de vérifier si une autre carte trouverait la cible.

Test-Connection, l'alternative de PowerShell 7

PowerShell 7 propose aussi Test-Connection, qui envoie des requêtes ICMP comme un ping classique. Dans sa version actuelle, elle sait aussi tester un port TCP avec -TcpPort, et renvoie $true si la connexion est établie, $false sinon :

Test-Connection -TargetName srv-web01 -TcpPort 443

La documentation montre qu'avec -Detailed et -Count, elle répète le test et affiche la latence de chaque tentative. C'est pratique pour repérer une connexion instable. Le paramètre -TimeoutSeconds (cinq secondes par défaut, selon Microsoft) règle le délai d'attente.

Quand le test échoue

Un TcpTestSucceeded : False se diagnostique dans l'ordre, du plus proche au plus lointain :

1. Le service écoute-t-il ? Sur le serveur, Get-NetTCPConnection -State Listen liste les ports en écoute.
2. Le pare-feu Windows du serveur autorise-t-il le port ? Une règle entrante manquante est la cause la plus fréquente après une installation.
3. Un pare-feu réseau filtre-t-il ? Testez depuis une machine du même réseau que le serveur, puis depuis le réseau du client.
4. Le nom pointe-t-il vers la bonne adresse ? Comparez RemoteAddress avec l'adresse attendue.

Si le port SMB répond alors que vous l'avez fermé volontairement, vérifiez aussi que le vieux protocole est bien coupé : la page pour désactiver SMBv1 sur Windows Server détaille le contrôle. Et pour connaître l'adresse publique sous laquelle votre poste sort sur Internet, voyez comment afficher son IP publique en PowerShell.

D'autres cmdlets d'administration courantes sont présentées dans la rubrique Windows Server et PowerShell.

Questions fréquentes