Port 443 : à quoi il sert et comment vérifier qu’il est ouvert

Le port 443 correspond au trafic web chiffré en HTTPS. Quand un site charge en https://, c’est généralement ce port https qui transporte les données entre le navigateur et le serveur. Dans ce guide, vous allez voir comment verifier port 443 ouvert, distinguer un blocage réseau d’un problème de pare-feu, et comprendre la différence entre port 80 et 443 sans partir dans un cours complet sur TLS.

Port 443, réponse rapide et différence avec le port 80

Le port 443 est celui du trafic web chiffré en HTTPS.

Le port 80 est celui du trafic HTTP en clair.

Pour la plupart des usages web, retenir port 80 et 443 suffit : 80 pour les redirections ou le HTTP, 443 pour la connexion sécurisée.

Concrètement, si votre site doit servir des pages en HTTPS, le service web doit écouter sur le port 443, le pare-feu doit l’autoriser et, si vous publiez depuis un réseau privé, la box ou le routeur doit rediriger ce port vers le bon serveur.

Cette logique s’inscrit dans les bases des Réseaux, où l’on sépare toujours le service applicatif, le filtrage et le routage.

À quoi sert le port 443 en pratique

Le port https sert à transporter du trafic HTTP chiffré via TLS. C’est le port utilisé par défaut par les navigateurs pour les sites en https://. Quand vous ouvrez https://example.com, le client tente une connexion TCP sur le port 443 de l’hôte distant.

Le chiffrement ne dépend pas du numéro de port à lui seul. Un service peut écouter sur 443 sans être correctement configuré en TLS, ou présenter un certificat invalide. Pour cette partie, il faut distinguer l’ouverture réseau du service et la validité du certificat SSL.

À ne pas confondre non plus avec le fonctionnement du transport réseau. Une connexion HTTPS passe habituellement par TCP, d’où l’intérêt de comprendre le fonctionnement du protocole TCP/IP lorsque le diagnostic devient plus technique.

Ce qu’il faut vérifier avant de tester un port

Quand on cherche à tester un port, trois niveaux différents sont souvent mélangés :

• Le service écoute-t-il sur le serveur ? Par exemple Nginx, Apache, IIS ou un reverse proxy.
• Le pare-feu autorise-t-il le trafic entrant ? Pare-feu local, pare-feu cloud, groupe de sécurité, ACL.
• Le routeur ou la box redirige-t-il le port ? Cas fréquent si le serveur est derrière une NAT privée.

Un même port 443 peut donc sembler fermé pour trois raisons différentes :

• le serveur n’écoute sur rien,
• le pare-feu bloque les connexions entrantes,
• la redirection NAT n’envoie pas le trafic vers la bonne machine.

Si le domaine pointe vers la mauvaise IP, vous pouvez aussi croire à un problème de port alors que c’est un souci DNS. Dans ce cas, il faut vérifier la résolution DNS avec nslookup. Ce type de confusion fait partie des erreurs IP et DNS fréquentes lors de la mise en ligne d’un site.

Comment vérifier si le port 443 est ouvert sur le serveur

La première étape consiste à contrôler si le service écoute localement. Cela répond à la question : le système a-t-il bien un processus en écoute sur 443 ?

Sur Linux

Commande avec ss :

ss -ltnp | grep :443

Si le port est ouvert en écoute, la sortie ressemble à :

LISTEN 0 511 0.0.0.0:443 0.0.0.0:* users:(("nginx",pid=1234,fd=6))

Ou à :

LISTEN 0 511 [::]:443 [::]:* users:(("apache2",pid=987,fd=4))

Si rien n’écoute sur 443, la commande n’affiche aucune ligne.

Alternative avec netstat si l’outil est installé :

netstat -ltnp | grep :443

Si le service écoute, vous verrez une ligne en LISTEN. Sinon, aucune ligne ne correspondra au filtre. Le principe est le même que sur la page dédiée à netstat.

Sur Windows

Commande dans PowerShell ou l’invite de commandes :

netstat -ano | findstr :443

Quand le port est ouvert en écoute, vous obtenez par exemple :

TCP 0.0.0.0:443 0.0.0.0:0 LISTENING 4321

Le dernier nombre est le PID du processus. S’il n’y a aucune sortie, aucun service n’écoute sur 443.

Pour relier le PID au programme :

tasklist /FI "PID eq 4321"

La commande affiche le nom du processus, par exemple :

nginx.exe 4321 Services 0 12 345 K

Sur macOS

Commande avec lsof :

sudo lsof -nP -iTCP:443 -sTCP:LISTEN

Si le port est ouvert, la sortie peut ressembler à :

nginx 615 root 6u IPv4 0x123456789abc 0t0 TCP *:443 (LISTEN)

Si le port n’est pas ouvert, aucune ligne n’apparaît.

Comment tester le port 443 depuis un autre poste

Une écoute locale ne prouve pas que le port est accessible depuis l’extérieur. Il faut alors tester la connectivité réseau depuis une autre machine que le serveur, sur un hôte que vous administrez.

Avec PowerShell sous Windows

Test-NetConnection votre-domaine.tld -Port 443

Si le port répond, PowerShell affiche notamment :

TcpTestSucceeded : True

Si le port est fermé, filtré ou inaccessible, la sortie affiche :

TcpTestSucceeded : False

La commande donne aussi l’adresse IP ciblée, ce qui aide à confirmer que le domaine pointe vers le bon hôte.

Avec nc sur Linux et macOS

nc -vz votre-domaine.tld 443

Quand le port est ouvert :

Connection to votre-domaine.tld 443 port [tcp/https] succeeded!

Quand il est fermé ou bloqué, vous pouvez voir :

nc: connect to votre-domaine.tld port 443 (tcp) failed: Connection refused

Ou, selon le cas :

nc: connect to votre-domaine.tld port 443 (tcp) failed: Operation timed out

Connection refused indique souvent qu’aucun service n’écoute à cette adresse. timed out évoque plus souvent un filtrage ou un problème réseau.

Avec curl pour vérifier la couche HTTPS

curl -I https://votre-domaine.tld

Si le port 443 répond et que le serveur web fonctionne, la commande affiche des en-têtes HTTP, par exemple :

HTTP/1.1 200 OK

server: nginx

Si la connexion échoue, vous verrez un message d’erreur, par exemple :

curl: (7) Failed to connect to votre-domaine.tld port 443 after 0 ms: Connection refused

Ou un problème de certificat si le service répond mais que la configuration TLS n’est pas correcte. Pour l’utilisateur final, cela change aussi la perception d’une connexion HTTPS fiable.

Comment savoir si le blocage vient du pare-feu ou de la redirection

Si le service écoute localement mais que le test distant échoue, cherchez ensuite du côté du filtrage ou de la NAT.

Pare-feu local ou cloud

• Sur Linux, vérifiez les règles ufw, firewalld ou iptables/nftables.
• Sur Windows Server, contrôlez le Pare-feu Windows avec fonctions avancées de sécurité.
• Sur un VPS ou un cloud public, contrôlez aussi le groupe de sécurité ou la règle réseau du fournisseur.

Exemple avec UFW :

sudo ufw status

Si le port est autorisé, une ligne comme celle-ci apparaît :

443/tcp ALLOW Anywhere

Si aucune règle ne l’autorise, 443 n’apparaît pas, ou une règle de refus peut être visible.

Redirection de port sur box ou routeur

Si le serveur a une adresse privée, par exemple 192.168.1.10 ou 10.0.0.5, la box doit rediriger le trafic entrant sur 443 vers cette machine. Sinon, le service peut être parfaitement ouvert localement sans être joignable depuis Internet.

Dans ce cas, le diagnostic porte sur la NAT ou le port-forwarding, pas sur le serveur web lui-même. Vérifiez aussi que l’IP publique visée est la bonne, point à rapprocher de la page adresse IP.

Tableau des ports courants voisins

Voici un rappel des ports courants souvent comparés au 443 :

Ce tableau aide à situer le port https parmi les services les plus courants, sans confondre usage web, administration système et messagerie.

Erreurs fréquentes lors d’un test du port 443

• Tester depuis le même serveur uniquement : cela valide l’écoute locale, pas l’accessibilité Internet.
• Tester le mauvais nom de domaine : la résolution DNS pointe parfois vers une ancienne IP.
• Confondre certificat invalide et port fermé : un service peut répondre sur 443 tout en présentant une erreur TLS.
• Oublier IPv6 : le service peut écouter sur 0.0.0.0:443 mais pas sur [::]:443, ou l’inverse.
• Ne regarder que le pare-feu local : le blocage peut venir d’un pare-feu intermédiaire ou du fournisseur cloud.

Si vous utilisez un outil d’inventaire ou de diagnostic plus large, une page dédiée à nmap peut être utile, mais ce guide reste centré sur la vérification d’un service que vous administrez, sans détailler le scan de ports tiers.

Questions fréquentes

Quel port pour le HTTPS ?

Le HTTPS utilise par défaut le port 443. C’est le port standard associé aux connexions web chiffrées via TLS. Dans la majorité des cas, un navigateur qui ouvre une URL en https:// vise ce port. Un autre port peut être utilisé, mais il faut alors le préciser dans l’URL.

Comment vérifier si le port 443 est ouvert ?

Commencez par vérifier si un service écoute localement avec ss, netstat ou lsof selon le système. Ensuite, testez l’accès depuis un autre poste avec Test-NetConnection, nc ou curl. Si l’écoute locale fonctionne mais pas le test distant, cherchez du côté du pare-feu ou de la redirection NAT. Il faut bien séparer service, filtrage et routage.

Quel est le port HTTPS ?

Le port HTTPS standard est le 443. Il correspond au trafic HTTP transporté dans une session chiffrée TLS. C’est pourquoi on parle souvent de port 443 et de port https comme de la même chose dans les usages courants. Le 80 reste associé au HTTP en clair.

Que faire si le port 443 est bloqué ?

Vérifiez d’abord si le service web écoute réellement sur 443. Contrôlez ensuite le pare-feu local, puis les règles réseau du fournisseur ou de l’hébergeur. Si le serveur est derrière une box ou un routeur, vérifiez la redirection du port 443 vers l’adresse privée correcte. Enfin, confirmez que le domaine pointe bien vers la bonne IP publique.