le point.https://docs.nginx.com/nginx/admin-guide/web-server/reverse-proxy/Je ne sais pas.
si je comprends correctement (c'est loin d'être sûr) ça a l'air de dire que tu dois redéfinir la variable host (valeur $proxy_host par défaut) au moyen de la directive proxy_set_header?
mais je raconte peut-être de grosses bêtises.
Vu la diversité des réponses trouvées, et mon inexpérience sur cette utilisation, je me dis que quelqu’un de la liste qui a déjà rencontré le problème ou a su configurer correctement ce reverse proxy saura mettre immédiatement le doigt sur
Je lis dans la doc :
location /some/path/ {
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_pass http://localhost:8000;
}
Il suffit donc dans ce cas d'interroger la valeur de "X-Real-IP".
Bonjour,
C’est très discuté dans les forums.
Cette page que tu indiques semble confirmer que c’est assez flou (les
‘ X-*’ inventés pour faire des corrections rustines).
Je sais qu’un reverse proxy peut réécrire les entêtes pour déjà faire passer l’adresse IP du client qu’il fait disparaître si on le laisse faire.
[...]Le 19 août 2023 à 18:58, Michel Verdier <mv524@free.fr> a écrit :
Le problème que tu auras si ton proxy est transparent c'est que ton appli >> va répondre vers l'IP du client et ça cassera la connexion.
Si je comprends bien, il suffirait que le reverse proxy ajoute une
entête avec l’adresse IP du client qui sera lue par le serveur web,
qui répondra ensuite à la requêtes au reverse proxy qui routera au
client.
C’est ça ?
Par exemple, nginx, apache et d'autres vont pouvoir se baser surServeur web Apache. https ou WebDAV.
l'en-tête créé, mais si tu veux t'adresser à des service comme exim,
mailman ou transmission, ça risque d'être impossible.
Pas de serveur de messagerie.
Donc positionne un entête comme on t'a suggéré avec proxy_set_header et >> teste cet entête sur l'apache qui traite la requête. Tu n'as pas besoin >> de plus à priori non ?Non. Le serveur a juste besoin de lire l’adresse IP du client et de retourner (au reverse proxy, pour routage) la réponse à la requête.
Le 20 août 2023 RogerT a écrit :
Donc positionne un entête comme on t'a suggéré avec proxy_set_header et >>> teste cet entête sur l'apache qui traite la requête. Tu n'as pas besoin >>> de plus à priori non ?Non. Le serveur a juste besoin de lire l’adresse IP du client et de
retourner (au reverse proxy, pour routage) la réponse à la requête.
C'est exactement ce qu'on (moi et d'autres) t'explique. Donc pourquoi
dis-tu "non" ? Explique-nous pourquoi tu ne veux pas faire cette
solution ?
Je pense qu'il dit "non" à "Tu n'as pas besoin de plus à priori non ?"Oui, exactement !
:)
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 156:37:30 |
| Calls: | 10,384 |
| Calls today: | 1 |
| Files: | 14,056 |
| Messages: | 6,416,471 |