Mes en-têtes HTTP

Par La rédaction de Mon-Adresse-IP.net·Publié le 22 mai 2026·Mis à jour le 21 août 2026·

À chaque page que vous ouvrez, votre navigateur envoie au serveur une série de métadonnées : les en-têtes HTTP. Cette page affiche ce que le vôtre vient de transmettre à Mon Adresse IP.net, puis explique en-tête par en-tête à quoi chacun sert, ce qu'il révèle de vous et ce que vous pouvez y changer.

Les en-têtes de votre requête

Voici, sans filtre, ce que votre navigateur vient d'envoyer. Les noms sont normalisés par PHP ; les valeurs sont affichées telles quelles, après échappement.

Cette liste varie selon le navigateur, le système, l'origine de votre clic et la présence éventuelle d'un relais sur le trajet. Rechargez la page depuis un autre appareil : la comparaison est souvent plus parlante qu'un long discours.

Ce qu'est un en-tête HTTP

Une requête HTTP est un message texte structuré en trois parties. La première ligne, dite ligne de requête, contient la méthode (GET, POST, HEAD…), la cible demandée et la version du protocole. Viennent ensuite les en-têtes, une par ligne, sous la forme Nom: valeur. Une ligne vide referme le bloc, puis vient éventuellement un corps : le contenu d'un formulaire, un fichier téléversé, un document JSON. Une requête de simple consultation n'a pas de corps : c'est pourquoi vous ne voyez ci-dessus ni Content-Type ni Content-Length.

Concrètement, une requête vers cette page ressemble à ceci :

GET /mes-en-tetes-http.php HTTP/1.1
Host: mon-adresse-ip.net
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/0.0.0.0 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: fr-FR,fr;q=0.9,en-US;q=0.8
Accept-Encoding: gzip, deflate, br, zstd
Connection: keep-alive
# ligne vide : fin des en-têtes, début du corps (absent pour un GET)

Ces métadonnées existent pour une raison simple : le protocole HTTP est sans état. Le serveur ne se souvient de rien d'une requête à l'autre. Chaque message doit donc porter lui-même tout ce qui est nécessaire pour être traité correctement : quel site est visé, dans quelle langue répondre, quelle compression le client sait décoder, quelle version du document il possède déjà en cache. Sans en-têtes, il faudrait un serveur par site, une seule langue par serveur et un rechargement complet de chaque image à chaque visite.

Le serveur en fait quatre usages principaux. Il route la requête grâce à Host, ce qui permet d'héberger des centaines de sites derrière une seule adresse IP : voyez notre guide du DNS pour comprendre comment le nom de domaine arrive jusque-là. Il négocie la représentation à renvoyer à partir des en-têtes Accept-*. Il optimise en renvoyant un code 304 plutôt que le document entier quand le cache du client est encore valable ; notre référence des codes de statut HTTP détaille ce dialogue. Enfin il sécurise, en vérifiant l'origine d'une requête ou en exigeant une authentification.

Deux précisions techniques utiles. D'abord, les noms d'en-têtes sont insensibles à la casse en HTTP/1.1 : user-agent et User-Agent désignent le même champ. En HTTP/2 et HTTP/3, ils sont obligatoirement en minuscules et compressés en binaire : le tableau ci-dessus est donc une reconstitution lisible, pas les octets réellement transmis. Ensuite, PHP expose les en-têtes dans $_SERVER en majuscules, préfixés par HTTP_ et avec les tirets convertis en tirets bas. Conséquence peu connue : un client peut envoyer X_Forwarded_For avec des tirets bas pour tenter de se confondre avec le véritable X-Forwarded-For. C'est l'une des raisons pour lesquelles ces valeurs ne doivent jamais être crues sur parole.

Le dictionnaire des en-têtes de requête

Voici les en-têtes que l'on rencontre réellement dans le trafic d'un navigateur moderne. Filtrez par mot-clé ou par catégorie : identité pour ce qui vous désigne, contenu pour la négociation de format, cache pour les revalidations, sécurité pour les signaux de protection, proxy pour les en-têtes d'intermédiaires, hints pour les Client Hints.

Les noms qui commencent par Sec- forment une catégorie à part : ils sont protégés, c'est-à-dire qu'un script de page n'a pas le droit de les créer ni de les modifier. Le navigateur en garde le contrôle exclusif, ce qui permet au serveur de leur accorder plus de confiance qu'aux autres. À l'inverse, les noms préfixés par X- sont des conventions historiques : personne ne les garantit. Le glossaire du site reprend les termes techniques employés ici.

Les en-têtes qui trahissent un proxy ou un VPN

Quand une requête traverse un relais (proxy d'entreprise, répartiteur de charge, réseau de diffusion de contenu), l'adresse IP que voit le serveur final est celle du relais, pas la vôtre. Pour ne pas perdre l'information d'origine, les intermédiaires ajoutent des en-têtes dédiés. Trois comptent vraiment.

X-Forwarded-For est le plus répandu. Chaque relais y ajoute, séparée par une virgule, l'adresse du client dont il a reçu la requête. La chaîne se lit de gauche à droite : le premier élément est censé être le client initial, les suivants les relais successifs. Via, normalisé par la spécification HTTP, décrit les intermédiaires eux-mêmes plutôt que les clients : version de protocole, pseudonyme, parfois logiciel. Forwarded est le remplaçant officiel des en-têtes X-Forwarded-* : une syntaxe unique à paramètres nommés qui évite d'avoir à combiner trois en-têtes distincts. Il reste minoritaire, l'habitude ayant fait loi.

Cette règle a deux conséquences pratiques. Côté éditeur, il ne faut jamais fonder un contrôle d'accès, une limitation de débit ou un journal probant sur un X-Forwarded-For brut : c'est un contournement d'authentification classique. Côté visiteur, ces en-têtes ne prouvent rien non plus de votre côté : leur absence ne signifie pas que vous n'utilisez pas de relais, et leur présence peut être un artefact de votre opérateur ou de votre entreprise. Notre guide des proxys détaille les différences entre proxys transparents, anonymes et élite précisément sur ce critère.

C'est aussi pour cette raison que ce site échappe systématiquement chaque valeur avant de l'afficher. Un en-tête n'est qu'une chaîne arbitraire fournie par le client : sans échappement, un visiteur pourrait y glisser du code et le voir exécuté dans le navigateur d'un autre. La fonction h() employée dans le tableau du haut neutralise ce risque, et nous l'appliquons partout, sans exception. Notre page méthodologie explique comment nous traitons ces données côté serveur, et la politique de confidentialité précise ce que nous en conservons.

User-Agent et Client Hints

Le User-Agent est l'en-tête le plus lu et le plus mal compris. Sa forme actuelle est le produit d'une course à l'imitation vieille de trente ans. Netscape, dont le nom de code interne était « Mozilla », annonçait Mozilla/2.0. Des serveurs se sont mis à réserver les pages riches aux clients dont la chaîne commençait par ce mot. Internet Explorer a donc annoncé Mozilla/4.0 (compatible; MSIE 4.0) pour ne pas être privé de contenu. Safari, bâti sur KHTML, a ajouté like Gecko pour bénéficier des mêmes traitements que Firefox. Chrome a ensuite cumulé les mentions AppleWebKit, KHTML, like Gecko, Chrome et Safari dans une seule chaîne. Résultat : tous les navigateurs commencent aujourd'hui par Mozilla/5.0, mention devenue strictement décorative.

Cette chaîne pose deux problèmes. Elle est illisible pour les serveurs, qui doivent recourir à des expressions régulières fragiles pour en extraire quoi que ce soit. Et elle est trop précise : numéro de version complet, version exacte du système, modèle d'appareil sur mobile. Autant d'éléments qui, combinés, réduisent drastiquement le nombre d'internautes qui vous ressemblent.

La réponse des éditeurs de navigateurs a été double. D'abord une réduction progressive du contenu de l'en-tête. Les navigateurs Chromium gèlent désormais les chiffres qui suivaient la version majeure (d'où les 0.0.0 que l'on voit apparaître) figent la version du système annoncée et remplacent, sur Android, le modèle d'appareil par une lettre unique. Deux appareils très différents peuvent donc envoyer aujourd'hui un User-Agent identique.

Ensuite, le remplacement par les Client Hints, un mécanisme de négociation. Le principe inverse celui du User-Agent : au lieu de tout envoyer d'emblée, le navigateur ne transmet par défaut que trois indices à faible entropie (Sec-CH-UA, Sec-CH-UA-Mobile, Sec-CH-UA-Platform). Un serveur qui a besoin de plus doit le demander explicitement, via un en-tête de réponse Accept-CH ; le navigateur enverra alors les indices supplémentaires (version du système, modèle, architecture) aux requêtes suivantes.

Pour le pistage, le bilan est donc nuancé. Les acteurs mineurs perdent un accès gratuit à des informations détaillées ; les grandes régies, elles, les demandent simplement. Notre outil empreinte de mon navigateur montre les valeurs effectivement exposées par votre configuration.

Do Not Track et Global Privacy Control

DNT est né au début des années 2010 d'une idée simple : un bit unique, envoyé à tous les sites, exprimant le refus d'être suivi. Les navigateurs l'ont implémenté rapidement. La suite a été moins heureuse : aucun texte n'obligeait qui que ce soit à en tenir compte, et les discussions de normalisation se sont enlisées avant d'être officiellement abandonnées à la fin de la décennie, faute de consensus sur ce que « ne pas suivre » signifiait exactement.

L'échec a produit un effet pervers documenté : comme une minorité d'internautes activaient l'option, l'envoi de DNT: 1 devenait lui-même un signal distinctif, donc un bit supplémentaire d'empreinte. Certains navigateurs ont retiré l'option de leurs préférences pour cette raison. Un signal qui n'est respecté par personne mais qui vous distingue de tout le monde est pire qu'inutile.

Sec-GPC reprend la même forme (un bit, une valeur 1) avec une différence décisive : il ne demande pas une faveur, il exprime un droit prévu par la loi. Aux États-Unis, plusieurs lois d'États sur la vie privée imposent aux entreprises de reconnaître un signal automatisé de refus de vente ou de partage des données personnelles ; l'autorité californienne a considéré qu'ignorer ce signal constituait un manquement, ce qui a donné à Sec-GPC une force qui a toujours manqué à DNT.

En Europe, la situation est différente et souvent mal expliquée. Le RGPD et la directive ePrivacy reposent sur un consentement préalable : en principe, rien ne doit être déposé ni partagé avant que vous ne l'ayez accepté, ce qui rend théoriquement superflu un signal de refus. Aucun texte européen ne rend aujourd'hui Sec-GPC juridiquement opposable, même si l'idée d'un mécanisme automatisé d'expression du choix revient régulièrement dans les débats sur la réforme d'ePrivacy. Le laisser activé ne coûte rien et peut servir ; en attendre une protection automatique en France serait une erreur. Notre page adresse IP et RGPD replace ces signaux dans le cadre juridique applicable.

Ce que ces en-têtes disent de vous

Pris un par un, ces champs sont banals. Des millions de personnes utilisent le même navigateur que vous ; des dizaines de millions de francophones envoient le même Accept-Language. C'est la combinaison qui pose problème. Chaque valeur retire une part d'incertitude, et le produit de ces réductions successives converge vite vers un groupe très restreint.

Un exemple concret : un Accept-Language configuré sur fr-FR,br;q=0.8, une plateforme peu répandue, une version de navigateur qui n'est plus tout à fait la dernière, un Save-Data: on et un DNT: 1. Aucune de ces valeurs n'est identifiante ; leur assemblage l'est presque. Et ces en-têtes ne sont que la partie visible côté serveur : le JavaScript de la page peut y ajouter la résolution d'écran, le fuseau horaire, la liste des polices installées, le rendu graphique. Notre guide de l'empreinte du navigateur décrit ces techniques et les défenses réalistes, et l'outil empreinte de mon navigateur calcule ce que votre configuration expose.

Deux idées reçues méritent d'être corrigées. La première : « mon VPN me protège ». Il masque votre adresse IP, pas vos en-têtes, qui sont générés à l'intérieur du tunnel. Une IP annoncée en Roumanie accompagnée d'un Accept-Language: fr-FR constitue même une incohérence remarquable. La seconde : « la navigation privée efface tout ». Elle isole les cookies et l'historique locaux, mais envoie exactement les mêmes en-têtes que la fenêtre normale. Ajoutez-y les fuites possibles au niveau du navigateur, que notre test de fuite WebRTC met en évidence, et l'on comprend que la protection tient à un ensemble cohérent de réglages, jamais à un outil unique.

Les en-têtes de réponse à connaître

La conversation est symétrique : le serveur répond lui aussi avec des en-têtes. Certains ne servent qu'à la mise en cache, d'autres constituent le principal dispositif de sécurité d'un site moderne. Voici ceux qu'il faut savoir lire.

Ces en-têtes s'accompagnent des codes de statut : un 403 renvoyé après un Origin inattendu, un 304 déclenché par If-None-Match, un 206 en réponse à un Range. Notre référence des codes de statut HTTP les recense un par un avec leurs causes probables.

Voir les en-têtes soi-même

Le tableau du haut vous montre vos propres en-têtes de requête. Pour observer ceux d'un autre site, ou pour vérifier ce qu'un serveur renvoie, deux outils suffisent.

La ligne de commande. curl est présent nativement sur Windows 10 et 11, macOS et la plupart des distributions Linux. L'option -v affiche le dialogue complet : les lignes préfixées par > sont ce que vous envoyez, celles préfixées par < ce que le serveur répond.

curl -v https://mon-adresse-ip.net/ # dialogue complet, requête et réponse
curl -I https://mon-adresse-ip.net/ # méthode HEAD : en-têtes de réponse seuls, sans le corps

# Simuler un autre navigateur ou une autre langue :
curl -H "Accept-Language: de-DE" -I https://mon-adresse-ip.net/
curl -A "Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X)" -I https://mon-adresse-ip.net/

# Suivre les redirections et n'afficher que les en-têtes de réponse :
curl -sL -D - -o /dev/null https://mon-adresse-ip.net/

Deux avertissements utiles. curl -I envoie une requête HEAD : certains serveurs y répondent différemment d'un GET, ce qui explique des écarts déroutants. Et curl n'est pas un navigateur : il n'envoie ni Client Hints, ni en-têtes Sec-Fetch-*, ni cookies. Comparer sa sortie à ce que fait Firefox ou Chrome est d'ailleurs le meilleur moyen de mesurer tout ce qu'un navigateur ajoute spontanément.

L'onglet Réseau du navigateur. Ouvrez les outils de développement avec F12 (ou Ctrl+Maj+I, Cmd+Option+I sur macOS), placez-vous sur l'onglet Réseau, rechargez la page, puis cliquez sur la première ligne de la liste.

1. Cochez « Désactiver le cache » avant de recharger, sinon la plupart des ressources ne provoqueront aucune requête réelle.
2. Ouvrez le panneau « En-têtes » de la requête sélectionnée : il sépare les en-têtes de réponse et les en-têtes de requête.
3. Passez en mode brut si l'option existe : vous verrez alors les lignes exactes, sans le reformatage décoratif de l'interface.
4. Comparez plusieurs requêtes de la même page : le document, une image et un appel en arrière-plan n'envoient pas les mêmes Sec-Fetch-Dest ni les mêmes Accept.

Ce réflexe sert bien au-delà de la curiosité : il permet de diagnostiquer une image qui ne se met pas à jour (un problème de cache), un formulaire refusé (un Origin ou un cookie SameSite), ou une ressource bloquée par une politique de sécurité. Pour analyser une adresse IP croisée dans ces échanges, notre outil de recherche d'adresse IP prend le relais ; pour les en-têtes d'un message électronique, qui obéissent à une logique différente, voyez l'analyseur d'en-têtes d'e-mail.

Questions fréquentes