Pour servir via l'IP, perso, je te conseillerai plutôt de faire un nouveau vhost, qui réponde uniquement "Allez sur lexpage.net", voire avec une redirection js.
Oui, ça peut paraitre crade une redirection js, je l'assume, mais 99% du traffic que tu chopera via l'IP seront des bots, et une bonne partie de ceux-là seront des bad bots. Les rares humains sauront cliquer (ou auront un js qui les redirigera, et shuis même pas certain que ce soit une bonne idée). Les "bons" bots de crawling verront qu'il y a pas de contenu et un lien vers www.lexpage . Les mauvais, ce sont ceux qui tenteront /phpmyadmin, /admin, /wp-admin, et tous les liens possibles et connus de failles possibles, avec des mélanges de GET et de POST : ceux-là, il vaut mieux qu'ils se choppent une 404 minimaliste (juste le header 404) qui va te coûter très peu de ressource plutôt que la 404 dynamique de la vraie lexpage.

Ton blocage par IP : ah ouais, du coup tu fais pas dans la dentelle, là : 15 connexions par 15 secondes pour une IP sur le http, ça peut arriver ultra vite, surtout dans le cas de réseaux d'entreprises. Le filtre http de fail2ban, tu déclare des "alertes" (genre tout accès à /admin/), et seulement là il analyse voir le nombre de connexions, et bannit en conséquence pendant 10 minutes. Ce qui protège (un peu) contre les attaques en bruteforce.


EDIT :
50 connexions simultanées, il est un brin à la ramasse (et encore), mais ça reste très honnête vu le coût mensuel. En toute sincérité, c'était la puissance de cette offre qui me faisait le plus peur, et ça semble très honnête pour du 2€/mois !

J'ai édité les 2 avant-derniers messages pour y mettre mes réponses

Je comprends pour l'accès via l'IP. Actuellement, c'est un 301 qui est renvoyé, je pense pas qu'un bot va suivre ça. Cela dit, je vais revenir sur ma première idée et ne pas autoriser l'accès au site via l'IP. Il n'y a aucune raison d'accéder au site via l'IP... !

Pour le blocage par IP, j'ai 5 "NEW" par 60 secondes pour SSH (j'ai souvent 2 terminaux + 1 ou 2 SFTP ^^), et 20 "NEW" par 10 secondes pour HTTP. Vu le trafic sur Lexpage, je doute que quelqu'un soit raisonnablement bloqué par 20 requêtes en 10 secondes, même si y a 3 gars derrière le même NAT qui essaye d'y accéder (ce sont les nouvelles connexions TCP, donc tout navigateur qui supporte le keep-alive n'aura aucun souci avec cette limite). Par contre, c'est une limite par IP mais sur le même serveur : le navigateur ne partage pas sa connexion TCP entre www.lexpage.net et analytics.lexpage.net, par exemple. Il faudra que je veille à ne pas abuser de sous-domaines en lien avec Lexpage sans revoir à la hausse cette limite.

On dirait que Lexpage s'acclimate bien à son nouveau petit nid douillet. Le serveur tourne sans souci, j'ai lancé quelques "ab" en tâche de fond pendant qu'on était 5 sur le site pour simuler 10 personnes qui s'acharnent, et je n'ai vu pratiquement aucune différence (à part le minichat qui met 1 à 2 secondes au lieu d'être instantané), ce qui est plutôt bon signe

Je vais finaliser la migration depuis l'hébergement web, et régler les derniers petits détails histoire de clore ça

Je vois dans les logs du serveur des tentatives d'accès à une page qui n'existe plus (/divers/v3/go.php)... pratiquement chaque nuit, avec une requête par seconde/par deux secondes (je pense que le firewall rejette le reste, sinon ce serait bien davantage). La plus longue était le 25, de 1h à 11h environ. La dernière date de cette nuit, de +/- 1h jusque +/- 7h...

Je pense que je vais mettre une règle spécifique dans Nginx pour renvoyer un 404 sur /divers, qui n'existe plus maintenant, parce qu'à chaque fois, ça fait appel à la machinerie Django, ce qui n'est pas terrible

Deux petits bugs corrigés aujourd'hui, postés ici pour la postérité :
- Le premier concerne le reset du password. Jusqu'à la version 1.5, Django utilise un codage sur 38 bits au lieu de 64, et évidemment, lors de la migration, j'en ai profité pour passer à la 1.6 sans penser à changer certaines choses...
- Le deuxième concerne la prévisualisation (forum, billets, etc.) qui générait une erreur lorsque le contenu était trop grand. En gros, l'appel JS pour prévisualiser un message génère une URL trop longue (>4096) que Gunicorn rejette systématiquement pour une histoire de DDOS. J'ai modifié la limite de sorte à monter au double, ce qui correspond déjà à de très larges contenus.

Unicorn ?
Comme celle-là?

Petite indisponibilité du site durant 15 minutes.

Le Lexpage ne répondait pas, et les tentatives de connexion par SSH non plus. La KVM d'OVH m'a permis d'entrer mon login, mais jamais le password. J'ai donc demandé un reboot du serveur, mais c'est resté coincé à 21% ! Connexion SSH toujours pas faisable, mais le serveur Nginx répondait (!??) un 504 (timeout sur la gateway, j'imagine la "jonction" avec Python via Gunicorn).

Au bout de 5 grosses minutes, c'est revenu. J'ai fouillé les logs, mais je n'ai rien vu. Curieux.

Tu as un retour de la charge de la machine ? Apparemment, même avec un regain d'activité (j'ai déjà vu 7-8 online ! oO), il tient encore super bien la charge. C'est quoi comme proc, tu le sais (cat /proc/cpuinfo) ? De mémoire tu avais 1Go de RAM, non ?

Et tout ça à moins cher que ton mutualisé ? Y'avait vraiment pas à hésiter (sous réserve d'avoir les compétences œuf corse).

TchouApparemment, même avec un regain d'activité (j'ai déjà vu 7-8 online ! oO)

J'ose espérer que le site parviendrait à tenir un peu plus que ça

Selon l'outil de monitoring d'OVH pour ses VPS, on a jamais dépassé les 8% d'usage du CPU sur la granularité proposée (ça doit être de l'ordre de la minute). Le load average affiché par htop est de 0.08, ce qui confirme cela

Niveau RAM, on tourne à environ 50%, c'est plutôt constant : 30% de 18 à 3h du matin, et là y a quelques crons et surtout logrotate (+ backup sur Dropbox) qui se mettent en route et ça monte à 57-58%, pour diminuer progressivement jusque midi (je suppose que c'est un buffer).

Pour le CPU, aucune idée si c'est "partagé" ou "pré-alloué". Je pense, vu qu'on doit être nombreux sur ces "super serveurs pleins de VM" que c'est du partagé, donc à priori avec une large limite tant que quelqu'un ne foire pas tout A défaut d'être pertinent, voilà ce que cpuinfo ressort :

processor : 0
vendor_id : AuthenticAMD
cpu family : 21
model : 16
model name : AMD Opteron(tm) Processor 6386 SE
stepping : 0
cpu MHz : 2799.999
cache size : 2048 KB

Reste à voir combien on est réellement là-dessus... OVH annonce "un vCore" par client. Sans plus d'info. Cela dit, le VPS est "performant" pour mon usage. La lecture/écriture disque est un vrai régal (on dirait du SSD derrière, ce qui n'est pas impossible d'ailleurs, à défaut d'un raid classique) et les performances en charge sont très honnêtes pour un seul "vCore" (je pense par exemple à la pré-génération d'une carte Minecraft qui s'effectue pratiquement aussi vite que sur ma machine de jeu !).

Pour le prix, ça coûte le même prix que le mutu d'entrée de gamme (mais celui-là contient les mails et le domaine en plus), mais moins cher (même en comptant le domaine et les mails) que le "Pro" qui équipait Lexpage v3.