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.
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.
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.
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.
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. Altrimenti utilizza il pannello del tuo registrar. La delega impiega da minuti a ore per essere visibile ovunque.
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:
- Il record
MXesiste ed è non proxato, che punta amail.kapsulehost.comcon priorità 10. SPFè un singolo record. Un dominio ha esattamente uno. Il nostro ha l'aspetto div=spf1 include:_spf.kapsulehost.com ~all. Se invii anche attraverso un altro servizio, i loro host appartengono a quel record, non a un secondo.- Ogni record
DKIMè passato. Ogni dominio ha le proprie chiavi di firma pubblicate come recordTXTsotto_domainkey. Ce n'è più di uno, e la posta firmata con una chiave il cui record manca fallisce l'autenticazione. DMARCè passato. Il record_dmarcdice 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 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.
Ritorno a Kapsule DNS
- 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.
- 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.
- Cambia i nameserver nel tuo registrar back a
ns1.kapsulecloud.com,ns2.kapsulecloud.com,ns3.kapsuledns.comens4.kapsuledns.com. - Una volta che la delega si muove, conferma che il sito si carica su HTTPS con un certificato valido.
- Controlla la scheda Deliverability su una mailbox e conferma che i record mail sono presenti.
- Riabilita Kapsule CDN se lo desideri e conferma che il certificato viene emesso.
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.
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. - La posta ha smesso di arrivare: il record
MXè mancante, proxato o punta all'host sbagliato. Vedi Email non riceve. - La posta viene inviata ma finisce nello spam: un record
SPF,DKIMoDMARCnon è passato. Correggi ciò che la scheda Deliverability segnala. Vedi Perché le mie email vanno nello spam?. - 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.
- 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.