Cohérence du proxy IPv4 et IPv6 dans un navigateur
Comprendre la sélection double pile avec le proxy et le DNS, puis vérifier une politique réseau stable dans un environnement contrôlé.
Vous voulez la documentation structurée pour Réseau ?
Cet article fait partie de la bibliothèque éditoriale. Pour les étapes de configuration, la référence et les mises à jour continues, passez directement à la section docs.
Un réseau double pile peut atteindre un service en IPv4 ou en IPv6, mais la famille choisie ne représente qu'une partie du trajet. Le navigateur peut envoyer une requête au proxy, lui confier la résolution de la destination, résoudre localement le nom du proxy ou employer une autre route pour une fonction que le proxy ne transporte pas. Un flux stable exige une politique explicite pour le transport, le DNS et les échecs.
La cohérence n'impose pas la même famille à chaque connexion. Elle impose le respect de la limite réseau déclarée. Une destination IPv4 et une destination IPv6 peuvent être cohérentes lorsqu'elles passent par la même politique de proxy approuvée. Une connexion directe et silencieuse après une panne du proxy constitue une autre politique et doit apparaître comme un échec.
La politique doit rester compréhensible sans capture détaillée du trafic. Le support doit connaître la route attendue, le propriétaire du résolveur, les conditions réseau prises en charge et le comportement visible en cas d'échec. Les traces de bas niveau restent un outil limité pour un dossier autorisé, pas une télémétrie permanente.
Sélection des adresses sur un réseau double pile
Une application part généralement d'un nom d'hôte, pas d'une adresse IP. Le DNS peut renvoyer des candidats IPv4 et IPv6, puis le client choisit lequel essayer. La section 6 de la RFC 6724 définit la sélection des adresses de destination comme un tri des candidats selon les règles spécifiées. Le résultat dépend des adresses disponibles, de la table de routage, de la politique configurée et de l'accessibilité réelle. Une adresse renvoyée reste une option, pas la preuve d'un chemin utilisable.
La section 5 de la RFC 8305 décrit l'enchaînement des tentatives de connexion Happy Eyeballs, conçu pour une connexion double pile réactive. Le client commence par un candidat, puis en lance un autre après un délai limité ; dès qu'une tentative aboutit, il annule celles qui n'ont pas encore réussi. Cela peut accélérer la reprise face à une famille d'adresses lente ou indisponible. La famille gagnante peut varier selon le réseau ou après une modification de route ; elle ne doit donc pas devenir une donnée permanente du profil.
Un proxy déplace le point où la sélection a lieu. Quand le navigateur transmet le nom au proxy, celui-ci peut résoudre la destination depuis son propre réseau. Quand le client résout d'abord et transmet une adresse, l'environnement local participe à la sélection. Le nom du proxy peut lui-même nécessiter une résolution locale avant la création du tunnel. En HTTP CONNECT, la cible de la requête identifie l'hôte et le port de destination ; en cas de succès, le destinataire établit un tunnel de données (section 9.3.6 de la RFC 9110). SOCKS5 peut transmettre un nom de domaine complet comme adresse de destination avec ATYP DOMAINNAME (sections 4 et 5 de la RFC 1928). La configuration doit désigner clairement le modèle retenu.
La famille d'adresse ne doit pas être assimilée à une localisation ou à une identité. IPv4 et IPv6 sont des choix de transport. Aucune famille ne prouve seule la position physique, le fournisseur ou le contexte régional prévu. Un dossier de support peut enregistrer l'étiquette de route et la famille observée sans transformer un choix temporaire en description durable d'une personne ou d'un appareil.
La réutilisation des connexions peut donner une impression de stabilité excessive. Le navigateur peut conserver une connexion et employer sa famille pour plusieurs navigations. Un nouveau contexte, la fermeture d'une connexion inactive ou un changement de réseau peuvent relancer la sélection. Pour comparer des sessions longues, notez si le navigateur et le contexte étaient neufs et si la requête réutilisait une connexion.
Propriété du proxy et du DNS
Décrivez la politique en termes de responsabilité. Identifiez qui résout le nom du proxy, qui résout les destinations, quel trafic le proxy accepte et ce que fait le navigateur si la route manque. Une équipe peut choisir une résolution distante afin de garder les requêtes et le DNS dans une limite administrée. Un autre déploiement peut utiliser un résolveur d'entreprise avant de joindre une adresse de proxy fixe. Les deux modèles restent valables s'ils sont explicites et vérifiés.
La résolution locale n'est pas automatiquement une exposition, et la résolution distante ne garantit pas automatiquement une protection complète. Le résultat dépend des données visibles par chaque résolveur, de son opérateur et de la conformité à l'attente de l'utilisateur. Les requêtes DNS peuvent révéler des noms malgré le chiffrement du contenu. Consignez la limite du résolveur avec la politique du proxy sans conserver un historique permanent des destinations.
Le navigateur peut utiliser plusieurs sous-systèmes réseau. Les requêtes HTTP, les communications en temps réel, les extensions, les mises à jour et le système peuvent avoir des contrôles distincts. Un réglage de proxy pour la page ne garantit pas la route de tous les processus. Le guide sur la cohérence du proxy, du DNS et de WebRTC relie ces surfaces, tandis que la revue de confidentialité DNS traite la limite du résolveur.
L'authentification du proxy et les détails du point de terminaison doivent rester dans une configuration protégée. Un résultat de validation nécessite en général une étiquette de route, la famille observée, la version du navigateur et un état fonctionnel. Il n'a pas besoin de l'URL complète ni des identifiants. Limitez ces informations aux opérateurs et masquez-les par défaut dans les exports du support.
Le cache de résolution a lui aussi besoin d'un propriétaire. Le navigateur, le système, le proxy et le résolveur peuvent conserver une réponse pendant des durées différentes. Après une modification de politique, d'anciennes réponses et connexions peuvent subsister. Ne videz pas tous les caches immédiatement, car vous perdriez l'indice indiquant quelle couche a servi le résultat. Comparez le contexte existant à un contexte neuf et contrôlé, puis décidez si la session peut terminer sa tâche ou doit redémarrer. Si les deux contextes présentent encore l'ancien résultat, vérifiez l'enregistrement DNS faisant autorité et le chemin du résolveur avant de modifier les paramètres du profil du navigateur.
Causes courantes d'une divergence de route
Le nom d'un proxy double pile peut fournir les deux familles alors que le service n'en accepte qu'une depuis un réseau client donné. Le client peut attendre un candidat inaccessible avant d'essayer le bon. Une réponse DNS ancienne, un répartiteur incohérent ou une règle de pare-feu peuvent produire le même symptôme. Vérifiez si le point de terminaison déclaré a été joint au lieu d'attendre la famille utilisée lors d'une ancienne session.
La résolution de la destination peut aussi diverger entre les limites. Un résolveur local et un résolveur proche du proxy peuvent recevoir des réponses différentes à cause de la géographie, d'un DNS partagé, d'une politique d'entreprise ou de la propagation. Le navigateur peut atteindre une autre version du service. Comparez uniquement des domaines que vous possédez ou êtes autorisé à tester, avec l'emplacement du résolveur et l'heure de l'essai.
Le mécanisme de reprise crée souvent l'incohérence la plus grave. Une bibliothèque peut réessayer directement, une extension ouvrir sa propre connexion ou un service worker conserver une connexion créée sous l'ancienne politique. La page semble alors disponible malgré la rupture de la limite déclarée. Affichez une erreur claire et laissez l'utilisateur choisir le nouvel essai. Créez un nouveau contexte si le changement mélangerait des états issus de politiques différentes.
La prise en charge des protocoles ajoute une autre distinction. Un proxy qui transporte la navigation web ordinaire peut ne pas porter chaque datagramme ou flux temps réel. Désactiver une voie facultative non prise en charge, choisir une voie compatible documentée ou signaler l'indisponibilité est plus clair qu'une connexion directe silencieuse. Consultez la cohérence de la couche réseau pour les flux qui dépassent la navigation.
Plan de validation contrôlé
Utilisez des points de terminaison que vous contrôlez. Préparez un service uniquement IPv4, un service uniquement IPv6 si l'environnement le permet et un service double pile. Chacun doit renvoyer l'adresse du service qui a reçu la requête et un identifiant de test court et non sensible. Ne conservez pas les en-têtes sans rapport, les identifiants ou l'adresse complète du client. La réponse du service, une étiquette de route attendue ou la famille d'adresses observée ne prouvent pas à elles seules quel proxy a transporté la requête.
Exécutez la même tâche de navigateur contre chaque point sans modifier le profil, le proxy, le DNS ou la version de l'application. Notez le service achevé et l'alternative visible par l'utilisateur. Ne comparez l'identifiant de test que si la configuration permet de l'observer des deux côtés : un tunnel proxy HTTPS ne le voit normalement pas dans le trafic chiffré. Sinon, rapprochez une preuve indépendante de connexion ou de sortie d'une seule requête contrôlée par l'heure, la destination et l'identifiant de connexion. Si ce lien reste ambigu, indiquez que l'utilisation du proxy n'est pas vérifiée. Si le service double pile choisit une autre famille qu'auparavant, examinez l'accessibilité et la politique avant de conclure à une régression. La sélection peut être valide dans les conditions présentes.
Pour une référence synthétique, déclarez que la route proxy gérée ne prend en charge que les destinations IPv4 et dispose d'une seule sortie IPv4 approuvée. Les points de terminaison de test IPv4 uniquement et double pile doivent aboutir par cette route, avec une preuve de connexion au proxy corrélée indépendamment et une adresse source observée par le point de terminaison contrôlé qui correspond à la sortie approuvée. Le point IPv6 uniquement doit signaler que la route est indisponible et conserver la saisie sans nouvel essai direct ; une requête achevée via une autre sortie enfreint la politique, et sans corrélation l'utilisation du proxy reste non vérifiée.
Testez séparément la résolution du nom du proxy et celle de la destination. L'échec du nom du proxy appartient à la préparation de la route. L'échec de destination après la connexion appartient à une autre étape. Cette séparation évite de modifier le profil quand le problème vient du résolveur, du pare-feu ou du service proxy et permet de conserver un résultat utile sans exposer la configuration.
Incluez l'interruption et la reprise. Coupez la route approuvée pendant une tâche contrôlée et confirmez que le navigateur ne continue pas directement. Après restauration, exigez un nouvel essai intentionnel ou un nouveau contexte selon la politique. Vérifiez que la saisie de l'utilisateur reste disponible et qu'une soumission partielle n'apparaît pas comme terminée. Le test concerne le comportement de l'application, pas la réputation d'une adresse.
Les téléchargements entrants et sortants méritent leur propre cas, car ils peuvent survivre à la navigation initiale. Utilisez un petit fichier synthétique et contrôlez la route au début, pendant le transfert et après une interruption. L'application doit distinguer un fichier complet, une partie récupérable et un échec. Un nouvel essai garde la route déclarée ou recommence dans un nouveau contexte, sans assembler des fragments issus de politiques différentes. Pour un envoi, conservez le fichier source local jusqu'à confirmation de la fin du transfert et n'en journalisez pas le contenu. Pour une réception, vérifiez la taille finale et l'état affiché par l'application; ne conservez l'adresse de destination que pendant la durée utile au dossier d'assistance.
Différences de réseau et de plateforme
Certains réseaux proposent IPv6 en natif, d'autres utilisent une traduction et d'autres restent uniquement IPv4. VPN d'entreprise, réseaux mobiles, routeurs domestiques et hôtes cloud peuvent présenter des combinaisons différentes sans changement du navigateur. Définissez les conditions prises en charge. Si IPv6 est facultatif, l'application doit fonctionner par la route IPv4 déclarée. Si IPv6 seul est requis, testez le proxy et le résolveur dans cette condition.
Les transitions réseau ont besoin d'une politique. Un ordinateur portable peut passer du Wi-Fi du bureau au réseau mobile avec le contexte ouvert. Les connexions existantes peuvent continuer, les nouvelles choisir une autre famille et le nom du proxy recevoir une autre réponse. Un flux qui exige une route stable doit se mettre en pause et demander une reconnexion ou un nouveau contexte. Mélanger l'état avant et après la transition rend la session difficile à expliquer.
Un système administré peut imposer DNS, VPN ou proxy en dehors du navigateur. Examinez ces contrôles avec les réglages du navigateur et indiquez quelle couche fait autorité ainsi que l'équipe responsable. Lorsqu'une mise à jour du navigateur coïncide avec un changement du système ou du réseau, reproduisez la tâche en gardant les autres variables constantes avant d'attribuer la cause.
Les messages d'erreur doivent nommer l'étape et la prochaine action. « Proxy indisponible », « nom de destination introuvable » et « route IPv6 indisponible » conduisent à des vérifications différentes. Une erreur générique encourage les essais répétés et les modifications improvisées. Un message précis réduit aussi le besoin de recueillir de grands ensembles de données réseau sans rapport.
La résolution peut changer pendant que le contexte reste ouvert. Les enregistrements DNS expirent, un résolveur administré met sa politique à jour et un service proxy peut déplacer ses points. Un flux long doit décider s'il accepte ce changement à la prochaine connexion ou exige un redémarrage contrôlé. Une opération financière ou une tâche administrative peut devoir s'arrêter si l'identité de la route change. Une application de lecture de contenu public peut accepter une reconnexion par un autre point soumis à la même politique. Enregistrez l'étiquette de route et l'interruption visible, pas une liste durable de toutes les adresses résolues.
L'état réseau doit également être accessible. Ne communiquez pas un échec uniquement par une couleur ou une notification brève. Placez le focus sur un état concis, conservez les données du formulaire et proposez une action claire de reprise ou de redémarrage. Si une partie fonctionne hors ligne, indiquez ce qui reste local et ce qui exige la route administrée. Les utilisateurs du clavier et d'un lecteur d'écran doivent distinguer pause, échec et fin.
Maintenir la politique
Conservez une petite matrice des versions et conditions prises en charge. Elle peut contenir la version du navigateur, la famille du système, l'étiquette de route, le propriétaire du résolveur, le type de point, la famille observée et le résultat fonctionnel. Utilisez des requêtes synthétiques et supprimez les journaux temporaires après la revue. La matrice répond au fonctionnement de la route, sans profiler l'historique réseau de l'utilisateur.
Réexaminez la politique quand changent le fournisseur du proxy, le résolveur, le navigateur, le système ou le réseau du déploiement. Validez la tâche complète, pas seulement l'ouverture d'une connexion. La page peut se connecter alors que l'authentification, les téléchargements, les fonctions temps réel ou les requêtes longues prennent une autre voie. Gardez une fonction facultative uniquement après l'avoir testée sous la même limite.
Face à un résultat incohérent, commencez par l'étiquette de route et l'étape en échec. Vérifiez la résolution du proxy, la connexion, la résolution de destination et la réception par le service contrôlé. Demandez les détails complets seulement par un canal autorisé lorsque le petit dossier ne suffit pas, puis supprimez le matériel sensible à la fermeture du cas.
Les utilisateurs qui dépendent d'une route stable doivent voir les changements. Si une version modifie les conditions prises en charge, nommez le flux concerné, l'alternative disponible et la nécessité éventuelle d'un nouveau contexte. Ne présentez pas un changement de famille de transport comme une conclusion universelle sur la plateforme. Une politique précise, des tests contrôlés et des échecs visibles renforcent la cohérence.
Sources publiques
Articles Connexes
Faites passer BotBrowser de la recherche à la production
Utilisez ces guides pour comprendre le modèle, puis passez à la validation multi-plateforme, aux contextes isolés et au déploiement navigateur prêt pour l'échelle.