Un proxy inverso può essere utilizzato per caricare un sito WordPress da una sottodirectory mentre un sito completamente separato viene caricato al dominio principale.

Un proxy inverso è costituito da un insieme di regole aggiunte a un server web che indica al server di inviare richieste per una determinata sottodirectory a un server separato.

Consideriamo un esempio per comprendere meglio per cosa può essere utilizzato un proxy inverso. Immaginate di avere un sito non WordPress che viene caricato su example.com e che desiderate utilizzare WordPress per un blog. Volete caricare quel blog su example.com/blog e volete ospitare il vostro blog su un host WordPress gestito come Kinsta.

A tal fine, è necessario configurare le regole del proxy inverso sul server che ospita example.com istruendo il server in modo che invii eventuali richieste per la sottodirectory /blog a un altro server che ospita il sito /blog sostenuto da WordPress.

Add-On Proxy Inverso

Kinsta consente e supporta l’utilizzo di proxy inversi per caricare WordPress da una sottodirectory o per indirizzare una sottodirectory del vostro sito a un server esterno. Tuttavia, i proxy inversi sono spesso difficili da configurare e supportare e i siti che utilizzano proxy inversi in genere richiedono un supporto molto maggiore rispetto alle installazioni WordPress standard.

Per questo motivo, viene applicato un canone mensile di $50 per l’add-on per ogni proxy inverso che viene configurato da Kinsta o per cui è richiesto supporto.

Inoltre, si prega di attendere fino ad un intero un giorno lavorativo per la configurazione iniziale di un proxy inverso. In alcuni casi d’uso non standard, potrebbe essere necessario maggior tempo e ulteriore collaborazione con il team di supporto di Kinsta per far funzionare correttamente il proxy inverso.

Casi d’Uso del Proxy Inverso

Ci sono tre possibili casi d’uso per i proxy inversi qui su Kinsta. Per comprendere questi casi d’uso dobbiamo prima definire due concetti: sito principale e sito proxy.

  • Il sito principale è il sito che carica nel dominio principale.
  • I siti proxy sono i siti che caricano da una sottodirectory su un proxy inverso.

Tornando al nostro esempio, example.com sarebbe il sito principale mentre example.com/blog sarebbe il sito proxy.

Con queste definizioni in mente, ecco i tre possibili casi d’uso per i proxy inversi su Kinsta:

  • Siti principali e proxy entrambi ospitati su Kinsta: il sito principale, example.com, e il sito proxy, example.com/blog, sono entrambi ospitati su Kinsta. Ciò consentirebbe a un’installazione di WordPress di alimentare example.com mentre un’installazione di WordPress completamente separata sarebbe utilizzata su example.com/blog.
  • Sito proxy ospitato su Kinsta: il sito principale, example.com, non è ospitato su Kinsta mentre il sito proxy, example.com/blog, è ospitato su Kinsta. Ciò consentirebbe di utilizzare un’installazione WordPress ospitata su Kinsta su example.com/blog, mentre il sito principale sarebbe ospitato altrove.
  • Sito principale ospitato su Kinsta: il sito principale, example.com, è ospitato su Kinsta mentre il sito proxy, example.com/blog, non è ospitato su Kinsta. Ciò consentirebbe a un’installazione di WordPress ospitata su Kinsta di essere utilizzata su example.com, mentre la sottodirectory del blog sarebbe ospitata altrove.

Rivediamo le implicazioni di ciascuna opzione. In particolare, illustreremo i limiti del supporto di Kinsta per ogni possibile scenario.

Esempio di server proxy inverso

Esempio di server proxy inverso

Siti Principali e Proxy Ospitati su Kinsta

Se entrambi i siti sono ospitati su Kinsta, il team di supporto di Kinsta può sia impostare le regole del proxy inverso necessarie sul sito principale, sia configurare il sito proxy per il caricamento sul proxy inverso. Si noti che sia il sito principale sia il sito proxy devono trovarsi sullo stesso data center. Inoltre, durante l’installazione del proxy inverso, sono possibili brevi tempi di inattività finché Kinsta non avrà spostato i siti nella loro posizione.

In questo scenario, il cliente ha queste responsabilità:

  • Migrare entrambi i siti nell’ambiente di Kinsta (o inviare richieste di migrazione per consentire a Kinsta di migrare i siti).
  • Fornire al team di supporto di Kinsta una chiara descrizione della configurazione del dominio.
  • Prevedere circa un giorno lavorativo per ciascuna configurazione di proxy inverso.

In questo scenario, le responsabilità di Kinsta sono le seguenti:

  • Impostare le regole di proxy inverso necessarie sul sito principale.
  • Configurare il sito proxy per il caricamento sul proxy inverso.

Solo il Sito Proxy è Ospitato su Kinsta

Nota importante: se su Kinsta è ospitato solo il sito proxy, è necessario fornire gli indirizzi IP del server proxy e configurare il server proxy per impostare le intestazioni elencate nella nostra regola di proxy inverso Nginx standard. Questi passaggi sono necessari per garantire che il nostro sistema di analisi funzioni correttamente e che non inseriamo nella blacklist gli indirizzi IP del server proxy.

Se solo il sito proxy è ospitato su Kinsta, la configurazione del proxy inverso non è una cosa che può fare Kinsta dato che il proxy inverso deve essere configurato sul server che ospita il sito principale. In questo scenario la responsabilità di Kinsta è limitata alla configurazione del sito proxy in modo che sia pronto per essere caricato su un proxy inverso.

In questo scenario, il cliente ha queste responsabilità:

  • Migrare il sito proxy su Kinsta (o inviare una richiesta di migrazione per consentire a Kinsta di migrare il sito).
  • Aggiungere un dominio al sito che verrà utilizzato dal proxy inverso. Il proxy inverso deve essere puntato su un dominio per accedere al sito proxy. In genere, a questo scopo viene utilizzato un sottodominio. Ad esempio, per il caricamento di un proxy inverso su example.com/blog sarebbe generalmente utilizzato blog.example.com.
  • Fornire al team di supporto di Kinsta una chiara descrizione della configurazione del dominio.
  • Consentire circa un giorno lavorativo per configurare il sito proxy per il caricamento su un proxy inverso.
  • Una volta configurato il sito proxy, creare il proxy inverso sul server che ospita il sito principale.

In questo scenario, come detto, la responsabilità di Kinsta è limitata alla configurazione del sito proxy in modo che sia impostato correttamente per il caricamento su un proxy inverso.

Solo il Sito Principale è Ospitato su Kinsta

Se solo il sito principale è ospitato su Kinsta, la responsabilità di Kinsta è limitata alla configurazione di un proxy inverso per caricare il sito proxy (ospitato altrove). Kinsta aggiungerà la regola del proxy inverso standard descritta in questo articolo. Su richiesta del cliente possono essere implementate personalizzazioni di questa regola.

In questo scenario, il cliente si assume la responsabilità della configurazione del sito proxy, in modo che venga caricato correttamente sul proxy inverso, e della richiesta di modifiche alla regola del proxy inverso nel caso in cui il sito proxy non riesca a caricare correttamente.

Limitazioni dei Siti Proxy

Ci sono alcune limitazioni inerenti all’utilizzo dei proxy inversi su Kinsta.

Innanzitutto, tenete presente che Kinsta non supporta l’utilizzo di multisite su un proxy inverso.

Inoltre, il ripristino dei backup o il passaggio dei siti di stagin in produzione su siti che caricano su proxy inverso può causare correttamente l’interruzione del caricamento del sito proxy. Quando si lavora con un sito proxy, è sempre consigliabile pianificare modifiche come queste per periodi di traffico limitato e consultare il team di supporto di Kinsta prima di mettersi all’opera.

Su Kinsta, quando si ha a che fare con siti proxy, l’utilizzo migliore dello staging è come ambiente di test. Dopo il testing in ambiente di staging, il workflow più semplice consiste nel duplicare tali modifiche sul sito live piuttosto che spingere lo staging. Inoltre, il ripristino dei backup dei siti proxy deve essere eseguito solo in caso di emergenza, quando non è possibile eseguire manualmente il ripristino delle modifiche.

Per via di queste limitazioni, si sconsiglia l’utilizzo di siti proxy se si prevede di ripristinare i backup o di inviare i siti di staging in produzione.

Un’alternativa ai siti proxy che vale la pena considerare è l’utilizzo di un’installazione di WordPress multisite a sottodirectory.

Configurazione del Proxy Inverso del Sito Principale

Esistono due importanti implicazioni per il sito principale quando si caricano sottodirectory su proxy inverso.

  • Le regole del proxy inverso devono essere aggiunte per ogni sottodirectory proxy.
  • Il sito principale non sarà in grado di utilizzare le sottodirectory proxy per nessuno scopo poiché tutte le richieste per quella sottodirectory saranno inoltrate al sito proxy.

Questa è la regola del proxy inverso standard Nginx utilizzata da Kinsta per caricare un sito su proxy inverso:

location ^~ /subdirectory/ {
  proxy_pass http://subdirectory.domain.com;
  proxy_set_header X-Real-IP $remote_addr;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_set_header X-Forwarded-Proto $scheme;
}

La sottodirectory effettiva verrebbe sostituita dalla /subdirectory/ segnaposto. Inoltre, http://subdirectory.domain.com verrebbe modificato in modo che corrisponda al dominio utilizzato per puntare il proxy inverso sul sito proxy.

Configurazione del Sito Proxy

Per caricare un sito su un proxy inverso, è necessario apportare le seguenti modifiche:

  • È necessario aggiungere una sottodirectory al percorso della directory sul server, facendo sì che corrisponda alla sottodirectory utilizzata per caricare il sito e tutti i file del sito spostati in questa sottodirectory.
  • È necessario effettuare aggiornamenti alla configurazione del server per aggiornare la root del sito in modo da includere la nuova sottodirectory. Inoltre, è necessario aggiungere un rewrite alla configurazione del server per rimuovere la sottodirectory dall’URI della richiesta per ogni richiesta in arrivo.
  • Tutti gli URL nel database del sito proxy devono essere aggiornati in modo che corrispondano agli URL del sito live (ad esempio, example.com/blog).
  • Il file wp-config.php file del sito deve essere aggiornato con una definizione $_SERVER['HTTP_HOST'] che punti all’URL del sito principale (example.com nell’esempio che abbiamo preso in considerazione).
  • Se il sito è forzato a caricare su https, è necessario aggiungere ulteriori definizioni a wp-config.php per evitare cicli di reindirizzamento.

Si noti che a causa delle regole di riscrittura necessarie, un sito proxy deve evitare di creare URL che duplichino la stessa sottodirectory in cui viene caricato il sito proxy. Ad esempio, un sito proxy su example.com/blog dovrebbe evitare di creare una pagina o una directory su example.com/blog/blog.

Riepilogo

Su Kinsta è possibile utilizzare proxy inversi e abbiamo un buon numero di clienti che hanno scelto di utilizzare la nostra infrastruttura in questo modo. Tuttavia, è importante comprendere la complessità tecnica aggiuntiva introdotta da questa modifica, nonché le implicazioni per l’utilizzo dei sistemi di staging e di backup di Kinsta.

Se ritenete che un proxy inverso sia la soluzione migliore per le vostre esigenze attuali, contattate il team di supporto di Kinsta tramite la chat di MyKinsta per avviare la procedura!

14
Condivisioni