Dit Magento-omdirigeringsloop er sandsynligvis ikke VPN'en

Du ser 302 i adgangsloggen, butikken indlæses ikke gennem VPN'en, og konklusionen skriver sig selv. Den konklusion er som regel forkert på en interessant måde. Et omdirigeringssvar registrerer en destination, som browseren blev bedt om at besøge, og det siger intet om, hvorvidt tunnelen, certifikatet eller applikationen skabte problemet. Loglinjen er begyndelsen på undersøgelsen, ikke dens fund.

En 302 siger hvor, ikke hvorfor

En post i adgangsloggen registrerer anmodningen, status og størrelse og udelader som regel det Location-hovede, der betyder noget. En enkelt omdirigering kan være helt normal: et kanonisk værtsnavn, en normalisering af den afsluttende skråstreg, et skift til HTTPS. Det, du har brug for, er rækkefølgen, fordi et enkelt hop og et loop er forskellige fejl med forskellige ejere. Gentagne hop mellem skemaer peger på håndtering af URL og skema. Et hop til et navn, browseren ikke kan slå op, peger et helt andet sted hen.

Intet af det er bevis om VPN'en. Tunnelen er en vej; omdirigeringen er en instruks, applikationen skrev.

Fang kæden, ikke loglinjen

Brug browserens netværksvisning, og notér fire felter per hop: den anmodede URL, status, Location-hovedet og tiden. Slut af med enten det endelige svar eller forbindelsesfejlen, fordi det interessante tilfælde er hoppet, der aldrig fuldføres. Gør det én gang på en fungerende vej og én gang på den fejlende, med samme konto og samme navigation. At sammenligne to kæder er mere værd end nogen enkelt linje i en log.

Hold den registrering privat. URL'er bærer sessions-id'er, og et gemt browserarkiv bærer mere, end du forventer. Fjern forespørgselsstrenge, før du indsætter noget i en billet.

Applikationens opfattelse af sin egen URL

Magento genererer absolutte URL'er ud fra konfigurationen, afgrænset per websted eller butiksvisning. bin/magento config:show web/secure/base_url udskriver den værdi, applikationen tror på, og den er ofte et værtsnavn, der er tilbage fra et build eller en migrering, i stedet for det, browseren brugte. Hvis den angiver en intern vært, sendes browseren et sted hen, hvor den ikke kan komme, og ingen ændring af tunnelen retter det.

Sammenlign de sikre og usikre basis-URL'er med de offentlige navne foran dig. Uoverensstemmelse i en af dem giver præcis den omdirigering, du stirrer på.

Betroede proxy-hoveder er en kontrakt

Når TLS slutter ved en load balancer, ser applikationen ren HTTP og skal have at vide, at det er anderledes. Indstillingen for offloader-hovedet angiver det hovede, proxyen sætter, fx det videresendte protokol, og applikationen stoler på det ved beslutninger om skema.

Den tillid er en kontrakt med én proxy, ikke en generel tilladelse. At acceptere hovedet fra vilkårlige klienter lader enhver hævde et skema, og derfor hører det kun til der, hvor en udpeget proxy sætter det. Hvis hovedets navn og proxyens adfærd ikke stemmer overens, genererer applikationen omdirigeringer til et skema, browseren aldrig brugte, og loopet lukker sig. Kontrollér proxykonfigurationen og applikationsindstillingen sammen, og ryd derefter konfigurationscachen, så ændringen træder i kraft.

Når loopet er en session, ikke en rute

En kæde, der altid vender tilbage til login, er som regel et cookie-problem. Undersøg, om sessionscookien blev udstedt til det værtsnavn, browseren faktisk brugte, og om den blev markeret som sikker på en forbindelse, browseren anser for sikker. En cookie, der er afgrænset til det forkerte domæne, giver et login-loop, der ser præcis ud som en routingfejl.

Ret den påviste uoverensstemmelse hos dens ejer, hvad enten det er basis-URL'en, cookie-domænet eller proxykontrakten, og test derefter hele navigationen igen i stedet for at se en enkelt 302 forsvinde. At slå HTTPS-krav fra for at bryde loopet bytter en omdirigering for et værre problem. Når ændringen er gjort, kontrollér tunnelen separat: anmod om en kendt privat ressource, og bekræft at den ankommer, så den næste omdirigering har en ren baseline at sammenligne med.