Débogage du Routage Multi-Service Fastly

Problème

Vous déployez des modifications sur un service Fastly Compute mais le comportement ne change pas. Les requêtes renvoient toujours les anciennes réponses, redirections ou erreurs même après :

• Déployer un nouveau code avec fastly compute publish
• Purger le cache avec fastly purge --all
• Vérifier que la bonne version du service est active

Contexte / Conditions de déclenchement

• DNS résout les IPs Fastly (151.101.x.x)
• Les en-têtes de réponse affichent x-served-by: cache-xxx (cache Fastly)
• Le code déployé devrait renvoyer un statut/des en-têtes différents mais ne le fait pas
• Plusieurs services Fastly existent pour le même projet (par ex. divine-web, divine-router)
• Le routage de sous-domaine générique est impliqué (*.example.com)

Solution

Étape 1 : Identifier quel service gère le domaine

# Lister tous les services
fastly service list

# Vérifier quel service gère votre domaine en utilisant domain-v1
fastly domain-v1 list | grep your-domain.com

La sortie affiche l'ID du service pour chaque domaine :

*.divine.video      glh3AfBEmZKzmAmByvGyAg  76fTayX6mBKa8faLeZ1fet  2025-12-28...
divine.video        1JttvGPc6AlOVg4koUGhPg  76fTayX6mBKa8faLeZ1fet  2025-11-23...

La troisième colonne est l'ID du service qui gère ce domaine.

Étape 2 : Vérifier l'architecture du service

Patterns courants :

• Routeur + Contenu : Un service de routage (souvent en Rust) se situe en amont et gère la logique de sous-domaine, puis transfère vers un service de contenu
• Pattern Passerelle : Une passerelle edge gère l'authentification/limitation de débit, puis effectue un proxy vers l'origine
• Routage Générique : *.domain.com peut être géré par un service différent de domain.com

Étape 3 : Déboguer le service correct

Une fois que vous avez identifié le service de routage :

# Vérifier sa version active
fastly service-version list --service-id <router-service-id>

# Vérifier ses domaines
fastly domain list --service-id <router-service-id> --version active

# Trouver et lire son code source (généralement dans un dépôt différent)

Étape 4 : Tracer le flux de requête

Ajouter du logging de débogage pour comprendre le flux :

1. Dans le service de routage : enregistrer l'en-tête Host et la décision de routage
2. Dans le service de contenu : enregistrer si les requêtes le rejoignent seulement
3. Vérifier les logs Fastly : fastly log-tail --service-id <id>

Étape 5 : Corriger le service approprié

Si le service de routage effectue des redirections indésirables :

• Mettre à jour sa logique de routage pour faire passer au lieu de rediriger
• Ou le mettre à jour pour renvoyer directement la réponse souhaitée
• Déployer sur le service de routage, pas seulement sur le service de contenu

Vérification

# Test avec contournement de cache
curl -sI -H "Cache-Control: no-cache" "https://subdomain.your-domain.com/?t=$(date +%s)"

# Vérifier que le nouveau comportement apparaît
# Vérifier que les en-têtes de réponse correspondent à ce que votre code devrait renvoyer

Exemple

Symptôme : rabble.divine.video renvoie une redirection 301 bien que divine-web ait du code pour servir du HTML directement.

Découverte :

$ fastly domain-v1 list | grep divine.video
*.divine.video      ...  76fTayX6mBKa8faLeZ1fet  ...  # C'est divine-router !
divine.video        ...  76fTayX6mBKa8faLeZ1fet  ...  # Pareil - le routeur gère les deux

Cause racine : divine-router (service Rust) retournait des redirections 301 dans sa fonction serve_profile(), ne laissant jamais les requêtes atteindre divine-web.

Correction : Mis à jour divine-router pour renvoyer directement la réponse souhaitée au lieu de rediriger.

Notes

• La commande fastly domain list affiche les domaines sur un service/version spécifique
• La commande fastly domain-v1 list affiche TOUS les domaines sur TOUS les services
• Les domaines génériques (*.domain.com) acheminent souvent vers un service différent de l'apex
• Lors de l'utilisation de backends Fastly Compute, la requête peut emprunter le chemin : Routeur → Contenu → Origine
• La purge du cache n'affecte que le service qui met en cache ; si un routeur met en cache, purgez là
• Les en-têtes de réponse comme x-publisher-server-collection indiquent quel service a répondu

Patterns d'architecture

Pattern 1 : Routeur → Contenu

Utilisateur → DNS → Service Fastly Routeur → Service Fastly Contenu → Origine/KV Store

Le routeur gère la logique de sous-domaine, l'authentification ou les règles de routage.

Pattern 2 : Direct

Utilisateur → DNS → Service Fastly Contenu → Origine/KV Store

Un seul service gère tout.

Conseil de débogage

Si vous ne savez pas quel pattern s'applique, vérifiez la section [setup.backends] du fastly.toml de chaque service pour voir si un service effectue un proxy vers l'URL edgecompute.app d'un autre.