Traceur de redirections — voir chaque saut qu'une URL prend réellement

Une URL qui a l’air correcte dans la barre d’adresse peut prendre trois ou quatre sauts avant d’atterrir quelque part. Chaque saut ajoute de la latence, chaque saut est un point de défaillance potentiel, et n’importe lequel peut tranquillement dépouiller les témoins, rétrograder le schéma, ou envoyer un référent à un domaine que l’équipe marketing n’attendait pas. Le navigateur cache tout cela par défaut — au moment où vous voyez la page, la chaîne s’est déjà effondrée en une seule URL. Le Traceur de redirections de PortJar rend la chaîne visible pour que vous puissiez décider quoi garder et quoi enlever.

Ce que fait l’outil

Le Traceur de redirections récupère l’URL que vous lui donnez et suit chaque réponse 3xx en séquence, retournant la liste complète des sauts — URL demandée, code de statut, en-tête Location qui a déclenché le saut suivant, et destination finale. Il ne rendra pas la page, n’exécutera pas de JavaScript, et n’effondrera pas silencieusement la chaîne comme le fait un navigateur. La sortie est ce qu’un client HTTP frais voit à la première requête, avant que les témoins ou les service workers ne s’en mêlent.

Le résultat est partageable par une URL sans état — collez la trace dans un billet et la prochaine personne voit la même chaîne en rechargeant. C’est important quand une chaîne ne se produit que pour une URL, une langue ou un paramètre de campagne spécifique et qu’il faut le prouver sans reproduire les conditions d’origine.

Comment l’utiliser

Ouvrez portjar.com/tools/redirect-tracer, collez l’URL complète avec le schéma et les paramètres de requête, et lancez. La liste des sauts s’affiche immédiatement. Lisez de haut en bas — la première ligne est ce que vous avez tapé, la dernière est où la requête s’est finalement posée, et chaque ligne entre les deux est quelque chose qui a réécrit la destination en chemin.

Quand vous y recourriez

Attraper des sauts de fournisseur ou de raccourcisseur non désirés. Le marketing vous a remis une URL de campagne qui passe par un domaine de pistage que vous n’avez pas autorisé. La trace montre le saut, vous permet d’en faire une capture pour la discussion avec le fournisseur, et vous donne la destination canonique à publier.
Diagnostiquer une paire canonique cassée. Un hôte www qui 301 vers l’apex, où l’apex 302 vers www, produit une boucle de redirection que le navigateur finira par briser avec une page d’erreur. Le traceur signale la boucle en deux secondes.
Vérifier les promotions de schéma. Chaque URL publique devrait atterrir sur HTTPS après au plus un saut. Si la trace montre http://example.com → http://www.example.com → https://www.example.com, le premier saut est inutile et fuit du trafic en clair.
Auditer un site migré après une bascule. Quand vous déplacez un site vers une nouvelle plateforme, vous voulez que chaque ancienne URL atterrisse sur la bonne nouvelle avec un 301, pas un 302 ni un 404. Vérifiez une poignée d’URLs à fort trafic à travers le traceur pour confirmer.
Confirmer qu’un domaine personnalisé ou un sous-domaine partenaire pointe toujours là où il devrait. Les fournisseurs font tourner les URLs plus souvent que leurs clients ne le remarquent. Le traceur est le moyen le plus rapide de confirmer qu’une URL personnalisée se termine encore sur votre origine et non sur un domaine stationné.

Quoi faire de la sortie

Une trace propre fait un ou deux sauts et se termine sur un 200. Toute chaîne plus longue mérite un second regard — les chaînes cumulent la latence, et sur une connexion lente une redirection à quatre sauts peut coûter une seconde complète avant le premier octet de contenu. Si la chaîne est longue mais légitime, documentez pourquoi pour que le prochain ingénieur n’essaie pas de la « nettoyer ».

Surveillez les codes de statut. Un 301 (permanent) dit aux caches en aval et aux moteurs de recherche de retenir le nouvel emplacement. Un 302 ou 307 (temporaire) leur dit de ne pas le faire. Utiliser 302 là où 301 était voulu est une erreur courante lors des bascules et est invisible jusqu’à ce que les données de trafic dérapent. Le traceur met le code de statut exact devant vous à chaque saut.

Surveillez les transitions de schéma. Tout saut en HTTP simple est un saut en clair — les témoins sur ces sauts sont exposés, et selon le drapeau Secure du témoin, ils peuvent ne pas être envoyés au saut suivant non plus. Si une chaîne publique a même un seul saut HTTP, corrigez-le.

Surveillez les sauts entre domaines. Une redirection de votre domaine vers un domaine de fournisseur puis retour est un moment où le référent de l’utilisateur fuit, et où les témoins ne survivent pas. Parfois c’est volontaire (flux SSO). Parfois c’est un pisteur que l’outil marketing a ajouté par défaut.

Si la trace atterrit sur un 4xx ou 5xx, vous avez votre bogue — le saut précédent envoie le trafic vers une destination qui ne répond plus. Combinez le résultat avec l’Inspecteur d’en-têtes HTTP quand vous devez voir ce que le point d’accès final a retourné au-delà de la ligne de statut.

Stack Harbor utilise le Traceur de redirections comme étape de vérification routinière lors des migrations, des changements de fournisseur et des bascules DNS gérées dans le cadre de la gestion de déploiement.