ping envoie ICMP echo. Une réponse dit : une machine (ou un middlebox) a répondu à ICMP. Elle ne dit pas que TCP 443 est ouvert, que le process écoute, que le certificat est bon, ni que le nom DNS pointe encore ici. Prendre ping pour « le réseau est OK » est l’erreur junior que cette question piège.
Des machines filtrent ICMP et servent parfaitement HTTP. L’inverse est plus fréquent en entretien : ICMP passe, le métier non.
Le nom.
getent hosts / dig depuis le client qui échoue. Un /etc/hosts de laptop, un DNS interne, un IPv6 AAAA mort : ping a peut-être tapé une autre adresse que curl. Comparer les IP.
Le port.
ss -lntup sur le serveur : est-ce que quelque chose écoute 0.0.0.0:443 ou seulement 127.0.0.1 ? Derrière un reverse proxy, l’appli écoute en local et c’est normal — alors on teste le proxy, pas le backend depuis l’extérieur.
Le chemin TCP.
curl -v, nc -vz host 443, éventuellement mtr. Timeout : filtrage (security group, iptables/nft, NetworkPolicy). Connexion reset : quelque chose refuse activement. SYN sans réponse : drop, pas l’appli.
TLS et l’HTTP.
Handshake qui échoue (certificate verify failed, SNI, protocole) alors que nc au port réussit : ce n’est plus « le réseau ». Un curl -k qui passe oriente vers le certificat. Un 502 : le proxy joint le mauvais upstream.
L’identité du client.
Pare-feu qui autorise le bastion mais pas le runner CI ; source NAT ; IPv6 du client vs IPv4 du serveur. Ping depuis votre poste ne reproduit pas le chemin du pod.
« Telnet au port 80 marche, le navigateur non. »
Redirection HTTPS, HSTS, nom qui ne match pas le certificat, ou le navigateur passe par un proxy d’entreprise que nc ignore.
« Ça marche en curl sur le serveur, pas depuis l’extérieur. »
Écoute localhost, security group, ou routing de retour (trafic qui entre, réponses qui ne ressortent pas). On ne réinstalle pas nginx.
Vous concluez : ping est un test ICMP ; l’application est un contrat TCP (ou UDP) + protocole. On ne saute pas les étages.