તમારો Magento રીડાયરેક્ટ લૂપ કદાચ VPN નથી

તમે એક્સેસ લોગમાં 302 જુઓ છો, સ્ટોરફ્રન્ટ VPN દ્વારા લોડ થતું નથી, અને તારણ જાતે જ લખાઈ જાય છે. એ તારણ સામાન્ય રીતે રસપ્રદ રીતે ખોટું હોય છે. રીડાયરેક્ટ પ્રતિસાદ એ ગંતવ્ય નોંધે છે જ્યાં બ્રાઉઝરને જવાનું કહેવાયું હતું, અને સમસ્યા ટનલે, પ્રમાણપત્રે કે એપ્લિકેશને ઊભી કરી તે વિશે કંઈ કહેતું નથી. લોગની લાઇન તપાસની શરૂઆત છે, તેનું તારણ નહીં.

302 કહે છે ક્યાં, કેમ નહીં

એક્સેસ લોગની નોંધ વિનંતી, સ્થિતિ અને કદ નોંધે છે, અને સામાન્ય રીતે મહત્ત્વનું Location હેડર છોડી દે છે. એક રીડાયરેક્ટ સંપૂર્ણ સામાન્ય હોઈ શકે: પ્રમાણભૂત હોસ્ટનામ, અંતિમ સ્લેશનું સામાન્યીકરણ, HTTPS તરફ સંક્રમણ. તમને ક્રમની જરૂર છે, કારણ કે એક કૂદકો અને લૂપ અલગ-અલગ ખામીઓ છે, અલગ-અલગ માલિકો સાથે. સ્કીમ વચ્ચે વારંવાર કૂદકા URL અને સ્કીમ હેન્ડલિંગ તરફ ઇશારો કરે છે. પણ જે નામ બ્રાઉઝર ઉકેલી શકતું નથી ત્યાંનો કૂદકો સાવ બીજી જગ્યા તરફ ઇશારો કરે છે.

એમાંથી કંઈ પણ VPN વિશે પુરાવો નથી. ટનલ એક માર્ગ છે; રીડાયરેક્ટ એ સૂચના છે જે એપ્લિકેશને લખી છે.

શૃંખલા પકડો, લોગની લાઇન નહીં

બ્રાઉઝરના નેટવર્ક વ્યૂનો ઉપયોગ કરો અને દરેક કૂદકા માટે ચાર ક્ષેત્રો નોંધો: વિનંતી કરેલ URL, સ્થિતિ, Location હેડર અને સમય. અંતિમ પ્રતિસાદ અથવા કનેક્શન ભૂલ સાથે પૂર્ણ કરો, કારણ કે રસપ્રદ કિસ્સો એ કૂદકો છે જે કદી પૂર્ણ થતો નથી. આ એક વાર કાર્યક્ષમ માર્ગ પર અને એક વાર નિષ્ફળ માર્ગ પર કરો, એ જ ખાતું અને એ જ નેવિગેશન સાથે. બે શૃંખલાઓની સરખામણી લોગની કોઈ પણ એક લાઇન કરતાં વધુ મૂલ્યવાન છે.

એ રેકોર્ડ ખાનગી રાખો. URL સેશન ઓળખકર્તા ધરાવે છે, અને સાચવેલું બ્રાઉઝર આર્કાઇવ તમે ધારો છો તેના કરતાં વધુ ધરાવે છે. ટિકિટમાં કંઈ પણ પેસ્ટ કરતાં પહેલાં ક્વેરી સ્ટ્રિંગ દૂર કરો.

એપ્લિકેશનની પોતાની URL વિશેની કલ્પના

Magento કન્ફિગરેશનમાંથી સંપૂર્ણ URL બનાવે છે, દરેક વેબસાઇટ કે સ્ટોર વ્યૂ પ્રમાણે મર્યાદિત. bin/magento config:show web/secure/base_url એ મૂલ્ય છાપે છે જે એપ્લિકેશન માને છે, અને તે ઘણી વાર બિલ્ડ કે માઇગ્રેશનમાંથી બચેલું હોસ્ટનામ હોય છે, બ્રાઉઝરે વાપરેલું નામ નહીં. જો ત્યાં આંતરિક હોસ્ટનું નામ હોય, તો બ્રાઉઝરને એવી જગ્યાએ મોકલાય છે જ્યાં તે જઈ શકતું નથી, અને ટનલમાં કોઈ ફેરફાર તેને સુધારતો નથી.

સુરક્ષિત અને અસુરક્ષિત બેઝ URLની તમારી સામેના જાહેર નામો સાથે સરખામણી કરો. બંનેમાંથી કોઈ પણ એકમાં અસંગતિ એ જ રીડાયરેક્ટ ઉત્પન્ન કરે છે જે તમે જોઈ રહ્યા છો.

વિશ્વસનીય પ્રોક્સી હેડર એક કરાર છે

જ્યારે TLS લોડ બેલેન્સર પર પૂર્ણ થાય છે, ત્યારે એપ્લિકેશન સાદું HTTP જુએ છે અને તેને બીજી રીતે કહેવું પડે છે. ઓફલોડર હેડર સેટિંગ એ હેડરનું નામ આપે છે જે પ્રોક્સી સેટ કરે છે, જેમ કે ફોરવર્ડ કરેલ પ્રોટોકોલ, અને એપ્લિકેશન સ્કીમ નિર્ણયોમાં તેના પર ભરોસો કરે છે.

એ ભરોસો એક પ્રોક્સી સાથેનો કરાર છે, સામાન્ય પરવાનગી નહીં. મનસ્વી ક્લાયન્ટ્સ તરફથી હેડર સ્વીકારવાથી કોઈ પણ સ્કીમનો દાવો કરી શકે છે, તેથી તે ફક્ત ત્યાં જ હોવો જોઈએ જ્યાં નિયુક્ત પ્રોક્સી તેને સેટ કરે છે. જો હેડરનું નામ અને પ્રોક્સીનું વર્તન મળતું ન હોય, તો એપ્લિકેશન એવી સ્કીમ તરફ રીડાયરેક્ટ બનાવે છે જે બ્રાઉઝરે કદી વાપરી નથી, અને લૂપ બંધ થાય છે. પ્રોક્સી કન્ફિગરેશન અને એપ્લિકેશન સેટિંગ સાથે ચકાસો, પછી ફેરફાર અમલમાં આવે તે માટે કન્ફિગરેશન કેશ ફ્લશ કરો.

જ્યારે લૂપ સેશન હોય, રૂટ નહીં

જે શૃંખલા હંમેશા સાઇન-ઇન પર પાછી આવે છે તે સામાન્ય રીતે કૂકીની સમસ્યા છે. સેશન કૂકી બ્રાઉઝરે ખરેખર વાપરેલા હોસ્ટનામ માટે જારી થઈ હતી કે નહીં, અને બ્રાઉઝર જે કનેક્શનને સુરક્ષિત ગણે છે તેના પર તે સુરક્ષિત તરીકે ચિહ્નિત થઈ હતી કે નહીં, તે તપાસો. ખોટા ડોમેન સાથે જોડાયેલી કૂકી એવો લોગિન લૂપ બનાવે છે જે બરાબર રાઉટિંગ નિષ્ફળતા જેવો દેખાય છે.

સાબિત થયેલી અસંગતિ તેના માલિક પાસે સુધારો, પછી તે બેઝ URL હોય, કૂકી ડોમેન હોય કે પ્રોક્સી કરાર, અને પછી એક 302 અદૃશ્ય થવાનું જોવાને બદલે આખું નેવિગેશન ફરી ચકાસો. લૂપ તોડવા માટે HTTPS જરૂરિયાતો બંધ કરવી એ રીડાયરેક્ટને વધુ ખરાબ સમસ્યા સાથે બદલે છે. ફેરફાર થઈ ગયા પછી ટનલ અલગથી ચકાસો: જાણીતા ખાનગી સ્રોતની વિનંતી કરો અને તે પહોંચે છે તેની ખાતરી કરો, જેથી આગલા રીડાયરેક્ટ પાસે સરખામણી માટે સ્વચ્છ આધારરેખા હોય.