Lien court qui ne fonctionne pas ? Diagnostiquez-le en une seule commande

Un lien court qui ne fonctionne pas échoue de l'une de quatre façons, qui n'ont rien à voir entre elles. Exécutez curl -sI dessus et la première ligne vous indique laquelle vous avez :

curl -sI https://s.elido.me/ab12cd

Un 301 accompagné d'un en-tête Location signifie que le lien est en bonne santé et que le problème se trouve plus loin. Un 404 signifie que le slug est incorrect, supprimé, ou dans la mauvaise casse. Une erreur TLS avant même le moindre HTTP signifie que le domaine n'est pas terminé. Et un 200 qui affiche une page d'avertissement signifie que quelque chose entre vous et le lien a décidé de ne pas l'autoriser.

Dix secondes dans un terminal valent mieux qu'une heure à deviner, car un navigateur regroupe les quatre causes dans la même page d'erreur peu utile. Cet article passe en revue chaque cause et sa solution.

Une erreur 404 depuis le domaine court

Le domaine a répondu, donc le DNS et le TLS sont corrects. Le problème vient du slug.

Vérifiez d'abord la casse. La plupart des raccourcisseurs traitent les slugs comme sensibles à la casse, donc /Spring et /spring sont deux liens différents et un seul des deux existe. Si le lien provient d'un flyer imprimé, méfiez-vous des caractères qui se ressemblent dans une police sans empattement : le I majuscule, le l minuscule, et le chiffre 1 ; le O majuscule et le zéro. C'est le meilleur argument en faveur des custom back-halves faits de vrais mots plutôt que de caractères aléatoires.

Si le slug est correct, vérifiez si le lien a été supprimé ou archivé, et s'il a une expiration. Expiration des liens et liens à autodestruction explique comment se comporte une expiration programmée une fois qu'elle se déclenche : le lien cesse de se résoudre et ressemble exactement à une faute de frappe pour celui qui clique dessus.

Une dernière possibilité sur un lien qui fonctionnait auparavant : une règle géographique ou d'appareil qui exclut l'endroit depuis lequel vous testez. Les liens intelligents acheminent selon le pays et l'appareil, et une règle sans repli est une erreur 404 pour tout le monde en dehors de sa liste.

Un avertissement de certificat sur un domaine personnalisé

Rien d'HTTP ne s'est produit ici. Le navigateur a refusé pendant la négociation TLS, ce qui signifie que le domaine sert du contenu avant que son certificat n'existe.

Deux causes couvrent presque tous les cas. L'enregistrement DNS a été ajouté mais la vérification n'a jamais abouti, donc le certificat n'a jamais été délivré. Ou bien le domaine a été pointé avec un enregistrement A alors que le fournisseur demandait un CNAME, et le challenge qui prouve le contrôle ne peut pas aboutir.

La solution consiste à terminer l'enregistrement exactement comme le tableau de bord le précise, puis à attendre : la propagation dépend du TTL précédent de ce qui existait avant, donc un enregistrement qui avait un TTL d'une heure met jusqu'à une heure à se dissiper. Domaines personnalisés pour liens courts propose le guide complet du DNS et du TLS, et TLS de domaine personnalisé en cinq minutes couvre le cas simple.

Cela fonctionne dans un navigateur mais pas dans une application

Le lien se résout parfaitement depuis votre terminal et se fait retirer, signaler, ou supprimer silencieusement dans Slack, Teams, WhatsApp, ou une passerelle email.

Ce n'est pas votre lien qui est en cause. C'est la réputation du domaine. Les domaines de raccourcisseurs publics gratuits sont partagés par tous ceux qui les utilisent, y compris la campagne de phishing qui a tourné sur l'un d'eux ce matin, et les éditeurs de solutions de sécurité alimentent ces applications avec des listes de blocage par domaine plutôt que par slug.

Aucune configuration ne résout cela sur un domaine partagé. La solution, c'est votre propre domaine, où la réputation n'appartient qu'à vous et s'améliore au lieu de s'effondrer au hasard. Pourquoi vos liens courts sont bloqués dans Slack et Teams explique le mécanisme complet, y compris que faire si votre propre domaine finit par être signalé.

L'email ajoute une couche supplémentaire : certains produits de sécurité réécrivent chaque lien d'un message, si bien que ce sur quoi le destinataire clique est l'URL de l'éditeur, pas la vôtre. Les liens courts nuisent-ils à la délivrabilité des emails traite de cette interaction.

Si vous êtes encore sur un domaine partagé, c'est le moment de changer. Configurez un domaine de marque sur le plan gratuit et réémettez les liens qui comptent.

Boucles de redirection et chaînes longues

curl -sI montre un seul saut. Ajoutez -L et comptez-les :

curl -sIL https://s.elido.me/ab12cd | grep -E '^HTTP|^[Ll]ocation'

Deux ou trois lignes, c'est normal : le lien court redirige, et la destination peut rediriger encore une fois de http vers https ou de la racine vers www. Un mur de lignes signifie une boucle, et la cause habituelle est un lien modifié pour pointer vers une page qui redirige elle-même vers l'URL courte. Pointez la destination vers la page finale, pas vers une autre redirection.

Les navigateurs arrêtent de suivre après un nombre fixe de sauts et affichent une page générique "trop de redirections", ce qui explique pourquoi le terminal est le diagnostic le plus rapide : curl affiche chaque en-tête Location au passage, pour que vous puissiez voir exactement quelles deux URL pointent l'une vers l'autre. La sémantique des codes de statut est définie dans la RFC 9110, et la version pratique est qu'une redirection permanente est mise en cache par le navigateur, donc un 301 erroné reste erroné pour ce visiteur même après que vous l'ayez corrigé.

Les chaînes longues méritent d'être raccourcies même quand elles fonctionnent. Chaque saut ajoute de la latence sur une connexion mobile, et chacun est un endroit de plus où une chaîne de requête peut se perdre, ce qui explique comment les paramètres UTM disparaissent dans GA4. L'explication 301 contre 302 couvre quel code de statut utiliser où, et les types de redirections couvrent le reste de la famille.

Quand c'est la destination qui est cassée

Parfois, le lien court est en bon état et c'est la page derrière lui qui ne l'est pas. La redirection renvoie 301, le navigateur la suit, et la destination renvoie 404 parce que la page de campagne a été dépubliée ou que son slug a changé.

C'est ce mode de défaillance qui justifie l'existence des liens courts, car la solution est un repointage plutôt qu'une réimpression. Changez la destination et chaque endroit où le lien a été publié se remet à fonctionner, y compris les supports imprimés. Prévention de la pourriture des liens explique comment les repérer avant qu'un client ne le fasse, et surveiller les redirections de liens avec Sentry et Datadog couvre les alertes à grande échelle.

L'ordre de vérification

Toujours les en-têtes d'abord. curl -sI sépare le DNS du TLS et du HTTP en une seule ligne, et chacun de ces trois éléments a sa propre solution qui n'a rien à voir avec les deux autres. Puis le slug, puis la destination, puis l'application ou la passerelle entre les deux.

Le contrôle qui détecte la plupart des problèmes avant que quiconque d'autre ne les voie : ouvrez chaque nouveau lien une fois, sur un téléphone, en données mobiles plutôt que sur le wifi du bureau. Cela prend quinze secondes et cela détecte le certificat qui n'a pas encore été délivré, la règle géographique sans repli, et la destination qui redirige vers un endroit auquel vous ne vous attendiez pas.

Lire la série pilier

Cet article appartient au cluster tutoriels. Pour les mécanismes sous-jacents, comment fonctionnent les raccourcisseurs d'URL couvre le trajet de la redirection, et la checklist de sécurité des raccourcisseurs d'URL couvre le volet abus qui fait bloquer les domaines en premier lieu.

À lire aussi sur le blog

• Pourquoi vos liens courts sont bloqués dans Slack et Teams
• Domaines personnalisés pour liens courts : le guide du DNS et du TLS
• Redirections 301 contre 302 : laquelle utiliser pour vos liens
• Stratégie de prévention de la pourriture des liens pour les campagnes d'URL courtes