Aller au contenu principal

Configuration de Cloudflare

En accrochant Aivory à Cloudflare, vous pouvez obtenir trois choses à la fois : ** Station de source cachée IP ** (Les visiteurs ne voient que les adresses des nœuds de bord de Cloudflare) ** Certificat de bord gratuit et renouvelable automatiquement ** (Vous n'avez pas à vous soucier du HTTPS du navigateur vers Cloudflare) et de Cloudflare ** DDoS et WAF de base ** Les avantages associés incluent le cache à bord de ressources statiques et d'accès proche Anycast à l'échelle mondiale.

Cette page propose deux itinéraires complets :

  • ** Programme A : Orange Cloud Agent ** Les stations source ont un IP public, les enregistrements DNS ouvrent le proxy Cloudflare (nuage orange) et le parcours de trafic est « Visiteurs → Cloudflare → Station source Nginx → application ».
  • ** Catégorie : Cloudflare Tunnel ** La station source n'a pas d'IP de réseau public ou ne veut pas ouvrir un port d'entrée. cloudflared Les conteneurs construisent activement des tunnels de sortie pour Cloudflare.

Les deux routes sont basées sur le même fait : Aivory. app Conteneur unique à source unique pour serveur SPA et /api Quel nom de domaine utiliser, quel nom de domaine utiliser ** Pas besoin ** Modification de Cloudflare ALLOWED_ORIGINS Ou n'importe quelle configuration de nom de domaine (cette variable n'a de sens que lorsqu'elle est déployée séparément à l'avant-arrière).

Condition préalable : Accès au nom de domaine Cloudflare

  1. Inscrivez votre compte Cloudflare en cliquant sur le panneau Add a domain Entrez votre nom de domaine (comme example.com Choisissez le package gratuit.
  2. Cloudflare scanne les enregistrements DNS existants et donne deux adresses de serveur NS à votre registre de domaine pour remplacer Nameserver par ces deux adresses.
  3. Attendre que l’état change Active (Généralement de quelques minutes à quelques heures), les DNS et les agents du nom de domaine sont gérés par le panneau Cloudflare.

Confirmer que le déploiement de base du côté Aivory est terminé : Déploiement de production de Docker Compose Le plan A a été adopté et le plan A a été adopté. Proxy inverse et HTTPS Installez Nginx sur la station source.

Programme A : Orange Cloud Agent

Étape 1 : Les enregistrements DNS ouvrent le nuage orange

Sur le panneau Cloudflare DNS → Records Ajouter (ou modifier) les enregistrements qui pointent vers la station source et Proxy statusétablies pour Proxied Les nuages orange :

TypeNameContentProxy status
AchatAdresse source IPv4Proxied (nuage orange)
AAAAchatAdresse IPv6 de la station source (si disponible)Proxied (nuage orange)

Après l’ouverture de l’orange, dig chat.example.com Il s’agit de Cloudflare Edge IP, où l’adresse réelle de la station source n’est plus exposée.

Pour mieux cacher les sources.

Le Cloud Orange permet simplement aux DNS de ne plus divulguer l’IP de la station source. Si vous souhaitez que le niveau du pare-feu de la station source ne reçoive que du trafic de retour provenant de Cloudflare, vous pouvez uniquement accéder au port 443 dans le réseau de retour officiellement annoncé par Cloudflare (https://www.cloudflare.com/ips/) dans le pare-feu (UFW / Cloud Security Group). Cette étape est optionnelle et n’affecte pas les fonctionnalités.

Étape 2 : Sélectionnez le mode de cryptage SSL/TLS

SSL/TLS → Overview Choisissez le mode de cryptage. Les trois modes diffèrent selon la section « Cloudflare à la source » :

ModèleUtilisation de CloudflareCloudflare → Station d’origineExigences de la sourceEst-il recommandé
FlexibleHTTPS** HTTP clairement **La station source n'a besoin que d'une surveillance de 80, pas de certificatSeuls les liens internes / fiables
FullHTTPSHTTPS, mais ** Pas de certificat scolaire **Certificat facultatif (incluant la signature)Utilisation transitoire
Full (strict)HTTPSHTTPS, ** Validité du certificat scolaire **Un vrai certificat de confiance** Recommandé**

** Recommandé complet (strict) ** Source de la station Proxy inverse et HTTPS Un certificat Let's Encrypt est disponible si vous ne voulez pas exécuter certbot. SSL/TLS → Origin Server L'émission d'un certificat Cloudflare Origin CA (valable jusqu'à 15 ans et seulement confié par Cloudflare) sur la station source Nginx est également conforme à la norme Full (strict).

** Les avantages et les inconvénients de Flexible avec HTTP uniquement **:

  • Avantages: Aivory prend en charge le déploiement explicite HTTP dans l'environnement de production (l'algorithme de signature de demande de l'application a un retour JS pur et ne dépend pas de l'API de cryptage du contexte sécurisé du navigateur). https:// La page est sécurisée, au contraire. **Évitez les restrictions du navigateur dans les déploiements HTTP purement textuels ** La station source n'a pas de certificat de configuration, c'est la voie la plus rapide pour le coût de fonctionnement du certificat zéro.
  • Inconvénients: Cloudflare à la station source Ce paragraphe est clair, n'importe quel réseau intermédiaire peut voir le contenu du trafic (y compris les identifiants de connexion et le contenu de la conversation). seulement si ce lien est fiable (comme le réseau interne, le réseau privé du fournisseur de nuage) est recommandé; Aller à la source de connexion de réseau public, assurez-vous de mettre à niveau à Full (strict).
Le mode flexible le plus courant : rediriger vers un cercle mort

Proxy inverse et HTTPS Par exemple, une configuration Nginx transforme les demandes de 80 ports en 301 vers HTTPS. Dans le mode flexible, Cloudflare utilise toujours la source HTTP et la station source 301 fois. https:// Dans Flexible, le port 80 de la station source doit servir directement à l'activité sans effectuer de saut HTTPS.

Les stations source Nginx dans le mode flexible (pure HTTP, conservant le traitement SSE et IP réel) :

server {
listen 80;
listen [::]:80;
server_name chat.example.com;

# 普通上传默认上限 50MB(MAX_UPLOAD_BYTES),留出余量
client_max_body_size 100m;

location / {
proxy_pass http://127.0.0.1:8787;

# SSE 流式输出
proxy_buffering off;
proxy_read_timeout 3600s;
proxy_http_version 1.1;
proxy_set_header Connection "";

# 真实客户端 IP(配合下一步的 real_ip 配置)
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
Combinaison Flexible + OAuth

Dans le mode flexible, le lien vers le site source est HTTP, si vous avez configuré un login OAuth, veuillez OAUTH_CALLBACK_BASE_URL apparemment à l’extérieur. https://chat.example.comÉviter que l’adresse soit retournée. http:// Synchroniser et enregistrer les adresses de référence https sur le côté du fournisseur OAuth. FAQ

Étape 3 : la station source Nginx récupère l'IP du visiteur réel

Cette étape ** Impossible de négliger ** Aivory compte le flux en fonction de la limite de maintenance IP du client, et juge que la règle est la suivante: la confiance est uniquement donnée lorsque la connexion directe est un réseau interne ou une adresse de retour. X-Forwarded-For / X-Real-IP (Prenez l'entrée non interne de la partie la plus droite), les titres sont ignorés en direct sur le réseau public.

Lorsque le Cloud Orange est activé, le bouton TCP que Nginx voit sur la station source est le nœud de bord de Cloudflare. Si ce nœud n’est pas restauré, l’IP « réel » de Nginx est le nœud IP de Cloudflare : les visiteurs du monde entier sont regroupés en quelques adresses de nœud Cloudflare, le nombre de limites de trafic partagées et un seul déclencheur de limites de trafic est associé à un grand nombre d’utilisateurs.

Cloudflare met en place les vrais IP des visiteurs CF-Connecting-IP Récupérer avec le module real_ip de Nginx : Nouveau /etc/nginx/conf.d/cloudflare-realip.conf Le contenu est le suivant :

# /etc/nginx/conf.d/cloudflare-realip.conf
# 信任的 Cloudflare 回源网段,官方列表:https://www.cloudflare.com/ips/
# IPv4
set_real_ip_from 173.245.48.0/20;
set_real_ip_from 103.21.244.0/22;
set_real_ip_from 103.22.200.0/22;
set_real_ip_from 103.31.4.0/22;
set_real_ip_from 141.101.64.0/18;
set_real_ip_from 108.162.192.0/18;
set_real_ip_from 190.93.240.0/20;
set_real_ip_from 188.114.96.0/20;
set_real_ip_from 197.234.240.0/22;
set_real_ip_from 198.41.128.0/17;
set_real_ip_from 162.158.0.0/15;
set_real_ip_from 104.16.0.0/13;
set_real_ip_from 104.24.0.0/14;
set_real_ip_from 172.64.0.0/13;
set_real_ip_from 131.0.72.0/22;

# IPv6
set_real_ip_from 2400:cb00::/32;
set_real_ip_from 2606:4700::/32;
set_real_ip_from 2803:f800::/32;
set_real_ip_from 2405:b500::/32;
set_real_ip_from 2405:8100::/32;
set_real_ip_from 2a06:98c0::/29;
set_real_ip_from 2c0f:f248::/32;

# 从 Cloudflare 注入的头里取访客真实 IP
real_ip_header CF-Connecting-IP;
sudo nginx -t
sudo systemctl reload nginx

La version principale de la distribution nginx.conf Définitivement contient include /etc/nginx/conf.d/*.conf; (dans les blocs HTTP), les fichiers ci-dessus s’appliquent automatiquement ; si votre distribution n’est pas disponible, placez ce contenu dans une configuration au niveau des blocs HTTP.

Le principe de fonctionnement est une chaîne de confiance complète:

  1. Le module real_ip est à l’écran. set_real_ip_from Dans la liste blanche, CF-Connecting-IP La valeur * est écrite $remote_addr * En ce moment $remote_addr C’est l’IP du visiteur.
  2. L’ancien serveur proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; Aucun changement n'est nécessaire, il ajoute l'IP réelle après la restauration X-Forwarded-For Transféré à l’app.
  3. L’appli est un outil d’exploitation (127.0.0.1:8787 Pour satisfaire aux conditions de « Réseau intérieur / Récupération », alors faites confiance à l'en-tête et prenez l'entrée non intérieure la plus droite, et obtenez exactement l'IP réelle du visiteur.

Vérification : visite du site après le rechargement, tail -f /var/log/nginx/access.log L’adresse IP de la source doit être votre propre IP de réseau public et non l’adresse d’un segment Cloudflare.

La liste du site va-t-elle changer ?

Cloudflare est stable depuis de nombreuses années, mais il est toujours recommandé de vérifier occasionnellement la liste des paires officielles.

{ curl -s https://www.cloudflare.com/ips-v4; echo; curl -s https://www.cloudflare.com/ips-v6; } \
| sed '/^$/d; s/^/set_real_ip_from /; s/$/;/'

Connexion longue SSE : ouvre la boîte, mais ne cache pas l'API

Les réponses d'AI d'Aivory sont diffusées via le streaming SSE (Server-Sent Events) sans WebSocket.La transmission de l'agent Cloudflare vers SSE est automatique pour deux raisons:

  • ** Des heures supplémentaires libres ** La connexion de proxy Cloudflare dure environ 100 secondes, tandis que le serveur Aivory émet un ping-card toutes les 15 secondes, la connexion ne sera jamais jugée vide, et les tâches de réponse longue et de recherche profonde ne seront pas interrompues. ** Pas besoin de configuration supplémentaire. **。
  • ** Le buzz ** Cloudflare ne cache pas les réponses qui n'entrent pas dans le cache, et le jeton atteint le navigateur en temps réel tant que la réponse de l'API n'est pas cache.

La seule garantie de Cloudflare est donc :** /api/* Pas de cache** (traitement de la règle du cache dans la section suivante). côté source de la station Nginx proxy_buffering off Le délai de lecture doit être maintenu, voir Proxy inverse et HTTPS

Règles du cache : API contourné, ressources statiques cachées

Cloudflare ne cache pas par défaut text/html En théorie, les réponses dynamiques avec des API peuvent fonctionner sans règles, mais les déclarations explicites peuvent empêcher l'ouverture ultérieure de règles globales telles que "Cache Everything". Caching → Cache Rules Deux règles sont établies :

règlesConditions de correspondancemouvementExpliquer
Le feu passe.URI Path starts with /api/Bypass cacheAssurez-vous que SSE ne cache jamais toutes les interfaces
Ressources statiquesURI Path starts with /assets/Eligible pour le cache, Edge TTL prolongé (par exemple 1 mois)Le nom du fichier produit est construit avec l'empreinte digitale du contenu, le contenu change de nom du fichier, le cache long est absolument sécurisé.

L’ordre des règles : l’API passe en avant (les règles du cache correspondent à l’ordre).

Téléchargement du panneau : à fermer et à ouvrir

InterrupteurPositionnementRecommandéCause
Rocket LoaderSpeed → Optimization** fermé**Il réarrange les scripts dans l'ordre de chargement, ce qui peut facilement blanchir l'écran ou entraîner des anomalies dans le SPA.
Always Use HTTPSSSL/TLS → Edge Certificates** Ouverture **Tous les http:// Visite à la frontière 301 https://
Auto MinifyPas besoin de traiterCette fonctionnalité a été téléchargée par Cloudflare et ne nécessite pas de recherche.
Compression de BrotliSpeedRestez à l’écoute (Open)Définitivement activé
HTTP/2 / HTTP/3NetworkRestez à l’écoute (Open)Définitivement activé
WebSocketsNetworkRien à voirLe flux Aivory passe à SSE et non à WebSocket, ce commutateur n'affecte pas l'ouverture et l'arrêt

Ouvrir le plafond de la demande et l’importation de sauvegarde

Cloudflare limite la taille des requêtes individuelles par paquet :

paquetsDemande de plafond
Free / Pro100MB
Business200MB
Enterprise500MB

Deux catégories de grandes requêtes d'Aivory :

scèneLimites de service par défautLes nuages d’orange sont touchés.
Documents/documentation générale (MAX_UPLOAD_BYTES)50MBNon affecté, le package gratuit peut être couvert
L'administrateur de sauvegarde d'importation (MAX_BACKUP_BYTES)20GiB** Il sera rejeté par Cloudflare. ** Tous les paquets ne suffisent pas.

Administrateur exécutif Importation de sauvegarde Lorsque l'archivage peut atteindre 20 GiB, vous devez contourner l'agent Cloudflare et choisir l'un d'eux:

  1. ** Connexion Internet (recommandée) ** Accès direct sur le serveur local ou en interne http://127.0.0.1:8787 L'importation exécutée de la console d'administration est entièrement exempte de limitations de volume pour Cloudflare et Nginx.
  2. ** Les nuages gris ** Créer un fichier DNS tel que direct.chat.example.com Le statut de proxy est DNS only (nuage grise), l'importation est effectuée directement sur la station source. La station source Nginx doit préparer un bloc de serveur pour le nom de domaine et client_max_body_size Transfert à21g ( Référence Proxy inverse et HTTPS Une partie de la requête).
Les sous-domaines de nuage gris exposent l'IP de la station source

Les enregistrements DNS only sont résolus directement à l’adresse réelle de la station source et entrent en conflit avec la cible de la « station source cachée ». Il est recommandé de supprimer le registre une fois l’importation terminée ou d’utiliser une solution de connexion interne dès le début.

Catégorie : Cloudflare Tunnel

Le tunnel à l'intérieur de la station cloudflared Processus ** Initiative à l’extérieur ** Connectez-vous au bord de Cloudflare et récupérez le trafic via le tunnel. Pour les situations où vous n'avez pas d'IP public (NAT à largeur de maison, serveur intranet) ou si vous ne voulez pas ouvrir un port d'entrée : le pare-feu peut complètement bloquer l'entrée, l'IP de la station source n'est pas naturellement exposée et n'a plus besoin de la station source Nginx et de certificats.

Étape 1 : Créer un tunnel dans le panneau

  1. Entrez dans le panneau Cloudflare. Zero Trust (La première utilisation nécessite une initialisation, le programme Free est disponible).
  2. Networks → Tunnels → Create a tunnel Choisir le type de connecteur Cloudflared Un nom (comme aivory)。
  3. La page suivante affiche une commande d'installation contenant une longue chaîne de jetons (eyJh... Il suffit de copier le token lui-même et de le transmettre au conteneur sous forme de variable environnementale.

Étape 2 : ajouter le service cloudflared à composer

deploy/docker-compose.prod.ymlservices Suppléments (et app Niveau équivalent :

cloudflared:
image: cloudflare/cloudflared:latest
restart: unless-stopped
command: tunnel run
environment:
TUNNEL_TOKEN: ${TUNNEL_TOKEN:?请在 .env 中设置 Cloudflare Tunnel token}
networks:
- internal
depends_on:
app:
condition: service_healthy

.env Adhérer à :

TUNNEL_TOKEN=eyJh...你的token...

Le point :

  • cloudflared Rejoignez le réseau privé existant internal, avec app Le conteneur est directement interconnecté et ne revient pas à l'hôte.
  • Le tunnel est une connexion de sortie pure. cloudflared Pas besoin de rien ports La cartographie .
  • app du service ports Peut-être à partir de l’avertissement. "80:8787" Resserrer pour "127.0.0.1:8787:8787" Toute la circulation du réseau public passe par le tunnel, et la connexion directe 8787 native est réservée exclusivement à l'administrateur pour l'importation de sauvegarde (voir ci-dessous).
docker compose -f docker-compose.prod.yml up -d
docker compose -f docker-compose.prod.yml logs -f cloudflared # 看到 Registered tunnel connection 即连通

Étape 3 : Configurer un nom d'hôte public (ingress)

Retour sur le tunnel. Public Hostname Page d’étiquette, ajouter :

champs
Subdomainchat
Domainexample.com
TypeHTTP
URLapp:8787

Introduction à la direction http://app:8787: cloudflaredapp Ensemble àinternal Réseau, directement en utilisant le nom de service. Une fois sauvegardé, Cloudflare crée automatiquement les enregistrements DNS Orange Cloud correspondants auxquels le navigateur accède https://chat.example.com Ouvrez Aivory.

IP réel et flux limité dans le mode Tunnel

Le mode Tunnel ne nécessite pas de Nginx, les liens IP réels s'établissent automatiquement : Cloudflare écrit les IP des visiteurs sur le bord X-Forwarded-ForCF-Connecting-IP, cloudflared ainsi transmis àapp; app A l’extrême droite, c’est cloudflared l'adresse du conteneur en ligne privée, qui remplit les conditions de confiance, et X-Forwarded-For L'entrée non intranet, c'est-à-dire l'IP réelle du visiteur, se trouve en haut à droite. Une fois le déploiement terminé, il est possible de vérifier une fois sur la liste de fin.

Importer des sauvegardes dans le mode Tunnel

Le trafic de tunnels traverse également le bord de Cloudflare, ** Le plafond de la demande correspond parfaitement aux nuages orange. ** (Free/Pro à partir de 100 Mo).L'importation de sauvegarde au niveau 20 GiB doit encore être contournée: avec la dernière étape 127.0.0.1:8787 Importer directement sur le serveur, c'est la raison pour laquelle compose recommande de conserver la cartographie du port.

Comparaison des deux programmes

DimensionsProgramme A : Orange Cloud AgentCatégorie : Cloudflare Tunnel
Réseau public IP/port ouvertOuverture au moins 443Pas besoin de passer par le port.
Composants de la sourceCertificat Nginx + (Full strict)Les conteneurs cloudflared
Certificat de fonctionnementLes stations source nécessitent un certificat authentique (certbot ou Origin CA)Non, les certificats de bord sont gérés par Cloudflare
Source cachéeOrange Cloud cache le DNS et recommande une liste blanche de pare-feuLes murs de sécurité naturels peuvent être complètement verrouillés.
Récupérer la vraie IPLe module Nginx real_ip est nécessaireInstallation automatique, pas besoin de configuration
Le flux SSENormale (15s de battement cardiaque couvrant le bord de l'excès de temps)Normal (à gauche)
Demande de plafondPar paquet CF (Free 100MB)Même
Importation de sauvegardeRéseau intérieur ou nuage gris.L’appareil directement 127.0.0.1:8787
DéfaillanceNginx, renouvellement de certificat et CFProcessus cloudflared et CF

Une phrase de suggestion: avoir un IP public et déjà exécuter Nginx, option A; nouveau déploiement, largeur de maison ou ne pas vouloir toucher le certificat, option B.

Fin de la liste de vérification

Tout se répète une fois terminé :

  • ** Modèle SSL/TLS ** La solution A est définie comme Full (strict) (ou acceptant explicitement Flexible et les liens de retour sont fiables); la solution B n'a pas besoin d'être configurée.
  • Always Use HTTPS Ouverture et visite. http://chat.example.com 301 à HTTPS.
  • Rocket Loader a été fermé.
  • Cache Rules: /api/* La règle de bypass cache existe et se trouve en première ligne.
  • ** OAuth Récupération ** (Si vous activez la connexion OAuth): OAUTH_CALLBACK_BASE_URL Construit à l’extérieur. https:// Les noms de domaine, les adresses de rappel du fournisseur OAuth ont été synchronisées et mises à jour. FAQ
  • ** SSE est normal. **: Envoyer un message et répondre à l'effet de la machine à écrire. Si la carte est éteinte après une longue période, vérifiez d'abord si la station source Nginx est omise. proxy_buffering off Vérifiez s’il existe des règles de sécurité. /api/*
  • ** Les limites de flux s'appliquent à l'IP réelle ** Solution A Affiche le log d'accès Nginx de la station source, la source doit être l'IP du réseau public du visiteur et non le segment Cloudflare; Solution B accède à deux réseaux différents (tels que le trafic mobile et le haut débit domestique) pour vérifier que le nombre de limites de trafic n'est pas affecté. Si vous trouvez que tous les utilisateurs partagent des limites de trafic, vérifiez la configuration real_ip ou X-Forwarded-Forà transmettre.
  • ** Réservation des entrées dans le canal ** L’accès à l’accès à l’internet est sécurisé (127.0.0.1:8787 Si vous connaissez les pratiques de sous-domaine du cloud gris, ne trouvez pas la limite maximale de 100 Mo lorsqu'il est nécessaire de récupérer les données.
  • ** Inspection de santé** (si l’on utilise une distribution externe) : le chemin de la racine GET / Le retour de 200 représente la survie.

L’idée générale en cas de panne : contournez d’abord la station source Cloudflare (native) curl http://127.0.0.1:8787/ Pour vérifier que l’application est normale, vérifiez la configuration du panneau Nginx et Cloudflare.