Puncte:0

Configurarea NGINX pentru API-ul REST returnează configurația implicită

drapel cn

Am angajat un VPS pentru a juca cu unele proiecte personale. Pentru a începe, încerc să-l configurez pentru a găzdui un API REST folosind Node.js, deoarece am folosit vreodată Spring Boot doar pentru asta.

Am implementat soluțiile adaptându-mă din următoarele ghiduri:

https://www.robinwieruch.de/node-express-server-rest-api (majoritatea codului API arată astfel)

https://itnext.io/building-restful-api-with-node-js-express-js-and-postgresql-the-right-way-b2e718ad1c66 (dar mă convertesc încet pentru a folosi standardele de aici)

Pentru implementarea propriu-zisă, am schimbat pentru a combina API-ul cu Babel și îl implementez cu PM2.

https://www.nginx.com/blog/deploying-nginx-plus-as-an-api-gateway-part-1/ (nu Plus totusi)

(Toate aceste link-uri sunt disponibile prin http://web.archive.org/ deci nu vor merge nicăieri prea curând)

Am creat un alt proiect Node.js folosind axios pentru a testa cererile REST. Rularea acestuia în același VPS funcționează, dar a trebuit să schimb codul API la care să mă leagă gazdă locală. Înainte, cu adresa de legare nespecificată, aceasta era legată de un IPv6 gazdă locală (dacă am înțeles bine) și, din moment ce domeniul meu nu funcționează cu IPv6, voi rămâne cu IPv4.

Pe partea NGINX, am făcut cele mai multe modificări, deoarece am doar 1 API acum și nu voi folosi echilibrarea încărcării. De asemenea, am schimbat politica de denumire. Voi folosi example.com/app_or_project_name/api_or_web_or_other_kind_of_interface/project_specific_routes.

Iată cum arată configurația mea NGINX. L-am anonimizat și am schimbat pentru a folosi același nume ca exemplul NGINX:

api_backends.conf

depozit din amonte {
    zona api 64k;
    server 127.0.0.1: some_port_number;
}

Acesta este gazda API-ului REST și numărul portului.

api_conf.d/warehouse_api.conf

# API Warehouse
#
locație /depozit/api/ {
    # Configurarea politicii aici (autentificare, limitare a ratei, înregistrare în jurnal, mai multe...)
    #
    access_log /var/log/nginx/warehouse_api.log principal;
    auth_request /_validate_apikey;

    # URI rutare
    #
    proxy_pass http://warehouse;

    întoarce 404; # Prindele pe toate
}

api_gateway.conf

include api_backends.conf;
include api_keys.conf;

Server {
    access_log /var/log/nginx/api_access.log principal; # Fiecare API se poate conecta și la un fișier separat

    asculta 443 ssl;
    nume_server domeniul-meu.net;

    # Configurare TLS
    ssl_certificate /etc/letsencrypt/live/my-domain.net/fullchain.pem; # gestionat de Certbot
    ssl_certificate_key /etc/letsencrypt/live/my-domain.net/privkey.pem; # gestionat de Certbot
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 5m;
    ssl_ciphers HIGH:!aNULL:!MD5;
    ssl_protocols TLSv1.2 TLSv1.3;

    # Definiții API, una per fișier
    include api_conf.d/*.conf;

    # Răspunsuri de eroare
    # error_page 404 = @400; # Căile nevalide sunt tratate ca solicitări incorecte
    proxy_intercept_errors activat; # Nu trimiteți erori de backend către client
    includ api_json_errors.conf; # Răspunsuri de eroare JSON prietenoase cu clienții API
    tip_implicit aplicație/json; # Dacă nu există tip de conținut, presupuneți JSON

    # Validare cheie API
    locație = /_validate_apikey {
        intern;

        dacă ($http_apikey = "") {
            întoarce 401; # Neautorizat
        }
        if ($api_client_name = "") {
            întoarce 403; # Interzis
        }

        întoarcere 204; # OK (fără conținut)
    }

}

S-ar putea să setez proxy_intercept_errors la oprit odată ce funcționează. Va trebui să fac niște teste pentru a vedea ce modificări au răspunsuri.

api_json_errors.conf

La fel ca exemplu.

implicit.conf

Server {
    nume_server www.domeniul-meu.net;

    #access_log /var/log/nginx/host.access.log principal;

    Locație / {
        root /usr/share/nginx/html;
        index index.html index.htm;
    }

    #error_page 404 /404.html;

    # redirecționează paginile de eroare ale serverului către pagina statică /50x.html
    #
    pagina_eroare 500 502 503 504 /50x.html;
    locație = /50x.html {
        root /usr/share/nginx/html;
    }

    # proxy scripturile PHP către Apache care ascultă pe 127.0.0.1:80
    #
    #locație ~ \.php$ {
    # proxy_pass http://127.0.0.1;
    #}

    # treceți scripturile PHP către serverul FastCGI care ascultă pe 127.0.0.1:9000
    #
    #locație ~ \.php$ {
    # rădăcină html;
    # fastcgi_pass 127.0.0.1:9000;
    # fastcgi_index index.php;
    # fastcgi_param SCRIPT_FILENAME /scripts$fastcgi_script_name;
    # include fastcgi_params;
    #}

    # interzice accesul la fișierele .htaccess, dacă rădăcina documentului Apache
    # de acord cu cel al lui nginx
    #
    #locație ~ /\.ht {
    # nega totul;
    #}

    asculta 443 ssl; # gestionat de Certbot
    ssl_certificate /etc/letsencrypt/live/my-domain.net/fullchain.pem; # gestionat de Certbot
    ssl_certificate_key /etc/letsencrypt/live/my-domain.net/privkey.pem; # gestionat de Certbot
    includ /etc/letsencrypt/options-ssl-nginx.conf; # gestionat de Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # gestionat de Certbot

}

Server {
    dacă ($gazdă = www.domeniul-meu.net) {
        returnează 301 https://$host$request_uri;
    } # gestionat de Certbot

    dacă ($gazdă = domeniul-meu.net) {
        returnează 301 https://$host$request_uri;
    } # gestionat de Certbot

    asculta 80;
    nume_server domeniul-meu.net www.domeniul-meu.net;
    întoarce 404; # gestionat de Certbot

}

A trebuit să fac câteva modificări aici, deoarece a existat o combinație de adresă și port care avea un duplicat Server configurație.

nginx.conf

utilizator nginx;
worker_proceses auto;

error_log /var/log/nginx/error.log informații;
pid /var/run/nginx.pid;

load_module /etc/nginx/modules/ngx_http_js_module.so;

evenimente {
    conexiuni_muncitor 1024;
}

http {
    includ /etc/nginx/mime.types;
    aplicație de tip_default/octet-stream;

    log_format principal „$remote_addr - $remote_user [$time_local] „$request” '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log /var/log/nginx/access.log principal;

    sendfile activat;
    #tcp_nopush on;

    keepalive_timeout 65;

    includ /etc/nginx/api_gateway.conf; # Toată configurația gateway-ului API
    includ /etc/nginx/conf.d/*.conf; # Trafic web regulat
}

Când rulez același proiect de testare în afara VPS-ului, obțin următorul rezultat:

{
  mesaj: „Solicitarea eșuată cu codul de stare 404”,
  nume: „Eroare”,
  descriere: nedefinit,
  număr: nedefinit,
  fileName: nedefinit,
  lineNumber: nedefinit,
  columnNumber: nedefinit,
  grămadă: '...',
  config: {
    url: „https://my-domain.net/warehouse/api/messages”,
    metoda: „obține”,
    antete: {
      Accept: „application/json, text/plain, */*”,
      „Acces-Control-Allow-Origin”: „*”,
      „User-Agent”: „axios/0.21.1”
    },
    transformRequest: [[ [Funcția: transformRequest] ],
    transformResponse: [[ [Funcție: transformResponse] ],
    timeout: 0,
    adaptor: [Funcție: httpAdapter],
    xsrfCookieName: „XSRF-TOKEN”,
    xsrfHeaderName: „X-XSRF-TOKEN”,
    maxContentLength: -1,
    maxBodyLength: -1,
    validateStatus: [Funcție: validateStatus],
    apikey: '...',
    date: nedefinite
  },
  cod: nedefinit
}

Un lucru pe care am reușit să-mi dau seama este că eroarea 404 este returnată de warehouse_api.conf pentru că, dacă mă schimb întoarce 404; la alt cod, acesta este codul pe care îl voi primi.

Am activat depanarea în NGINX, dar nu am putut înțelege rezultatul, chiar și după ce am căutat puțin:

2021/07/22 11:54:17 [depanare] nginx_pid#nginx_pid: *757 folosind locația: @404 "/warehouse/api/messages?"
22/07/2021 11:54:31 [depanare] nginx_pid#nginx_pid: *758 http cl:-1 max:1048576
22/07/2021 11:54:31 [depanare] nginx_pid#nginx_pid: *758 faza de rescriere: 3
22/07/2021 11:54:31 [depanare] nginx_pid#nginx_pid: *758 http cerere de finalizare: 404, „/warehouse/api/messages?” a:1, c:1
22/07/2021 11:54:31 [depanare] nginx_pid#nginx_pid: *758 http special response: 404, "/warehouse/api/messages?"
22/07/2021 11:54:31 [depanare] nginx_pid#nginx_pid: *758 locație de testare: „@400”
22/07/2021 11:54:31 [depanare] nginx_pid#nginx_pid: *758 locație de testare: „@401”
22/07/2021 11:54:31 [depanare] nginx_pid#nginx_pid: *758 locație de testare: „@403”
22/07/2021 11:54:31 [depanare] nginx_pid#nginx_pid: *758 locație de testare: „@404”
2021/07/22 11:54:31 [depanare] nginx_pid#nginx_pid: *758 folosind locația: @404 "/warehouse/api/messages?"

Am încercat câteva abordări diferite pentru a căuta despre toate acestea, dar nu am găsit piste.

Deci, ce se întâmplă, ce este în neregulă și cum o repar?

Mulțumesc anticipat.

Actualizare 2021-08-04

În urma răspunsului lui @jose-fernando-lopez-fernandez, m-am schimbat api_conf.d/warehouse_api.conf la următoarele:

# API Warehouse
#
locație /depozit/api/ {
    # Configurarea politicii aici (autentificare, limitare a ratei, înregistrare în jurnal, mai multe...)
    #
    access_log /var/log/nginx/warehouse_api.log principal;
    auth_request /_validate_apikey;

    # URI rutare
    #
    locație /depozit/api/ {
        proxy_pass http://warehouse;
    }

    întoarce 404; # Prindele pe toate
}

pentru a-l menține în concordanță cu exemplele pe care le urmez. Am testat din nou și am primit o eroare 401. Am verificat și am trecut pe lângă apikey incorect.

L-am reparat, am testat din nou și am primit din nou un 404. Dar acum primesc mult mai mult rezultat nginx-debug.

L-am anonimizat. Am înlocuit apikey de un altul pe care l-am generat și nu îl voi folosi pentru nimic.

Am inlocuit si eu posix_memalign, http cleanup add, liber, scriitor de lanț în și malloc prin șiruri de aceeași lungime cu octeți aleatori.Nu stiu daca ar trebui sa fie anonim sau nu. Dacă este necesar pentru rezolvarea acestei întrebări, vă rugăm să întrebați și le voi adăuga înapoi în funcție de necesitatea cunoașterii.

Aici merge:

2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 http cl:-1 max:1048576
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 fază de rescriere: 3
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 fază de post rescriere: 4
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 fază generică: 5
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 fază generică: 6
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 fază generică: 7
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 fază de acces: 8
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 fază de acces: 9
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 fază de acces: 10
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 handler de solicitare de autentificare
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 subsolicitare http „/_validate_apikey?”
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 Solicitare postată http: „/_validate_apikey?”
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 fază de rescriere: 1
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 locație de testare: „/warehouse/api/”
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 locație de testare: „/_validate_apikey”
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 folosind configurația „=/_validate_apikey”
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 http cl:-1 max:1048576
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 fază de rescriere: 3
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 var script http
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 var script http: "o6ZlKSX24MCY/uPwCRl80WAS"
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 Valoare script http: ""
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 script http egal
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 script http egal: nu
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 script http dacă
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 script http dacă: false
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 var script http
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 harta http a început
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 var script http: "o6ZlKSX24MCY/uPwCRl80WAS"
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 hartă http: „o6ZlKSX24MCY/uPwCRl80WAS” „client_one”
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 http script var: "client_one"
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 Valoare script http: ""
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 script http egal
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 script http egal: nu
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 script http dacă
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 script http dacă: false
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 Solicitare de finalizare http: 0, "/_validate_apikey?" a:1, c:2
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 cerere de autentificare făcută s:204
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 Solicitare http wake parent: „/warehouse/api/messages?”
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 Solicitare postată http: „/warehouse/api/messages?”
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 fază de acces: 10
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 handler de solicitare de autentificare
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 variabile de set de cereri de autentificare
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 fază de post acces: 11
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 fază generică: 12
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 fază generică: 13
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 posix_memalign: 218512C89A2ED401:4096 @16
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 http init upstream, temporizator client: 0
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 eveniment de adăugare epoll: fd:3 op:3 ev:80002005
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 copie script http: „Gazdă”
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 http script var: "warehouse"
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 copie script http: „Conexiune”
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 copie script http: „închidere”
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 copie script http: ""
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 copie script http: ""
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 antet proxy http: „Accept: application/json, text/plain, */*”
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 antet proxy http: „Acces-Control-Allow-Origin: *”
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 antet proxy http: „apikey: o6ZlKSX24MCY/uPwCRl80WAS”
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 antet proxy http: „User-Agent: axios/0.21.1”
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 antet proxy http:
„GET /warehouse/api/messages HTTP/1.0
Gazdă: depozit
Conexiune: aproape
Accept: application/json, text/plain, */*
Acces-Control-Permite-Origine: *
apikey: o6ZlKSX24MCY/uPwCRl80WAS
User-Agent: axios/0.21.1

"
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 adăugare de curățare http: 90C9DA232086B6FA
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 obțineți rr peer, încercați: 1
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 soclu de flux 15
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 epoll adăugați conexiune: fd:15 ev:80002005
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 se conectează la 127.0.0.1:some_port_number, fd:15 #2
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 http upstream connect: -2
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 posix_memalign: A9E50626EC2A1D36:128 @16
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 adăugare cronometru eveniment: 15: 60000:878601635
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 Solicitare de finalizare http: -4, "/warehouse/api/messages?" a:1, c:2
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 Număr de solicitări http:2 blk:0
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 cerere de rulare http: „/warehouse/api/messages?”
2021/08/04 17:43:08 [debug] nginx_pid#nginx_pid: *1 http client de verificare în amonte, scrieți evenimentul:1, „/warehouse/api/messages”
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 Solicitare http în amonte: „/warehouse/api/messages?”
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 http upstream send request handler
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 cerere de trimitere http în amonte
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 http upstream trimite corpul cererii
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 scriitor de lanț buf fl:1 s:225
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 scriitor de lanț în: 4C4F626384F523C9
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 writev: 225 din 225
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 lanț de scriitor: 0000000000000000
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 cronometru de evenimente del: 15: 878601635
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 adăugare cronometru eveniment: 15: 60000:878601636
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 Solicitare http în amonte: „/warehouse/api/messages?”
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 antet proces în amonte http
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 malloc: 1D36E73206B5EE11:4096
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 recv: eof:1, avail:-1
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 recv: fd:15 444 din 4096
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 stare proxy http 404 „404 nu a fost găsit”
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 antet proxy http: „X-Powered-By: Express”
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 antet proxy http: „Acces-Control-Allow-Origin: *”
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 Antet proxy http: „Politică-Securitate-Conținut: default-src „niciun””
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 antet proxy http: „X-Content-Type-Options: nosniff”
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 antet proxy http: „Content-Type: text/html; charset=utf-8”
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 antet proxy http: „Lungimea conținutului: 168”
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 antet proxy http: „Data: miercuri, 04 august 2021 17:43:08 GMT”
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 antet proxy http: „Conexiune: închidere”
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 antet proxy http terminat
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 finaliza cererea http upstream: 404
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 finaliza cererea de proxy http
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 gratuit rr peer 1 0
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 închide conexiunea http în amonte: 15
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 gratuit: A9E50626EC2A1D36, neutilizat: 48
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 cronometru de evenimente del: 15: 878601636
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 conexiune reutilizabilă: 0
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 Solicitare de finalizare http: 404, "/warehouse/api/messages?" a:1, c:1
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 http special response: 404, "/warehouse/api/messages?"
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 locație de testare: „@400”
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 locație de testare: „@401”
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 locație de testare: „@403”
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 locație de testare: „@404”
2021/08/04 17:43:08 [depanare] nginx_pid#nginx_pid: *1 folosind locația: @404 "/warehouse/api/messages?"

Mi se pare ciudat că pare să ia în considerare depozit ca nume de gazdă. Pe de altă parte, NGINX definește unele adrese cu acest nume, așa că ar putea avea legătură cu acesta.

Puncte:1
drapel sz

Presupun că tocmai ați eliminat mașinațiunile legate de proxy pentru a fi tratate mai târziu în fișierul API al depozitului, dar asta de fapt nu va funcționa, așa cum ați aflat.

# API Warehouse
#
locație /depozit/api/ {
    # Configurarea politicii aici (autentificare, limitare a ratei, înregistrare în jurnal, mai multe...)
    #
    access_log /var/log/nginx/warehouse_api.log principal;
    auth_request /_validate_apikey;

    # URI de rutare
    #
    proxy_pass http://warehouse;

    întoarce 404; # Prindele pe toate
}

Comparați acea linie responsabilă de rutarea URI cu versiunea din exemplul pe care l-ați conectat.

# API Warehouse
#
locație /api/warehouse/ {
    # Configurarea politicii aici (autentificare, limitare a ratei, înregistrare în jurnal, mai multe...)
    #
    access_log /var/log/nginx/warehouse_api.log principal;
    auth_request /_validate_apikey;

    # URI de rutare
    #
    locație /api/warehouse/inventory {
        proxy_pass http://inventar_depozit;
    }

    locație /api/warehouse/pricing {
        proxy_pass http://warehouse_pricing;
    }

    întoarce 404; # Prindele pe toate
}

Motivul pentru care exemplul funcționează, dar al tău nu are de-a face cu „precedenta” („imediatitatea” ar putea fi un termen mai bun) întoarcere directivă.

Conform documentației, întoarcere directiva determină imediat Nginx să oprească procesarea cererii curente și să revină imediat1. Aceasta înseamnă că dvs proxy_pass directiva nici măcar nu are șansa de a încerca să o execute.

Cu toate acestea, în exemplu, există două locații imbricate, bazate pe prefix, în interiorul blocului, ceea ce înseamnă că Nginx va opta pentru cea mai lungă potrivire. Acesta este motivul pentru care cererea de exemplu a reușit; URI-ul solicitat, https://api.example.com/api/warehouse/pricing/item001, corespundea celui de-al doilea dintre cele două blocuri de locații imbricate și, prin urmare, cererea a fost trimisă prin proxy așa cum era de așteptat.

În concluzie, trebuie să adăugați un bloc de locație imbricat pentru proxy_pass directivă de executat, dacă doriți să replicați exemplul. În caz contrar, se pare că ar trebui să puteți elimina pur și simplu întoarcere directivă și backend-ul dvs. configurat în amonte va fi liber să încerce să-și facă treaba.

GuiRitter avatar
drapel cn
Mulțumiri! Cu toate acestea, acum eșuează mai departe. Am actualizat primul post cu mai multe informații.
Jose Fernando Lopez Fernandez avatar
drapel sz
Cu adevărat nu știu dacă aceasta este sursa problemei, dar API-ul Warehouse este o caracteristică Plus, nu-i așa? Sincer, nu am experiență cu el, așa că s-ar putea să greșesc, dar un 401 sună de parcă ar putea fi, nu?
GuiRitter avatar
drapel cn
Nu văd cum ar putea fi cazul. După înțelegerea mea, API-ul Warehouse este doar un exemplu, în care „Depozitul” este o aplicație ipotetică care accesează un API ipotetic, iar exemplul NGINX arată cum să expuneți acel API.

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.