Am configurat nginx pentru a termina o conexiune SSL și a redirecționa solicitările către un backend http. Clientul face o serie de solicitări de fundal, dintre care una eșuează 400 Cerere proastă ori de câte ori încearcă să negocieze conexiunea SSL. Dacă nu trebuie să negocieze conexiunea - de ex. dacă o altă solicitare de fundal tocmai a fost postată cu succes, cererea reușește. Examinarea filei de rețea Chrome nu arată nicio diferență relevantă între o solicitare reușită și o solicitare nereușită. Călătoria mea este postată aici în acest raport de eroare, dar iată ce am putut distila până acum:
Conexiunea SSL
Când solicitarea problemei reușește, pot spune că nu trebuie să negocieze conexiunea SSL, vizualizând fila Timing a solicitării de rețea (în Chrome): Timing - cerere reușită
Pe de altă parte, ori de câte ori cererea eșuează, văd că a încercat să negocieze conexiunea SSL, așa cum se vede în această imagine: Timing - cerere eșuată
Manipularea Nginx
Prin verificarea jurnalelor de acces la aplicație, am stabilit că nginx este cel care returnează fișierul 400 Solicitare greșită eroare, și nu aplicația HTTP.Când cererea eșuează, toate jurnalele nginx sunt corpul POST Decat metoda HTTP și adresa URL în mod obișnuit (nu am personalizat formatul de jurnal nginx).
Am activat depanarea în jurnalul de erori nginx (cu linia error_log /var/log/nginx/error.log depanare;). Acest lucru îmi permite să văd ce se întâmplă în timpul negocierii SSL (deși nu înțeleg).
După cum am menționat pe scurt mai sus, există și alte solicitări de fundal care reușesc, deși rulează mai rar. După ce orice cerere reușește, toate solicitările vor avea succes pentru o perioadă de timp (până când trebuie să negocieze conexiunea SSL).
În plus, dacă folosesc Copiați ca cURL funcționalitatea din Chrome și rulați cererea ca cerere cURL, reușește întotdeauna. Singura dată când am observat că eșuează este atunci când browserul face cererea.
Jurnalele de depanare Nginx
Iată bitul relevant dintr-o solicitare SSL reușită în jurnale:
22/10/2021 20:37:59 [depanare] 1858722#1858722: *441 gratuit: 0000562A9F69F340
22/10/2021 20:37:59 [depanare] 1858722#1858722: *438 Solicitare http în amonte: „/api/method/frappe.core.doctype.log_settings.log_settings.has_unseen_error_log?”
2021/10/22 20:37:59 [depanare] 1858722#1858722: *438 http antet proces în amonte
22/10/2021 20:37:59 [depanare] 1858722#1858722: *438 malloc: 0000562A9F712CB0:131072
22/10/2021 20:37:59 [depanare] 1858722#1858722: *438 recv: eof:0, avail:-1
22/10/2021 20:37:59 [depanare] 1858722#1858722: *438 recv: fd:9 678 din 131072
22/10/2021 20:37:59 [depanare] 1858722#1858722: *438 stare proxy http 200 „200 OK”
22/10/2021 20:37:59 [depanare] 1858722#1858722: *438 Antet proxy http: „Server: gunicorn”
... mai multe anteturi proxy http...
22/10/2021 20:37:59 [depanare] 1858722#1858722: *438 antet proxy http terminat
22/10/2021 20:37:59 [depanare] 1858722#1858722: *438 antet filtru xslt
22/10/2021 20:37:59 [depanare] 1858722#1858722: *438 HTTP/1.1 200 OK
Server: nginx/1.18.0 (Ubuntu)
... răspuns HTTP
Iată negocierea eșuată:
22/10/2021 20:39:00 [depanare] 1858722#1858722: *446 gratuit: 0000562A9F69F340
22/10/2021 20:39:00 [depanare] 1858722#1858722: *446 http handler de solicitare așteptare
22/10/2021 20:39:00 [depanare] 1858722#1858722: *446 malloc: 0000562A9F69F340:1024
22/10/2021 20:39:00 [depanare] 1858722#1858722: *446 SSL_read: 812
22/10/2021 20:39:00 [depanare] 1858722#1858722: *446 SSL_read: -1
22/10/2021 20:39:00 [depanare] 1858722#1858722: *446 SSL_get_error: 2
22/10/2021 20:39:00 [depanare] 1858722#1858722: *446 conexiune reutilizabilă: 0
22/10/2021 20:39:00 [depanare] 1858722#1858722: *446 posix_memalign: 0000562A9F70CEB0:4096 @16
22/10/2021 20:39:00 [depanare] 1858722#1858722: *446 http linie de solicitare a procesului
2021/10/22 20:39:00 [informații] 1858722#1858722: *446 client a trimis o metodă nevalidă în timp ce citește linia de solicitare a clientului, client: 107.185.20.83, server: atlas-dev.ebs.llc, cerere: "doctype= Eroare+Log&fields=%5B%22%60tabError+Log%60.%60name%60%22%2C%22%60tabError+Log%60.%60owner%60%22%2C%22%60tabError+Log%60.% 60creation%60%22%2C%22%60tabError+Log%60.%60modified%60%22%2C%22%60tabError+Log%60.%60modified_by%60%22%2C%22%60tabError+Log%60. %60_user_tags%60%22%2C%22%60tabError+Log%60.%60_comments%60%22%2C%22%60tabError+Log%60.%60_assign%60%22%2C%22%60tabError+Log%60 .%60_liked_by%60%22%2C%22%60tabError+Log%60.%60docstatus%60%22%2C%22%60tabError+Log%60.%60parent%60%22%2C%22%60tabError+Log% 60.%60parenttype%60%22%2C%22%60tabError+Log%60.%60parentfield%60%22%2C%22%60tabError+Log%60.%60idx%60%22%2C%22%60tabError+Log %60.%60method%60%22%2C%22%60tabError+Log%60.%60seen%60%22%5D&filters=%5B%5D&order_by=%60tabError+Log%60.%60modified%60+desc&start=0&page_start 20&view=List&with_comment_count=true"
2021/10/22 20:39:00 [depanare] 1858722#1858722: *446 http cerere de finalizare: 400, "?" a:1, c:1
22/10/2021 20:39:00 [depanare] 1858722#1858722: *446 cronometru evenimente del: 9: 337737968
2021/10/22 20:39:00 [depanare] 1858722#1858722: *446 http răspuns special: 400, "?"
22/10/2021 20:39:00 [depanare] 1858722#1858722: *446 http set eliminarea corpului
22/10/2021 20:39:00 [depanare] 1858722#1858722: *446 antet filtru xslt
22/10/2021 20:39:00 [depanare] 1858722#1858722: *446 HTTP/1.1 400 Solicitare greșită
Server: nginx/1.18.0 (Ubuntu)
Data: vineri, 22 octombrie 2021 20:39:00 GMT
Tip de conținut: text/html
Lungimea conținutului: 166
Conexiune: aproape
Pe baza a câte puține știu despre jurnalul de depanare nginx (adică, nimic), mi se pare că nginx schimbă metoda HTTP și adresa URL pentru corp în timpul negocierii. Când caută metoda HTTP, aceasta nu mai este prezentă și se sufocă.
Configurare Nginx SSL
Informații despre versiune: nginx/1.18.0 (Ubuntu), Ubuntu 20.04 LTS
Folosesc implicit nginx.conf. Porțiunea SSL a conf. server arată astfel:
asculta 443 ssl;
nume_server [HOST];
root /opt/erpnext/bench/sites;
dimensiunea_buffer_proxy 128k;
proxy_buffers 4 256k;
proxy_busy_buffers_size 256k;
ssl_certificate /etc/letsencrypt/live/[HOST]/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/[HOST]/privkey.pem;
ssl_session_timeout 5m;
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off;
ssl_capsare activată;
ssl_stapling_verify on;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers EECDH+AESGCM:EDH+AESGCM;
ssl_ecdh_curve secp384r1;
ssl_prefer_server_ciphers activat;
Există o redirecționare SSL în partea de jos a fișierului, iar nginx este configurat pentru a server un server web HTTP bazat pe fișiere plate pe portul 8080 dintr-o altă configurație.
Cum pot determina ce cauzează problema? Știu că cererea este formată corect, pentru că cererile identice reușesc... până când trebuie să negocieze conexiunea SSL. Ajutor?
