Problème Erreur 429 avec Reverse proxy

Hi, My Discourse is run with reverse proxy (NPM)

the discourse don’t it does not support the x-forwarded field and therefore shows me all the time the ip address of my reverse proxy when we look for example from which ip the user is registering etc …

I sniff the request on discourse and the X-forwarder is present but in access.log the IP view is the reverse proxy

I view on interne il necessary to change the configuration template or de configuration file nginx for Discourse (not nginx on NPM)

do you help me for this ? because the discourse activate de tempalte web.ratelimite and send most error 429

:frowning:
Thank you for you help

See How to set up Discourse on a server with existing Apache sites - sysadmin - Discourse Meta for an example of how to conduits) configure the internal nginx for your reverse proxy ip.

1 « J'aime »

J’ai aussi du mal avec ça.

J’ai un serveur Debian avec des vHosts Apache 2.4 et l’un de ces vHosts est le conteneur Docker Discourse. Sur Apache, mod_remoteip est activé (il n’y avait pas de mod_extract_forwarded), mais sans aucune option de configuration. La configuration du vHost est assez simple :

RequestHeader set X-Forwarded-Proto "https"
ProxyPreserveHost On
ProxyRequests Off
ProxyPass /.well-known !
ProxyPass / http://localhost:8083/
ProxyPassReverse / http://localhost:8083/

8083 est le port HTTP exposé du conteneur Docker Discourse.

C’est à peu près tout.

Je vois les différents visiteurs (par IP) dans les statistiques créées avec le fichier access.log d’Apache et, plus important encore, je vois aussi différentes dernières IP pour les utilisateurs (c’était une vérification simple pour moi). Il semble donc que les adresses IP des visiteurs soient exposées par le proxy Apache à Discourse. C’était déjà le cas sans mod_remoteip activé, que j’ai seulement activé il y a quelques jours.

Quoi qu’il en soit, j’ai de nouveau des problèmes maintenant. Un crawler ou une attaque DoS s’exécute sur notre serveur avec une IPv4 de Cracovie, Pologne. Il génère beaucoup d’erreurs 429. Cela me convient, mais tous les autres visiteurs reçoivent également ces erreurs.

Est-ce aussi le cas ? Donc, lorsque la limite de connexion est atteinte, tout le monde reçoit une erreur ? Ou par IP ?

Manque-t-il quelque chose dans ma configuration ou puis-je l’améliorer/l’optimiser ? Nous avons eu des problèmes avec Claudebot il y a quelques semaines et aussi il y a quelques jours, donc peut-être que la limite doit être augmentée un peu.

Merci et salutations,
Roi

Avez-vous ajouté les éléments pour voir que l’adresse IP distante arrive sur Discourse ou tous les utilisateurs semblent-ils provenir du proxy ?

Recherchez x-forwarded-for

Ehm… :see_no_evil: J’ai oublié la partie Nginx (Discourse). :see_no_evil: Merci ! :slight_smile:

J’ai juste modifié app.yml et relancé une reconstruction du conteneur. Le bot est revenu presque instantanément après le redémarrage du conteneur. Je ne vois pas d’erreurs 429 pour le moment. J’espère que cela restera ainsi pour les utilisateurs « normaux ».

C’est ça le truc… Quand je vérifie la page d’administration des utilisateurs, je voyais toujours des entrées différentes pour le « dernier IP ». Donc, d’une manière ou d’une autre, Discourse voyait les vrais IP des utilisateurs, même sans mod_remoteip et sans le changement de configuration Nginx. :man_shrugging:

Quoi qu’il en soit, je suis curieux de voir si le changement de configuration Nginx a apporté la solution à ce problème ! :slight_smile:

1 « J'aime »