Bloquer une adresse IP avec .htaccess

Trouver l'adresse à bloquer

Avant d'écrire une règle, relevez l'adresse exacte dans le journal d'accès du site, au moment du problème : formulaire inondé, page appelée des centaines de fois, tentatives de connexion. Le journal montre l'adresse telle que le serveur la voit, et c'est elle que la règle compare. Un pic soudain dans les statistiques du site aide à situer le moment. Pour ouvrir les journaux dans Plesk, voir Logs Apache : lire les journaux de son site.

La règle à écrire

La syntaxe est celle d'Apache 2.4, décrite dans la documentation des modules mod_authz_host et mod_authz_core, relue le 15 octobre 2026.

1. Ouvrez le gestionnaire de fichiers de Plesk, puis le dossier httpdocs du site.
2. Téléchargez une copie du fichier .htaccess avant de le modifier.
3. Ajoutez ce bloc tout en haut du fichier, au-dessus du bloc de WordPress s'il y en a un, en remplaçant l'adresse d'exemple :

<RequireAll>
    Require all granted
    Require not ip 203.0.113.45
</RequireAll>

4. Enregistrez, puis rechargez une page du site depuis votre propre connexion : elle doit s'afficher normalement.
5. Si une erreur 500 apparaît, remettez la copie et vérifiez la saisie.

Le not ne peut jamais autoriser seul une requête, d'après la documentation d'Apache : il exclut, et il lui faut une ligne qui autorise. C'est le rôle de Require all granted, et c'est pourquoi les deux lignes vont ensemble dans <RequireAll>.

Plusieurs adresses, une plage

Require not ip accepte plusieurs adresses sur la même ligne, et les formes que décrit la documentation d'Apache :

Les adresses de ces exemples sont réservées à la documentation : elles ne désignent personne.

Faire l'inverse : n'autoriser que vous

Pour un dossier d'administration ou une préproduction, il est souvent plus sûr de n'ouvrir l'accès qu'à vos propres adresses. Dans le .htaccess du dossier concerné :

Require ip 203.0.113.45

Tout autre visiteur reçoit une erreur 403. Cette protection suppose une adresse fixe chez votre fournisseur d'accès : si elle change, vous vous bloquez vous-même, et il faut corriger le fichier par le gestionnaire de fichiers de Plesk. Pour un accès à plusieurs personnes, la protection par mot de passe convient mieux : voir Protéger un dossier par mot de passe.

Si votre site passe par Cloudflare

Quand le domaine passe par le proxy de Cloudflare, les requêtes arrivent depuis les serveurs de Cloudflare, et l'adresse du visiteur voyage dans un en-tête, CF-Connecting-IP, comme le décrit la documentation de Cloudflare. Sans réglage côté serveur, Apache ne verrait que l'adresse de Cloudflare, ce contre quoi sa propre documentation met en garde pour tout proxy.

Nos serveurs font ce réglage : nginx rétablit l'adresse réelle à partir de cet en-tête, pour les seules plages de Cloudflare, et la transmet à Apache. Une règle Require not ip vise donc bien le visiteur, que votre site passe par Cloudflare ou non.

Bloquer l'adresse dans les règles de sécurité de Cloudflare reste possible, en amont : la requête n'atteint alors plus du tout le serveur. Voir Qu'est-ce que Cloudflare.

Les limites du blocage par adresse

Un blocage par adresse arrête une source stable : un concurrent qui aspire vos pages, un serveur mal réglé qui appelle la même adresse en boucle. Contre des robots qui changent d'adresse à chaque essai, il est inutile, comme l'explique Attaque par force brute. Sur WordPress, si les requêtes visent xmlrpc.php, fermer ce fichier vaut mieux qu'une liste d'adresses : voir XML-RPC sur WordPress.

Une partie du travail est déjà faite en amont sur nos hébergements : le pare-feu applicatif refuse les requêtes qui ressemblent à une attaque, et fail2ban bannit un temps les adresses qui échouent plusieurs fois à se connecter. Une liste d'adresses bloquées tenue à la main grossit vite : relisez-la de temps en temps et retirez ce qui ne sert plus.

Questions fréquentes