Pourquoi un proxy inverse redirige-t-il une application vers le domaine d’une autre application ?

Un proxy inverse peut envoyer une application vers le domaine d’une autre lorsque le backend ou le middleware génère des redirections à partir d’un nom d’hôte public incorrect.

Dans une infrastructure auto-hébergée ZimaSpace, plusieurs applications peuvent partager le même proxy tout en attendant chacune sa propre URL de base publique. Si l’en-tête Host, X-Forwarded-Host, le schéma, le middleware ou l’URL canonique définie au niveau de l’application pointe vers un autre service, la première page peut se charger correctement, puis la redirection 301, 302 ou le callback de connexion peut basculer vers un autre domaine.

Vérifiez le Host et le schéma envoyés au backend

Capturez les en-têtes des requêtes au niveau du proxy et du backend pendant que vous reproduisez la redirection.

Un guide pratique ciblé sur l’implémentation d’un proxy inverse, disponible sur le transfert du nom d’hôte et du schéma vers le backend, aide à isoler cette piste, car il traite le même problème précis au lieu de se limiter à définir le protocole sous-jacent.

Corrigez les en-têtes du proxy avant de modifier les URL de l’application. Un backend ne peut pas générer la bonne redirection absolue s’il pense que la requête utilise un autre hôte.

Inspectez spécifiquement X-Forwarded-Host

Certains frameworks utilisent X-Forwarded-Host plutôt que l’en-tête Host brut pour générer des URL absolues.

Un guide ciblé sur les en-têtes HTTP, disponible sur la conservation du nom d’hôte public par X-Forwarded-Host, aide à isoler cette piste, car il traite le même problème précis au lieu de se limiter à définir le protocole sous-jacent.

Comparez cet en-tête entre l’application qui fonctionne et celle qui redirige incorrectement. Supprimez les remplacements globaux qui imposent le même domaine à tous les backends.

Vérifiez si l’application génère des URL absolues

Recherchez les paramètres du framework qui font confiance aux en-têtes du proxy et construisent des liens canoniques ou des redirections.

Un article de blog ciblé sur le dépannage concret d’un proxy, disponible sur les URL absolues incorrectes derrière un proxy, aide à isoler cette piste, car il traite le même problème précis au lieu de se limiter à définir le protocole sous-jacent.

Corrigez la configuration de confiance envers le proxy ou le paramètre d’URL publique du framework, plutôt que de réécrire chaque redirection à la périphérie.

-15% OFF

ZimaBoard 2 - Mini serveur domestique pour votre grande idée

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Vérifiez l’URL de base ou le domaine canonique de l’application

De nombreuses applications auto-hébergées enregistrent une URL de site indépendamment de la règle du proxy.

Une étude de cas pratique ciblée sur une application derrière un proxy, disponible sur la possibilité que l’URL de base de l’application remplace le nom d’hôte du proxy, aide à isoler cette piste, car elle traite le même problème précis au lieu de se limiter à définir le protocole sous-jacent.

Comparez les valeurs d’URL enregistrées dans l’application après des migrations ou des restaurations. Une base de données copiée peut conserver le nom d’hôte canonique d’un autre environnement applicatif.

Auditez le middleware de redirection avant le backend

Une règle de proxy peut intentionnellement réécrire le schéma ou l’hôte avant même que la requête n’atteigne l’application.

Un guide pratique ciblé sur Traefik dans un homelab, disponible sur la possibilité que le middleware de redirection remplace l’hôte, aide à isoler cette piste, car il traite le même problème précis au lieu de se limiter à définir le protocole sous-jacent.

Désactivez uniquement le middleware de redirection suspect pour un routeur de test. Gardez l’application de HTTPS séparée des redirections interdomaines.

Vérifiez les URL de callback OAuth et OIDC

Les flux d’authentification révèlent souvent un nom d’hôte public incorrect, car le fournisseur valide une URI de redirection exacte.

Un article ciblé sur le dépannage d’OIDC, disponible sur la dépendance des callbacks OIDC à l’URL publique du proxy, aide à isoler cette piste, car il traite le même problème précis au lieu de se limiter à définir le protocole sous-jacent.

Comparez ensemble l’émetteur, le callback, les en-têtes transférés et l’URL de base de l’application. Le chargement normal d’une page ne prouve pas que le chemin du callback de connexion est correct.

Testez à nouveau le chemin exact du serveur domestique

Après avoir modifié une seule variable, répétez le même flux NAS ou auto-hébergé depuis le même client, au lieu de passer à un autre test susceptible d’utiliser un chemin différent.

Le guide ZimaSpace associé sur le chemin réseau adjacent du serveur domestique aide à conserver une vérification finale liée au même environnement auto-hébergé.

La correction n’est terminée que lorsque le symptôme initial reste résolu après une reconnexion, un redémarrage du service et un second transfert ou une seconde requête contrôlée.

Foire aux questions

Le DNS peut-il provoquer une redirection HTTP 301 ou 302 ?

Le DNS renvoie uniquement une adresse. La redirection est générée par le proxy, la couche d’authentification ou l’application.

Pourquoi la bonne application se charge-t-elle avant que le navigateur ne change de domaine ?

La route initiale du proxy peut être correcte, tandis que le backend génère ensuite une redirection absolue à partir d’une URL de base ou d’un hôte transféré incorrect.

Dois-je réécrire tous les en-têtes Location au niveau du proxy ?

Non. Corrigez d’abord la source du nom d’hôte incorrect ; une réécriture générale des réponses peut masquer des erreurs de configuration de l’application.