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.

Featured

ZimaCube 2 NAS personale cloud domestico

ZimaCube2

$799.00 - $2,499.00

Buy Now

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.