Redirection Nginx via Proxy, Réécrire et Préserver l'URL

Vous devriez utiliser la partie URI dans la directive proxy_pass. De plus, vous avez inversé l'ordre des arguments de la directive proxy_redirect, et probablement vous n'en avez pas besoin du tout. Nginx a une valeur par défaut raisonnable pour cette directive.

Dans ce cas, votre bloc location pourrait être très simple :

location /some/path/ {
    proxy_pass http://192.168.1.24/;
    # notez ce slash ---------^
    proxy_set_header Host $host;
}

Vous pouvez utiliser la configuration suivante pour avoir une correspondance 100% transparente entre /some/path/ côté client et / côté serveur.

Notez que c'est la seule réponse jusqu'à présent qui traiterait également automatiquement les chemins absolus générant des erreurs 404 Not Found, à condition que l'en-tête HTTP Referer correct soit envoyé par le navigateur, donc, tous ces gifs devraient continuer à se charger sans avoir besoin de modifier le HTML sous-jacent (ce qui est non seulement coûteux, mais n'est pas non plus pris en charge sans modules supplémentaires non compilés par défaut).

location /some/path/ {
    proxy_pass http://192.168.1.24/; # notez le slash final !
}
location / {
    error_page 404 = @404;
    return 404; # normalement, cela serait d'abord `try_files`
}
location @404 {
    add_header Vary Referer; # malheureusement, pas d'effet sur le 404
    if ($http_referer ~ ://[^/]*(/some/path|/the/other)/) {
        return 302 $1$uri;
    }
    return 404 "Not Found\n";
}

Vous pouvez trouver la preuve de concept complète et le produit minimal viable dans le référentiel https://github.com/cnst/StackOverflow.cnst.nginx.conf.

Voici un test pour confirmer que tous les cas limites semblent fonctionner:

curl -v -H 'Referer: http://example.su/some/path/page.html' localhost:6586/and/more.gif | & fgrep -e HTTP/ -e Referer -e Location
> GET /and/more.gif HTTP/1.1
> Referer: http://example.su/some/path/page.html
< HTTP/1.1 302 Moved Temporarily
< Location: http://localhost:6586/some/path/and/more.gif
< Vary: Referer

curl -v localhost:6586/and/more.gif | & fgrep -e HTTP/ -e Referer -e Location
> GET /and/more.gif HTTP/1.1
< HTTP/1.1 404 Not Found

curl -v localhost:6586/some/path/and/more.gif | & fgrep -e HTTP/ -e Referer -e Location -e uri
> GET /some/path/and/more.gif HTTP/1.1
< HTTP/1.1 200 OK
request_uri:    /and/more.gif

P.S. Si vous avez beaucoup de chemins différents à mapper, au lieu de faire une comparaison regex de $http_referer dans un if dans location @404, vous voudrez peut-être utiliser la directive map basée sur le contexte global à la place.

Remarquez également que les slashes finaux dans à la fois le proxy_pass, ainsi que le location dans lequel il est contenu, sont assez importants selon une réponse connexe.

Références:

• http://nginx.org/r/location
• http://nginx.org/r/error_page
• http://nginx.org/r/if
• http://nginx.org/r/return
• http://nginx.org/r/add_header

Lorsque cette barre oblique est ajoutée à un jenkins proxifié par nginx, vous êtes présenté avec l'erreur "Il semble que votre configuration de reverse proxy est incorrecte".

proxy_pass          http://localhost:8080/;

Retirez ceci -----------------------------^

Il devrait être lu

proxy_pass          http://localhost:8080;

Nous pouvons simplifier la réponse de cnst à cela :

server {
    listen          80;
    server_name     www.example.com;

    location /some/path/ {
        # Comme expliqué dans les autres réponses, c'est suffisant pour que nginx
        # réécrive les URLs des requêtes.
        proxy_pass http://192.168.1.24/;
    }

    location / {
        # Rediriger les liens, expliqué ci-dessous
        if ($http_referer ~ ^http://www\.example\.com/some/path) {
            return 302 /some/path/$request_uri;
        }

        index index.html;
        root  /var/www/example.com/htdocs;
    }
}

Le problème avec le reverse proxy d'un serveur web ignorant (192.168.1.24) vers un sous-chemin (/some/path/) est que nginx renvoie généralement tous les contenus de réponse du serveur reverse proxy sans les modifier, ce qui inclut souvent des URLs absolus comme /index.html. Quand un navigateur visite /some/path/, cet exemple d'URL pointerait alors vers http://www.example.com/index.html, mais la ressource n'est disponible qu'à http://www.example.com/some/path/index.html !

Cependant, il existe une solution : L'en-tête "Referer" est envoyé par le navigateur pour indiquer au serveur d'où vient l'utilisateur. En le faisant correspondre avec notre "URL proxy", nous pouvons rediriger toutes les requêtes faites depuis /some/path/ vers la bonne URL.

if ($http_referer ~ ^http://www\.example\.com/some/path) {

~ est l'opérateur regex sensible à la casse, et comme nous utilisons regex ici, nous devons échapper les points avec \. Le caractère ^ au début de l'URL signifie que la chaîne doit commencer par l'expression qu'il précède.

return 302 /some/path/$request_uri;

HTTP 302 signifie "Trouvé" (à l'origine "Temporairement déplacé"). Cela dit au navigateur : "Hé, j'ai trouvé ce que vous avez demandé, mais c'est en réalité à /some/path/[...]." Le navigateur effectue ensuite la requête vers la bonne URL.

Évidemment, cette solution suppose et nécessite que le serveur web à 192.168.1.24 ne connaisse rien du reverse proxy et ne préfixe /some/path/ à ses liens. Sinon, la partie de redirection n'est pas nécessaire. Ces liens pourraient ressembler à ceci : /abc, qui serait alors redirigé par nginx vers /some/path/abc, si l'en-tête Referer est défini sur http://www.example.com/some/path.