Due proxy inversi possono condividere le porte 80 e 443 su un unico server domestico?

Non sullo stesso IP e protocollo contemporaneamente, a meno che un proxy sia l'unica porta d'ingresso e inoltri il traffico selezionato all'altro, oppure che ciascuno si associ a un IP diverso.

Questa diventa una vera questione di compatibilità quando due container proxy pubblicano entrambi le porte host 80 e 443 per stack di app separati su una sola macchina. Inizia con un percorso o un account usa e getta, mantieni disponibile lo stato precedente funzionante e valuta la progettazione in base al carico di lavoro originale, non in base a un test di connessione una tantum.

Identifica chi possiede la risorsa condivisa

Il ramo supportato prevede un listener per ogni coppia IP-porta, con il routing gestito a valle. Il ramo concorrente prevede due listener indipendenti che competono per lo stesso socket. Registra versioni, identità, indirizzi, percorsi di mount, autorizzazioni e stato osservabile attuale prima di modificare uno dei due rami.

Le pertinenti regole di associazione dei socket definiscono il primo limite di compatibilità. Usale per circoscrivere l'affermazione, quindi verifica lo stesso comportamento su questo esatto home server invece di considerare una funzionalità documentata come prova che l'intera progettazione funzioni.

Scrivi la regola decisionale prima del test: il successo deve produrre esclusivamente la situazione in cui il proxy frontale previsto possiede ogni socket pubblico e ogni hostname raggiunge l'upstream corretto con il certificato previsto; il fallimento include un avvio che segnala address in use, il traffico che raggiunge il proxy sbagliato o TLS che termina con il certificato di un altro sito. Questo impedisce di interpretare erroneamente una connessione parziale o l'uscita regolare di un comando come compatibilità end-to-end.

Modifica un listener o una route alla volta

Usa un solo discriminatore controllato: elenca i listener attuali, associa ciascun proxy a un IP di test distinto oppure sposta uno dietro l'altro, quindi testa il routing Host, SNI, WebSocket e dei certificati. Mantieni costanti client, carico di lavoro, insieme di file, account e tempistiche, così il componente modificato è l'unica spiegazione plausibile.

Usa il comportamento delle porte pubblicate per scegliere la seconda osservazione importante per questo percorso. Acquisisci entrambi i lati della transazione: resolver o route, protocollo negoziato, identità del processo, stato di uscita, latenza, byte trasferiti ed eventuali eventi di ripristino.

Ripeti il test dopo l'evento del ciclo di vita indicato nel titolo: ricreazione, riconnessione, nuovo mount, riavvio, failover o modifica del client. Una progettazione che funziona solo mentre i vecchi socket, le cache o le credenziali restano attivi non ha superato il test.

ss -ltnp '( sport = :80 or sport = :443 )'
docker ps --format '{{.Names}} {{.Ports}}'

Usa prove di routing osservabili per decidere

SUPERATO: solo il proxy frontale previsto possiede ogni socket pubblico e ogni hostname raggiunge l'upstream corretto con il certificato previsto. Salva le versioni esatte e la topologia che hanno prodotto questo stato, perché la conclusione si applica a quelle condizioni e non a ogni implementazione del protocollo.

FALLITO: l'avvio segnala address in use, il traffico raggiunge il proxy sbagliato oppure TLS termina con il certificato di un altro sito. Controlla le dipendenze condivise, come DNS, MTU, identità, stato del firewall, latenza dello storage e sessioni memorizzate nella cache, prima di dichiarare responsabile uno dei due rami principali.

ECCEZIONE: interrompi il secondo bind pubblico, ripristina l'ultimo listener funzionante e scegli un'unica porta d'ingresso oppure indirizzi host separati. Non ampliare i privilegi, eliminare dati sorgente, indebolire la sicurezza del trasporto o sostituire lo storage funzionante finché un'osservazione ripetibile non identifica quale limite ha avuto esito negativo.

Featured

ZimaCube 2 NAS personale cloud domestico

ZimaCube2

$799.00 - $2,499.00

Buy Now

Ricontrolla l'isolamento prima del ritorno del traffico di produzione

Applica solo l'azione corrispondente al ramo osservato, quindi esegui nuovamente il carico di lavoro originale. Mantieni la progettazione solo quando, per due cicli di vita rilevanti e sotto il carico simultaneo previsto, solo il proxy frontale previsto possiede ogni socket pubblico e ogni hostname raggiunge l'upstream corretto con il certificato previsto.

Usa le reti proxy dedicate per verificare il workflow dipendente più vicino. Il suo comportamento di accesso, tempistica e ripristino deve rimanere invariato mentre la nuova progettazione è attiva.

Interrompi e torna allo stato salvato se l'avvio segnala address in use, il traffico raggiunge il proxy sbagliato oppure TLS termina con il certificato di un altro sito. Inoltra l'escalation con timestamp, versioni esatte, prove relative a route o mount e la riproduzione più ridotta possibile, invece di aggiungere un'altra soluzione temporanea.

Confronta il risultato con le sostituzioni DNS del reverse proxy, così il rischio non viene semplicemente spostato in un altro livello di rete, identità, backup o storage.

Per la proprietà delle porte di due reverse proxy, la risposta qualificata è quindi il giudizio iniziale, non un sì incondizionato. Lo stato osservabile superato è la linea di accettazione; lo stato fallito è la linea di rollback.

Domande frequenti

SO_REUSEPORT può consentire a proxy non correlati di condividere la 443?

Non è una progettazione sicura per il routing basato sugli hostname dei proxy indipendenti; usa un'unica porta d'ingresso TLS oppure IP separati.

Un proxy può inoltrare TLS al secondo?

Sì, quando il routing si basa su SNI e il proxy a valle gestisce la terminazione del certificato per quell'hostname.

I listener IPv4 e IPv6 entrano in conflitto?

Possono farlo, a seconda del comportamento dei socket dual-stack e degli indirizzi di bind; controlla esplicitamente entrambe le famiglie di protocolli.