# Utilizzo di Cloudflare o un altro proxy con KapsuleHost

Source: https://support.kapsulehost.com/it-it/using-cloudflare-with-kapsule

# Come utilizzare un proxy Cloudflare o di terze parti con KapsuleHost

Come mettere un proxy o CDN di terze parti davanti a un sito KapsuleHost, incluse le due impostazioni che rompono i siti, i record che non devono mai essere proxati e come annullare il tutto.

KapsuleHost gestisce i propri nameserver e la propria rete edge globale, quindi la maggior parte di ciò che offre un proxy di terze parti è già disponibile qui, integrato e supportato. Puoi comunque mettere uno davanti se lo desideri. Questa pagina ti mostra come e quale prezzo ha.

> **Note:** Se desideri solo caching e un edge globale, utilizza invece Kapsule CDN. Si integra con il pannello, mantiene intatti gli indirizzi IP dei client e non richiede un account aggiuntivo. Vedi [Abilitazione del CDN](https://support.kapsulehost.com/it-it/cdn-enabling).

## Cosa guadagni e cosa sacrifichi

| Guadagni | Sacrifichi |
|---|---|
| Il loro firewall, le regole bot e il rate limiting | L'indirizzo IP del visitatore reale dal nostro lato, permanentemente |
| La loro dashboard di analisi | Geo-blocking accurato e IP blocking in KPanel |
| Assorbimento DDoS al loro edge | Un unico posto per gestire DNS, SSL e caching |
| Page rules e redirect edge | La nostra capacità di diagnosticare il percorso completo della richiesta per te |
| Un secondo livello di cache, se ne hai bisogno | Kapsule CDN, che dovresti disattivare |

Spostarsi per una funzione specifica che hai testato e di cui hai bisogno è una buona ragione. Spostarsi perché un post del forum lo diceva scambia una configurazione supportata per una non supportata.

Nota che Cloudflare richiede di delegare l'intero dominio ai loro nameserver nei piani Free e Pro: la configurazione completa (primaria) è l'unica opzione lì, e la configurazione CNAME (parziale), che ti permetterebbe di proxare un singolo hostname, è disponibile solo nei piani Business ed Enterprise. In un piano entry-level non puoi proxare un hostname e lasciare il resto del tuo DNS con noi. Spostare i tuoi nameserver sposta tutto: record web, record mail, record di verifica, tutto.

## Le due impostazioni che rompono tutto

### 1. Utilizza SSL completo (strict), mai Flexible

Il tuo sito KapsuleHost ha un certificato reale, pubblicamente affidabile, e reindirizza il plain HTTP a HTTPS all'origine.

Se il tuo proxy è impostato su **Flexible** SSL, parla plain HTTP alla tua origine. La tua origine lo reindirizza a HTTPS. Il proxy lo recupera di nuovo su HTTP. Giro e rigiro. I visitatori vedono `ERR_TOO_MANY_REDIRECTS` e il sito è inutilizzabile.

Imposta la modalità SSL su **Full (strict)**. Il tuo certificato di origine è valido e pubblicamente affidabile, quindi la validazione strict passa. Questa è la causa più comune di un sito che si rompe nel momento in cui un proxy viene attivato.

### 2. Non intercettare il percorso della sfida del certificato

I certificati vengono emessi e rinnovati provando il controllo del dominio su plain HTTP, in `/.well-known/acme-challenge/`. Quella richiesta deve raggiungere l'origine KapsuleHost e restituire la risposta esatta. Qualsiasi cosa al proxy che la intercetta rompe l'emissione e, tre mesi dopo, il rinnovo:

- Protezione bot, modalità "under attack" o qualsiasi managed challenge che serve una pagina interstiziale.
- Firewall, regole personalizzate o page rules che corrispondono al percorso o user agent, o che riscrivono il percorso.
- Caching che serve un 404 stantio per il percorso della sfida.
- Forzare HTTPS sul percorso della sfida stesso, prima che esista un certificato per servirlo.

Aggiungi una regola esplicita escludendo `/.well-known/` da ognuna di queste funzioni.

> **Warning:** Questo errore è ritardato e silenzioso. L'emissione riesce oggi, poi in circa 60 giorni il rinnovo fallisce silenziosamente, e una mattina ogni visitatore riceve un avviso di certificato. Se attivi la protezione bot in seguito, aggiungi l'esclusione contemporaneamente.

I certificati pagati ordinati tramite KapsuleHost vengono convalidati su DNS, quindi proxare non li influisce. Vedi [Certificati SSL](https://support.kapsulehost.com/it-it/ssl-certificates).

## Spostamento del tuo DNS su Cloudflare

**Passaggio 1: copia i tuoi record attuali.** Apri la scheda **DNS** per il tuo sito in KPanel e annota ogni record: tipo, nome, valore, priorità. Non saltare quelli che non riconosci. I record di verifica di terze parti e i record mail di seguito sono quello che le persone perdono. Gli importatori automatici mancano i record regolarmente, quindi questo elenco è quello che verifichi rispetto all'importazione e da cui ripristini in seguito.

**Passaggio 2: aggiungi il dominio e verifica l'importazione.** Aggiungi il dominio su Cloudflare e lascia che scansioni il tuo DNS. Confronta il risultato riga per riga rispetto al tuo elenco e aggiungi manualmente tutto ciò che manca. I valori devono corrispondere esattamente, inclusi i punti finali e le virgolette nei record `TXT`.

**Passaggio 3: decidi cosa è proxato.** Ogni record ottiene un interruttore proxy, solitamente una nuvola arancione o grigia. Proxato significa che il traffico per quel hostname passa attraverso la loro rete; non proxato significa che DNS si risolve direttamente all'indirizzo reale. Proxare solo i record che servono il traffico del sito web. La sezione successiva è l'elenco definitivo.

**Passaggio 4: cambia i nameserver.** Solo una volta che i record sono corretti, punta il dominio ai nameserver che Cloudflare ti fornisce. Se il dominio è registrato con KapsuleHost, utilizza la pagina **Nameservers**, coperta in [Nameservers](https://support.kapsulehost.com/it-it/nameservers). Altrimenti utilizza il pannello del tuo registrar. La delega impiega da minuti a ore per essere visibile ovunque.

> **Warning:** Non eliminare la zona in KPanel dopo aver delegato via. Mantenerla non costa nulla ed è la copia da cui ripristini se lo spostamento va male.

## Quali record non devono mai essere proxati

Proxare un record che non è traffico web non lo protegge. Sostituisce la risposta con l'indirizzo del proxy, quindi il servizio dall'altra parte smette di funzionare.

| Record | Proxare? | Perché |
|---|---|---|
| Dominio bare e `www` | Sì, se desideri il proxy a tutti | Questo è il traffico web |
| Record `MX` | **Mai** | Un proxy non può portare SMTP. Questo rompe tutta la posta in arrivo |
| L'hostname mail a cui punta l'MX | **Mai** | Deve risolvere al server mail reale |
| `SPF`, `DKIM`, `DMARC` | Nessun interruttore esiste | Ricreali esattamente |
| Autodiscover e autoconfig | **Mai** | I client di posta hanno bisogno dell'host reale |
| Record `SRV` | Nessun interruttore esiste | Devono essere esatti |
| Sottodominio che punta a un altro provider | **Mai** | Proxare lo nasconde dietro l'indirizzo sbagliato |

La regola sottostante: proxare i hostname che servono HTTP e HTTPS ai browser, e nient'altro.

## Mantenere la tua email funzionante

La posta è la vittima più comune di uno spostamento di nameserver, e spesso passa inosservata per un giorno o due perché la posta in arrivo semplicemente smette di arrivare invece di produrre un errore visibile.

Se le tue mailbox sono con KapsuleHost, quattro cose devono essere vere in seguito:

1. **Il record `MX` esiste ed è non proxato**, che punta a `mail.kapsulehost.com` con priorità 10.
2. **`SPF` è un singolo record.** Un dominio ha esattamente uno. Il nostro ha l'aspetto di `v=spf1 include:_spf.kapsulehost.com ~all`. Se invii anche attraverso un altro servizio, i loro host appartengono a quel record, non a un secondo.
3. **Ogni record `DKIM` è passato.** Ogni dominio ha le proprie chiavi di firma pubblicate come record `TXT` sotto `_domainkey`. Ce n'è più di uno, e la posta firmata con una chiave il cui record manca fallisce l'autenticazione.
4. **`DMARC` è passato.** Il record `_dmarc` dice ai server riceventi cosa fare con la posta che fallisce i controlli di cui sopra.

La scheda **Deliverability** su qualsiasi mailbox mostra ciò che è attualmente pubblicato e ciò che manca, con i valori corretti da copiare. Verificalo dopo che i nameserver si sono propagati. [SPF, DKIM e DMARC spiegati](https://support.kapsulehost.com/it-it/spf-dkim-dmarc) copre cosa fa ogni record.

La posta viene inviata e ricevuta direttamente sull'hostname mail reale, quindi non passa mai attraverso il proxy. Le impostazioni del tuo client di posta non cambiano.

## Quello che perdi: l'indirizzo IP del client reale

KapsuleHost legge l'indirizzo IP del visitatore reale da un header inoltrato, ma solo quando la richiesta arriva dalla nostra stessa rete edge o dalla macchina stessa. Qualsiasi altra fonte non è attendibile, deliberatamente, perché un header inoltrato può essere falsificato da chiunque. Un proxy di terze parti non è su quella lista di trust, e non c'è modo supportato di aggiungerne uno.

Quindi tutto ciò che dipende dall'IP del visitatore vede il proxy:

| Funzione | Cosa succede |
|---|---|
| Log di accesso | Registrano l'indirizzo del proxy, non del visitatore |
| Analitiche del sito | Attribuiscono il traffico al proxy |
| Geo-blocking | Geolocalizza il data center del proxy, quindi le regole di paese sparano male |
| Il tuo denylist IP | Non può bloccare un visitatore che non vedi mai |
| Blocco degli abusi della piattaforma | Vede il proxy |
| Plugin di sicurezza WordPress | La limitazione dell'accesso e il filtro dei commenti si innescano male |

C'è una versione peggiore. La piattaforma blocca automaticamente gli indirizzi che generano un burst di errori o accessi falliti. Dietro un proxy quell'attività sembra provenire tutta dal proxy, quindi un visitatore mal comportato può far bloccare temporaneamente un intero data center proxy, eliminando tutti gli altri instradati attraverso di esso. Non possiamo risolvere questo dal nostro lato.

## Non impilare due CDN

Eseguire Kapsule CDN con un proxy di terze parti davanti non raddoppia le tue prestazioni. Ti dà due cache che non sono d'accordo, due serie di regole di purga e un problema molto difficile da debuggare.

C'è anche un blocco concreto: abilitare Kapsule CDN richiede al nostro edge di emettere un certificato per il tuo hostname, il quale richiede che l'hostname si risolva al nostro edge. Se il DNS punta a un proxy di terze parti, quel certificato non viene mai emesso e il CDN silenziosamente non fa nulla.

Scegli uno. Se desideri il loro, spegni prima Kapsule CDN, prima di delegare i tuoi nameserver. Se desideri il nostro, spegni il proxy. L'abilitazione di Kapsule CDN normalmente scrive i record edge richiesti per te, ma solo quando il tuo DNS è ospitato con noi; altrimenti pubblicali da solo utilizzando l'hostname edge sulla scheda CDN.

![La pagina Kapsule CDN per un sito in KPanel](https://support.kapsulehost.com/help/screenshots/using-cloudflare-with-kapsule.b7b43ee5.webp)

## Ritorno a Kapsule DNS

1. Apri la scheda **DNS** in KPanel e controlla che i record corrispondano ancora a quelli live al proxy. Aggiungi tutto ciò che hai creato da allora che te ne sei andato.
2. Spegni l'interruttore proxy su ogni record al servizio di terze parti, in modo che la zona mostri indirizzi reali. Conferma che il sito si carica comunque.
3. Cambia i nameserver nel tuo registrar back a `ns1.kapsulecloud.com`, `ns2.kapsulecloud.com`, `ns3.kapsuledns.com` e `ns4.kapsuledns.com`.
4. Una volta che la delega si muove, conferma che il sito si carica su HTTPS con un certificato valido.
5. Controlla la scheda **Deliverability** su una mailbox e conferma che i record mail sono presenti.
6. Riabilita Kapsule CDN se lo desideri e conferma che il certificato viene emesso.

> **Note:** Se DNSSEC è abilitato al proxy, spegnilo e attendi che la zona parent smetta di pubblicare il record di delega PRIMA di cambiare i nameserver. Spostare i nameserver mentre una chiave stantia è pubblicata rende il dominio irrisolvibile ovunque. Vedi [DNSSEC](https://support.kapsulehost.com/it-it/domains-dnssec).

## Quando qualcosa va storto

- **`ERR_TOO_MANY_REDIRECTS`**: la modalità SSL è Flexible. Cambiala a Full (strict).
- **Certificato scaduto o non valido**: il rinnovo è stato bloccato. Aggiungi l'esclusione `/.well-known/`, quindi ristampa dal pannello. Vedi [Certificati SSL](https://support.kapsulehost.com/it-it/ssl-certificates).
- **La posta ha smesso di arrivare**: il record `MX` è mancante, proxato o punta all'host sbagliato. Vedi [Email non riceve](https://support.kapsulehost.com/it-it/email-not-receiving).
- **La posta viene inviata ma finisce nello spam**: un record `SPF`, `DKIM` o `DMARC` non è passato. Correggi ciò che la scheda **Deliverability** segnala. Vedi [Perché le mie email vanno nello spam?](https://support.kapsulehost.com/it-it/email-spam-sending).
- **Le modifiche non vengono visualizzate**: due cache. Purga entrambe, quindi controlla in una finestra privata.
- **Alcuni visitatori non riescono a raggiungere il sito, altri sì**: probabilmente un blocco automatico su un data center proxy. Vedi [Apertura di un ticket di supporto](https://support.kapsulehost.com/it-it/opening-a-support-ticket).
- **Il dominio ha smesso di risolvere subito dopo il cambio del nameserver**: solitamente un record di delega DNSSEC stantio. Chiedi al tuo registrar di rimuoverlo.
- **Avvisi di contenuto misto**: non correlati al proxy, ma spesso notati nello stesso momento. Vedi [Correzione del contenuto misto](https://support.kapsulehost.com/it-it/ssl-mixed-content).

## Guide correlate

- [Attivare Kapsule CDN sul tuo sito](https://support.kapsulehost.com/it-it/cdn-enabling)
- [Svuotare la cache di Kapsule CDN](https://support.kapsulehost.com/it-it/cdn-cache-purge)
- [Modifica dei nameserver per indirizzare il tuo dominio a Kapsule](https://support.kapsulehost.com/it-it/nameservers)
- [Nozioni di base su DNS: record A, MX, CNAME e TXT spiegati](https://support.kapsulehost.com/it-it/dns-basics)
- [Sicurezza: da dove iniziare](https://support.kapsulehost.com/it-it/security-overview)
- [Glossario di Hosting: Ogni Termine Spiegato](https://support.kapsulehost.com/it-it/glossary)