Magento-endurbeiningarlykkjan þín er líklega ekki VPN-ið

Þú sérð 302 í aðgangsskrá, verslunin hleðst ekki í gegnum VPN og niðurstaðan skrifar sig sjálf. Sú niðurstaða er yfirleitt röng á áhugaverðan hátt. Svar um endurbeiningu skráir áfangastað sem sagt var við vafrann að fara á, og segir ekkert um hvort göngin, skírteinið eða forritið olli vandamálinu. Skrárlínan er byrjun rannsóknarinnar, ekki niðurstaða hennar.

302 segir hvert, ekki hvers vegna

Færsla í aðgangsskrá skráir beiðnina, stöðuna og stærðina og sleppir yfirleitt Location-hausnum sem skiptir máli. Ein endurbeining getur verið algjörlega eðlileg: kanónískt hýsingarheiti, staðfærsla lokaskástafsins, skipti yfir í HTTPS. Það sem þú þarft er röðin, því einn stökk og lykkja eru mismunandi gallar með mismunandi eigendur. Endurtekin stökk milli skema benda á meðferð URL og skema. Stökk á nafn sem vafrinn getur ekki leyst bendir alveg annað.

Ekkert af þessu er sönnun um VPN-ið. Göngin eru leið; endurbeiningin er fyrirmæli sem forritið skrifaði.

Náðu keðjunni, ekki skrárlínunni

Notaðu netssýn vafrans og skráðu fjögur svæði fyrir hvert stökk: umbeðið URL, stöðuna, Location-hausinn og tímann. Endaðu annaðhvort með lokasvarinu eða tengivillunni, því áhugaverða tilvikið er stökkið sem klárast aldrei. Gerðu þetta einu sinni á leið sem virkar og einu sinni á þeirri sem bregst, með sama reikningi og sömu leiðsögn. Að bera saman tvær keðjur er meira virði en nokkur ein lína í skrá.

Hafðu þessa skráningu leynd. URL bera setuauðkenni og vistað vafrasafn ber meira en þú átt von á. Fjarlægðu fyrirspurnastrengina áður en þú límir eitthvað í miða.

Hugmynd forritsins um eigið URL

Magento býr til algjör URL út frá stillingunum, afmörkuð eftir vefsvæði eða verslunarsýn. bin/magento config:show web/secure/base_url prentar gildið sem forritið telur rétt, og það er oft hýsingarheiti sem er eftir af byggingu eða flutningi í stað þess sem vafrinn notaði. Ef þar er nefndur innri hýsill er vafranum sendur á stað sem hann kemst ekki á, og engin breyting á göngunum lagar það.

Berðu saman öruggu og óöruggu grunn-URL við opinberu nöfnin fyrir framan þig. Misræmi í hvorugu þeirra framleiðir nákvæmlega þá endurbeiningu sem þú ert að stara á.

Hausar trausts proxy eru samningur

Þegar TLS endar í álagsdreifinum sér forritið hreint HTTP og það verður að segja því annað. Stilling offloader-haussins nefnir hausinn sem proxyið setur, til dæmis framsendu siðaregluna, og forritið treystir honum við skemaákvarðanir.

Það traust er samningur við eitt proxy, ekki almenn heimild. Að samþykkja hausinn frá handahófskenndum biðlurum leyfir hverjum sem er að halda fram skema, og þess vegna á hann aðeins heima þar sem tilnefnt proxy setur hann. Ef heiti haussins og hegðun proxysins stemma ekki, býr forritið til endurbeiningar á skema sem vafrinn notaði aldrei, og lykkjan lokast. Athugaðu proxy-stillinguna og stillingu forritsins saman, og tæmdu síðan stillingarskyndiminnið svo breytingin taki gildi.

Þegar lykkjan er seta, ekki leið

Keðja sem snýr alltaf aftur að innskráningu er yfirleitt vandamál með köku. Athugaðu hvort setu-kakan var gefin út fyrir hýsingarheitið sem vafrinn notaði í raun og hvort hún var merkt örugg á tengingu sem vafrinn telur örugga. Kaka sem er afmörkuð á rangt lén framleiðir innskráningarlykkju sem lítur nákvæmlega út eins og bilun í leiðsögn.

Lagaðu sannaða misræmið hjá eiganda þess, hvort sem það er grunn-URL, lén kökunnar eða proxy-samningurinn, og prófaðu síðan alla leiðsögnina aftur í stað þess að horfa á eitt 302 hverfa. Að slökkva á HTTPS-kröfum til að brjóta lykkjuna skipir endurbeiningu fyrir verra vandamál. Þegar breytingunni er lokið skaltu athuga göngin sérstaklega: biddu um þekkta einkaaðlind og staðfestu að hún komi, svo næsta endurbeining hafi hreinan grunn til samanburðar.