Il tuo loop di reindirizzamento Magento probabilmente non è la VPN

Vedi 302 nel log di accesso, la vetrina non si carica attraverso la VPN e la conclusione si scrive da sola. Quella conclusione è di solito sbagliata in modo interessante. Una risposta di reindirizzamento registra una destinazione verso cui è stato detto al browser di andare e non dice nulla se il problema sia stato prodotto dal tunnel, dal certificato o dall'applicazione. La riga di log è l'inizio dell'indagine, non il suo risultato.

Un 302 dice dove, non perché

Una voce del log di accesso registra la richiesta, lo stato e la dimensione, e di solito omette l'intestazione Location che conta. Un singolo reindirizzamento può essere del tutto normale: un nome host canonico, una normalizzazione della barra finale, un passaggio a HTTPS. Ciò che serve è la sequenza, perché un solo salto e un loop sono guasti diversi con responsabili diversi. I salti ripetuti tra schemi indicano la gestione di URL e schema. Un salto verso un nome che il browser non riesce a risolvere indica un luogo del tutto diverso.

Nessuna di queste è una prova sulla VPN. Il tunnel è un percorso; il reindirizzamento è un'istruzione scritta dall'applicazione.

Cattura la catena, non la riga di log

Usa la vista di rete del browser e annota quattro campi per salto: l'URL richiesto, lo stato, l'intestazione Location e l'ora. Termina con la risposta finale o con l'errore di connessione, perché il caso interessante è il salto che non si completa mai. Fallo una volta su un percorso funzionante e una volta su quello che fallisce, con lo stesso account e la stessa navigazione. Confrontare due catene vale più di qualsiasi singola riga di un log.

Mantieni privata quella registrazione. Gli URL portano identificatori di sessione e un archivio del browser salvato porta più di quanto ti aspetti. Rimuovi le stringhe di query prima di incollare qualcosa in un ticket.

L'idea che l'applicazione ha del proprio URL

Magento genera URL assolute dalla configurazione, con ambito per sito web o vista store. bin/magento config:show web/secure/base_url stampa il valore in cui l'applicazione crede, e spesso è un nome host rimasto da una build o da una migrazione invece di quello usato dal browser. Se lì è indicato un host interno, il browser viene inviato dove non può arrivare, e nessuna modifica al tunnel lo risolve.

Confronta gli URL di base sicuro e non sicuro con i nomi pubblici che hai davanti. Una discrepanza in uno dei due produce esattamente il reindirizzamento che stai fissando.

Le intestazioni del proxy fidato sono un contratto

Quando il TLS termina su un bilanciatore di carico, l'applicazione vede HTTP semplice e deve essere avvisata del contrario. L'impostazione dell'intestazione offloader indica l'intestazione che il proxy imposta, come il protocollo inoltrato, e l'applicazione si fida di essa per le decisioni sullo schema.

Quella fiducia è un contratto con un proxy, non un permesso generale. Accettare l'intestazione da client arbitrari permette a chiunque di rivendicare uno schema, ed è per questo che appartiene solo dove la imposta un proxy designato. Se il nome dell'intestazione e il comportamento del proxy non concordano, l'applicazione genera reindirizzamenti verso uno schema che il browser non ha mai usato, e il loop si chiude. Controlla insieme la configurazione del proxy e l'impostazione dell'applicazione, poi svuota la cache di configurazione perché la modifica abbia effetto.

Quando il loop è una sessione, non una rotta

Una catena che torna sempre all'accesso è di solito un problema di cookie. Verifica se il cookie di sessione è stato emesso per il nome host che il browser ha realmente usato, e se è stato contrassegnato come sicuro su una connessione che il browser considera sicura. Un cookie limitato al dominio sbagliato produce un loop di accesso che assomiglia esattamente a un guasto di instradamento.

Correggi la discrepanza dimostrata presso il suo responsabile, che sia l'URL di base, il dominio del cookie o il contratto con il proxy, poi ritesta l'intera navigazione invece di guardare sparire un singolo 302. Disattivare i requisiti HTTPS per rompere il loop scambia un reindirizzamento con un problema peggiore. Quando la modifica è fatta, controlla il tunnel separatamente: richiedi una risorsa privata nota e conferma che arrivi, così il prossimo reindirizzamento ha una base pulita con cui confrontarsi.