Proxy inverso Nginx + riscrittura URL

Nginx è in esecuzione sulla porta 80 e la sto usando per invertire gli URL proxy con il percorso /fooper la porta in 3200questo modo:

location /foo {
                proxy_pass http://localhost:3200;
                proxy_redirect     off;
                proxy_set_header   Host $host;
}

Funziona bene, ma ho un'applicazione sulla porta 3200, per la quale non voglio che l'iniziale /foovenga inviata. Cioè - quando accedo http://localhost/foo/bar, voglio solo /baressere il percorso ricevuto dall'app. Quindi ho provato ad aggiungere questa linea al blocco di posizione sopra:

rewrite ^(.*)foo(.*)$ http://localhost:3200/$2 permanent;

Ciò causa 302 reindirizzamenti (modifica dell'URL), ma voglio 301. Cosa devo fare?

Qualsiasi reindirizzamento a localhost non ha senso da un sistema remoto (ad esempio il browser Web del client). Quindi i flag di riscrittura permanenti (301) o reindirizzamento (302) non sono utilizzabili nel tuo caso.

Prova a seguire la configurazione usando una regola di riscrittura trasparente:

location  /foo {
  rewrite /foo/(.*) /$1  break;
  proxy_pass         http://localhost:3200;
  proxy_redirect     off;
  proxy_set_header   Host $host;
}

Utilizzare curl -iper testare le riscritture. Una modifica molto sottile alla regola può causare un reindirizzamento a nginx.

La semplice corrispondenza del prefisso di località funziona per questo senza usare una regola di riscrittura fintanto che si specifica un URI nella direttiva proxy_pass:

location /foo {
  proxy_pass http://localhost:3200/;
}

Si noti il ​​supplemento /alla fine della proxy_passdirettiva. NGINX rimuoverà il prefisso corrispondente /fooe passerà il resto al server back-end nell'URI /. Pertanto, http://myserver:80/foo/barinvieremo al backend all'indirizzo http://localhost:3200/bar.

Dai documenti NGINX su proxy_pass :

Se la direttiva proxy_pass è specificata con un URI, quando una richiesta viene passata al server, la parte di un URI di richiesta normalizzata corrispondente alla posizione viene sostituita da un URI specificato nella direttiva:

Il modo più corretto in assoluto e le migliori pratiche sono generalmente le seguenti:

location /foo/ {
    proxy_pass http://localhost:3200/; # note the trailing slash!
}

• Nota la terribile importanza della barra finaleproxy_pass , che altera automaticamente la $urivariabile in modo che /foo/il front-end corrisponda /al back-end. Non è necessaria una rewritedirettiva esplicita .

• Inoltre, tieni presente che anche il trailing /inlocation è abbastanza importante - senza di esso, rischi di avere URL dall'aspetto strano sul tuo sito in un punto (ad esempio, un lavoro /fooenin aggiunta a /foo/en).

  Inoltre, il trascinamento /in locationcon proxy_passassicura anche qualche trattamento speciale , come per la documentazione della locationdirettiva, per causare efficacemente un implicito location = /foo {return 301 /foo/;}pure.

  Quindi, definendo un locationcon la barra finale come sopra, non solo si garantisce che gli URL suffisso senza barra come /fooennon saranno validi, ma anche che anche /foouna barra senza barra continuerà a funzionare.

Documentazione di riferimento:

• http://nginx.org/r/location
• http://nginx.org/r/proxy_pass

provare

location /foo {
    proxy_pass http://localhost:3200/;
    ....

o

location ^~ /foo {
    proxy_pass http://localhost:3200/;
    ....

@Terabuck Siamo spiacenti per non aver ancora risposto a nessun rappresentante.

Non dovresti usare localhost perché dipende dal fatto che l'applicazione è in esecuzione su un server con un file hosts. l'host locale è solo una traduzione predefinita in 127.0.0.1. Non c'è nulla che affermi che è necessario disporre di questi file host. È molto comune averne uno.

Avere un'interfaccia di loopback è di nuovo un'altra cosa comune da cui dipendere, ma si è ancora dipendenti dall'interfaccia di loopback sullo stack di rete. È un caso raro non avere questi due. Se mai ti preoccupi di questo. Almeno su unix / linux hai l'opzione per i socket. Ciò eliminerà la necessità per lo stack di rete di raggiungere l'host locale. Prestare attenzione con questo approccio in quanto vi sono alcuni fattori che entreranno in vigore nel sistema operativo host. Come il numero di file aperti ecc.