Comment configurer un proxy inverse pour protéger votre site des bots, des scanners et des parseurs : guide complet

Chaque jour, votre site est attaqué par des centaines de bots : certains volent des prix et du contenu, d'autres surchargent le serveur avec des requêtes, d'autres encore cherchent des vulnérabilités. Si vous possédez une boutique en ligne sur Wildberries ou Ozon, gérez des pages de destination pour des campagnes publicitaires sur Facebook Ads ou administrez des sites pour des clients — ce problème vous concerne directement. Un proxy inverse (reverse proxy) est la première ligne de défense que vous pouvez configurer sans connaissances techniques approfondies.

Qu'est-ce qu'un proxy inverse et en quoi diffère-t-il d'un proxy classique

La plupart des gens connaissent le proxy comme un outil pour changer d'adresse IP : vous vous connectez à un serveur proxy, et les sites voient son adresse au lieu de la vôtre. Cela s'appelle un proxy direct (forward proxy) — il protège l'utilisateur.

Un proxy inverse (reverse proxy) fonctionne de l'autre côté. Il se place devant votre serveur et reçoit toutes les requêtes entrantes à sa place. Le visiteur pense qu'il communique directement avec votre site — mais en réalité, il passe d'abord par le serveur proxy, qui vérifie la requête, filtre l'activité suspecte et ne transmet ensuite que le trafic légitime à votre serveur réel.

La principale différence avec un proxy classique est que votre véritable adresse IP de serveur reste cachée. Les attaquants et les bots ne savent pas où se trouve physiquement votre site — ils ne voient que l'adresse du proxy inverse. Cela, en soi, élimine une partie significative des attaques.

Pour les propriétaires de boutiques en ligne, les marketeurs et les arbitragistes qui gèrent des dizaines de pages de destination, c'est crucial : les concurrents ne pourront pas trouver votre véritable hébergement et l'attaquer directement, contournant ainsi la protection.

Pourquoi les bots et les scanners sont dangereux pour votre entreprise

De nombreux propriétaires de sites sous-estiment la menace des bots, la considérant comme un "problème technique". En réalité, cela entraîne des pertes directes pour l'entreprise. Examinons des scénarios concrets auxquels nos lecteurs sont confrontés.

Parsing des prix par les concurrents

Si vous vendez sur des places de marché ou gérez votre propre boutique en ligne, des concurrents peuvent lancer un parseur qui extrait vos prix toutes les 15-30 minutes et affiche automatiquement les leurs 1-2 % en dessous. Vous perdez des ventes sans comprendre pourquoi. Les bots parseurs surchargent également le serveur : des centaines de requêtes par minute ralentissent le site pour les vrais acheteurs, ce qui impacte directement la conversion.

Click fraud (fraude au clic)

Les arbitragistes et les marketeurs travaillant avec Facebook Ads et Google Ads sont régulièrement confrontés à des clics frauduleux. Les bots cliqueurs cliquent sur vos annonces, brûlant votre budget sans aucune conversion. Selon des études, jusqu'à 20-30 % du trafic publicitaire dans certaines niches provient de bots. Un proxy inverse avec les bonnes règles aide à identifier et à bloquer ces sources.

Scanners de vulnérabilités

Des scanners automatiques comme Shodan, Masscan et des centaines d'autres outils moins connus parcourent constamment Internet à la recherche de sites non protégés. Ils vérifient les versions obsolètes de CMS, les ports ouverts, les mots de passe par défaut. Si votre site est sur WordPress ou toute autre plateforme populaire, il est probablement déjà dans leurs bases de données. Sans protection, il ne s'agit que d'une question de temps avant qu'une vulnérabilité ne soit trouvée.

Attaques DDoS et surcharge du serveur

Des concurrents ou simplement des malveillants peuvent organiser une attaque qui mettra votre site hors ligne au moment le plus inopportun — par exemple, pendant une vente ou une campagne publicitaire active. Même un petit DDoS de quelques milliers de requêtes par seconde peut "faire tomber" un hébergement bon marché.

Comment un proxy inverse protège le site : mécanisme de fonctionnement

Un proxy inverse protège le site à plusieurs niveaux. Comprendre ces niveaux vous aidera à configurer correctement le système et à ne pas manquer des étapes importantes.

Niveau 1 — Masquage de l'IP réelle

Dès que vous dirigez le trafic via un proxy inverse, votre véritable adresse IP de serveur cesse d'être publique. Les bots et les attaquants ne peuvent pas accéder directement au serveur — ils se heurtent au proxy. Cela est particulièrement important pour la protection contre les DDoS : même si un attaquant connaît le domaine de votre site, il ne pourra pas attaquer le serveur en contournant la protection.

Niveau 2 — Analyse et filtrage des requêtes

Chaque requête entrante est vérifiée selon plusieurs paramètres : User-Agent (quel navigateur/bot effectue la requête), fréquence des requêtes depuis une seule IP, géolocalisation, modèles de comportement. Les bots, en général, effectuent des requêtes trop rapidement, utilisent des chaînes User-Agent non standard ou proviennent d'adresses IP connues de centres de données. Un proxy inverse sait tout cela suivre et bloquer.

Niveau 3 — Limitation de fréquence (rate limiting)

Une personne réelle ne peut pas parcourir 500 pages d'un site par minute. Un proxy inverse permet de définir des limites : par exemple, pas plus de 60 requêtes par minute depuis une seule IP. Si quelqu'un dépasse la limite, il reçoit un blocage temporaire ou un test CAPTCHA. Cela arrête efficacement la plupart des parseurs et des scanners sans nuire aux visiteurs ordinaires.

Niveau 4 — Mise en cache et réduction de la charge

Un proxy inverse met en cache le contenu statique (images, CSS, JavaScript) et le fournit directement, sans faire appel à votre serveur. Ainsi, même si des bots passent à travers les filtres, ils obtiennent des pages mises en cache — la charge sur le serveur réel est minimale. De plus, cela accélère le site pour les visiteurs réels, ce qui a un impact positif sur le SEO et la conversion.

Niveau 5 — Terminaison SSL/TLS

Un proxy inverse prend en charge le cryptage du trafic. Votre serveur fonctionne plus rapidement, car il ne dépense pas de ressources pour chiffrer chaque requête. Et les visiteurs voient une connexion sécurisée HTTPS — cela est important tant pour la confiance que pour le classement dans Google.

Aperçu des solutions : Cloudflare, Nginx, Caddy — que choisir

Il existe plusieurs solutions populaires pour organiser un proxy inverse. Le choix dépend de votre niveau technique, de votre budget et de l'ampleur de la tâche.

Pour la plupart des propriétaires de sites, des marketeurs et des arbitragistes qui ne souhaitent pas se plonger dans les réglages serveur, Cloudflare est le choix optimal. Le plan gratuit couvre 90 % des tâches de protection contre les bots et les scanners. C'est par là que nous commencerons notre guide étape par étape.

Configuration de Cloudflare en tant que proxy inverse : étape par étape

Cloudflare est un service cloud qui devient un proxy inverse pour votre site après un simple changement de serveurs DNS. Pas de programmation, pas d'accès au serveur — juste des réglages dans le navigateur.

Étape 1 — Inscription et ajout du site

Rendez-vous sur cloudflare.com et créez un compte. Après vous être connecté, cliquez sur le bouton "Add a Site" et entrez le domaine de votre site (par exemple, myshop.ru). Choisissez le plan gratuit Free — pour commencer, c'est plus que suffisant.

Cloudflare analysera automatiquement vos enregistrements DNS et affichera leur liste. Vérifiez que tous les enregistrements sont en place (généralement, il s'agit d'un enregistrement A avec l'IP du serveur et d'enregistrements MX pour le courrier). Cliquez sur "Continue".

Étape 2 — Changement des serveurs DNS chez le registraire de domaine

Cloudflare vous fournira deux adresses de serveur de noms — quelque chose comme alex.ns.cloudflare.com et diana.ns.cloudflare.com. Accédez au panneau de contrôle de votre registraire de domaine (RU-CENTER, Reg.ru, Namecheap, etc.) et remplacez les serveurs de noms actuels par ces deux adresses.

La mise à jour des DNS prend de 15 minutes à 48 heures. Une fois que tout est mis à jour, tout le trafic vers votre site commencera à passer par les serveurs de Cloudflare — le proxy inverse fonctionnera automatiquement.

Étape 3 — Activation du mode "Under Attack" si nécessaire

Dans le panneau Cloudflare, allez dans la section Security → Overview. Ici, vous voyez le niveau de protection (Security Level). Pour la plupart des sites, le niveau "Medium" est approprié. Si le site subit une attaque active, passez temporairement en "Under Attack Mode" : tous les visiteurs passeront par un test JS que les bots ne passent généralement pas.

Étape 4 — Configuration du mode Bot Fight

Allez dans Security → Bots. Activez le commutateur "Bot Fight Mode" — c'est une protection de base contre les bots automatiques, disponible gratuitement. Cloudflare identifie et bloque automatiquement le trafic des bots malveillants connus, en utilisant une base de données de milliards de requêtes.

Dans les plans payants (Pro et supérieurs), le Super Bot Fight Mode est disponible avec des réglages plus détaillés : vous pouvez configurer séparément le comportement pour les bots de recherche (Googlebot, Yandexbot doivent être autorisés !), pour les bots vérifiés (monitoring uptime) et pour les requêtes automatiques suspectes.

Étape 5 — Création de règles de pare-feu (Firewall Rules)

Allez dans Security → WAF → Firewall Rules et créez des règles selon vos besoins. Voici quelques exemples de règles à ajouter immédiatement :

Étape 6 — Configuration de la limitation de fréquence

Dans la section Security → WAF → Rate limiting rules, créez une règle de limitation de fréquence des requêtes. Par exemple : pas plus de 100 requêtes par minute depuis une seule adresse IP. Si la limite est dépassée — afficher un CAPTCHA ou bloquer temporairement. Cela arrête la plupart des parseurs qui essaient de collecter rapidement toutes les pages de votre site.

Configuration du proxy inverse Nginx : configuration de base

Si vous avez votre propre serveur VPS (par exemple, sur Timeweb, Selectel ou DigitalOcean), vous pouvez configurer Nginx comme proxy inverse. Cela donne plus de contrôle et de flexibilité, bien que cela nécessite des compétences de base en ligne de commande.

Schéma typique : vous avez un serveur principal avec une application (par exemple, une boutique en ligne sur le port 8080), et un serveur séparé ou le même serveur avec Nginx sur le port 80/443, qui reçoit tout le trafic et le transmet à l'application.

La configuration de base de Nginx en tant que proxy inverse avec protection contre les bots ressemble à ceci :

server {
    listen 80;
    server_name mysite.ru www.mysite.ru;

    # Redirection vers HTTPS
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;
    server_name mysite.ru www.mysite.ru;

    ssl_certificate /etc/letsencrypt/live/mysite.ru/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/mysite.ru/privkey.pem;

    # Blocage des User-Agent vides (bots sans UA)
    if ($http_user_agent = "") {
        return 403;
    }

    # Blocage des scanners connus par User-Agent
    if ($http_user_agent ~* (sqlmap|nikto|nmap|masscan|zgrab|python-requests)) {
        return 403;
    }

    # Limitation de fréquence — appliquer la zone de limitations
    limit_req zone=one burst=20 nodelay;

    # Transmission des requêtes au serveur réel
    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        # Masquer les informations sur le serveur réel
        proxy_hide_header X-Powered-By;
        proxy_hide_header Server;
    }
}

# Définition de la zone de limitation de fréquence (ajouter dans le bloc http)
# limit_req_zone $binary_remote_addr zone=one:10m rate=60r/m;

Faites attention à la directive proxy_hide_header — elle masque les en-têtes qui révèlent des informations sur votre serveur réel et votre CMS. Cela complique le travail des scanners de vulnérabilités : ils ne savent pas ce qu'ils cherchent exactement.

La zone limit_req_zone limite chaque adresse IP à 60 requêtes par minute. Le paramètre burst=20 permet des pics temporaires (un utilisateur réel peut rapidement ouvrir plusieurs pages), mais une charge élevée prolongée est bloquée.

Règles de blocage des bots et des scanners : checklist

Après la configuration de base du proxy inverse, utilisez cette checklist pour vous assurer que la protection est configurée de manière globale. Chaque point représente un vecteur d'attaque distinct qui doit être fermé.

✅ Protection de base (obligatoire pour tous)

• Le mode Bot Fight est activé dans Cloudflare (ou l'équivalent dans une autre solution)
• La limitation de fréquence est configurée : pas plus de 60-100 requêtes par minute depuis une seule IP
• Les requêtes avec un User-Agent vide sont bloquées
• Les scanners connus sont bloqués : sqlmap, nikto, nmap, masscan
• Les en-têtes Server et X-Powered-By sont masqués (nous ne montrons pas la version du serveur et du CMS)
• HTTPS est configuré, HTTP redirige automatiquement vers HTTPS
• L'IP réelle du serveur n'est pas exposée dans les bases de données publiques (Shodan, Censys)

✅ Protection avancée (pour les sites activement attaqués)

• Un honeypot est configuré — une page cachée que seuls les bots voient (les vrais utilisateurs n'y vont pas). Les IP ayant visité le honeypot sont automatiquement bloquées
• La vérification de l'intégrité du navigateur est activée (Browser Integrity Check dans Cloudflare)
• Un CAPTCHA est configuré pour le trafic suspect (pas pour tous — seulement pour les suspects)
• Géoblocage des pays d'où l'on n'attend pas de trafic légitime
• Surveillance des journaux : alertes configurées en cas d'augmentation soudaine des erreurs 403/429
• Blocage des plages d'IP des grands fournisseurs de cloud (AWS, Azure, GCP) — la plupart des bots fonctionnent depuis des clouds
• Un robots.txt est configuré avec des interdictions pour les bots agressifs

✅ Protection des pages spécifiques

• Page de connexion (/admin, /wp-admin, /login) — limitation stricte de fréquence (5-10 tentatives par minute) et authentification à deux facteurs
• Endpoints API — autorisation obligatoire via clé API ou token
• Pages de prix — vérifications supplémentaires pour les requêtes fréquentes (protection contre le parsing)
• Formulaire d'inscription/demande — CAPTCHA ou piège honeypot invisible pour les bots

Proxy pour le monitoring : comment vérifier la protection de votre site

Après avoir configuré un proxy inverse, il est important de s'assurer que la protection fonctionne correctement et ne bloque pas les vrais utilisateurs. C'est ici que les proxies classiques interviennent — vous devenez vous-même un "utilisateur externe" et vérifiez le comportement du site.

Pourquoi les marketeurs et les arbitragistes doivent vérifier leurs sites via un proxy

Imaginez la situation : vous avez configuré une protection contre les bots, activé un géoblocage, et soudain vous remarquez que la conversion a chuté. Il est possible que vous ayez accidentellement bloqué de vrais utilisateurs de certaines régions ou appareils. Vous pouvez vérifier cela en accédant au site via un proxy depuis différents pays et types de connexions.

Pour de telles tâches, les proxies mobiles sont idéaux — ils imitent une connexion depuis un véritable appareil mobile via un opérateur de télécommunications. Si vos règles de blocage laissent passer le trafic mobile correctement, cela signifie que les utilisateurs ordinaires avec des smartphones ne souffrent pas de la protection.

Scénarios pratiques de vérification

Scénario 1 — Vérification de la géo-accessibilité. Vous avez lancé une publicité sur Facebook Ads pour un public de plusieurs régions de France. Via un proxy avec une IP de Bordeaux, Lyon et Marseille, vérifiez que la page de destination s'ouvre correctement, ne montre pas de CAPTCHA et se charge rapidement.

Scénario 2 — Test de la limitation de fréquence. Ouvrez plusieurs onglets via un seul proxy et passez rapidement entre les pages. Si vous recevez un blocage en agissant normalement — le seuil est trop bas, il faut l'augmenter.

Scénario 3 — Vérification depuis différents types d'IP. Essayez d'accéder via un proxy de centre de données (imitation d'un bot/serveur) — si votre protection fonctionne, une telle requête devrait recevoir un CAPTCHA ou un blocage. Ensuite, accédez via un proxy résidentiel (imitation d'un utilisateur domestique ordinaire) — l'accès doit être libre.

Scénario 4 — Vérification par des concurrents. Si vous souhaitez vérifier à quel point il est difficile de parser votre site, essayez de le faire vous-même via un outil simple. Si le parseur reçoit un blocage après seulement 10-20 requêtes — la protection fonctionne. S'il collecte des données sans entrave — il faut renforcer les règles.

Surveillance de l'efficacité de la protection

Dans Cloudflare, allez dans la section Security → Overview — ici, vous voyez des graphiques des requêtes bloquées, des types de menaces et la géographie des attaques. Faites attention à :

• Une augmentation soudaine des requêtes bloquées — signe d'une attaque active ou d'un parsing
• Un pourcentage élevé de trafic provenant d'un seul pays — il peut être judicieux d'ajouter un géoblocage
• Augmentation des erreurs 403/429 dans les journaux — vérifiez si de vrais utilisateurs ne sont pas bloqués
• Requêtes régulières à /admin, /wp-login.php — tentatives de piratage, renforcez la protection de ces chemins

Conclusion : un proxy inverse n'est pas une option, mais une nécessité

Un proxy inverse ne se limite plus à être un outil pour les grandes entreprises. Aujourd'hui, même une petite boutique en ligne, une page de destination pour une campagne d'arbitrage ou un site d'agence SMM a besoin d'une protection de base contre les bots, les scanners et les parseurs de concurrents.

Les points clés de ce guide : Cloudflare est le moyen le plus rapide de commencer sans connaissances techniques, Nginx offre un contrôle maximal si vous avez votre propre serveur. Dans les deux cas, la protection de base peut être configurée en 30 à 60 minutes et couvre 80 à 90 % des menaces typiques. N'oubliez pas de vérifier que les bots utiles (Googlebot, Yandexbot) restent sur la liste blanche et que les vrais utilisateurs ne souffrent pas de règles trop agressives.

Un point particulier pour ceux qui utilisent des proxies dans leur travail : si vous vérifiez des campagnes publicitaires, surveillez des concurrents ou testez l'accessibilité de vos sites depuis différentes régions — pour ces tâches, les proxies résidentiels sont les mieux adaptés. Ils possèdent des adresses IP de véritables utilisateurs domestiques, ce qui leur permet de passer à travers la plupart des systèmes de protection comme des visiteurs ordinaires et de donner une image objective de ce que voit votre audience.