Come risolvere il problema di un reverse proxy che indirizza un dominio all’app sbagliata dopo l’aggiunta di una regola catch-all
Un proxy inverso può inviare un dominio all’app sbagliata quando una nuova route catch-all corrisponde in modo più ampio o ha priorità superiore rispetto alla regola host prevista.
Questo problema è più specifico di un generico reindirizzamento al dominio sbagliato o di un problema DNS. Il test fondamentale consiste nel verificare se il dominio corretto continua a raggiungere l’IP proxy e il certificato previsti, ma il proxy seleziona il backend sbagliato solo dopo l’aggiunta della nuova route predefinita. Confronta le corrispondenze e le priorità delle route prima di modificare il DNS, gli URL di base dell’applicazione o i certificati.
Dimostra che la regola catch-all ha cambiato la selezione del backend
Invia la stessa richiesta al dominio prima e dopo aver disabilitato soltanto la nuova route catch-all o predefinita. Registra il log di accesso del proxy, il router o il blocco server selezionato, l’indirizzo del backend, l’indicatore della risposta e il certificato.
Una guida pratica sul server predefinito di Nginx avverte che le regole catch-all possono intercettare il traffico anche quando esistono già diversi host virtuali espliciti.
Se la disattivazione del fallback ripristina immediatamente l’app prevista, lascia invariati il DNS e l’applicazione backend. Il passaggio successivo consiste nel fare in modo che la route specifica prevalga senza rimuovere il comportamento di fallback sicuro per gli hostname sconosciuti.
Verifica che la regola per l’host specifico corrisponda ancora esattamente
Confronta l’hostname richiesto con la regola della route prevista carattere per carattere, includendo il sottodominio, i limiti dei caratteri jolly, i punti finali negli strumenti di test e il fatto che la regola ascolti sullo stesso punto di ingresso HTTP o HTTPS della catch-all.
Una guida sui proxy inversi per più app mostra che le regole hostname selezionano backend diversi solo quando l’host in ingresso corrisponde alla regola effettivamente caricata dal proxy.
Correggi una corrispondenza host incompleta o errata prima di modificare la priorità. Aumentare la priorità di una regola che non corrisponde mai rende soltanto la configurazione più difficile da comprendere.
Confronta la priorità della route con quella della catch-all
Per i proxy che supportano una priorità esplicita o derivata, controlla quale regola prevale quando sia l’host specifico sia il fallback ampio possono corrispondere alla stessa richiesta. Registra la regola valutata, non soltanto l’ordine nel file di configurazione.
Un esempio di catch-all in Traefik assegna volutamente al fallback una priorità inferiore rispetto alle route effettive, in modo che i servizi specifici vengano valutati per primi.
Imposta il fallback al di sotto di ogni route applicativa prevista e ripeti il test. Non risolvere il problema assegnando numeri enormi e arbitrari a ogni router; mantieni invece uno schema di priorità semplice e documentato, in grado di resistere all’aggiunta futura di nuove app.
Controlla il server predefinito sui proxy in stile Nginx
Su Nginx e configurazioni simili, determina quale blocco server diventa predefinito per quell’indirizzo e quella porta di ascolto quando non viene trovata alcuna corrispondenza hostname. Il primo blocco caricato può diventare il fallback se non ne viene definito esplicitamente uno predefinito.
Un articolo mirato sulla risoluzione dei problemi di Nginx spiega perché gli host senza corrispondenza raggiungono i server predefiniti invece di essere rifiutati silenziosamente.
Usa una risposta predefinita neutra o un servizio di errore invece di rendere un’applicazione reale il fallback. In questo modo un hostname sconosciuto o digitato male non potrà esporre accidentalmente un’altra app self-hosted.
Controlla separatamente i fallback HTTP e HTTPS
Una catch-all aggiunta per la porta 80 non si comporta automaticamente allo stesso modo sulla porta 443. Il routing TLS, SNI, i punti di ingresso separati o una seconda catch-all possono far sì che soltanto le richieste HTTPS raggiungano l’app sbagliata.
Un caso di risoluzione dei problemi in Caddy descrive una catch-all con comportamento diverso a seconda dello schema e mostra perché la route specifica per lo schema deve essere testata direttamente.
Richiedi lo stesso hostname sia tramite HTTP sia tramite HTTPS e registra l’handler selezionato. Correggi il fallback sul punto di ingresso interessato invece di modificare il percorso del protocollo che funziona.
Mantieni il fallback neutro e ripeti il test per ogni dominio conosciuto
Dopo aver corretto l’ambito della corrispondenza o la priorità, fai in modo che il fallback restituisca un errore 404, 421 o una pagina di errore controllata e neutra, invece di inoltrare ogni hostname sconosciuto a un’unica app di produzione. Poi testa una volta ciascun dominio self-hosted conosciuto.
Una panoramica dell’architettura dei proxy inversi sottolinea che è il proxy a decidere il backend dopo che la richiesta lo raggiunge; per questo la correttezza del DNS da sola non dimostra la correttezza del routing.
La correzione è completa quando ogni hostname conosciuto raggiunge l’app prevista e un hostname sconosciuto raggiunge soltanto il fallback neutro. L’articolo correlato di ZimaSpace sul proxy inverso che reindirizza un’app verso un altro dominio è il ramo successivo quando il proxy seleziona il backend corretto ma l’applicazione cambia dominio in un secondo momento.
Domande frequenti
Il DNS può fare in modo che prevalga una route catch-all?
Il DNS può inviare la richiesta all’IP proxy sbagliato, ma quando il proxy corretto riceve l’hostname previsto, la corrispondenza delle route è una decisione del proxy. Verifica separatamente entrambi i livelli.
La catch-all dovrebbe inoltrare le richieste a un’app dashboard?
Di solito no. Una destinazione di errore neutra è più sicura, perché gli errori di digitazione e gli hostname sconosciuti non possono esporre accidentalmente una vera applicazione di amministrazione o multimediale.
Perché soltanto HTTPS raggiunge l’app sbagliata?
HTTPS può utilizzare un listener, un percorso SNI, un sito certificato o una regola di fallback diversi da HTTP. Testa separatamente entrambi i punti di ingresso prima di modificare il routing globale.
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...
