Les ports à partir de 1024 sont sémantiquement équivalents. L'implèmentation TCP/UDP ne fait absolument aucune différence entre eux.

C'est inexact, cf ip_local_port_range/ip_local_reserved_ports sous Linux.
De plus "l'implèmentation TCP/UDP" ne veut rien dire, il y a des implèmentations avec des paramétrages différents à ce niveau.

Chrome sur Windows 10:

https://lafibre.info:0/ -> ERR_ADDRESS_INVALID (c'est l'OS qui répond ca, on voit un appel systeme dans le tracing de Chrome)
https://lafibre.info:1/ -> ERR_UNSAFE_PORT (c'est Chrome qui bloque ca avec sa liste de 'restricted port' (voir source ligne 70).)
https://lafibre.info:2/ -> ERR_CONNECTION_REFUSED (le paquet quitte bien la machine, c'est le serveur de lafibre qui n'ecoute pas sur le port 2 donc normal)
https://lafibre.info:3/ -> idem port 1

https://lafibre.info:1/ -> ERR_UNSAFE_PORT (c'est Chrome qui bloque ca avec sa liste de 'restricted port' (voir source ligne 70).)

En effet, les navigateurs peuvent être utilisés pour ouvrir des connexions depuis l'intérieur d'une zone protégée par un pare-feu. Et même sans pare-feu, le navigateur peut être utilisé pour ouvrir des connexions depuis une IP locale ou de confiance.

C'est un problème intrinsèque au Web tel que conçu initialement.

Sous linux?

Alors pourquoi tu introduis un guide des bonnes manières et pourquoi tu l'interprètes à l'envers?

Reserved signifie INTERDIT!

Si il est interdit, c'est qu'il existe. Donc, il y a un bien un port 0.

Avec une vieille version de Nmap (nmap -p 0-3 -T4 -A -v lafibre.info) :

C'est intéressant, seul le port 0 affiche un port filtré tandis que les autres sont closed. Donc ça prouve que quelque chose passe par le port 0, mais avec Firefox, ses protections bloquent l'accès comme d'autres ont remarqués. Un wget n'a rien donné non plus.

Il n'y a rien qui écoute sur ces ports sur lafibre.info alors à quoi tu t'attends ?