Puncte:0

Ordinea de potrivire a locației Nginx

drapel th

Am citit câteva articole despre potrivirea nginx și au spus că blocul de locație mai lung ar trebui să fie potrivit mai întâi.

Cu toate acestea, când încerc să configurez un proxy pentru două locații, prima locație înregistrează tot traficul, iar a doua nu primește nimic.

Aceasta este configurația serverului meu.

Server {
asculta 80;
nume_server IP;
#return 301 https://$host$request_uri;
# nginx/sites-available/fdp.conf

locație /lls/ {
    proxy_set_header Gazdă $gazdă;
    proxy_set_header X-Forwarded-Proto $schema;
    proxy_pass_request_headers activat;
    proxy_pass http://IP:8080;
}

Locație / {
    proxy_set_header Gazdă $gazdă;
    proxy_set_header X-Forwarded-Proto $schema;
    proxy_pass_request_headers activat;
    proxy_pass http://IP:8000/;
}
}

De ce nginx nu redirecționează traficul către proxy-ul /lls? De asemenea, am încercat să folosesc locația regex ~ /lls, dar nici nu am avut noroc aici. Ambele aplicații rulează când vizitez porturile de pe IP.

Am o aplicație care rulează sub portul 8000. Scopul meu este să adaug o a doua aplicație care rulează sub /lls. Pentru aceasta vreau ca tot traficul să meargă în portul 8000, cu excepția cazului în care /lls este în url, atunci vreau ca tot traficul să meargă la a doua aplicație de pe portul 8080. În situația actuală, traficul destinat portului 8080 este preluat de portul 8000.

Ieșirea curl -v IP/lls:

* Încerc IP: 80...
* TCP_NODELAY setat
* Conectat la portul IP (IP) 80 (#0)
> GET /lls HTTP/1.1
> Gazdă: IP
> User-Agent: curl/7.68.0
> Accept: */*
>
* Marcați pachetul ca nu acceptă mai multe utilizări
< HTTP/1.1 400
< Server: nginx/1.18.0 (Ubuntu)
< Data: Sâmbătă, 09 Oct 2021 08:41:47 GMT
< Content-Type: text/turtle
< Transfer-Coding: fragmentat
< Conexiune: păstrați-vă în viață
< Acces-Control-Permite-Origine: *
< Access-Control-Allow-Heaters: Origine,Authorization,Accept,Content-Type
< Access-Control-Expose-Headers: Locație,Link
< Permite: GET,POST,PUT,PATCH,DELETE
< Acces-Control-Permite-Metode: GET,POST,PUT,PATCH,DELETE
< X-Content-Type-Options: nosniff
< X-XSS-Protecție: 1; mod=bloc
< Cache-Control: no-cache, no-store, max-age=0, must-revalidate
< Pragma: fără cache
< Expiră: 0
< X-Frame-Options: DENY
<
* Conexiunea #0 la IP gazdă a rămas intactă

Ieșire lsof -Pi :8080

COMANDA PID UTILIZATOR TIP FD DIMENSIUNEA DISPOZITIV/OPRIT NUMELE NODULUI
docker-pr 2698710 root 4u IPv4 8351515 0t0 TCP *:8080 (ASCULTATE)
docker-pr 2698721 root 4u IPv6 8351519 0t0 TCP *:8080 (ASCULTATE)

Ieșire lsof -Pi :8000

 COMANDA PID UTILIZATOR TIP FD DIMENSIUNEA DISPOZITIV/OPRIT NUMELE NODULUI
docker-pr 2615262 root 4u IPv4 7781060 0t0 TCP *:8000 (ASCULTATE)
docker-pr 2615267 root 4u IPv6 7781066 0t0 TCP *:8000 (ASCULTATE)
drapel cn
Comentariile nu sunt pentru discuții extinse; această conversație a fost [mutată în chat](https://chat.stackexchange.com/rooms/130389/discussion-on-question-by-moopsish-nginx-location-matching-order).

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.