Magento-omdirigeringsløkken din er sannsynligvis ikke VPN-en

Du ser 302 i tilgangsloggen, butikken lastes ikke gjennom VPN-en, og konklusjonen skriver seg selv. Den konklusjonen er vanligvis feil på en interessant måte. Et omdirigeringssvar registrerer en destinasjon som nettleseren ble bedt om å besøke, og det sier ingenting om hvorvidt tunnelen, sertifikatet eller applikasjonen skapte problemet. Logglinjen er starten på undersøkelsen, ikke funnet.

En 302 sier hvor, ikke hvorfor

En oppføring i tilgangsloggen registrerer forespørselen, statusen og størrelsen, og utelater vanligvis Location-overskriften som betyr noe. En enkelt omdirigering kan være helt normal: et kanonisk vertsnavn, en normalisering av den avsluttende skråstreken, et bytte til HTTPS. Det du trenger er rekkefølgen, fordi ett hopp og en løkke er forskjellige feil med forskjellige eiere. Gjentatte hopp mellom skjemaer peker på håndtering av URL og skjema. Et hopp til et navn nettleseren ikke kan slå opp, peker et helt annet sted.

Ingen av disse er bevis om VPN-en. Tunnelen er en vei; omdirigeringen er en instruks applikasjonen skrev.

Fang kjeden, ikke logglinjen

Bruk nettleserens nettverksvisning og noter fire felt per hopp: den forespurte URL-en, statusen, Location-overskriften og tiden. Avslutt med enten det endelige svaret eller tilkoblingsfeilen, fordi det interessante tilfellet er hoppet som aldri fullføres. Gjør dette én gang på en fungerende vei og én gang på den feilende, med samme konto og samme navigasjon. Å sammenligne to kjeder er verdt mer enn noen enkelt linje i en logg.

Hold den registreringen privat. URL-er bærer sesjonsidentifikatorer, og et lagret nettleserarkiv bærer mer enn du forventer. Fjern spørringsstrenger før du limer noe inn i en sak.

Applikasjonens oppfatning av sin egen URL

Magento genererer absolutte URL-er fra konfigurasjonen, avgrenset per nettsted eller butikkvisning. bin/magento config:show web/secure/base_url skriver ut verdien applikasjonen tror på, og den er ofte et vertsnavn som er igjen fra en bygging eller migrering i stedet for det nettleseren brukte. Hvis den angir en intern vert, sendes nettleseren et sted den ikke kan nå, og ingen endring av tunnelen retter det.

Sammenlign den sikre og den usikre basis-URL-en med de offentlige navnene foran deg. Et avvik i en av dem gir nøyaktig den omdirigeringen du stirrer på.

Overskrifter fra en klarert proxy er en kontrakt

Når TLS avsluttes i en lastbalanserer, ser applikasjonen ren HTTP og må få beskjed om noe annet. Innstillingen for offloader-overskrift navngir overskriften proxyen setter, for eksempel den videresendte protokollen, og applikasjonen stoler på den ved skjemavalg.

Den tilliten er en kontrakt med én proxy, ikke en generell tillatelse. Å godta overskriften fra vilkårlige klienter lar hvem som helst hevde et skjema, og derfor hører den bare hjemme der en utpekt proxy setter den. Hvis overskriftsnavnet og proxyens oppførsel ikke stemmer, genererer applikasjonen omdirigeringer til et skjema nettleseren aldri brukte, og løkken lukker seg. Kontroller proxykonfigurasjonen og applikasjonsinnstillingen sammen, og tøm deretter konfigurasjonsbufferen slik at endringen trer i kraft.

Når løkken er en sesjon, ikke en rute

En kjede som alltid går tilbake til innlogging, er vanligvis et informasjonskapselproblem. Undersøk om sesjonskapselen ble utstedt for vertsnavnet nettleseren faktisk brukte, og om den ble merket som sikker på en tilkobling nettleseren anser som sikker. En informasjonskapsel som er avgrenset til feil domene, gir en innloggingsløkke som ser nøyaktig ut som en rutingfeil.

Rett opp det påviste avviket hos eieren, enten det er basis-URL-en, informasjonskapselens domene eller proxykontrakten, og test deretter hele navigasjonen på nytt i stedet for å se på at én 302 forsvinner. Å slå av HTTPS-krav for å bryte løkken bytter en omdirigering mot et verre problem. Når endringen er gjort, kontroller tunnelen separat: be om en kjent privat ressurs og bekreft at den ankommer, slik at neste omdirigering har en ren basislinje å sammenligne med.