Perché un reverse proxy reindirizza un’app al dominio di un’altra app?
Un proxy inverso può indirizzare un’app al dominio di un’altra app quando il backend o il middleware genera reindirizzamenti utilizzando l’hostname pubblico errato.
In uno stack self-hosted ZimaSpace, diverse app possono condividere lo stesso proxy, mentre ciascuna si aspetta il proprio URL di base pubblico. Se Host, X-Forwarded-Host, lo schema, il middleware o un URL canonico configurato a livello di app punta a un altro servizio, la prima pagina può caricarsi correttamente, mentre il successivo reindirizzamento 301, 302 o callback di accesso può cambiare dominio.
Controlla l’host e lo schema inviati al backend
Acquisisci le intestazioni della richiesta sul proxy e sul backend mentre riproduci il reindirizzamento.
Una guida mirata all’implementazione di un proxy inverso su inoltro dell’host e dello schema al backend aiuta a isolare questo aspetto perché affronta lo stesso problema specifico invece di limitarsi a definire il protocollo sottostante.
Correggi le intestazioni del proxy prima di modificare gli URL dell’applicazione. Un backend non può generare il reindirizzamento assoluto corretto se ritiene che la richiesta abbia utilizzato un altro host.
Esamina nello specifico X-Forwarded-Host
Alcuni framework utilizzano X-Forwarded-Host invece dell’intestazione Host originale per generare URL assoluti.
Una guida mirata alle intestazioni HTTP su X-Forwarded-Host mantiene l’hostname pubblico aiuta a isolare questo aspetto perché affronta lo stesso problema specifico invece di limitarsi a definire il protocollo sottostante.
Confronta questa intestazione tra l’app funzionante e quella che esegue il reindirizzamento errato. Rimuovi le sovrascritture globali che obbligano ogni backend a utilizzare un unico dominio.
Controlla se l’app genera URL assoluti
Cerca le impostazioni del framework che considerano attendibili le intestazioni del proxy e costruiscono link canonici o reindirizzamenti.
Un blog mirato sul debug pratico dei proxy su gli URL assoluti possono essere errati dietro un proxy aiuta a isolare questo aspetto perché affronta lo stesso problema specifico invece di limitarsi a definire il protocollo sottostante.
Correggi la configurazione di attendibilità del proxy nel framework o l’impostazione dell’URL pubblico, invece di riscrivere ogni reindirizzamento sul proxy.
Verifica l’URL di base dell’app o il dominio canonico
Molte app self-hosted memorizzano l’URL del sito indipendentemente dalla regola del proxy.
Un caso di studio mirato e pratico su un’app dietro un proxy, disponibile su l’URL di base dell’app può sovrascrivere l’hostname del proxy, aiuta a isolare questo aspetto perché affronta lo stesso problema specifico invece di limitarsi a definire il protocollo sottostante.
Confronta i valori dell’URL dell’applicazione memorizzati dopo migrazioni o ripristini. Un database copiato può contenere l’hostname canonico dell’ambiente di un’altra app.
Controlla il middleware di reindirizzamento prima del backend
Una regola del proxy può riscrivere intenzionalmente lo schema o l’host prima che la richiesta raggiunga l’applicazione.
Una guida pratica mirata su Traefik per homelab, disponibile su il middleware di reindirizzamento può sostituire l’host, aiuta a isolare questo aspetto perché affronta lo stesso problema specifico invece di limitarsi a definire il protocollo sottostante.
Disabilita solo il middleware di reindirizzamento sospetto su un router di test. Mantieni separata l’imposizione di HTTPS dai reindirizzamenti tra domini.
Controlla gli URL di callback OAuth e OIDC
I flussi di autenticazione spesso rivelano un hostname pubblico errato perché il provider convalida un URI di reindirizzamento esatto.
Un articolo mirato sulla risoluzione dei problemi OIDC su le callback OIDC dipendono dall’URL pubblico del proxy aiuta a isolare questo aspetto perché affronta lo stesso problema specifico invece di limitarsi a definire il protocollo sottostante.
Confronta insieme issuer, callback, intestazioni inoltrate e URL di base dell’app. Il normale caricamento di una pagina non dimostra che il percorso della callback di accesso sia corretto.
Ripeti il test del percorso esatto del server domestico
Dopo aver modificato una variabile, ripeti lo stesso flusso NAS o self-hosted dallo stesso client invece di passare a un test diverso che potrebbe utilizzare un altro percorso.
La guida ZimaSpace correlata su il percorso di rete adiacente del server domestico aiuta a mantenere la verifica finale legata allo stesso ambiente self-hosted.
La correzione è completa solo quando il sintomo originale rimane risolto dopo la riconnessione, il riavvio del servizio e un secondo trasferimento o una seconda richiesta controllata.
Domande frequenti
Il DNS può causare un HTTP 301 o 302?
Il DNS restituisce solo un indirizzo. Il reindirizzamento viene generato dal proxy, dal livello di autenticazione o dall’applicazione.
Perché l’app corretta si carica prima che il browser cambi dominio?
Il percorso iniziale del proxy può essere corretto, mentre il backend genera in seguito un reindirizzamento assoluto utilizzando un URL di base o un host inoltrato errato.
Devo riscrivere ogni intestazione Location nel proxy?
No. Correggi prima la fonte dell’hostname errato; una riscrittura generica delle risposte può nascondere gli errori di configurazione dell’applicazione.
Prodotti consigliati
Supporto e consigli
Altro da leggere
Plex può condividere una GPU con un altro container Docker?
Plex e un altro container possono spesso accedere alla stessa GPU, ma è necessario testare il supporto dei driver, la mappatura dei dispositivi, il...
Come capire se un errore di Plex proviene dal client o dal server
Riproduci lo stesso elemento su un altro client, confronta il percorso della sessione, quindi raccogli le prove dal server solo dopo che l’ambito ti...
Come configurare la cache di Plex e l’archiviazione temporanea per la transcodifica
Proteggi lo stato persistente di Plex collocando i file temporanei di transcodifica su un’unità locale adatta, quindi verifica la pulizia, lo spazio libero e...
