Perché un reverse proxy funziona per dominio ma fallisce con l’IP locale?

Eva Wong

IceWhale author

Eva Wong è la Technical Writer e smanettatrice residente di ZimaSpace. Una geek da sempre con una passione per homelab e software open-source, si specializza nel tradurre concetti tecnici complessi in guide accessibili e pratiche. Eva crede che l'auto-ospitare debba essere divertente, non intimidatorio. Attraverso i suoi tutorial, dà potere alla comunità di demistificare le configurazioni hardware, dalla costruzione del loro primo NAS al dominio dei container Docker.

Why Does a Reverse Proxy Work by Domain but Fail by Local IP?

Un reverse proxy funziona per dominio perché le sue regole di routing e TLS spesso dipendono dal nome host richiesto, non solo dall’IP di destinazione.

Quando un client domestico apre https://app.example.com, il DNS fornisce un IP ma il browser invia comunque il dominio tramite la stretta di mano TLS e l’intestazione HTTP Host. Aprire https://192.168.1.20 cambia questi identificatori, quindi il proxy potrebbe selezionare un sito predefinito, rifiutare il certificato, non trovare il percorso dell’applicazione o reindirizzare di nuovo all’URL pubblico configurato. Il test corretto preserva il nome host previsto cambiando solo la destinazione di rete.

Confronta la Richiesta con Nome Host e la Richiesta con IP Diretto

Invia una richiesta al dominio e una all’IP locale, poi confronta codice di stato, certificato, intestazioni di risposta, posizione del reindirizzamento e log di accesso del reverse proxy. Non dare per scontato che entrambe le richieste siano equivalenti solo perché raggiungono la stessa interfaccia Ethernet.

Una guida al reverse proxy per homelab spiega che il proxy ispeziona l’intestazione HTTP Host per instradare diversi servizi attraverso un unico IP e porta.

Se la richiesta al dominio corrisponde a un percorso applicativo mentre quella all’IP raggiunge una pagina predefinita o un 404, il proxy funziona come configurato. La decisione successiva è se l’accesso diretto all’IP sia effettivamente necessario o se il DNS locale debba preservare il dominio.

Testa l’IP Locale Preservando l’Intestazione Host Prevista

Usa uno strumento client che si connetta all’IP locale del proxy inviando però il dominio dell’applicazione come intestazione Host. Per HTTPS, preserva anche il dominio come nome server TLS invece di sostituirlo con l’IP.

Server Fault descrive come un reverse proxy HTTP possa usare l’intestazione Host per scegliere il percorso allo stesso modo degli host virtuali basati sul nome.

Se la richiesta con host forzato ha successo, il percorso del proxy e il backend sono sani; il fallimento con IP diretto è un problema di identità. Se fallisce ancora, controlla il listener, il firewall locale, il punto di ingresso del proxy e la priorità del percorso prima di modificare il DNS.

Controlla la Corrispondenza TLS SNI e Certificato

HTTPS aggiunge una decisione sul nome host prima della richiesta HTTP. Il client solitamente invia la Server Name Indication durante la stretta di mano TLS così il proxy può selezionare il certificato corretto e l’host virtuale sicuro.

Un’implementazione di reverse proxy SNI nota che i backend HTTPS sono selezionati usando il nome SNI del client prima che le normali intestazioni HTTP possano essere esaminate.

L’accesso diretto tramite IP può presentare un certificato predefinito o fallire la validazione del nome host anche quando il proxy è raggiungibile. Usa il dominio con DNS locale o distribuisci un certificato gestito appositamente contenente l’IP solo se l’HTTPS diretto su IP è un requisito operativo reale.

Featured

ZimaCube 2 NAS personale cloud domestico

ZimaCube2

Ispeziona il Sito Predefinito e la Priorità del Percorso

Verifica quale host virtuale gestisce le richieste che non corrispondono a un dominio configurato. Un sito predefinito può restituire una dashboard, reindirizzare a un altro nome host, chiudere la connessione o mostrare un errore generico.

Una discussione su Caddy mostra che una richiesta può raggiungere l’IP corretto del proxy mentre l’intestazione Host e il nome TLS determinano ancora se viene scelto l’upstream previsto.

Mantieni la rotta predefinita esplicita e sicura. Non aggiungere un proxy catch-all ampio verso un solo backend solo per far funzionare l’accesso via IP, perché questo potrebbe instradare nomi host sconosciuti o traffico di scansione verso un’applicazione che dovrebbe essere limitata al dominio.

Verifica se l’Applicazione Reindirizza al Suo URL Canonico

Anche quando il proxy accetta la richiesta via IP, il backend può imporre un URL base pubblico configurato e reindirizzare il browser al dominio. Cookie di autenticazione, callback OAuth, origini WebSocket e controlli CSRF possono dipendere da quell’host canonico.

Confronta il log del proxy con quello dell’applicazione e ispeziona l’intestazione Location. Un reindirizzamento al dominio non è un errore di routing; è la prova che l’applicazione si aspetta un’identità pubblica unica.

Correggi le intestazioni host e protocollo inoltrate quando l’app genera un URL esterno errato. Non sostituire il dominio canonico con un IP privato solo per bypassare il reindirizzamento, perché questo può compromettere certificati e accesso remoto.

Usa il DNS Locale Quando il Dominio è l’Interfaccia Prevista

Crea un record DNS interno che risolva il dominio dell’applicazione all’indirizzo locale del reverse proxy. Il browser utilizza così il percorso LAN efficiente preservando la stessa intestazione Host, nome SNI, certificato, cookie e URL dell’applicazione.

Il confronto di ZimaSpace tra reverse proxy e percorsi di accesso privati aiuta a decidere se il dominio debba rimanere un punto di ingresso locale e pubblico o restare dietro una rete privata.

Il problema si risolve quando il dominio funziona sia internamente che esternamente tramite risposte DNS intenzionali, mentre l’IP diretto raggiunge un sito predefinito documentato o viene deliberatamente rifiutato. Un proxy instradato per dominio non deve comportarsi come un server a sito singolo indirizzato tramite IP.