Jurnalele de erori HTTP înregistrează modul în care a fost gestionată o solicitare eșuată în diferite puncte ale lanțului de livrare. Un browser, un CDN, un proxy și un server de origine pot afișa coduri de stare diferite, deoarece fiecare componentă înregistrează răspunsul pe care l-a primit sau l-a returnat. Compararea înregistrărilor în funcție de timp, detaliile cererii și identificatori ajută la corelarea acelor intrări cu o singură eroare.
Cuprins
De ce o singură cerere eșuată poate avea coduri de stare diferite?
O cerere poate trece prin mai multe componente înainte de a ajunge la serverul de origine. Browserul înregistrează răspunsul vizibil pentru vizitator. Un CDN sau un proxy poate înregistra răspunsul la propriul său nivel. Serverul de origine înregistrează modul în care a gestionat cererea care a ajuns la el.
Aceste înregistrări descriu diferite etape ale aceleiași căi de solicitare. Prin urmare, codul de stare afișat de browser nu este întotdeauna codul de stare generat de serverul de origine. O componentă intermediară poate returna un răspuns înainte ca solicitarea să ajungă la serverul de origine sau poate returna propriul răspuns după ce a primit unul de la un server din amonte.
Din acest motiv, comparați rezultatul browserului cu înregistrările CDN-ului, ale proxy-ului și ale serverului de origine, în loc să considerați un singur cod de stare ca fiind istoricul complet al cererii.
Ce înseamnă un cod de stare 403?
O eroare 403 înseamnă că accesul la resursa solicitată a fost refuzat. Serverul a înțeles solicitarea, dar a refuzat să furnizeze conținutul. Aceasta poate afecta atât vizitatorii site-ului, cât și proprietarii acestuia, iar cauza sau pasul următor pot diferi în funcție de situație. Consultați Motivele pentru mesajul 403 pentru a afla semnificația acestui răspuns.
Dacă un browser afișează 403, dar un alt jurnal conține un statut diferit, verificați ce componentă a generat fiecare înregistrare. Eroarea 403 poate descrie răspunsul final afișat vizitatorului, în timp ce o altă înregistrare poate descrie un răspuns anterior sau din amonte.
Ce câmpuri din jurnal ar trebui să compar?
Utilizați următoarele câmpuri pentru a stabili dacă înregistrările aparțin aceleiași solicitări:
- Timestamp: Comparați data și ora înregistrate de fiecare componentă. Luați în considerare faptul că intrările pot fi create în momente diferite din fluxul cererii.
- Calea cererii: Comparați calea solicitată, inclusiv calea URL relevantă pentru resursa care a eșuat.
- Numele gazdei: Confirmați că fiecare intrare se referă la aceeași gazdă. Căile similare pe nume de gazde diferite reprezintă cereri separate.
- Starea din amonte: Comparați starea primită de la componenta următoare cu starea returnată către componenta anterioară. Acest lucru ajută la identificarea locului în care răspunsul s-a modificat.
- Adresa IP a clientului: Comparați adresa IP a clientului înregistrată la fiecare strat. Un proxy sau un CDN poate înregistra adresa stratului de conectare, în loc de adresa afișată într-un alt jurnal.
- ID-ul cererii: Utilizați același ID al cererii atunci când acesta este prezent în mai multe jurnale. Aceasta este cea mai puternică legătură directă între intrările provenite de la componente diferite.
Cum pot urmări o singură cerere eșuată de-a lungul lanțului de livrare?
- Începeți cu rezultatul din browser. Notați codul de stare, numele de gazdă, calea cererii și ora afișate pentru cererea eșuată.
- Găsiți intrarea corespunzătoare din CDN sau proxy. Potriviți mai întâi numele de gazdă și calea, apoi restrângeți rezultatele după marcajul temporal, adresa IP a clientului sau ID-ul cererii.
- Verificați starea din amonte. Comparați starea primită de CDN sau proxy cu starea pe care a returnat-o browserului.
- Verificați jurnalul de origine. Utilizați aceeași cale, același nume de gazdă, aceeași marcă temporală, aceleași informații despre IP-ul clientului sau același ID al cererii pentru a găsi cererea la serverul de origine.
- Comparați secvența. Înregistrați starea la fiecare punct: browser, CDN sau proxy și serverul de origine. Primul punct în care starea diferă identifică partea din lanț care necesită o analiză mai amănunțită.
Jurnalele serverului web și ale serverului de e-mail sunt instrumente de diagnosticare pentru analizarea erorilor site-ului web și a altor probleme ale serverului. Acestea pot ajuta la identificarea erorilor de execuție a scripturilor și a răspunsurilor incorecte ale serverului. Consultați Jurnalele serverului web și de e-mail.
Ce se întâmplă dacă jurnalele nu afișează aceeași adresă IP a clientului?
Nu utilizați adresa IP a clientului ca singurul câmp de potrivire. Comparați-o cu data și ora, numele gazdei, calea cererii și ID-ul cererii. Adresa IP a clientului poate fi înregistrată diferit în diferite puncte ale lanțului de livrare, în timp ce celelalte câmpuri pot oferi modalități suplimentare de identificare a cererii.
Ce se întâmplă dacă nu există nicio cerere la origine?
Dacă browserul și o componentă intermediară conțin intrări care se potrivesc, dar originea nu are nicio intrare corespunzătoare, comparați câmpurile "stare în amonte" și "ID-ul cererii". Aceste câmpuri ajută la stabilirea faptului dacă cererea a ajuns la origine sau dacă răspunsul a fost generat mai devreme în lanț.
Cum ar trebui să utilizez rezultatul?
Păstrați o secvență scurtă a intrărilor corespunzătoare și notați starea returnată la fiecare nivel. Un cod 403 confirmă că accesul la o resursă a fost refuzat, dar câmpurile de jurnal înconjurătoare arată ce componentă a înregistrat acel răspuns și cum se raportează acesta la celelalte intrări. Acest lucru face investigația mai precisă decât analizarea exclusivă a stării browserului.