proxy_redirect ne relie pas NGINX à votre hôte VPN
proxy_redirect réécrit des en-têtes dans une réponse déjà arrivée ; il ne choisit jamais l’upstream. Vérifiez proxy_pass, la route vers le backend, puis les en-têtes.
Le nom contient le mot redirect, alors on le colle dans un bloc location quand un backend derrière le VPN est injoignable. Rien ne change, et la conclusion évidente est que la directive est cassée ou exige une autre syntaxe. Ce qui s’est réellement produit est plus simple et moins flatteur : proxy_redirect agit sur une réponse déjà revenue, et dans ce déploiement aucune requête n’est jamais allée aussi loin.
Deux directives, deux moments dans une requête
Une requête HTTP à travers un proxy inverse traverse plusieurs décisions dans l’ordre, et les deux directives se situent aux extrémités opposées de cette séquence. L’une choisit où va la requête. L’autre modifie certains en-têtes dans la réponse qui revient.
| Directive | When it acts | What it can change |
|---|---|---|
proxy_pass | Before any bytes leave the proxy | Which upstream receives the request |
proxy_redirect | After the upstream responds | Matching Location and Refresh text |
Cet ordre est toute la réponse. Si la deuxième ligne ne s’exécute jamais parce que la première a échoué, la deuxième directive n’est pas mal configurée, elle est simplement inatteignable. Vous aurez beau réécrire la deuxième ligne, elle ne créera pas la réponse qu’elle devait modifier. Diagnostiquez depuis la première ligne vers l’extérieur, et le comportement déroutant se résout en une route manquante ou une connexion refusée.
Le choix de l’upstream appartient à proxy_pass
Supposons que NGINX tourne sur un hôte d’entrée public et atteigne une application à 10.40.0.20:8080 via son VPN. Le fragment qui choisit cette application ressemble à ceci, dans un bloc server existant :
location / {
proxy_pass http://10.40.0.20:8080;
}Utilisez le schéma, l’adresse et le port réels, et traitez ceci comme un fragment et non comme un déploiement. L’hôte d’entrée doit aussi tenir la route VPN, un chemin de transfert autorisé et un trafic retour fonctionnel vers ce service, car un proxy qui atteint une adresse sur le papier a encore besoin de l’accord du noyau.
La référence du module proxy garde la sélection de l’upstream séparée de la réécriture des en-têtes de réponse, et note qu’une valeur proxy_pass contenant une URI change la façon dont le préfixe location correspondant est remplacé. Ajouter ou retirer des composants de chemin sans vérifier l’URL attendue par l’application est un moyen fiable de produire un 404 qui ressemble à une panne de routage.
proxy_redirect corrige les réponses qui divulguent une adresse privée
Une fois le trafic établi, un backend peut répondre avec un en-tête Location nommant son adresse privée. Un navigateur qui suit cet en-tête quitte le point d’entrée public et tente d’atteindre quelque chose qu’il ne peut pas résoudre. Une réécriture de réponse configurée exprès fait correspondre l’URL privée à la publique :
proxy_redirect http://10.40.0.20:8080/ https://app.example.com/;Remplacez les deux côtés par des valeurs réelles. Comprenez aussi la portée étroite : le texte des en-têtes Location et Refresh correspondants est réécrit, mais les URL intégrées dans du HTML, du JavaScript ou des fichiers téléchargés ne le sont pas.
Si une application construit des liens absolus partout, la solution durable est sa propre configuration d’URL externe, pas une liste croissante de règles de réécriture sur le proxy. Ajouter des règles jusqu’à ce que la sortie paraisse correcte produit une configuration qui échoue sur la première page que personne n’a testée. Un seul réglage correct de l’application remplace toute la collection.
Ce qu’une réécriture d’en-tête ne peut pas réparer
Plusieurs problèmes voisins ressemblent à des problèmes de redirection et n’en sont pas. L’en-tête Host envoyé à l’upstream peut devoir correspondre à l’hôte virtuel du backend. Un upstream TLS peut exiger un nom de serveur précis plus une vérification du certificat, et réécrire un en-tête de réponse n’aide pour ni l’un ni l’autre.
La portée des cookies et les attributs de domaine appartiennent à l’application et à sa configuration. Un proxy peut jeter ou réécrire des en-têtes toute la journée et produire malgré tout une session qui échoue à la deuxième requête, parce que le cookie a été émis pour un hôte que le navigateur n’a jamais visité. Cette panne paraît intermittente, et c’est pourquoi elle survit si longtemps dans une file de tickets. Lire le domaine du cookie termine généralement l’enquête en une minute.
Gardez aussi l’authentification et la sélection du backend limitées à l’application prévue. Un proxy inverse public devrait exposer une seule application via le VPN du serveur plutôt que devenir une passerelle générique vers chaque adresse privée que cet hôte peut atteindre. Un seul location générique qui transfère tout ce que demande l’appelant transforme un service exposé en carte de votre réseau privé. Nommez l’upstream explicitement et gardez-le là.
Testez dans l’ordre où la requête voyage
Confirmez trois choses dans l’ordre : NGINX a choisi le location prévu, il a mené une requête jusqu’au backend, et le navigateur a suivi toute redirection ultérieure et chargé les sous-ressources. Chaque étape a ses propres lignes de log, et les lire dans l’ordre transforme un 502 vague en constat précis.
La distinction dont vous avez besoin est entre une connexion montante échouée et un navigateur envoyé vers un nom privé injoignable. La première apparaît dans le log d’erreurs du proxy ; la seconde apparaît comme une requête qui n’arrive jamais, le navigateur se plaignant d’un hôte qu’il ne peut pas résoudre. Deux problèmes différents, deux fichiers différents, et un seul des deux concerne proxy_redirect.