Via Magento-rijekta buklo probable ne estas la VPN

Vi vidas 302 en la alirprotokolo, la butiko ne ŝargiĝas tra la VPN, kaj la konkludo skribas sin mem. Tiu konkludo kutime malĝustas laŭ interesa maniero. Rijekta respondo registras celon, al kiu oni diris al la retumilo iri, kaj ĝi diras nenion pri tio, ĉu la tunelo, la atestilo aŭ la aplikaĵo kreis la problemon. La protokollinio estas la komenco de la esploro, ne ĝia rezulto.

302 diras kien, ne kial

Enira ero en la alirprotokolo registras la peton, la staton kaj la grandecon, kaj ĝi kutime preterlasas la Location-kaplinion, kiu gravas. Unu rijekto povas esti tute normala: kanonika gastigantnomo, normaligo de la fina oblikvo, ŝanĝo al HTTPS. Tio, kion vi bezonas, estas la sinsekvo, ĉar unu salto kaj buklo estas malsamaj paneoj kun malsamaj posedantoj. Ripetaj saltoj inter skemoj montras al traktado de URL kaj skemo. Salto al nomo, kiun la retumilo ne povas solvi, montras tute aliloken.

Neniom da tio estas pruvo pri la VPN. La tunelo estas vojo; la rijekto estas instrukcio, kiun la aplikaĵo skribis.

Kaptu la ĉenon, ne la protokollinion

Uzu la retan vidon de la retumilo kaj registru kvar kampojn por ĉiu salto: la petitan URL-on, la staton, la Location-kaplinion kaj la tempon. Finu aŭ per la fina respondo aŭ per la konekta eraro, ĉar la interesa kazo estas la salto, kiu neniam kompletiĝas. Faru tion unufoje sur funkcianta vojo kaj unufoje sur la malsukcesa, kun la sama konto kaj la sama navigado. Kompari du ĉenojn valoras pli ol iu ajn unuopa linio en protokolo.

Tenu tiun registron privata. URL-oj portas seanckodojn, kaj konservita retumila arkivo portas pli ol vi atendas. Forigu demandoĉenojn antaŭ ol alglui ion en bileton.

La imago de la aplikaĵo pri sia propra URL

Magento generas absolutajn URL-ojn el agordo, limigitajn laŭ retejo aŭ butika vido. bin/magento config:show web/secure/base_url presas la valoron, kiun la aplikaĵo kredas, kaj tio ofte estas gastigantnomo restinta de konstruo aŭ migrado anstataŭ tiu, kiun la retumilo uzis. Se ĝi nomas internan gastiganton, la retumilo estas sendata tien, kien ĝi ne povas iri, kaj neniu tunela ŝanĝo tion riparas.

Komparu la sekurajn kaj nesekurajn bazajn URL-ojn kun la publikaj nomoj antaŭ vi. Mispareco en iu ajn el ili produktas ĝuste la rijketon, kiun vi rigardas.

Fidindaj prokuraj kaplinioj estas kontrakto

Kiam TLS finiĝas ĉe ŝarĝa balancilo, la aplikaĵo vidas simplan HTTP kaj oni devas diri al ĝi alie. La agordo de la elŝuta kaplinio nomas la kaplinion, kiun la prokurilo starigas, ekzemple la plusenditan protokolon, kaj la aplikaĵo fidas ĝin por skemaj decidoj.

Tiu fido estas kontrakto kun unu prokurilo, ne ĝenerala permeso. Akcepti la kaplinion de arbitraj klientoj lasas iun ajn postuli skemon, tial ĝi apartenas nur tien, kie difinita prokurilo starigas ĝin. Se la kaplinia nomo kaj la konduto de la prokurilo malkongruas, la aplikaĵo generas rijketojn al skemo, kiun la retumilo neniam uzis, kaj la buklo fermiĝas. Kontrolu la prokuran agordon kaj la aplikaĵan agordon kune, poste malplenigu la agordan kaŝmemoron, por ke la ŝanĝo efiku.

Kiam la buklo estas seanco, ne vojo

Ĉeno, kiu ĉiam revenas al ensaluto, kutime estas kuketa problemo. Kontrolu, ĉu la seanca kuketo estis eldonita por la gastigantnomo, kiun la retumilo efektive uzis, kaj ĉu ĝi estis markita kiel sekura sur konekto, kiun la retumilo konsideras sekura. Kuketo limigita al la malĝusta domajno produktas ensalutan buklon, kiu aspektas ĝuste kiel enkursiga paneo.

Riparu la pruvitan misparecon ĉe ĝia posedanto, ĉu temas pri la baza URL, la kuketa domajno aŭ la prokura kontrakto, poste retestu la tutan navigadon anstataŭ rigardi unu 302 malaperi. Malŝalti HTTPS-postulojn por rompi la buklon interŝanĝas rijketon kontraŭ pli malbona problemo. Kiam la ŝanĝo estas farita, kontrolu la tunelon aparte: petu konatan privatan rimedon kaj konfirmu, ke ĝi alvenas, por ke la sekva rijekto havu puran bazlinion por kompari.