Como colocar um proxy de terceiros ou uma CDN em frente de um site KapsuleHost, incluindo as duas configurações que prejudicam sites, os registos que nunca devem ser proxied, e como desfazer.
KapsuleHost executa os seus próprios nameservers e a sua própria rede global de edge, portanto a maioria do que um proxy de terceiros oferece já está disponível aqui, integrada e suportada. Pode ainda colocar um em frente se desejar. Esta página mostra-lhe como, e o que lhe custa.
Se apenas deseja cache e um edge global, utilize Kapsule CDN. Integra-se com o painel, mantém os endereços IP do cliente intactos, e não necessita de conta adicional. Consulte Ativar a CDN.
O que Ganha e o que Perde
| Ganha | Perde |
|---|---|
| Firewall deles, regras de bots e limitação de taxa | O endereço IP real do visitante do nosso lado, permanentemente |
| Painel de análise deles | Bloqueio geográfico e bloqueio por IP precisos no KPanel |
| Absorção de DDoS no seu edge | Um único local para gerir DNS, SSL e cache |
| Regras de página e redirecionamentos de edge | A capacidade de diagnosticar o caminho completo do pedido para si |
| Uma segunda camada de cache, se precisar | Kapsule CDN, que deveria desativar |
Mudar por uma funcionalidade específica que testou e necessita é uma boa razão. Mudar porque uma publicação num fórum disse para fazer é trocar uma configuração suportada por uma não suportada.
Tenha em conta que Cloudflare requer que delegue o domínio inteiro aos seus nameservers nos planos Free e Pro: a configuração completa (primária) é a única opção lá, e a configuração CNAME (parcial), que permitiria proxied um único hostname, está disponível apenas nos planos Business e Enterprise. Num plano de entrada não pode proxied um hostname e deixar o resto do seu DNS connosco. Mover os seus nameservers move tudo: registos web, registos de correio, registos de verificação, tudo.
As Duas Configurações que Prejudicam Tudo
1. Utilize SSL Completo (Rigoroso), Nunca Flexível
O seu site KapsuleHost tem um certificado real, publicamente confiável, e redireciona HTTP simples para HTTPS na origem.
Se o seu proxy está definido para SSL Flexível, comunica HTTP simples com a sua origem. A sua origem redireciona para HTTPS. O proxy obtém-o novamente sobre HTTP. De novo e de novo. Os visitantes veem ERR_TOO_MANY_REDIRECTS e o site é inutilizável.
Defina o modo SSL para Completo (rigoroso). O certificado de origem é válido e publicamente confiável, portanto a validação rigorosa passa. Esta é a causa mais comum de um site se quebrar no momento em que um proxy é ligado.
2. Não Intercete o Caminho do Desafio de Certificado
Os certificados são emitidos e renovados provando o controlo do domínio sobre HTTP simples, em /.well-known/acme-challenge/. Esse pedido deve atingir a origem KapsuleHost e devolver a resposta exata. Qualquer coisa no proxy que o intercete prejudica a emissão e, três meses depois, a renovação:
- Proteção de bots, modo "sob ataque", ou qualquer desafio gerido servindo uma página intersticial.
- Firewall, regras personalizadas ou de página que correspondam ao caminho ou agente de utilizador, ou que reescrevam o caminho.
- Cache que serve um 404 obsoleto para o caminho do desafio.
- Forçar HTTPS no próprio caminho do desafio, antes de um certificado existir para o servir.
Adicione uma regra explícita excluindo /.well-known/ de cada uma dessas funcionalidades.
Esta falha é atrasada e silenciosa. A emissão sucede hoje, depois em cerca de 60 dias a renovação falha silenciosamente, e uma manhã todos os visitantes recebem um aviso de certificado. Se ativar proteção de bots mais tarde, adicione a exclusão ao mesmo tempo.
Certificados pagos encomendados através de KapsuleHost são validados sobre DNS, portanto proxied não afeta aqueles. Consulte Certificados SSL.
Mover o Seu DNS para Cloudflare
Passo 1: Copie os seus registos atuais. Abra o separador DNS para o seu site no KPanel e escreva cada registo: tipo, nome, valor, prioridade. Não ignore os que não reconhece. Registos de verificação de terceiros e os registos de correio abaixo são o que as pessoas perdem. Os importadores automáticos deixam registos regularmente, portanto esta lista é o que verifica a importação e o que restaura mais tarde.
Passo 2: Adicione o domínio e verifique a importação. Adicione o domínio no Cloudflare e deixe-o analisar o seu DNS. Compare o resultado linha por linha contra a sua lista e adicione à mão o que falta. Os valores devem corresponder exatamente, incluindo pontos finais e cotação em registos TXT.
Passo 3: Decida o que é proxied. Cada registo tem um comutador de proxy, normalmente uma nuvem laranja ou cinzenta. Proxied significa que o tráfego para esse hostname passa pela sua rede; não proxied significa que DNS resolve diretamente para o endereço real. Proxied apenas registos que servem tráfego de website. A secção seguinte é a lista definitiva.
Passo 4: Altere os nameservers. Apenas quando os registos estão corretos, aponte o domínio para os nameservers que Cloudflare lhe dá. Se o domínio está registado com KapsuleHost, utilize a página Nameservers, coberta em Nameservers. Caso contrário, utilize o painel do seu registador. A delegação leva minutos a horas para ser visível em todo o lado.
Não elimine a zona no KPanel depois de delegá-la. Mantê-la não custa nada e é a cópia de que restaura se a mudança corre mal.
Quais Registos Nunca Devem Ser Proxied
Proxied um registo que não é tráfego web não o protege. Substitui a resposta pelo endereço do proxy, portanto o serviço do outro lado deixa de funcionar.
| Registo | Proxied? | Porquê |
|---|---|---|
Domínio simples e www | Sim, se deseja o proxy | Este é o tráfego web |
Registos MX | Nunca | Um proxy não pode transportar SMTP. Isto prejudica todo o correio recebido |
| O hostname de correio para o qual o MX aponta | Nunca | Deve resolver para o servidor de correio real |
SPF, DKIM, DMARC | Não existe comutador | Recrie-os exatamente |
| Autodiscover e autoconfig | Nunca | Clientes de correio necessitam do host real |
Registos SRV | Não existe comutador | Devem ser exatos |
| Subdomínio apontando para outro fornecedor | Nunca | Proxied esconde-o atrás do endereço errado |
A regra por baixo: proxied hostnames que servem HTTP e HTTPS a navegadores, e nada mais.
Manter o Seu Correio a Funcionar
O correio é a vítima mais comum de uma mudança de nameserver, e muitas vezes passa despercebido por um dia ou dois porque o correio recebido simplesmente deixa de chegar em vez de produzir um erro visível.
Se as suas caixas de correio estão com KapsuleHost, quatro coisas devem ser verdadeiras depois:
- O registo
MXexiste e não é proxied, apontando paramail.kapsulehost.comcom prioridade 10. SPFé um registo único. Um domínio é permitido exatamente um. O nosso parecev=spf1 include:_spf.kapsulehost.com ~all. Se também envia através de outro serviço, os seus hosts pertencem dentro desse registo, não num segundo.- Cada registo
DKIMveio. Cada domínio tem as suas próprias chaves de assinatura publicadas como registosTXTsob_domainkey. Há mais de um, e o correio assinado com uma chave cujo registo falta falha na autenticação. DMARCveio. O registo_dmarcdiz aos servidores recetores o que fazer com o correio que falha nas verificações acima.
O separador Deliverability em qualquer caixa de correio mostra o que está atualmente publicado e o que falta, com os valores corretos para copiar. Verifique-o depois de os nameservers terem propagado. SPF, DKIM e DMARC Explicado cobre o que cada registo faz.
O correio é enviado e recebido no hostname real de correio diretamente, portanto nunca passa através do proxy. As suas definições de cliente de correio não mudam.
O que Perde: O Endereço IP Real do Cliente
KapsuleHost lê o endereço IP do visitante real de um cabeçalho encaminhado, mas apenas quando o pedido chega da nossa própria rede edge ou da própria máquina. Qualquer outra fonte não é confiável, deliberadamente, porque um cabeçalho encaminhado pode ser falsificado por qualquer um. Um proxy de terceiros não está nessa lista de confiança, e não há forma suportada de adicionar um.
Portanto, tudo o que depende do IP do visitante vê o proxy:
| Funcionalidade | O que acontece |
|---|---|
| Registos de acesso | Registam o endereço do proxy, não o do visitante |
| Análise do site | Atribuem tráfego ao proxy |
| Bloqueio geográfico | Geolocalizam o centro de dados do proxy, portanto as regras de país disparam incorretamente |
| A sua lista de negação de IP | Não pode bloquear um visitante que nunca vê |
| Bloqueio automático de abuso da plataforma | Vê o proxy |
| Plugins de segurança WordPress | Limitação de início de sessão e filtragem de comentários com chave incorreta |
Há uma versão pior. A plataforma bloqueia automaticamente endereços gerando uma explosão de erros ou tentativas de login falhadas. Atrás de um proxy essa atividade parece toda vir do proxy, portanto um visitante mal comportado pode fazer com que um centro de dados proxy inteiro seja temporariamente bloqueado, levando todos os outros encaminhados através dele. Não podemos corrigir isso do nosso lado.
Não Empilhe Duas CDNs
Executar Kapsule CDN com um proxy de terceiros em frente não duplica o seu desempenho. Dá-lhe dois caches discordando, dois conjuntos de regras de purga, e um problema muito difícil de depurar.
Há também um bloqueador concreto: ativar Kapsule CDN requer que o nosso edge emita um certificado para o seu hostname, o que requer que o hostname resolva para o nosso edge. Se o DNS aponta para um proxy de terceiros, esse certificado nunca é emitido e a CDN silenciosamente não faz nada.
Escolha um. Se quer o deles, desative Kapsule CDN primeiro, antes de delegar os seus nameservers. Se quer o nosso, desative o proxy. Ativar Kapsule CDN normalmente escreve os registos de edge necessários para si, mas apenas quando o seu DNS é hospedado connosco; caso contrário, publique-os si mesmo utilizando o hostname de edge no separador CDN.
Voltando para Kapsule DNS
- Abra o separador DNS no KPanel e verifique os registos ainda correspondem ao que está ativo no proxy. Adicione qualquer coisa que criou lá desde que saiu.
- Desative o comutador de proxy em cada registo no serviço de terceiros, portanto a zona mostra endereços reais. Confirme que o site ainda carrega.
- Altere os nameservers no seu registador de volta para
ns1.kapsulecloud.com,ns2.kapsulecloud.com,ns3.kapsuledns.comens4.kapsuledns.com. - Uma vez que a delegação se move, confirme que o site carrega sobre HTTPS com um certificado válido.
- Verifique o separador Deliverability numa caixa de correio e confirme que os registos de correio estão presentes.
- Reative Kapsule CDN se a deseja, e confirme que o certificado é emitido.
Se DNSSEC está ativado no proxy, desative-o e espere até que a zona pai deixe de publicar o registo de delegação ANTES de alterar nameservers. Mover nameservers enquanto uma chave obsoleta é publicada torna o domínio irresolvível em todo o lado. Consulte DNSSEC.
Quando Corre Mal
ERR_TOO_MANY_REDIRECTS: O modo SSL é Flexível. Altere para Completo (rigoroso).- Certificado expirou ou é inválido: a renovação foi bloqueada. Adicione a exclusão
/.well-known/, depois reemita do painel. Consulte Certificados SSL. - O correio deixou de chegar: o registo
MXestá em falta, proxied, ou apontando para o host errado. Consulte Correio Não Está a Receber. - O correio envia mas cai no spam: um registo
SPF,DKIMouDMARCnão veio. Corrija o que o separador Deliverability assinala. Consulte Por Que Os Meus Emails Estão a Ir Para Spam?. - As alterações não estão a aparecer: dois caches. Purgue ambos, depois verifique numa janela privada.
- Alguns visitantes não conseguem atingir o site, outros conseguem: provavelmente um bloqueio automático num centro de dados de proxy. Consulte Abrir um Bilhete de Suporte.
- O domínio deixou de resolver logo após a alteração de nameserver: geralmente um registo de delegação DNSSEC obsoleto. Peça ao seu registador para removê-lo.
- Avisos de conteúdo misto: não relacionado com o proxy, mas muitas vezes notado ao mesmo tempo. Consulte Corrigindo Conteúdo Misto.