Cosa fa sì che il DNS locale restituisca l’IP corretto ma il servizio sbagliato?
Il DNS locale può restituire l’IP corretto del NAS, ma aprire il servizio sbagliato quando il reverse proxy condiviso indirizza l’hostname verso un host virtuale diverso.
Su un home server ZimaSpace, diverse app possono condividere lo stesso indirizzo LAN dietro Nginx, Traefik, Caddy o un altro reverse proxy. Il DNS sceglie solo l’IP di destinazione. Il browser invia comunque un hostname tramite SNI TLS e l’header HTTP Host, mentre il proxy decide quale container riceverà la richiesta.
Verifica che la risposta dello split DNS sia effettivamente prevista
Confronta il record locale con quello pubblico e conferma che entrambi gli hostname debbano terminare sullo stesso reverse proxy.
Un articolo pratico e mirato sullo split DNS per homelab, disponibile su split DNS può restituire un percorso privato, aiuta a isolare questo ramo perché affronta lo stesso micro-problema invece di limitarsi a definire il protocollo sottostante.
Mantieni invariato l’hostname nel browser e modifica solo l’indirizzo restituito dal DNS interno.
Dimostra che il proxy instrada in base all’hostname
Invia richieste con l’hostname previsto e confrontale con l’accesso tramite IP diretto allo stesso NAS.
Una guida pratica e mirata sul reverse proxy per homelab, disponibile su l’header Host seleziona il backend, aiuta a isolare questo ramo perché affronta lo stesso micro-problema invece di limitarsi a definire il protocollo sottostante.
Se l’IP diretto apre un’app predefinita mentre l’hostname apre l’app corretta, il DNS non è la causa: l’instradamento dell’host virtuale si comporta come previsto.
Verifica se l’header Host viene riscritto
Esamina gli header Host e forwarded-host sul proxy e sul backend.
Un approfondimento mirato sulla sicurezza e su HTTP, disponibile su le modifiche all’header Host possono alterare l’instradamento, aiuta a isolare questo ramo perché affronta lo stesso micro-problema invece di limitarsi a definire il protocollo sottostante.
Correggi solo il livello che riscrive l’hostname. Non aggiungere record DNS duplicati per compensare un errore di instradamento HTTP.
Controlla lo SNI TLS prima dell’instradamento HTTP
Più app HTTPS sullo stesso IP devono comunque presentare l’hostname necessario per selezionare il certificato e l’host virtuale corretti.
Una guida pratica e mirata sullo SNI, disponibile su lo SNI seleziona tra più siti HTTPS su un unico IP, aiuta a isolare questo ramo perché affronta lo stesso micro-problema invece di limitarsi a definire il protocollo sottostante.
Confronta il nome del certificato con il percorso del backend. Un certificato appartenente a un’altra app indica che la selezione è avvenuta in modo errato prima che la richiesta raggiungesse il servizio previsto.
Esamina l’host virtuale predefinito
Se nessuna regola per l’hostname corrisponde, molti proxy restituiscono un server predefinito che potrebbe appartenere a un’altra app.
Un articolo mirato sulla risoluzione dei problemi di Nginx, disponibile su un hostname non corrispondente può raggiungere il server predefinito, aiuta a isolare questo ramo perché affronta lo stesso micro-problema invece di limitarsi a definire il protocollo sottostante.
Crea regole esplicite per gli host e una risposta predefinita neutra, invece di lasciare che un’applicazione diventi il catch-all per ogni dominio sconosciuto.
Mantieni separati l’instradamento DNS e quello del proxy
Considera il DNS come il livello che seleziona l’indirizzo e il reverse proxy come quello che seleziona l’applicazione.
Un approfondimento mirato sulla differenza tra DNS e reverse proxy, disponibile su DNS e reverse proxy risolvono livelli di instradamento diversi, aiuta a isolare questo ramo perché affronta lo stesso micro-problema invece di limitarsi a definire il protocollo sottostante.
Esegui nuovamente il test con l’hostname esatto dell’app da un client LAN. Il risultato corretto deve includere il certificato previsto, il percorso corretto del proxy e il backend previsto, senza ricorrere a segnalibri con l’IP diretto.
Ripeti il test sul percorso esatto dell’home server
Dopo aver modificato una variabile, ripeti lo stesso flusso di lavoro NAS o self-hosted dallo stesso client, invece di passare a un test diverso che potrebbe utilizzare un altro percorso.
La guida correlata di ZimaSpace su il percorso di rete dell’home server correlato aiuta a mantenere la verifica finale legata allo stesso ambiente self-hosted.
La correzione è completa solo quando il sintomo originale resta risolto dopo la riconnessione, il riavvio del servizio e un secondo trasferimento o una seconda richiesta controllata.
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...
