Comment placer un proxy ou CDN tiers devant un site KapsuleHost, avec les deux paramètres qui cassent les sites, les enregistrements qui ne doivent jamais être proxifiés, et comment l'annuler.
KapsuleHost exécute ses propres serveurs de noms et son propre réseau edge mondial, donc la plupart de ce qu'offre un proxy tiers est déjà disponible ici, intégré et soutenu. Vous pouvez toujours en placer un devant si vous le souhaitez. Cette page vous montre comment, et ce que cela vous coûte.
Si vous voulez seulement la mise en cache et un edge mondial, utilisez plutôt Kapsule CDN. Il s'intègre avec le panneau, préserve les adresses IP des clients, et ne nécessite aucun compte supplémentaire. Voir Activation du CDN.
Ce que vous gagnez et ce que vous perdez
| Vous gagnez | Vous perdez |
|---|---|
| Leur pare-feu, règles de bots et limitation de débit | L'adresse IP réelle du visiteur de notre côté, de façon permanente |
| Leur tableau de bord d'analytique | Le blocage géographique et le blocage IP précis dans KPanel |
| Absorption DDoS à leur edge | Un seul endroit pour gérer DNS, SSL et la mise en cache |
| Règles de page et redirections edge | Notre capacité à diagnostiquer le chemin complet de la requête pour vous |
| Une deuxième couche de cache, si vous en avez besoin | Kapsule CDN, que vous devriez désactiver |
Changer pour une fonctionnalité spécifique que vous avez testée et dont vous avez besoin est une bonne raison. Changer parce qu'un message de forum l'a dit échange une configuration soutenue pour une non soutenue.
Notez que Cloudflare vous demande de déléguer le domaine entier à leurs serveurs de noms sur les plans Free et Pro : la configuration complète (primaire) est la seule option là, et la configuration CNAME (partielle), qui vous permettrait de proxifier un seul nom d'hôte, n'est disponible que sur les plans Business et Enterprise. Sur un plan d'entrée de gamme, vous ne pouvez pas proxifier un seul nom d'hôte et laisser le reste de votre DNS avec nous. Déplacer vos serveurs de noms déplace tout : les enregistrements web, les enregistrements de courrier, les enregistrements de vérification, tout.
Les deux paramètres qui cassent tout
1. Utilisez Full (Strict) SSL, jamais Flexible
Votre site KapsuleHost a un vrai certificat publiquement approuvé et redirige le HTTP simple vers HTTPS à l'origine.
Si votre proxy est réglé sur SSL Flexible, il parle HTTP simple à votre origine. Votre origine le redirige vers HTTPS. Le proxy le récupère à nouveau sur HTTP. Rond et rond. Les visiteurs voient ERR_TOO_MANY_REDIRECTS et le site est inutilisable.
Réglez le mode SSL sur Full (strict). Votre certificat d'origine est valide et publiquement approuvé, donc la validation stricte réussit. C'est la cause la plus courante d'un site qui casse au moment où un proxy est activé.
2. N'interceptez pas le chemin du défi du certificat
Les certificats sont émis et renouvelés en prouvant le contrôle du domaine sur HTTP simple, à /.well-known/acme-challenge/. Cette requête doit atteindre l'origine KapsuleHost et retourner la réponse exacte. Tout au proxy qui l'intercepte casse l'émission et, trois mois plus tard, le renouvellement :
- Protection bot, mode « under attack » ou tout challenge géré servant une page interstitielle.
- Pare-feu, règles personnalisées ou de page qui correspondent sur le chemin ou l'agent utilisateur, ou qui réécrivent le chemin.
- Mise en cache qui sert un 404 obsolète pour le chemin du défi.
- Forcer HTTPS sur le chemin du défi lui-même, avant qu'un certificat n'existe pour le servir avec.
Ajoutez une règle explicite excluant /.well-known/ de chacune de ces fonctionnalités.
Cet échec est retardé et silencieux. L'émission réussit aujourd'hui, puis dans environ 60 jours le renouvellement échoue silencieusement, et un matin chaque visiteur reçoit un avertissement de certificat. Si vous activez la protection bot plus tard, ajoutez l'exclusion en même temps.
Les certificats payants commandés via KapsuleHost sont validés via DNS à la place, donc la proxification ne les affecte pas. Voir Certificats SSL.
Déplacer votre DNS vers Cloudflare
Étape 1 : Copiez vos enregistrements actuels. Ouvrez l'onglet DNS de votre site dans KPanel et notez chaque enregistrement : type, nom, valeur, priorité. Ne sautez pas ceux que vous ne reconnaissez pas. Les enregistrements de vérification tiers et les enregistrements de courrier ci-dessous sont ce que les gens perdent. Les importateurs automatiques manquent régulièrement des enregistrements, donc cette liste est ce que vous vérifiez par rapport à l'importation et ce que vous restaurez ultérieurement.
Étape 2 : Ajoutez le domaine et vérifiez l'importation. Ajoutez le domaine à Cloudflare et laissez-le scanner votre DNS. Comparez le résultat ligne par ligne par rapport à votre liste et ajoutez manuellement tout ce qui manque. Les valeurs doivent correspondre exactement, y compris les points finaux et les guillemets sur les enregistrements TXT.
Étape 3 : Décidez ce qui est proxifié. Chaque enregistrement obtient un bouton bascule de proxy, généralement un nuage orange ou gris. Proxifié signifie que le trafic pour ce nom d'hôte passe par leur réseau ; non proxifié signifie que DNS se résout directement à l'adresse réelle. Proxifiez seulement les enregistrements qui servent le trafic du site web. La section suivante est la liste définitive.
Étape 4 : Changez les serveurs de noms. Uniquement une fois les enregistrements corrects, pointez le domaine sur les serveurs de noms que Cloudflare vous donne. Si le domaine est enregistré avec KapsuleHost, utilisez la page Nameservers, couverte dans Serveurs de noms. Sinon, utilisez le panneau de votre registraire. La délégation prend des minutes à des heures pour être visible partout.
Ne supprimez pas la zone dans KPanel après l'avoir déléguée. La garder ne coûte rien et c'est la copie dont vous restaurez si le déplacement se passe mal.
Quels enregistrements ne doivent jamais être proxifiés
Proxifier un enregistrement qui n'est pas du trafic web ne le protège pas. Il remplace la réponse par l'adresse du proxy, de sorte que le service de l'autre côté arrête de fonctionner.
| Enregistrement | Proxifier ? | Pourquoi |
|---|---|---|
Domaine nu et www | Oui, si vous voulez le proxy du tout | C'est le trafic web |
Enregistrements MX | Jamais | Un proxy ne peut pas supporter SMTP. Cela casse tout le courrier entrant |
| Le nom d'hôte de courrier vers lequel MX pointe | Jamais | Il doit se résoudre en serveur de courrier réel |
SPF, DKIM, DMARC | Pas de bouton bascule | Recréez-les exactement |
| Autodiscover et autoconfig | Jamais | Les clients de courrier ont besoin du vrai hôte |
Enregistrements SRV | Pas de bouton bascule | Ils doivent être exacts |
| Sous-domaine pointant vers un autre fournisseur | Jamais | La proxification le cache derrière la mauvaise adresse |
La règle en dessous : proxifiez les noms d'hôtes qui servent HTTP et HTTPS aux navigateurs, et rien d'autre.
Garder votre courrier fonctionnel
Le courrier est la victime la plus courante d'un déplacement de serveur de noms, et il passe souvent inaperçu pendant un jour ou deux car le courrier entrant s'arrête simplement d'arriver plutôt que de produire une erreur visible.
Si vos boîtes aux lettres sont avec KapsuleHost, quatre choses doivent être vraies après :
- L'enregistrement
MXexiste et n'est pas proxifié, pointant versmail.kapsulehost.comavec la priorité 10. SPFest un seul enregistrement. Un domaine en est autorisé exactement un. Le nôtre ressemble àv=spf1 include:_spf.kapsulehost.com ~all. Si vous envoyez aussi via un autre service, ses hôtes appartiennent à cet enregistrement, pas un deuxième.- Chaque enregistrement
DKIMest arrivé. Chaque domaine a ses propres clés de signature publiées comme enregistrementsTXTsous_domainkey. Il y en a plus d'un, et le courrier signé avec une clé dont l'enregistrement manque échoue l'authentification. DMARCest arrivé. L'enregistrement_dmarcindique aux serveurs de réception ce qu'il faut faire avec le courrier qui échoue les vérifications ci-dessus.
L'onglet Deliverability sur n'importe quelle boîte aux lettres affiche ce qui est actuellement publié et ce qui manque, avec les valeurs correctes à copier. Vérifiez-le après la propagation des serveurs de noms. SPF, DKIM et DMARC expliqués couvre ce que chaque enregistrement fait.
Le courrier est envoyé et reçu directement sur le vrai nom d'hôte de courrier, il ne passe jamais par le proxy. Vos paramètres client de courrier ne changent pas.
Ce que vous perdez : l'adresse IP réelle du client
KapsuleHost lit l'IP réelle du visiteur à partir d'un en-tête transmis, mais seulement lorsque la requête provient de notre propre réseau edge ou de la machine elle-même. Toute autre source n'est pas approuvée, délibérément, car un en-tête transmis peut être contrefait par n'importe qui. Un proxy tiers n'est pas sur cette liste d'approbation, et il n'y a aucun moyen soutenu d'en ajouter un.
Donc tout ce qui dépend de l'IP du visiteur voit le proxy à la place :
| Fonctionnalité | Ce qui se passe |
|---|---|
| Journaux d'accès | Enregistrez l'adresse du proxy, pas celle du visiteur |
| Analytique du site | Attribuez le trafic au proxy |
| Blocage géographique | Géolocalise le centre de données du proxy, donc les règles de pays mal fonctionnent |
| Votre liste de refus IP | Ne peut pas bloquer un visiteur que vous ne voyez jamais |
| Blocage des abus de plateforme | Voit le proxy |
| Plug-ins de sécurité WordPress | La limitation de connexion et le filtrage des commentaires mal-clés |
Il y a une version pire. La plateforme bloque automatiquement les adresses générant une rafale d'erreurs ou des connexions échouées. Derrière un proxy, cette activité semble provenir du proxy, de sorte qu'un seul visiteur mal comporté peut faire bloquer temporairement un centre de données proxy entier, mettant hors ligne tous les autres routés par celui-ci. Nous ne pouvons pas le réparer de notre côté.
Ne cumulez pas deux CDN
Exécuter Kapsule CDN avec un proxy tiers devant ne double pas vos performances. Cela vous donne deux caches en désaccord, deux ensembles de règles de purge, et un problème très difficile à déboguer.
Il y a aussi un blocker concret : l'activation de Kapsule CDN nécessite que notre edge émette un certificat pour votre nom d'hôte, ce qui nécessite que le nom d'hôte se résolve à notre edge. Si DNS pointe plutôt vers un proxy tiers, ce certificat n'est jamais émis et le CDN ne fait silencieusement rien.
Choisissez-en un. Si vous voulez le leur, désactivez Kapsule CDN d'abord, avant de déléguer vos serveurs de noms. Si vous voulez le nôtre, désactivez le proxy. L'activation de Kapsule CDN écrit normalement les enregistrements edge requis pour vous, mais seulement lorsque votre DNS est hébergé avec nous ; sinon publiez-les vous-même en utilisant le nom d'hôte edge de l'onglet CDN.
Revenir à Kapsule DNS
- Ouvrez l'onglet DNS dans KPanel et vérifiez que les enregistrements correspondent toujours à ce qui est actuellement actif au proxy. Ajoutez tout ce que vous avez créé là depuis que vous êtes parti.
- Désactivez le bouton bascule du proxy sur chaque enregistrement au service tiers, de sorte que la zone affiche les adresses réelles. Confirmez que le site se charge toujours.
- Changez les serveurs de noms chez votre registraire pour revenir à
ns1.kapsulecloud.com,ns2.kapsulecloud.com,ns3.kapsuledns.cometns4.kapsuledns.com. - Une fois la délégation déplacée, confirmez que le site se charge sur HTTPS avec un certificat valide.
- Vérifiez l'onglet Deliverability sur une boîte aux lettres et confirmez que les enregistrements de courrier sont présents.
- Réactivez Kapsule CDN si vous le souhaitez, et confirmez que le certificat s'émettent.
Si DNSSEC est activé au proxy, désactivez-le et attendez que la zone parente arrête de publier l'enregistrement de délégation AVANT de changer les serveurs de noms. Changer les serveurs de noms alors qu'une clé obsolète est publiée rend le domaine inrésolvable partout. Voir DNSSEC.
Quand quelque chose se passe mal
ERR_TOO_MANY_REDIRECTS: Le mode SSL est Flexible. Changez-le en Full (strict).- Certificat expiré ou invalide : le renouvellement a été bloqué. Ajoutez l'exclusion
/.well-known/, puis réémettez à partir du panneau. Voir Certificats SSL. - Le courrier a arrêté d'arriver : l'enregistrement
MXmanque, est proxifié ou pointe vers le mauvais hôte. Voir Courrier non reçu. - Le courrier s'envoie mais arrive dans le courrier indésirable : un enregistrement
SPF,DKIMouDMARCn'est pas arrivé. Corrigez ce que l'onglet Deliverability signale. Voir Pourquoi mes e-mails vont-ils dans le courrier indésirable?. - Les modifications n'apparaissent pas : deux caches. Purgez les deux, puis vérifiez dans une fenêtre privée.
- Certains visiteurs ne peuvent pas atteindre le site, d'autres peuvent : probablement un bloc automatique sur un centre de données proxy. Voir Ouverture d'un ticket d'assistance.
- Le domaine a arrêté de se résoudre juste après le changement de serveur de noms : généralement un enregistrement de délégation DNSSEC obsolète. Demandez à votre registraire de le supprimer.
- Avertissements de contenu mixte : sans rapport avec le proxy, mais souvent remarqué en même temps. Voir Correction du contenu mixte.