Problema ar putea fi legată de lipsa de conștientizare a protocolului atunci când vine vorba de cache. Este destul de tipic ca o solicitare HTTP care ar trebui redirecționată către o solicitare HTTPS să ajungă în cache, care redirecționează necondiționat utilizatorii către versiunea HTTPS, chiar dacă aceștia au solicitat de fapt o versiune HTTPS.
Există mai multe modalități de a remedia acest lucru, în funcție de tipul de server web pe care îl utilizați.
ieșire varnishlog
Dar înainte să putem sări la concluzii, vreau să văd câteva vernislog ieșire.
Aș dori să văd rezultatul următoarei comenzi când are loc bucla de redirecționare:
varnishlog -g request -q "ReqUrl eq '/'"
Presupunerea este că problema apare și pe pagina de pornire pe care am adăugat-o ca interogare VSL la vernislog comanda.
ti-am observat varnishncsa ieșire, dar, din păcate, este prea limitată în ceea ce privește ieșirea. vernislog este mult mai bun pentru depanare, în timp ce varnishncsa e doar.
Testarea ipotezei
Dacă bucla de redirecționare este într-adevăr cauzată de lipsa de cunoaștere a protocolului, putem declanșa problema după cum urmează:
- Alerga
varnishadm ban obj.status "!=" 0 pentru a goli memoria cache
- Apelați adresa URL HTTP simplă a site-ului web pentru a vă asigura că această versiune este stocată în cache
- Apelați adresa URL HTTPS a site-ului web pentru a verifica dacă sunteți sau nu blocat în bucla de redirecționare
Remedierea problemei
Dacă toate testele se adună și ipoteza este dovedită, soluția este de fapt destul de simplă.
Dacă utilizați Apache ca server web, puteți adăuga următorul conținut la dvs .htaccess fişier:
SetEnvIf X-Forwarded-Proto „https” HTTPS=on
Adăugarea antetului Variază: X-Forwarded-Proto
În caz contrar, puteți adăuga următorul cod la fișierul VCL:
sub vcl_backend_response {
dacă(beresp.http.Vary) {
if(beresp.http.Vary !~ "X-Forwarded-Proto") {
set beresp.http.Vary = set beresp.http.Vary + ", X-Forwarded-Proto";
}
} altfel {
set beresp.http.Vary = "X-Forwarded-Proto";
}
}
Adăugând X-Forwarded-Proto la Varia antetul se va asigura că Varnish creează obiecte separate în cache pentru HTTP și pentru HTTPS.
De asemenea, presupun că proxy-ul dvs. TLS trimite de fapt un X-Forwarded-Proto antet.
Actualizare: inspectarea jurnalelor
După câteva dus-întors în comentarii, am primit câteva jurnale perspicace prin intermediul https://pastebin.com/QzPh1r5R care explică ce se întâmplă.
În ** << BeReq >> 951078 poti vedea X-Forwarded-Proto: http antet. Aceasta înseamnă că solicitarea a fost trimisă printr-o solicitare HTTP simplă. Acest tip de solicitare ar trebui să aibă ca rezultat o redirecționare 301 și se face conform următoarelor linii de jurnal:
-- BerespProtocol HTTP/1.1
-- BerespStatus 301
-- BerespReason mutat definitiv
-- BerespHeader Data: joi, 13 ianuarie 2022 08:55:17 GMT
-- BerespHeader Server: Apache
-- BerespHeader Locație: https://[domeniul lac]/
-- BerespHeader Lungime conținut: 238
-- BerespHeader Content-Type: text/html; set de caractere=iso-8859-1
-- TTL RFC 120 10 0 1642064118 1642064118 1642064117 0 0 stocabil în cache
Nu numai că redirecționarea are loc, dar este și stocată în cache timp de 120 de secunde. De asemenea, este interesant de văzut că nu există Variază: X-Forwarded-Proto antet.
Mai târziu, cel * << Solicitare >> 951080 tranzacția apare în jurnalele. Vedem următoarele antete de solicitare:
- ReqHeader X-Forwarded-Proto: https
- Gazdă ReqHeader: [un alt domeniu de lac]
Deci, aceasta este o solicitare HTTPS pentru un alt domeniu Varnish și, din anumite motive, are ca rezultat o accesare în cache care returnează un Varia antet:
- RespHeader variază: Accept-Encoding, Cookie, X-Forwarded-Proto
- VCL_call HIT
- Hit 886585 90003.966201 10.000000 0.000000
Nu numai că vezi lovitura, dar poți și concluziona că obiectul a fost introdus în cache prin tranzacție 886585.
Deși este bine să ai un Varia antet, acesta conține Cookie valoare care este periculoasă.Aceasta înseamnă că un obiect separat va fi stocat în cache pentru fiecare valoare cookie posibilă care este prezentată lui Varnish. Acest lucru este destul de periculos, așa că vă rugăm să eliminați Cookie de la Varia antet și stick cu Variază: Accept-Encoding, X-Forwarded-Proto.
Ultima tranzacție la care m-am uitat este * << Solicitare >> 951082. Are o X-Forwarded-Proto: https antetul cererii și nu ar trebui să aibă ca rezultat o redirecționare 301, dar, din păcate, o face.
The Lovit eticheta expune câteva informații interesante:
- Hit 951078 82.391648 10.000000 0.000000
Obiectul care a fost lovit a fost introdus inițial în cache prin tranzacție 951078. Dacă ai fost foarte atent, acesta a fost primul pe care l-am acoperit. Această tranzacție a fost o tranzacție numai HTTP care a dus la redirecționarea 301.
Și exact acesta este obiectul care este returnat. Deci, chiar dacă solicitați conținut HTTPS, sunteți în continuare redirecționat și așa ajungeți în bucla nesfârșită.
Dacă te uiți la răspunsul care este returnat prin tranzacție 951082, nu vezi Varia antet:
- RespProtocol HTTP/1.1
- RespStatus 301
- RespReason mutat permanent
- Data RespHeader: joi, 13 ianuarie 2022 08:55:17 GMT
- Server RespHeader: Apache
- Locație RespHeader: https://[domeniul lac]/
- Lungimea conținutului RespHeader: 238
- RespHeader Content-Type: text/html; set de caractere=iso-8859-1
- RespHeader X-Lac: 951082 951078
- Vârsta RespHeader: 37
- RespHeader prin: 1.1 lac (Lac/7.0)
Concluzie: vă rugăm să vă asigurați că X-Forwarded-Proto este adăugat la dvs Varia antet. Acesta va preveni blocarea în bucla de redirecționare.
