Comment corriger un proxy inverse qui redirige un domaine vers la mauvaise application après l’ajout d’une règle générique
Un proxy inverse peut envoyer un domaine vers la mauvaise application lorsqu’une nouvelle route « fourre-tout » correspond à un ensemble plus large de requêtes ou prend le pas sur la règle d’hôte prévue.
Ce problème est plus spécifique qu’une redirection générique vers le mauvais domaine ou qu’un problème DNS. Le test clé consiste à vérifier que le domaine correct atteint toujours l’adresse IP et le certificat attendus du proxy, mais que celui-ci sélectionne le mauvais backend uniquement après l’ajout de la nouvelle route par défaut. Comparez les correspondances et les priorités des routes avant de modifier le DNS, les URL de base de l’application ou les certificats.
Prouver que la règle « fourre-tout » a modifié la sélection du backend
Envoyez la même requête vers le domaine avant et après avoir désactivé uniquement la nouvelle route « fourre-tout » ou par défaut. Consignez le journal d’accès du proxy, le routeur ou bloc serveur sélectionné, l’adresse du backend, l’indicateur de réponse et le certificat.
Un guide pratique sur le serveur par défaut de Nginx avertit que les règles fourre-tout peuvent intercepter le trafic, même lorsque plusieurs hôtes virtuels explicites existent déjà.
Si la désactivation du fallback restaure immédiatement l’application prévue, ne modifiez ni le DNS ni l’application backend. L’étape suivante consiste à faire gagner la route spécifique sans supprimer le comportement de fallback sûr pour les noms d’hôte inconnus.
Vérifier que la règle d’hôte spécifique correspond toujours exactement
Comparez le nom d’hôte demandé à la règle de route prévue, caractère par caractère, notamment le sous-domaine, les limites des jokers, les points finaux dans les outils de test et le fait que la règle écoute sur le même point d’entrée HTTP ou HTTPS que la route « fourre-tout ».
Un guide sur les proxys inverses multi-applications montre que les règles de nom d’hôte sélectionnent différents backends uniquement lorsque l’hôte entrant correspond à la règle effectivement chargée par le proxy.
Corrigez toute correspondance d’hôte incomplète ou mal saisie avant d’ajuster la priorité. Augmenter la priorité d’une règle qui ne correspond jamais ne fait que rendre la configuration plus difficile à comprendre.
Comparer la priorité de la route à celle de la règle « fourre-tout »
Pour les proxys qui prennent en charge une priorité explicite ou dérivée, vérifiez quelle règle gagne lorsque l’hôte spécifique et le fallback général peuvent tous deux correspondre à la même requête. Consignez la règle évaluée, et pas seulement l’ordre des fichiers de configuration.
Un exemple de règle « fourre-tout » avec Traefik attribue volontairement au fallback une priorité inférieure à celle des routes réelles, afin que les services spécifiques soient évalués en premier.
Placez le fallback sous chaque route applicative prévue, puis effectuez un nouveau test. Ne résolvez pas le problème en attribuant des nombres arbitrairement élevés à chaque routeur ; conservez plutôt une stratégie de priorité simple et documentée, capable de résister aux futurs ajouts d’applications.
Inspecter le serveur par défaut sur les proxys de type Nginx
Dans Nginx et les configurations similaires, déterminez quel bloc serveur devient le serveur par défaut pour cette adresse et ce port d’écoute lorsqu’aucune correspondance de nom d’hôte n’est trouvée. Le premier bloc chargé peut devenir le fallback si aucun serveur par défaut explicite n’est défini.
Un article consacré au dépannage de Nginx explique pourquoi les hôtes sans correspondance atteignent les serveurs par défaut au lieu d’être simplement rejetés.
Utilisez une réponse par défaut neutre ou un service d’erreur plutôt que de faire d’une application réelle le fallback. Ainsi, un nom d’hôte inconnu ou mal saisi ne pourra pas exposer accidentellement une autre application auto-hébergée.
Vérifier séparément les fallbacks HTTP et HTTPS
Une règle « fourre-tout » ajoutée pour le port 80 ne se comporte pas automatiquement de la même manière sur le port 443. Le routage TLS, le SNI, des points d’entrée distincts ou une seconde règle « fourre-tout » peuvent faire en sorte que seules les requêtes HTTPS atteignent la mauvaise application.
Un cas de dépannage avec Caddy décrit une règle fourre-tout qui se comporte différemment selon le protocole et montre pourquoi la route propre à chaque protocole doit être testée directement.
Envoyez des requêtes HTTP et HTTPS avec le même nom d’hôte et consignez le gestionnaire sélectionné. Corrigez le fallback sur le point d’entrée concerné au lieu de modifier le chemin de protocole qui fonctionne.
Conserver un fallback neutre et retester chaque domaine connu
Après avoir corrigé la portée des correspondances ou la priorité, faites en sorte que le fallback renvoie une page d’erreur 404, 421 ou contrôlée et neutre, plutôt que de transmettre chaque nom d’hôte inconnu à une seule application de production. Testez ensuite une fois chaque domaine auto-hébergé connu.
Une présentation de l’architecture des proxys inverses souligne que le proxy choisit le backend après l’arrivée de la requête sur celui-ci ; l’exactitude du DNS ne suffit donc pas à prouver l’exactitude du routage.
La correction est terminée lorsque chaque nom d’hôte connu atteint l’application prévue et qu’un nom d’hôte inconnu n’atteint que le fallback neutre. L’article ZimaSpace associé sur la redirection d’un proxy inverse vers un autre domaine constitue l’étape suivante lorsque le proxy sélectionne le bon backend, mais que l’application modifie ensuite les domaines.
Questions fréquemment posées
Le DNS peut-il faire gagner une route « fourre-tout » ?
Le DNS peut envoyer la requête vers la mauvaise adresse IP de proxy, mais une fois que le proxy correct reçoit le nom d’hôte prévu, la correspondance des routes relève de sa décision. Vérifiez séparément les deux niveaux.
La règle « fourre-tout » doit-elle rediriger vers une application de tableau de bord ?
En général, non. Une cible d’erreur neutre est plus sûre, car les fautes de frappe et les noms d’hôte inconnus ne peuvent pas exposer accidentellement une véritable application d’administration ou multimédia.
Pourquoi seule la connexion HTTPS atteint-elle la mauvaise application ?
HTTPS peut utiliser un écouteur, un chemin SNI, un site de certificat ou une règle de fallback différents de ceux de HTTP. Testez indépendamment les deux points d’entrée avant de modifier le routage global.
Produits recommandés
Assistance et conseils
Plus à lire
Plex peut-il partager un GPU avec un autre conteneur Docker ?
Plex et un autre conteneur peuvent souvent accéder au même GPU, mais vous devez tester la prise en charge des pilotes, le mappage des...
Comment déterminer si une erreur Plex vient du client ou du serveur
Reproduisez le même élément sur un autre client, comparez le chemin de session, puis recueillez les preuves côté serveur uniquement après que la portée...
Comment configurer le cache de Plex et le stockage temporaire du transcodage
Protégez l’état persistant de Plex en plaçant les fichiers temporaires de transcodage sur un stockage local adapté, puis vérifiez le nettoyage, l’espace libre et...
